Loading ...
Sorry, an error occurred while loading the content.
 

Re: [soaplite] Re: new to soap, cant seem to get it right

Expand Messages
  • Tim Wood
    ... SOAPbox: There seems to be a meta-problem with SOAP::Lite that s keeping from being as useful as it could be. Basically I and others are encountering fog
    Message 1 of 6 , Dec 30, 2003
      At 01:27 PM 12/30/03, opus23k wrote:
      >OK so I got some useful information from Jonathan:
      >---------
      >Take a look at http://soapenv.org/article.pl?
      >sid=02/02/11/1740229&mode=thread
      >
      >Also, see Byrne Reese's website.
      >http://majordojo.com/soaplite/
      >---------
      >
      >These sites have helped but I'm still having some trouble getting
      >this right.
      >
      >So you can see the XML I'm trying to generate...

      SOAPbox: There seems to be a meta-problem with SOAP::Lite that's keeping from being as useful as it could be. Basically I and others are encountering fog where there should be a clear semantic model of what SOAP::Lite APIs have what effect on which SOAP messages. Clearly SOAP::Lite is a powerful package, but without a tutorial doc, or at very least a Javadoc-style API spec, it's very difficult to know how to use the package to get a desired result.

      The fact that we have to work at the level of SOAP message text and reading the SOAP::Lite code in order to guess what to do is a red flag. The possible highest priority for SOAP::Lite development is not more cool features but a comprehensive usage guide that covers major distributed programming patterns. Byrne's site has several Perls which need to be edited and collected into a volume. Ideally, one should be able to design and implement a Web service (with components in different languages/frameworks) without having to view SOAP messages or the SOAP::Lite code. The sooner SOAP becomes a hidden implementation detail, the more productive we'll all be.

      Now back to your regularly scheduled hacking.

      TW
    • Byrne Reese
      I could not agree with you more Tim. I have considered documentation to be a real short-coming since I started using SOAP::Lite. Luckily Randy J. Ray, the
      Message 2 of 6 , Jan 4, 2004
        I could not agree with you more Tim.

        I have considered documentation to be a real short-coming since I
        started using SOAP::Lite. Luckily Randy J. Ray, the author of
        the "Programming Web Services with Perl" book from Oreilly, has
        volunteered (with permission from Oreilly of course) to reproduce a
        large part of the aforementioned book in Perl POD format. It will not
        be a carbon copy of the book, but will take the API documentation a
        quantum-leap forward.

        The sooner we can get a digital copy of that book, the sooner I can
        start integrating it. I will ping Randy again to check his status on
        this very important deliverable.

        --- In soaplite@yahoogroups.com, Tim Wood <timwood0@p...> wrote:
        > At 01:27 PM 12/30/03, opus23k wrote:
        > >OK so I got some useful information from Jonathan:
        > >---------
        > >Take a look at http://soapenv.org/article.pl?
        > >sid=02/02/11/1740229&mode=thread
        > >
        > >Also, see Byrne Reese's website.
        > >http://majordojo.com/soaplite/
        > >---------
        > >
        > >These sites have helped but I'm still having some trouble getting
        > >this right.
        > >
        > >So you can see the XML I'm trying to generate...
        >
        > SOAPbox: There seems to be a meta-problem with SOAP::Lite that's
        keeping from being as useful as it could be. Basically I and others
        are encountering fog where there should be a clear semantic model of
        what SOAP::Lite APIs have what effect on which SOAP messages.
        Clearly SOAP::Lite is a powerful package, but without a tutorial doc,
        or at very least a Javadoc-style API spec, it's very difficult to
        know how to use the package to get a desired result.
        >
        > The fact that we have to work at the level of SOAP message text and
        reading the SOAP::Lite code in order to guess what to do is a red
        flag. The possible highest priority for SOAP::Lite development is
        not more cool features but a comprehensive usage guide that covers
        major distributed programming patterns. Byrne's site has several
        Perls which need to be edited and collected into a volume. Ideally,
        one should be able to design and implement a Web service (with
        components in different languages/frameworks) without having to view
        SOAP messages or the SOAP::Lite code. The sooner SOAP becomes a
        hidden implementation detail, the more productive we'll all be.
        >
        > Now back to your regularly scheduled hacking.
        >
        > TW
      • jpeyser
        Here are some methods that will help to generate the desired XML. $soap - uri( urn:schemas-xmlsoap-org:soap:vl ) - on_action(sub { return
        Message 3 of 6 , Jan 5, 2004
          Here are some methods that will help to generate the desired XML.

          $soap
          ->uri('urn:schemas-xmlsoap-org:soap:vl')
          ->on_action(sub { return 'urn:schemas-xmlsoap-org:soap:vl' })
          ->proxy('https://www.mywebsite.com/secure/SOAP.asp')
          -> maptype({`elig' => 'www.mywebsite.com/secure/'})
          -> autotype(0)
          -> envprefix('SOAP')

          However, there are a number of issues.

          First, there are predefined schemas in SOAP::Lite that are placed in
          the envelope; urn:schemas-xmlsoap-org:v1 is not one of them. So,
          there is no way to put it in the envelope without hacking (See
          SOAP::Constants)

          Second, there is no reason to put it in the envelope as it will be
          the default namespace for the method.

          <namesp1:Batch xmlns:namesp1="urn:schemas-xmlsoap-
          org:soap:vl">

          Third, I have encountered ASP SOAP servers that do not like namespace
          prefixes. The above line would have to be generated as

          < Batch xmlns="urn:schemas-xmlsoap-org:soap:vl">

          This can be accomplished by redefining SOAP::Serializer::gen_ns (THIS
          IS A HACK)

          BEGIN {
          # no warnings 'redefine';
          local($^W) = 0;
          *SOAP::Serializer::gen_ns = sub {};
          }

          However, prefixes in SOAP::Lite are an important part of namespace
          mapping as can be seen from the next issue. Suppressing the prefixes
          will interfere with some mappings.

          Lastly, the method maptype will add the namespace definition to the
          envelope, provided that it is referenced in the XML. There is no
          prefix `elig' for any method or element.

          Jonathan

          --- In soaplite@yahoogroups.com, "opus23k" <nihal@e...> wrote:
          >
          > So you can see the XML I'm trying to generate at the bottom of this
          > message, but here's as close as I can get to that:
          >
          > <?xml version="1.0" encoding="UTF-8"?>
          > <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-
          > instance" xmlns:SOAP-
          ENC="http://schemas.xmlsoap.org/soap/encoding/"
          > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
          > xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP-
          > ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
          > <SOAP-ENV:Body>
          > <namesp1:Batch xmlns:namesp1="urn:schemas-xmlsoap-org:soap:vl">
          > <Transaction>
          > <MultipleRequestFlag xsi:type="xsd:string"/>
          > </Transaction>
          > <Transaction>
        • Byrne Reese
          In the upcoming release of SOAP::Lite, one will be able to programmatically turn namespace prefixing on/off. .NET for example wants default namespaces to be
          Message 4 of 6 , Jan 6, 2004
            In the upcoming release of SOAP::Lite, one will be able to
            programmatically turn namespace prefixing on/off. .NET for example wants
            default namespaces to be used, as opposed to prefixes. In any event, this
            capability is forthcoming.

            >
            >
            >
            >
            > Here are some methods that will help to generate the desired XML.
            >
            > $soap
            > -
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            > To visit your group on the web, go
            > to:http://groups.yahoo.com/group/soaplite/
            > To unsubscribe from this group, send an email
            > to:soaplite-unsubscribe@yahoogroups.com
            > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            >
            >
            >
            >
            >
            >
            >


            ^byrne :/
          Your message has been successfully submitted and would be delivered to recipients shortly.