----- Original Message -----
Sent: Tuesday, August 21, 2001 6:34
PM
Subject: RE: SOAP usage in the real
world
Hi,
I also have similar requirements... and I am please to say I
am having some degree of success with complex data exchange between .NET and
Apache SOAP 2.2. At the moment I use only document literal encoding in my
SOAP envelope, as my serialiser at the Java end doesn't support
SOAP.
In my current solution both client and server share the same
class definitions via an XML Schema. At the Java end I generate Java
classes/beans using Castor XML. At the client end I generate the C#/VB
classes using .Net's WSDL.EXE utility (I embed my XML Schema in the WSDL
file). This tool also creates a soap client proxy class with the appropriate
methods. All of this means that I get to use type safe methods and with
complex parameter types.
Andy.
-----Original Message-----
From:
David Wall [mailto:[EMAIL PROTECTED]]
Sent: 21 August 2001 16:30
To:
[EMAIL PROTECTED]
Subject: SOAP usage in the
real world
I like the concept around SOAP, but I'm wondering if there
are any "real
world" uses of it for web services
beyond perhaps the intranet. If so, how
are
people handling:
1) Interoperabliity. Seems like Apache SOAP server
don't work all that well
with most of the MSFT .NET
toolkits, especially for APIs needed or more than
simple tests.
2) Service description. WSDL seems like the way things
are going to
describe services to potential
customers, but Apache SOAP doesn't have plans
to
implement it, and Axis seems still a long way from production with
the
features currently in Apache SOAP. How are
people letting others know about
the format of
complex data objects, potentially with attachments, etc.?
3) Object/class sharing. Does anybody provide
end-users with the Java
classes that they use on the
server to return or accept complex data
objects? If so, did you create special "data only" Java classes
for use
with SOAP, since I can't imagine wanting to
share the true object classes
because they probably
have huge dependencies/references to other project
classes that you may not want to share, have internal logic data
elements
that you wouldn't normally share (i.e. the
so-called 'transient' fields that
may exist, like
'lastLoginTime' or what have you), additional fields that
you might share via the XML but are perhaps computed in your class
logic
(i.e. a 'total' field or a 'timestamp' that
you might want to return as the
Java long value, but
also expressed as String date/time according to the
caller's timezone), have processing logic that won't make sense
except on
the server (i.e. 'saveData' or methods
that might interact with other parts
of the your
system), etc. It seems like having to create a separate data
only class hierarchy for use with SOAP's XML marshallers is
perhaps overly
nasty.
What are people doing with this? We have created our
XML APIs around SOAP,
and they tended to work okay
in an all-Apache SOAP world, but things got
much
nastier once the caller was a .NET VB or COM object, and it was hard
to
describe the service's method+parameters for
complex objects (objects with
many data elements,
optional fields, embedded lists/arrays, references to
other potentially complex objects), and we did need a separate "data
object"
that expressed our objects in a more
portable format (i.e.
java.sql.Timestamp was shown
as both a long and a String defined in GMT).
Thanks for any advice on what successful, complext
implementations are doing
with respect to such
issues,
David
Yozons Inc. -
Secure Delivery and E-Signatures for everyone
www.yozons.com
