All the Perl that's Practical to Extract and Report

geoff's SOAP challenge

geoff on 2003-01-08T18:23:22

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.

Call call = new Call();

gnat on 2003-01-09T00:25:31

Yeah, and remember--Perl's confusing because it lets you have two variables named the same thing!

--Nat

Still awful writing Java then..

TeeJay on 2003-01-10T12:06:47

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 where there are tools to generate tedious code skeletons, dozens of suited trained chimps to churn hundreds of lines of code and applications that only provide a java API.

object by reference

momo on 2003-01-15T04:10:19

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.

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...

Re:object by reference

geoff on 2003-01-15T17:50:24

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:

<SOAP-ENV:Header><namesp3:My__Class xmlns:namesp3="http://namespaces.soaplite.com/header" xsi:type="namesp2:My__Class"><_new xsi:type="xsd:string">bar</_new></namesp3:My__Class></SOAP-ENV:Header><SOAP-ENV: Body><namesp4:methodResponse xmlns:namesp4="http://my.server.com/My/Class"><s-gensym7 xsi:type="xsd:string">new: </s-gensym7><s-gensym9 xsi:type="xsd:string">bar</s-gensym9><s-gensym11 xsi:type="xsd:string">, method: beer</s-gensym11></namesp4:methodResponse></SOAP-ENV:Body>