Axis to Javascript using MS Soap

[robert woodley <am...@yahoo.com>]

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

Re: Axis to Javascript using MS Soap

[Heitzso <he...@bellsouth.net>]

Bob,

Have you dug into PocketSOAP.  I was impressed with it
when I played with it.

Cheers,
Heitzso

On Wed, 2002-06-05 at 16:39, robert woodley wrote:
> 
> 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