You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsif-user@ws.apache.org by Matthieu RIOU <ma...@yahoo.fr> on 2004/08/26 11:12:51 UTC
Invocation by directly providing XML message
Hi Aleksander,
I was wondering if you plan to include the
functionality of invoking by directly passing the XML
message to send and directly extracting the XML from
the response, without object
serialization/deserialization in WSIF.
I checked the "test" code you provided a little while
ago and was rather happy with it. I'm working on
Twister (www.smartcomps.org/twister), an open source
WS-BPEL engine, and I would be very happy if I could
use WSIF. I could contribute by testing and debugging,
I'm afraid I don't have too much development time as
Twister takes all I have.
Thanks,
Matthieu.
Vous manquez despace pour stocker vos mails ?
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com
Re: Invocation by directly providing XML message
Posted by Jos van den Oever <jo...@gsf.de>.
On Friday 17 June 2005 19:15, Aleksander Slominski wrote:
> Jos van den Oever wrote:
> >Hi Alek,
> >
> >Thanks for your extensive reply.
> >
> >>i only support WSDL doc/literal and no rpc/encoding.
> >
> >Oops, I definitly need rpc.
> >
> >Well, I guess I'll have to roll my own. :-(
>
> rpc/literal is supported to some degree in XSUL2 but support is limited
> (and untestd)
>
> >But I've got a simple client running now. It's now difficult after all.
>
> i agree that generic functionality is easy but devil is in details in
> particular making API easier actually is hard part and then there is
> supporting SOAP 1.1 and 1.2, different binding styles in WSDL, async
> messaging (WS-Addressing, correlations) and so on.
Yes, the problem I was facing was that the APIs actually made it more
difficult to use Web Services. I'm now going to use my own code for a simple
client and I will add functionality as required. The promise of the libraries
that WS will be supported fully is simply not as good as it sounds.
For the moment, I don't need async access and I'll just implement the most
common binding styles, i.e. the ones that I encounter when using the client.
Cheers, Jos
Re: Invocation by directly providing XML message
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Jos van den Oever wrote:
>Hi Alek,
>
>Thanks for your extensive reply.
>
>
>
>>i only support WSDL doc/literal and no rpc/encoding.
>>
>>
>Oops, I definitly need rpc.
>
>Well, I guess I'll have to roll my own. :-(
>
>
rpc/literal is supported to some degree in XSUL2 but support is limited
(and untestd)
>But I've got a simple client running now. It's now difficult after all.
>
>
i agree that generic functionality is easy but devil is in details in
particular making API easier actually is hard part and then there is
supporting SOAP 1.1 and 1.2, different binding styles in WSDL, async
messaging (WS-Addressing, correlations) and so on.
>Thanks again for your trouble, though!
>
>
best,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Invocation by directly providing XML message
Posted by Jos van den Oever <jo...@gsf.de>.
Hi Alek,
Thanks for your extensive reply.
> i only support WSDL doc/literal and no rpc/encoding.
Oops, I definitly need rpc.
Well, I guess I'll have to roll my own. :-(
But I've got a simple client running now. It's now difficult after all.
Thanks again for your trouble, though!
Cheers, Jos
Re: Invocation by directly providing XML message
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Jos van den Oever wrote:
>On Friday 17 June 2005 09:11, Aleksander Slominski wrote:
>
>
>>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:
>>http://www.extreme.indiana.edu/xgws/xsul/guide/
>>
>>
>
>I took a look at
>http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/client/DecoderClient.java
>but it seems to require a stub class. Since I want to write a client to invoke
>_any_ webservice, i don't see how i can use this because I cannot generate a
>stub in advance.
>
>
both stub and DII API (Dynamic Invocation Interface) are supported and
DII is just WSIF-like, see:
http://www.extreme.indiana.edu/xgws/xsul/guide/#client.dii
>Would it be possible to do something like this:
>
>WSIFClient wsc = WSIFRuntime.newClient(wsdlLoc);
>
>
WSIFRuntime is meant for dynamic stubs you can use WSIF API direclty.
for example see DII client that takes WSDL, operaiton, and parameters as
strings from command line:
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xwsif_dynamic_invoker/xsul/dii/XsulDynamicInvoker.java
>// find the default bound operation
>Operation operation = wsc.findOperation(operName);
>if (operation == null) {
> System.out.println("Operation "+operName+" is not available.");
>}
>operation.addInput(inputName, inputNode);
>
>
WsdlDefinitions def = WsdlResolver.getInstance().loadWsdl(base,
new URI(wsdlLoc));
WSIFServiceFactory wsf = WSIFServiceFactory.newInstance();
WSIFService serv = wsf.getService(def);
WSIFPort port = serv.getPort(portName);
WSIFOperation op = port.createOperation(opName);
WSIFMessage in = op.createInputMessage();
and then set input to actual XML, for example:
XmlElement sarray = builder.parseFragmentFromReader(new
StringReader("<foo>... some xml content ... </foo>"));
in.setObjectPart("foo",sarray);
>operation.call();
>
>
boolean succes = op.executeRequestResponseOperation(in, out, fault);
if(succes) {
System.out.println("received response "+out);
} else {
System.err.println("received fault "+fault);
}
>for (Part p : operation.getOutput()) {
> System.out.println(p.name()+": "+p.xmlNode());
>}
>
>
another sample has this in more details:
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/samples/xsul_sample_google/Client.java
where it extracts data from XML output (XPath could be used too as XPP3
supports Jaxen API)
boolean succes = op.executeRequestResponseOperation(in, out, fault);
if(succes) {
//System.out.println("received response "+out);
XmlElement response = (XmlElement) out;
// return/resultElements
XmlElement resultElements = response
.requiredElement(null, "return")
.requiredElement(null, "resultElements");
// print URLs of all */URL/text()
int count = 1;
for (Iterator i = resultElements.elements(null, null).iterator(); i.hasNext(); ) {
XmlElement item = (XmlElement) i.next();
System.out.println((count++)+". "+item
.element(null, "URL")
.requiredTextContent());
}
} else {
System.out.println("received fault "+fault);
}
>Also I don't want to do any XML Schema validation initially. I just want to
>read a WSDL, find a bound operation, specify it's input as XML nodes, call
>the operation and process the ouput and faults.
>
that was motivation behind XSUL1 and my work on adding WSIF APIs in
XSUL2: to make all this possible and clearly define layers and
dependencies between modules.
>The input parts need to be
>specified as nodes, not elements, because e.g. a part of type xs:string is
>not an element.
>
>
i only support WSDL doc/literal and no rpc/encoding.
>Which module of xsul2 should I obtain to write only such a client?
>
>
check build.xml and add a target to compile of modules that are
necessary to build xwsif*client,xwsdl, and required soap* client modules.
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Invocation by directly providing XML message
Posted by Jos van den Oever <jo...@gsf.de>.
On Friday 17 June 2005 09:11, Aleksander Slominski wrote:
> 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:
> http://www.extreme.indiana.edu/xgws/xsul/guide/
Hi Alek,
I took a look at
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/client/DecoderClient.java
but it seems to require a stub class. Since I want to write a client to invoke
_any_ webservice, i don't see how i can use this because I cannot generate a
stub in advance.
Would it be possible to do something like this:
WSIFClient wsc = WSIFRuntime.newClient(wsdlLoc);
// find the default bound operation
Operation operation = wsc.findOperation(operName);
if (operation == null) {
System.out.println("Operation "+operName+" is not available.");
}
operation.addInput(inputName, inputNode);
operation.call();
for (Part p : operation.getOutput()) {
System.out.println(p.name()+": "+p.xmlNode());
}
Also I don't want to do any XML Schema validation initially. I just want to
read a WSDL, find a bound operation, specify it's input as XML nodes, call
the operation and process the ouput and faults. The input parts need to be
specified as nodes, not elements, because e.g. a part of type xs:string is
not an element.
Which module of xsul2 should I obtain to write only such a client?
Best regards,
Jos
Re: Invocation by directly providing XML message
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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 ...
>>
>>alek
>>
>>
>
>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:
http://issues.apache.org/jira/browse/AXIS2-12
>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);
>operation.setInput(input);
>operation.invoke();
>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:
http://www.extreme.indiana.edu/xgws/xsul/guide/
cheers,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Invocation by directly providing XML message
Posted by Jos van den Oever <jo...@gsf.de>.
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 ...
>
> alek
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.
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);
operation.setInput(input);
operation.invoke();
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.
Cheers, Jos
Re: Invocation by directly providing XML message
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Jos van den Oever wrote:
>On Thursday 26 August 2004 20:11, Aleksander Slominski wrote:
>
>
>>Matthieu RIOU wrote:
>>
>>
>>>I was wondering if you plan to include the
>>>functionality of invoking by directly passing the XML
>>>message to send and directly extracting the XML from
>>>the response, without object
>>>serialization/deserialization in WSIF.
>>>
>>>
>>absolutely yes and to make things smoother to have also DOM API
>>implemented on top of WSIFMessage and allow easy execution of XPATH
>>queries on WSIFMessage as well !
>>
>>
>
>I was wondering if it is now possible to invoke web services by providing all
>input as XML. This would be very useful in XML oriented frameworks. I'm
>working on code where I have all data in a DOM node and don't want to map to
>Java objects and back. I would think that since XML is the language of Web
>Services should be very easy. It turns out, however, that it's not easy at
>all to do this. Or is WSIF only meant to work from Java objects?
>
>
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 ...
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Invocation by directly providing XML message
Posted by Vishal Shah <sh...@yahoo.com>.
This is same as doc/literal approach where u pass the DOM element to the service and retrieve back the DOM element.
Jos van den Oever <jo...@gsf.de> wrote:On Thursday 26 August 2004 20:11, Aleksander Slominski wrote:
> Matthieu RIOU wrote:
> >I was wondering if you plan to include the
> >functionality of invoking by directly passing the XML
> >message to send and directly extracting the XML from
> >the response, without object
> >serialization/deserialization in WSIF.
>
> absolutely yes and to make things smoother to have also DOM API
> implemented on top of WSIFMessage and allow easy execution of XPATH
> queries on WSIFMessage as well !
I was wondering if it is now possible to invoke web services by providing all
input as XML. This would be very useful in XML oriented frameworks. I'm
working on code where I have all data in a DOM node and don't want to map to
Java objects and back. I would think that since XML is the language of Web
Services should be very easy. It turns out, however, that it's not easy at
all to do this. Or is WSIF only meant to work from Java objects?
Cheers,
Jos
---------------------------------
Discover Yahoo!
Find restaurants, movies, travel & more fun for the weekend. Check it out!
Re: Invocation by directly providing XML message
Posted by Jos van den Oever <jo...@gsf.de>.
On Thursday 26 August 2004 20:11, Aleksander Slominski wrote:
> Matthieu RIOU wrote:
> >I was wondering if you plan to include the
> >functionality of invoking by directly passing the XML
> >message to send and directly extracting the XML from
> >the response, without object
> >serialization/deserialization in WSIF.
>
> absolutely yes and to make things smoother to have also DOM API
> implemented on top of WSIFMessage and allow easy execution of XPATH
> queries on WSIFMessage as well !
I was wondering if it is now possible to invoke web services by providing all
input as XML. This would be very useful in XML oriented frameworks. I'm
working on code where I have all data in a DOM node and don't want to map to
Java objects and back. I would think that since XML is the language of Web
Services should be very easy. It turns out, however, that it's not easy at
all to do this. Or is WSIF only meant to work from Java objects?
Cheers,
Jos
Re: Invocation by directly providing XML message
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Matthieu RIOU wrote:
>I was wondering if you plan to include the
>functionality of invoking by directly passing the XML
>message to send and directly extracting the XML from
>the response, without object
>serialization/deserialization in WSIF.
>
absolutely yes and to make things smoother to have also DOM API
implemented on top of WSIFMessage and allow easy execution of XPATH
queries on WSIFMessage as well !
>
>I checked the "test" code you provided a little while
>ago and was rather happy with it.
>
i will soon post an updated version that fixes some bugs and may have
also support for local java provider.
>I'm working on
>Twister (www.smartcomps.org/twister), an open source
>WS-BPEL engine, and I would be very happy if I could
>use WSIF. I could contribute by testing and debugging,
>
this contribution is very useful (and we take any offer of help we can get!)
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Invocation by directly providing XML message
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Matthieu RIOU wrote:
>I was wondering if you plan to include the
>functionality of invoking by directly passing the XML
>message to send and directly extracting the XML from
>the response, without object
>serialization/deserialization in WSIF.
>
absolutely yes and to make things smoother to have also DOM API
implemented on top of WSIFMessage and allow easy execution of XPATH
queries on WSIFMessage as well !
>
>I checked the "test" code you provided a little while
>ago and was rather happy with it.
>
i will soon post an updated version that fixes some bugs and may have
also support for local java provider.
>I'm working on
>Twister (www.smartcomps.org/twister), an open source
>WS-BPEL engine, and I would be very happy if I could
>use WSIF. I could contribute by testing and debugging,
>
this contribution is very useful (and we take any offer of help we can get!)
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay