axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Haddad" <>
Subject RE: WSDL-Service Payload encoding/decoding to/from different "XML"-Formats
Date Tue, 09 Jul 2002 18:24:33 GMT
Wolfgang -   
Can you communicate the exact use case and maybe provide an example?
I've become a bit familiar with the serialization subsystem, but I'm not
clear on your exact requirements.  
For example, do you desire to:
Retain the default QName->object type mappings?
Override the default QName->object type mappings?
Extend the type map with new QName->object mappings?
Translate default QNames into alternative QNamess?
Are the above scenarios based on a specific service endpoint, or used
across the entire server?
There are already a fair amount of switches inside Axis to register
alternative Type mappings and serialization techniques, so from first
glance, it seems like you could build on top of the framework.
-----Original Message-----
From: [] 
Sent: Tuesday, July 09, 2002 10:39 AM
Subject: WSDL-Service Payload encoding/decoding to/from different
In a project I have to transform the communication between an
AXIS-Client and a SOAP-Service
directly to another XML-Format or Object Model. For that I need, similar
to that what is already
realised in AXIS, a Type Mapping between the Service Type
(RPC-Parameter-Types) and the
"local"-Types (Object Model).
Where is the best point to integrate such a mapping?
One option would be, directly to use the Stubs, as produced by
WSDL2Java, generating 
from these informations the transformators for type mapping.  
Looking at this option, I have the feeling to reimplent a lot of things
already implemented
in the AXIS-Encoding-Subsystem.
Therefore comes up the other option, to integrate this type-mapping
directly in the 
Encoding-Subsystem with special extended factory classes and 
Would this be the preferable solution?
Are there some papers around, giving a more global view on the 
AXIS-Encoding Subsystem?
Thanks for your comments.

View raw message