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