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]
Re: usage of custom classes in requests
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]
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]
Re: usage of custom classes in requests
How about using either an XML string or an XML Element as the input parameter. This way the client programs do not have to worry about the custom classes. What I did was to use an XML Element as the input parameter to the SOAP service. And on the server, extract the values from the Element into custom classes. The client only needs to know the structure of the XML element and you don't need to worry about distributing the custom classes. Any thoughts? Sanjesh Trang K. Duong wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
