The higher level of abstraction is true, but it's amazing that when sending
complex data structures, SOAP interoperability (often between .NET and Axis,
though others use many other SOAP implementations) can add an extra layer of
confusion as well as abstraction. It's often easier for typical developers
(not SOAP experts) to create some XML and do an HTTP POST of it and look for
the XML response since this is all very straightforward, but life gets more
complex with SOAP. In fact, I think this is why the WS-I Basic Profile was
created was to get rid of some of the complexity by specifying a more simple
profile and ignoring more complex things that tend to make interoperability
harder.
Adding two numbers, as a dumb example, with just XML and HTTP POST might
look as simple as creating a String with the value:
<add>
<number>10</number>
<number>20</number>
</add>
POST this and get back:
<result>30</result>
Just looking at the structure and simple POST semantics makes it very easy
to see what this is doing, and programming it seems trivial too. But as
soon as I say we'll use .NET or PocketSOAP on the client and Axis on the
server, and you get users who program in C++, Perl or C# who are trying to
talk to your Java code, and issues do arise.
Sometimes abstraction is good, and I think you'll see SOAP come to life more
as it's made truly SIMPLE again (it got far too complex, and the fear is
that big businesses will muck it more to make it "enterprise ready").
Interoperability is a real issue. Managing changes to WSDL's messaging
structures add complexity. Perhaps the Basic Profile will result in easier
to integrate SOAP systems, but that remains to be seen as vendors comply
with that profile and then we see what really goes on.
I think when you get into SOAP headers and "exposing a standard java object
as a web service," you are already going into a more complex land that may
simply not be needed, and when you rely on SOAP headers, interoperability
seems to get even worse. XML Schemas, namespaces and the like continue to
create problems for interoperability. First we started doing RPC style (it
was an advancement over XML-RPC after all), but now that code is already
considered "legacy SOAP" and we should instead be doing doc/literal.
Anyway, I do agree that the auto-marshalling routines and such are very
powerful, assuming your "standard java object" is really written with SOAP
in mind (so that it follows proper bean routines and typically doesn't have
"extra stuff" -- you almost need these objects to be "data objects" with
very simply get/set routines to avoid sending more than is necessary with
the auto-marshal routines). But we often write our classes with so-called
convenience methods, and if these follow javabeans naming conventions,
you'll often get a single attribute being sent multiple times, and not what
you'd like. For example:
public int getStatus() { return status; }
public boolean isStatusOkay { return getStatus() == Bean.OKAY; }
public boolean isStatusFailed { return !isStatusOkay(); }
Those last two are purely convenience routines, but because they follow bean
semantics, the marshal routines will often create XML with 3 data elements,
even though only the 'int' status needs to be sent. Anyway, I do think SOAP
is the way to go for the future, but I've run into more interoperability
issues than I'd like to think about, including just significant hassles
going from Apache SOAP to Axis. Despite it's age, SOAP is still pretty much
the bleeding edge.
David
----- Original Message -----
From: "Mike Perham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 25, 2003 2:26 PM
Subject: RE: what is advantage of document based APIs over HTTP post method?
> Why should you use servlets when you can write directly to a socket?
> Why use XML when you can write a binary file?
>
> It's a higher level abstraction. What you are doing is ok for simple
> stuff but try processing SOAP headers. Try exposing a standard java
> object as a web service. You can't do it without a lot of effort but
> Axis can.
>
> -----Original Message-----
> From: Jinghua Gu [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 25, 2003 3:44 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: what is advantage of document based APIs over HTTP post method?
>
>
> Hi All,
>
> For document based Soap APIs, we use Soap engine to pass XML document
> over wire then get response back to the client, which can be achieved
> by
> HTTP
> POST method as well. The difference is the latter doesn't use AXIS
> engine. If we
> are only interested HTTP protocol, AXIS engine is extra layer to the
> applications.
> Can you enlighten me what advantage the document based APIs have over
>
> HTTP POST
> method?
>
> Thanks,
> Emily
>
