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

Re: [soaplite] Server implementation: stubmaker vs. roll-your-own ?

Expand Messages
  • Eric Bridger
    I m no expert but I believe you have this backwards. A WSDL is published by a SOAP server and tells a SOAP client how to connect, what methods are available,
    Message 1 of 4 , Feb 9 6:13 AM
    • 0 Attachment
      I'm no expert but I believe you have this backwards.

      A WSDL is published by a SOAP server and tells a SOAP client how to
      connect, what methods are available, what the paramters are, what should
      be returned, etc. The module produced by stubmaker.pl can be used to
      create a client.

      So the short answer is to roll your own server as you've done.'

      >Here though I need to
      > add the complex data types which are choking during
      > deserialization.

      Do you mean the incoming paramters or the data objects you are returning?

      Either way the answer is the same. Make use of SOAP::SOM and SOAP::Data to
      parse and construct complex objects.
      See- How to nest XML elements using SOAP::Lite at
      http://www.majordojo.com/archives/2003_04.html

      Eric


      napc_kai said:
      > all-
      >
      > hoping for some advice here.
      > I need to create a server to respond to a 3rd party client.
      > They have provided the WSDL file, and I have generated
      > a module using stubmaker.pl, but this is where I am stuck.
      > For a server do you define the actual sub function in that
      > module that are defined in the %methods hash, and they
      > are subsequently called when the incoming SOAP message
      > is dispatched ? It wasn't clear to me from what I've read
      > if this stub module is meant to be used when implementing
      > a server.
      >
      > After many hours of puzzlement and frustration I created
      > my own package that implements each function and is
      > successfully called by the client. Here though I need to
      > add the complex data types which are choking during
      > deserialization.
      >
      > So, from a server standpoint what is the best approach:
      > Using the module created by stubmaker.pl or just creating
      > your own package ?
      >
      > a nudge in the right direction would be much appreciated.
      >
      > thanks,
      >
      > -kai
      >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
    • Kai McBride
      Hi Eric, ... That matches my understanding too. I was put in an odd position because the vendor I m working with has hard coded the SOAP calls into their
      Message 2 of 4 , Feb 9 6:27 AM
      • 0 Attachment
        Hi Eric,

        > I'm no expert but I believe you have this backwards.
        >
        > A WSDL is published by a SOAP server and tells a SOAP client how to
        > connect, what methods are available, what the paramters are, what
        > should
        > be returned, etc. The module produced by stubmaker.pl can be used to
        > create a client.

        That matches my understanding too. I was put in an odd position because
        the vendor I'm working with has hard coded the SOAP calls into their
        client.
        They supply a WSDL file, but it is more for reference- i.e. they
        don't read
        it in and change their behavior based on its values (that took
        several days
        of emails to determine).

        > So the short answer is to roll your own server as you've done.'

        great, thank you. That saves me a lot of time and headaches.

        >
        >> Here though I need to
        >> add the complex data types which are choking during
        >> deserialization.
        >
        > Do you mean the incoming paramters or the data objects you are
        > returning?
        >
        > Either way the answer is the same. Make use of SOAP::SOM and
        > SOAP::Data to
        > parse and construct complex objects.
        > See- How to nest XML elements using SOAP::Lite at
        > http://www.majordojo.com/archives/2003_04.html

        Incoming parameters, they pass a couple of complex types.
        Thanks for the pointers !

        -kai
      • Eric Bridger
        Have not played with this much but to access the parameter as a SOM object on the server side I v done this: # this is needed for full access to SOAP::SOM use
        Message 3 of 4 , Feb 9 7:51 AM
        • 0 Attachment
          Have not played with this much but to access the parameter as a SOM object
          on the server side I'v done this:

          # this is needed for full access to SOAP::SOM
          use vars qw(@ISA);
          @ISA = qw(SOAP::Server::Parameters);

          sub DataSubmission {
          my $class = shift;
          my $som = pop;
          .....

          Eric


          Kai McBride said:
          > Hi Eric,
          >
          >> I'm no expert but I believe you have this backwards.
          >>
          >> A WSDL is published by a SOAP server and tells a SOAP client how to
          >> connect, what methods are available, what the paramters are, what
          >> should
          >> be returned, etc. The module produced by stubmaker.pl can be used to
          >> create a client.
          >
          > That matches my understanding too. I was put in an odd position because
          > the vendor I'm working with has hard coded the SOAP calls into their
          > client.
          > They supply a WSDL file, but it is more for reference- i.e. they
          > don't read
          > it in and change their behavior based on its values (that took
          > several days
          > of emails to determine).
          >
          >> So the short answer is to roll your own server as you've done.'
          >
          > great, thank you. That saves me a lot of time and headaches.
          >
          >>
          >>> Here though I need to
          >>> add the complex data types which are choking during
          >>> deserialization.
          >>
          >> Do you mean the incoming paramters or the data objects you are
          >> returning?
          >>
          >> Either way the answer is the same. Make use of SOAP::SOM and
          >> SOAP::Data to
          >> parse and construct complex objects.
          >> See- How to nest XML elements using SOAP::Lite at
          >> http://www.majordojo.com/archives/2003_04.html
          >
          > Incoming parameters, they pass a couple of complex types.
          > Thanks for the pointers !
          >
          > -kai
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.