|
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. /Chris -----Original Message----- Hello, 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 serializers/deserializers. 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. Regards, Wolfgang |
- WSDL-Service Payload encoding/decoding to/from different &... Wolfgang M�ller
- Re: WSDL-Service Payload encoding/decoding to/from di... Chris Haddad
- Re: WSDL-Service Payload encoding/decoding to/fro... Wolfgang M�ller
