On Tuesday, Sep 23, 2003, at 14:53 Europe/Rome, [EMAIL PROTECTED] wrote:


Hi, let me start with a little personal introduction. I live in London and
have been using cocoon and following the mailing lists for the past year
and a half. Last year I had the pleasure of meeting some of you in person
in Gent and also in London. Recently I have been thinking about connecting
to web services from flow script and exposing flow scripts as web
services. Instead jumping in head first and hacking some code to send in
as a patch I thought would make more sense to submit my ideas for review
by the developers first. I will be grateful for any feedback positive or
negative.

find my humble one inside.


Calling Web Services from Flow

Wouldn’t it be great if we could load a web service dynamically as an
object in Flow Script simply by passing it the URI of its WSDL file?

var fooWS = loadWebService('http://foo.bar/webservice?wsdl');
var value = fooWS.someRemoteMethod(1,'text');

yes, that would be very cool.


Why is this needed? Well for web services that return data that is
destined for the view layer the Web Service Proxy Generator is probably
better suited. However for more transactional orientated web services it
could be very useful.

I agree. In fact, web services could much more useful this way (as they are, in fact, RPC on [unnecessary?/marketing?] steroids)


On
http://wiki.cocoondev.org/Wiki.jsp?page=FlowAndWebServices there is a
simple use case and example flow script for placing an order using a web
service.


It really should not be that hard to implement this using Axis and
existing cocoon components. Axis can use dynamic or generated proxies.
Dynamic proxies have the advantage of not needing to be compiled however
they do not handle complex types well. For this reason I think it would be
better to use generated proxies instead of dynamic ones.


1. Use a source to access the WSDL file.
2. Pass the file into the Axis emitter that will generate java source
files for accessing the web service.
3. Compile the source files using the default java compiler component.
4. Load the resulting class files using the class loader.
5. Create and return an instance of the web service proxy class.

Stages 3 – 5 are similar to those carried out in XSP.

uh, that seems pretty cool.


Data type mapping

Simple data type mapping should not cause any problems as it will be
handled be rhino and axis. To handle complex types Axis generates
corresponding beans. There needs to be some way to create instances of
these beans from Flow Script or perform some automatic mapping between
JavaScript objects and the Java beans.

Questions:

Does it mix concerns to access a web service from the flow layer, or is it
ok if you consider a webservice a remote part of the model?

I think it's perfectly fine to use a web service this way, just like a method call to a remote machine. [this was the intention of web services anyway]


Is there anyone who would like to see this functionality implemented?

I wouldn't personally know what to do with it (I still have to find a web service I need to access that way), but for sure it wouldn't hurt from a marketing perspective, rather the opposite.


Has anyone got any suggested use cases?

you might connect to the web service of a credit card company to find out if the card exists, if it has enough coverage and proceed the flow accordingly.


Food for thought… Exposing Flow Scripts as Web Services

Wouldn’t it be cool if you could expose flow scripts as web services? Even
better would be to automatically generate the corresponding WSDL file as
well.

Hmmm, not sure I follow you here. Care to elaborate more?


--
Stefano.



Reply via email to