ws-wsif-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: Invocation by directly providing XML message
Date Fri, 17 Jun 2005 07:11:32 GMT
Jos van den Oever wrote:

>On Thursday 16 June 2005 19:18, Aleksander Slominski wrote:
>>hi Jos,
>>in ancient times (few years ago) there was big push to hide XML and to
>>do aggressive XML-Java type-mapping.
>>now it seems we entered more XML as-it-is friendly era and definitely it
>>is one of the places where i think WSIF needs improvements - it should
>>be easy to send XML to any service described in WSDL *regardless* where
>>it is and what is its binding alas WSIF2 is designed not around XML
>>Infoset but around Java types that are used internally to make
>>invocations ...
>>still i think it should be possible to extend WSIFMessage API to allow
>>passing DOM object directly as a part (WSIFMessage.setObjectPart(name,
>>Element)) or even better as i was experimenting with WSIF API n XSUL2:
>>make WSIFMessage implement DOM::Element or in general terms XML Element
>>Information Item so you send any XML inside WSIFMessage ...
>Hello Alek,
>Yes, I never really understood the obsession with this mapping. It's so 
>aggressive that in e.g. Axis and WSIF it seems impossible to simply provide 
>all input as XML. WS are all about sending and receiving XML, so any 
>implementation should first start with implementing a layer for formatting 
>the available XML to the specific binding. The mapping layer should come on 
>top of that and should be independent of the WS invokation. It should only 
>depend on the format description which is usually XML Schema.
yes - hopefully this notion of orthogonality will survive in AXIS2 - 
here is a bit of discussion on this topic:

>So, to me, a sensible WSIF API looks something like this:
>Operation operation;
>Input input;
>Node part1node;
>Node part2node;
>input.setPart(part1name, part1node);
>input.setPart(part2name, part2node);
>Output output = operation.getOutput();
>List faults = operation.getFaults();
>In the absence of a good API like this, I'm considering of rolling my own SOAP 
>invocation layer like this. It will be simpler and insightful (although more 
>limited) than trying to bypass the mapping in WSIF.
you are welcome to take a look on XSUL2 that has this and many other 
improvements - in particular WSIFMessage is XmlElement and XML-Java 
mapping is optional layer - XmlBeans looked like the most complete XML 
Schema data binding so it is supported and there is simple XWSDL code 
generator that is SOAP toolkit independent:



The best way to predict the future is to invent it - Alan Kay

View raw message