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

Server implementation: stubmaker vs. roll-your-own ?

Expand Messages
  • napc_kai
    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
    Message 1 of 4 , Feb 8, 2006
    • 0 Attachment
      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
    • 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 2 of 4 , Feb 9, 2006
      • 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 3 of 4 , Feb 9, 2006
        • 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 4 of 4 , Feb 9, 2006
          • 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.