Re: WSDL-Service Payload encoding/decoding to/from different "XML"-Formats

[Wolfgang M�ller]

Hi Chris,   thanks for your support.   What I want to do concerns only the "client"-side of a SOAP-Service. Assume the chain of components as:   myClientsBackend -> myClient -> AXIS-Client -> SOAP-Service   Between "myClientsBackend" and "myClient" runs the "target-communication-protocol", which should look like that: (taken from the TestBeanDeser.java of AXIS Testcases)   Soap-Payload (as it comes to the AXIS-Client):     <TYPE xsi:type=\"xsd:string\">000</TYPE>\n" <ID xsi:type=\"xsd:string\">001</ID>\n" <NUMBER xsi:type=\"xsd:string\">002</NUMBER>\n" <MESSAGE xsi:type=\"xsd:string\">003</MESSAGE>\n" <LOG_NO xsi:type=\"xsd:string\">004</LOG_NO>\n" <LOG_MSG_NO xsi:type=\"xsd:string\">005</LOG_MSG_NO>\n" <MESSAGE_V1 xsi:type=\"xsd:string\">006</MESSAGE_V1>\n" <MESSAGE_V2 xsi:type=\"xsd:string\">007</MESSAGE_V2>\n" <MESSAGE_V3 xsi:type=\"xsd:string\">008</MESSAGE_V3>\n" <MESSAGE_V4 xsi:type=\"xsd:string\">009</MESSAGE_V4>\n"   Translatet target for "myClient":   [TYPE:4(000:3     ID:4(001:3         NUMBER:4(002:3             MESSAGE:4(003:3                 LOG_NO:4(004:3                     LOG_MSG_NO:4(005:3                         MESSAGE_V1:4 (006:3                             MESSAGE_V2:4(007:3                                 MESSAGE_V3:4(008:3                                     MESSAGE_V4:4(009:3)                                     )                                 )                             )                         )                     )                 )             )         )     ) ]   Just to explain: X:Y is the local Type-System, the meaning of X depends on Y. In this example NUMBER:4 means <SymbolName>:<SymbolType> similar 002:3 is <Value>:<ValueType>.   In this example, the translation of fields in a Bean-Instance results in a chained list of "symbol names", "symbol types", "values" and "value types" with the names and values from the actual JavaClass-instance. This is a intermedate format, from which the "results" will be transmitted to the backend.   My idea is, to use the mechanisms already implemented in the AXIS-Encoding system. As far as I understand it, the expected Java- and XML-Types of a SOAP-Service are registered in the Type-Mapping, together with Serializers- and Deserializers. The different instances of Deserialisers (BeanDeserializer, SimpleDeserializer...) have access to the target-value, which is managed by the DeserializerImpl. The method "valueComplete()" finally writes the value to the target. At this point would like to create instances of "Symbols-Objects" similar to the structure above, chaining them together during deserialisation.   Similar to the .getParams()-Method in the RPCElement-Class I imagine to get access to the symbol-chain-object on "myClient".   The solution should work for serialize and deserialize, the needed translaters should be automaticly generated from WSDL and of cause able to manage all possible data types.   The question for this first step is, which axis-encoding-classes have to be extended to generate the intermediate object-model during deseralization and is this a good starting point?   Actually I am missing a global view of the whole AXIS-Encoding-System, so it would very welcome, if you could give me some advice.   Many thanks in advance.   Best Regards, Wolfgang         ----- Original Message ----- From: Chris Haddad To: [EMAIL PROTECTED] Sent: Tuesday, July 09, 2002 8:24 PM Subject: RE: WSDL-Service Payload encoding/decoding to/from different "XML"-Formats 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----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 10:39 AM To: [EMAIL PROTECTED] Subject: WSDL-Service Payload encoding/decoding to/from different "XML"-Formats   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