Hi Ed,
I agree. When I wrote my service using custom classes and realized that how
clients from other galaxies could have the custom classes on hand. I changed
all i/o arguments to parameter: name/value. It's long and tedious, but it's
more versatile, and best of all, it works.
Thanks,
trang
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> list-help: <mailto:[EMAIL PROTECTED]>
> list-unsubscribe: <mailto:[EMAIL PROTECTED]>
> list-post: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> From: Ed Keen <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: usage of custom classes in requests
> Date: Tue, 5 Jun 2001 09:41:48 -0500
> MIME-Version: 1.0
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
>
> 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]
Trang K Duong
[EMAIL PROTECTED]
650-604-3989 (P) 650-604-2238 (F)
ELORET - Thermosciences Institute
NASA Ames Research Center
M/S 258-1
Moffett Field, CA 94035-1000
http://www.eloret.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
