Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

geoff (2013)

geoff
  reversethis-{gro ... om} {ta} {ffoeg}
http://www.modperlcookbook.org/

see http://www.modperlcookbook.org/~geoff/ [modperlcookbook.org] for personal information, links to presentations, GPG key, and so on.

Journal of geoff (2013)

Wednesday January 08, 2003
01:23 PM

geoff's SOAP challenge

[ #9844 ]
I'm starting to think that SOAP interoperability is simply a myth.

I have a fairly simple Perl class structure that I'd like to offer to the Oracle/Java-heads as a SOAP API. of course, they no nothing about SOAP, so I'm left with the task of prototyping their Java interface for them. why anybody would program in a language where

Call call = new Call();

actually means something, I'll never understand, but ok, I decided to give it a whirl.

anyone who has enjoyed the beauty of SOAP::Lite knows just how easy is to open up Perl classes via Apache::SOAP, and writing a Perl client is just as simple. have you ever tried to write a standalone Java client to access those classes? it's freaking insane. according to the SOAP::Lite mailing list, people ask for this alot and the answer is always something like "you need to write the java serializer and $otherstuff yourself." fine - if somebody shows me an example of exactly what it takes, including all of the fine details that I need as a non-Java programmer. the best I've been able to do are a few complex examples in Programming Web Services with SOAP, which shows calling a Perl method that returns a blessed hash. however, the example is within a long, complex application and doesn't show calling another method that accesses the stuff within the hash. (yes, I managed to get that running. Java truly sucks.)

I just can't believe that our community hasn't come up with a useful example that we can use to advocate Perl as the preferred backend for a SOAP API.

so, I'd like to issue an open challenge. if you have the ability, write a Java interface for this Perl class:

package My::Class;

sub new {
 my ($class, $newarg) = @_;
 return bless { _new => $newarg }, $class;
}

sub method {
 my ($self, $methodarg) = @_;
 return "new: ", $self->{_new}, ", method: $methodarg";
}
1;


then make it publically available with detailed instructions (all those silly java files, where they go, which xml.apache.org libraries to install, what CLASSPATH should look like, etc). the end result should be a Java interface that performs identically to this SOAP::Lite interface (namely, print "new: bar, method: drink"

use SOAP::Lite
 +autodispatch =>
 uri => 'http://my.server.com/My/Class',
 proxy => 'http://my.server.com/soap';

my $o = My::Class->new('bar');
print $o->method('drink');


if that's not possible, I really don't see any reason to even think about SOAP again.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Yeah, and remember--Perl's confusing because it lets you have two variables named the same thing!

    --Nat

  • in 2001 I wrote a client/server application in perl and C for my Degree. Later in the year I tried to replace the GTK/C application with a Java client.

    In short after 2 weeks I gave up. The URL Class didn't support any protocols other than FTP and HTTP , I had to convert between dozens of different objects, cast variables, and jump through hoops to do the same as a simple 5 line perl script.

    Unless there is a ready-build shrink-wrapped component Java connectivity is unnacceptable. The only use for Java is

    --

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;
  • I'm no expert, but it looks to me like the reason this doesn't work for Java or Python is because object-by-reference is explictly not part of SOAP: link [w3.org].

    The fact that SOAP::Lite provides a proprietary OBR mechanism is nice but certainly not something you should hold against other vendors for not implementing. Someone correct me if I'm wrong...

    • yeah, you may be right. chromatic thought it might not be part of the spec either, and maybe you're both right.

      however, because SOAP::Lite to SOAP::Lite does work (and work very well, I find it hard to believe that Java (or Python, or Ruby, or whatever) cannot be coerced into understanding SOAP::Lite objects.

      maybe it's just a matter of writing a java class that implements a serializer specific to understanding SOAP::Lite. after all, the contents of the envelope certainly look straightforward enough: