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

Passing Java complex types to server from SOAP::Lite

Expand Messages
  • Tim Wood
    I have a J2EE-based server that has an interface to be used by a Perl component via SOAP::Lite. The Java interface is defined thus: public FrammisID
    Message 1 of 4 , Dec 15, 2003
    • 0 Attachment
      I have a J2EE-based server that has an interface to be used by a Perl component via SOAP::Lite. The Java interface is defined thus:
      public FrammisID
      reserveObject(WhoseitID wsID,
      WhatsitID wtID,
      ThingInfo thingInfo)
      throws RemoteException;

      I have traced the SOAP that gets transferred between the server and a Java test client. I would like advice on whether I should try to get the SOAP messages exchanged with the Perl client as close as possible to the Java client SOAP. The "complex" types here are pretty simple--they each contain a single string member (a consequence of my design and using JAX-RPC to generate the remote call parameter classes).

      The Perl and Java sides do talk, unsuccessfully. At this point I am running into problems trying to get SOAP::Lite to tack on the right namespace string to each argument exchanged (to address the current fault). I tried creating a Perl package for each of the complex types, but that only confuses the server.

      On top of all this, I am an experienced programmer, but new to Perl.

      The reason I want complex types is for distributed type-safety. But I also want this done. Is it practical to reach this theoretical ideal, or should I just redefine the types to Java primitives (String, basically), so that SOAP::Lite can handle them easier? This interface will not be exposed outside my network for some time, so I can control observance of the contract in source without relying on strong typing.

      Thanks in advance.
      TW
    • Byrne Reese
      I would suggest you create some handy constructor methods for each complex type. This is a temporary solution until wsdl2perl is released - at which point this
      Message 2 of 4 , Dec 20, 2003
      • 0 Attachment
        I would suggest you create some handy constructor methods for each complex
        type. This is a temporary solution until wsdl2perl is released - at which
        point this will all be done for you automagically.

        For the time being, take a look at this server I wrote that uses a similar
        utility function. This is actually a part way implementation of the WSI
        interoperability demo written in Perl. Oooooh aaaaaah. This will be fully
        implemented soon enough. In any event, the createItem method helps me to
        construct a complex type of type catalog.

        As a general rule, try and make your Perl's SOAP look like the SOAP
        generated by your Java client. When 0.65 is released, this should be a lot
        easier.

        package ISupplier;
        use strict;
        use vars qw(@ISA @EXPORT @EXPORT_OK);
        @ISA = qw(Exporter SOAP::Server::Parameters); # to get envelope

        #
        sub createItem {
        my ($num,$name,$unit,$price) = @_;
        return SOAP::Data->type('wsisup:Product')
        ->name('item' => \SOAP::Data->value(
        SOAP::Data->name('itemNumber' => $num)->type('xsd:string'),
        SOAP::Data->name('itemName' => $name),
        SOAP::Data->name('unitOfMeasure' => $unit),
        SOAP::Data->name('unitPrice' => $price)->type('xsd:decimal')
        ));
        }

        sub getCatalog {
        my $self = shift;
        my $envelope = pop;
        my $req_hdr = $envelope->match(SOAP::SOM::header)->dataof;
        my @res_hdrs;
        foreach my $h ( $req_hdr->value ) {
        foreach my $name (keys %$h) {
        push( @res_hdrs, bless
        $envelope->match(SOAP::SOM::header."/$name")-
        >dataof, "SOAP::Header" );
        }
        }


        > I have a J2EE-based server that has an interface to be used by a Perl
        > component via SOAP::Lite. The Java interface is defined thus:
        > public FrammisID
        > reserveObject(WhoseitID wsID,
        > WhatsitID wtID,
        > ThingInfo thingInfo)
        > throws RemoteException;
        >
        > I have traced the SOAP that gets transferred between the server and a Java
        > test client. I would like advice on whether I should try to get the SOAP
        > messages exchanged with the Perl client as close as possible to the Java
        > client SOAP. The "complex" types here are pretty simple--they
        > each contain a single string member (a consequence of my design and using
        > JAX-RPC to generate the remote call parameter classes).
        >
        > The Perl and Java sides do talk, unsuccessfully. At this point I am
        > running into problems trying to get SOAP::Lite to tack on the right
        > namespace string to each argument exchanged (to address the current
        > fault). I tried creating a Perl package for each of the complex types,
        > but that only confuses the server.
        >
        > On top of all this, I am an experienced programmer, but new to Perl.
        >
        > The reason I want complex types is for distributed type-safety. But I
        > also want this done. Is it practical to reach this theoretical ideal, or
        > should I just redefine the types to Java primitives (String, basically),
        > so that SOAP::Lite can handle them easier? This interface will not be
        > exposed outside my network for some time, so I can control observance of
        > the contract in source without relying on strong typing.
        >
        > Thanks in advance.
        > TW
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > Yahoo! Groups Sponsor
        >
        >
        > ADVERTISEMENT
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > 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 :/
      • Tim Wood
        ... Byrne, Sorry for the delay in replying, and thanks for the info. It will take me a bit to fully apprehend it; the framework seems to be shifting a bit.
        Message 3 of 4 , Dec 23, 2003
        • 0 Attachment
          At 09:53 AM 12/20/03, you wrote:
          >I would suggest you create some handy constructor methods for each complex
          >type. This is a temporary solution until wsdl2perl is released - at which
          >point this will all be done for you automagically.

          Byrne,
          Sorry for the delay in replying, and thanks for the info. It will take me a bit to fully apprehend it; the framework seems to be shifting a bit. By "handy constructor[s]", I assume you mean in Perl. I'm still figuring out how to define the Perl object to have named members that the SOAP serializer can then translate into the right SOAP doc. It seems a nub of the problem is that the Java side wants to be told what data goes into what Java class member, but Perl doesn't have named class members per se. Or maybe it's not that strict; I don't have a handle on the true requirements each side has on the SOAP messages.

          Thanks,
          Tim
        • Byrne Reese
          By a constructor in this sense, I don t mean one in the Java sense. The idea is that you have somekind of subroutine that can construct a simple SOAP::Data
          Message 4 of 4 , Dec 26, 2003
          • 0 Attachment
            By a constructor in this sense, I don't mean one in the Java sense. The
            idea is that you have somekind of subroutine that can construct a simple
            SOAP::Data object ad return it to the caller. It just makes code a little
            simpler and easier to read is all. :)

            But Java will work, but you have to construct complex types manually - for
            the very reason you specified - Perl doesn't have named object parameters
            per se - and thus it is difficult for Perl to know how to serialize the
            Object without a little help from a custom serializer - which is not that
            trivial to write. It took me a long time how to figure it out when working
            on wsdl2perl.

            There are plennty of code samples on majordojo.com/soaplite that will
            instruct you on creating complex types - I encourage you to take a look.

            > At 09:53 AM 12/20/03, you wrote:
            >>I would suggest you create some handy constructor methods for each
            >> complex
            >>type. This is a temporary solution until wsdl2perl is released - at which
            >>point this will all be done for you automagically.
            >
            > Byrne,
            > Sorry for the delay in replying, and thanks for the info. It will take me
            > a bit to fully apprehend it; the framework seems to be shifting a bit. By
            > "handy constructor[s]", I assume you mean in Perl. I'm still figuring out
            > how to define the Perl object to have named members that the SOAP
            > serializer can then translate into the right SOAP doc. It seems a nub of
            > the problem is that the Java side wants to be told what data goes into
            > what Java class member, but Perl doesn't have named class members per se.
            > Or maybe it's not that strict; I don't have a handle on the true
            > requirements each side has on the SOAP messages.
            >
            > Thanks,
            > Tim
            >
            >


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