Yeah, a lot of thoughts :). See my comments inline
On 9/28/05, Chathura Herath <[EMAIL PROTECTED]> wrote:
Absolutely right. But If you look at it in a more abstract form, the transformation is irreversible because we are losing information. The meta data store is a sort of holder that keeps this missing info. It is populated via the "from WSDL 1.1 pump" and used by the "to WSDL 1.1 pump". With this approach we do not pollute the WOM's 2.0 nature.
Hmmm. For the immediately visible future it'll work fine but there are other things that might come into play. Say WS-Policy which can be attached to a message. I'm sure we can have a clear transformation rule but what I feel is attaching a meta data store would make things very much easier :)
That is what led us to suggest that we do a conversion as is :)
Hi Ajith,
>* When converting the WSDL 1.1 document to the WOM, some information is lost (information about messages etc). In other words when converting back from WOM to WSDL 1.1 the original WSDL 1.1 document cannot be recreated! There are several alternatives
I think the information is lost due to the fact that our transformation is not uniquely reversible(univalently) .
Actually for the case of the message we do a transform in WSDL1.1 --> WOM in the following manner(which is not in fine grain detail).
* let operation op1 have the message m1
*if the message is multipart (RPC)then create a new type with the qname of the message and then make the messagereference of the op1 to refer to the new type.
*if its not multipart and its an element we ll directly make the messagereference refer to the element in the message.
(So doc/lits are not affected )
Absolutely right. But If you look at it in a more abstract form, the transformation is irreversible because we are losing information. The meta data store is a sort of holder that keeps this missing info. It is populated via the "from WSDL 1.1 pump" and used by the "to WSDL 1.1 pump". With this approach we do not pollute the WOM's 2.0 nature.
Inverse of the above transform will not be a function meaning if we have a WOM operation with rpc style we dont know whether it was a multipart or not. This is the reason why we cannot uniquly serialise the WOM to a WSDL 1.1 document.
Btw the inverse of above works fine for the doc/lic case.
What if we can do the above transform in a more uniform way so that we can deterministically find the inverse. Check the following abstract function.IT will do the WSDL1.1->WOM conversion taking the style into acount
F:(wsdl1.1message, style):->wsdl2.0messagereference
CASE: wsdl1.1message style is rpc
we wrap and create a new wrapper element in place for the message even if its got only one part
CASE: wsdl1.1message style is doc
we dont create new elements rather directly chance the element reference in the WSDL message as the type of the WSDL 2.0 message reference
Now if you want to do the inverse of the above to do WOM->WSDL 1.1 serialization it will be another function
G:(WSDL2.0messagereference, style)->(wsdl1.1message)
CASE:(operationstyle is rpc)
Get the element refered by the message reference (which is the wrapper) create a message with the name of the wrapper element and extract parts(can be 1 or more) from the wrapper type
CASE:(operationstyle is doc)
Create a new message and make it refer to the type refered by the message reference.
Now this is completely reversible and Isomorphic. So we can wsdl11-->WOM and WOM-->WSDL11 with much ease and consistency.
Hmmm. For the immediately visible future it'll work fine but there are other things that might come into play. Say WS-Policy which can be attached to a message. I'm sure we can have a clear transformation rule but what I feel is attaching a meta data store would make things very much easier :)
That is what led us to suggest that we do a conversion as is :)
The whole thing described above is going to change one method of the code AFAIK.
WSDLPump
private QName generateReferenceQname(Message wsdl4jMessage)
thoughts??
Chathura Herath
--
Ajith Ranabahu
