Just thought I'd jot down some notes about how we approached this, and maybe get some feedback, discussion going...
Requirements: Consume SOAP services (from an AXIS server) in Javascript on Windows. The javascript should have no browser dependencies, i.e. you should be able to run it from cscript. The javascript should deal with objects and services, not bodies and headers. The javascript objects should map as closely as possible to the Java Beans used by the Axis service. There are various javascript to SOAP implementations out there, but the requirement to deal with objects and services narrowed the field. This requirement meant that we had to have a set of COM objects for Javascript to manipulate. We were looking for a way generate COM stubs, or at least automate the process to avoid writing all of these stubs by hand. There were 3 kinds of COM objects required: - one COM object for each JavaBean - one COM object for each Soap Service - one COM object for each Mapper (Serializer/Deserializer). MS SoapToolkit v3 beta allows for 'Generic Mappers' which allows one to skip having to code the Mapper COM objects. Cape Studio will generate the Bean COM objects and the Service COM objects. The service COM objects use the low-level API internally which is OK. But the generated classes have dependencies such that they only work with a Cape Clear server. Thus they don't interoperate. And anyhow it would be nice not to introduce a 3rd tech package! So until I get around to writing WSDL2VB, the COM Beans and the COM Services need to be written by hand. COM doesn't understand inheritance so you may have to flatten out any bean class hierarchies you might have. Use the VBArray Object to get Javascript to understand COM Arrays. Your arrays will have to be of anyType type, at least I couldn't get it work otherwise. The WSDL from Java2WSDL won't work with your Javascript client. You need to: 1. Flatten out your types, just like you flattened out your COM beans. 2. Change the capitalization of the WSDL Types to get around this quirk with Axis where the WSDL Types don't match the Soap tags in case. (posted elsewhere on this list). 3. The WSDL generated from Java2WSDL does not comply with the Soap Spec, Section 5.1, Rule 8. So you need to modify this by hand. Finally, you need to add the 'bean mappings' to a special .WSML file which acts like the .wsdd file. Painful, but eventually works. Just shows how far we have yet go on interoperability. Maybe someone knows a simpler way...? Bob Woodley __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
