Andrew,
I spent nearly a week trying to get an Apache server and MS client to work
using WSDL with complex parameter types. It worked fine with native types.
I'm sure there is a way to make it work (I probably didn't wave the dead
chicken over it long enough or say the right incantation), but it just
seemed like too much effort to me. I followed the Microsoft instructions to
the letter (based on their help file) and it still did not work.
I understand your point about hiding the names of the parameters from the
client. But to me, this is a small price to pay to avoid the need for the
behemoth of WSDL...
-Ed
-----Original Message-----
From: Andrew Burke [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 05, 2001 2:46 PM
To: [EMAIL PROTECTED]
Subject: RE: usage of custom classes in requests, WSDL issue
Ed-
I am interested in WSDL files because of an interest in "Web Services".
The WSDL file is a definition of a sites services, generally provided
via SOAP over HTTP (redundant, perhaps). And if I have a WSDL of
a site which will provide, say, stock quotes, I would like to
access those services. And it sure would be nice if all the information
I need to interact with that service were in the WSDL file.
That is almost true: the WSDL file can contain all the definitions of the
extra classes used (via the schema section), the functions/methods
available,
the arguments those functions take, and how those functions can be called.
BUT: there is no standardized way to bind the clients data classes to the
services data classes; the QName information isn't there. To quote the an
Apache SOAP FAQ: "Although not required by the SOAP specification, the
Apache
library requires that all XML Elements be namespace qualified via the QName
utility class. You can use (almost) anything for the QName." Sounds pretty
unstandardized to me.
Caveats: I have a very limited understanding of how things work and should
work, and I wouldn't be surprised if I'm just being stooopid... Thanks in
advance for any corrections.
andrew burke
-----Original Message-----
From: Ed Keen [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 05, 2001 11:42 AM
To: '[EMAIL PROTECTED]'
Subject: RE: usage of custom classes in requests, WSDL issue
Andrew,
Since you are using the Apache library (Java) on the client side, why do
you need to worry about WSDL? That is only required for Microsoft clients
using the high-level api.
The lowest level point of interface has to be the parameter names
themselves. Otherwise, how does the server know how to deserialize them?
So I see no way around this particular dilemma. If the mapping changes
(ie., if the QName changes), then yes all clients would need to change also.
This is one reason why you wouldn't want to do that! ;-)
-Ed
-----Original Message-----
From: Andrew Burke [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 05, 2001 12:33 PM
To: [EMAIL PROTECTED]
Subject: RE: usage of custom classes in requests, WSDL issue
As I see it, this is definitely a problem. First, as you noted, there
is the problem of the distribution of the custom classes. But isn't there
also the issue of how those classes are registered for the serialization?
Here is an example of some Apache SOAP code, which, as I understand things,
essentially defines the mapping between the client class and the server
class:
SMR = new SOAPMappingRegistry();
BeanSerialer = new BeanSerializer();
SMR.mapTypes(Constants.NS_URI_SOAP_ENC,
new QName("urn:MutualFundService","Date"), <----------- line of
interest
com.webgain.Services.MutualFund.Date.class, BeanSerialer,
BeanSerialer);
Again, as I understand things, the definition of the QName MUST match that
used on the server side. However, the two parts of the QName (namespace URI
and local part) are not defined in the WSDL file (PLEASE SOMEONE, CORRECT ME
IF I'M WRONG!). This information is only available in the deployment
descriptor
or in the server source.
So, if the QName used to register the class or the class itself changes, the
clients must be changed. This is not very cool, and certainly would lead one
to simplify all arguments to/from, as I see things.
andrew burke
-----Original Message-----
From: Ed Keen [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 05, 2001 7:42 AM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: usage of custom classes in requests
I would like feedback on the whether or not any of you are using custom
classes in your soap calls. While it is definitely convenient on the Apache
server side (with its serializers & deserializers), it places an extra
burden on the client, because now they must have these custom classes on
their side too. For win32 clients, this becomes an even more difficult
task. Our company would probably wind up writing a DLL that would contain
the analog of our custom classes for Windows. So, whenever the interface
for these classes changes (say we add a new required field), we would have
to redistribute the client classes. This could become a distribution
nightmare.
I am wondering if it would be less trouble to just have the clients send all
their data as separate parameters (which could make for a long parameter
list, I know) to some proxy-type servlet on the server-side which would
intercept the soap call, package that data into our custom classes, and send
the request on its way. It's more work on the server-side, but it would
avoid the need to distribute these custom serailizable client classes.
Does any of that make sense? What are the rest of you doing in regards to
this? Please don't tell me to use WSDL. Been there. Tried that.
Thanks,
Ed
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
