Craig, I have read most of the book entitled "Understanding Soap" by Scribner and Striver and I still don't understand the regular SOAP encoding. I understand the structure of the soap envelope but there seems to be a disconnect between the method call and the actual encoding of that method call into a soap envelope and then the uncoding of the soap envelope back into the method call on the server. Do you have any examples of this process that I may help to clear up the disconnect.
Thanks, Bryan -----Original Message----- From: Wilkins, Craig [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 4:41 PM To: '[EMAIL PROTECTED]' Subject: RE: xml schemas? What data types are the parameters to the methods? If they are just a set of strings, I advise you not to use the BeanSerializer, as that would require that your client either use the BeanSerializer or know how to encode/decode the SOAP body in such a way that the BeanSerializer knows how to deserialize at the server. If your clients are not using Apache SOAP, then using the BeanSerializer is a lot of work for them. The BeanSerializer works great if you have two or more java-only applications that need to share/pass java objects to each other in a distributed environment and your security team won't let you use RMI. Use regular SOAP encoding if you are passing a set of strings or any other simple types. Arrays of Strings work well too. When parameters become more complex (Objects that contain other objects, etc.), I prefer literal XML encoding. The downside to literal XML encoding is to find SOAP implementations that support it. There are a lot of SOAP implementations that are available for many different platforms. I got literal XML working with Apache SOAP and MSSoap, but had trouble with SOAP Lite and I think was related to a bug. If anyone out there has gotten this working for real, please let me know. In terms of learning more about WSDL, I recently read a white paper @ http://www.systinet.com/techres/intro.html It mostly talks about the larger subject of web services, but also drills down into what WSDL is. Good Luck. Craig -----Original Message----- From: Bryan Field [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 10:05 PM To: [EMAIL PROTECTED] Subject: RE: xml schemas? Craig, My inputs are not that complex. The methods are basically to create records in database tables, like createBusiness, createListing, etc... I am creating essentially beans to represent the data needed to create each of the objects. I am using the Apache BeanSerializer class provided with Soap to serialize the beans into xml. I know that WSDL is used to describe web services but I haven't worked with it before. What are your thoughts given this additional information. Thanks in advance, Bryan -----Original Message----- From: Wilkins, Craig [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 1:55 PM To: '[EMAIL PROTECTED]' Subject: RE: xml schemas? How complex are your inputs/outputs to these methods? The best thing that you could do is to create a WSDL file that describes all of your services, inputs, outputs, bindings, etc. for the client. The quick and easy way would be to provide a list of services and there inputs/outputs. However, if the input and output parameters are of a complex type, then you are going to need to provide much more information. I personally think that complex types are best handled by passing literal xml, and if you do this, then you are going to have to provide schema. Good Luck. -----Original Message----- From: Bryan Field [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 7:50 PM To: [EMAIL PROTECTED] Subject: xml schemas? I am trying to implement a soap service that has 20 or so methods. I have defined the data that is needed to invoke each of these methods. I am doing the server implementation and another party is doing the client side implementation. Do I need to create a schema for each of my commands in order for them to code the client side of soap? Thanks in advance, Bryan Field Senior Consultant T4CG (703) 729-4990 ext. 228 (main) (703) 862-5849 (cell) (703) 832-0364 (fax) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001
