Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <9D59E104-77D5-11D9-9CF9-000D93361CAA@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: dev@geronimo.apache.org
From: David Jencks <david_jencks@yahoo.com>
Subject: Runtime and deployment time web services architecture -- please
 comment
Date: Sat, 5 Feb 2005 16:25:33 -0800

I've been talking with David Blevins a bit about web services runtime 
and deployment time architecture and am belatedly moving to the list.  
I'm mostly thinking about ejb ws right now.

Goals:  support both Jetty and Tomcat (and possibly a standalone 
non-servlet-container for OpenEJB standalone), and both Axis and XFire.

or, more generally, support multiple web containers, multiple web 
service stacks, and multiple ejb containers.

Minimize the number of gbeans that need to be created.

Non goal at this time: support more than one of these at once in a 
running geronimo instance.  E.g., not possible to have both axis and 
xfire feeding ws requests to the same ejb.

-----------------
So, for ejb ws, we need interfaces between the web container and the 
web service stack, and between the web service stack and the ejb.

For POJO ws, we need at least an interface between the web container 
and the web service stack: the ws stack might or might not need an 
interface to the pojo: I think both Axis and XFire provide this 
themselves.

-----------------

web container -- ws stack interface:

I implemented a first draft proposal, WebServiceInvoker, which is 
probably wrong in all details.  It provides a name for the concept 
however.  I think no deployment time support for this is needed except 
for supplying the object name of the web container (e.g. 
JettyContainer) to the gbean supplying this interface for the ejb.  At 
runtime, this gbean related to the ejb will register the 
WebServiceInvoker with the web container, and the web container will do 
something to forward requests to this url to the WebServiceInvoker.

This appears to be moderately easy to implement in jetty using 
HttpContext subclasses, and quite easy to implement in tomcat using a 
container level valve.

This is different from my first draft implementation, which requires a 
gbean in the web container for each web service, and deploy time web 
container support.

-----------------

ws stack -- ejb interface

Assumptions:
-- the ws stack involves configuring an object or stack for each ws 
ejb, rather than funneling all requests through a single object.
-- each ejb only needs to be hooked up to one web service stack at a 
time (noted in "non-goals")
-- the ws stack works with "invocation" type objects rather than first 
splitting up into separate code for each method being called.  This 
seems more or less implied by the handler architecture.

The first of these means we can have the ejb builder delegate 
construction of the ws stack to a separate web service builder.  This 
stack object could be placed either inside the ejb container or as a 
separate gbean.  The second means that there will be only one of these 
stack objects per ejb container, so we can include the stack inside the 
ejb container.  In the interests of minimizing gbean count I think this 
is a good idea.

Now there is the question of the interface between the web service 
stack and the ejb interceptor stack.  Assuming that the ws stack works 
with invocation  type objects, we can most easily convert these 
directly into  EjbInvocation objects and send them down the ejb 
interceptor stack, without converting them into method calls to the 
ServiceEndpointInterface and then back into ejbInvocations.

My conclusion is that the ejb container should implement the 
WebServiceInvoker interface so the web server calls it directly, and 
the ws stack should be an object inside the ejb container that gets the 
WebServiceInvoker calls and eventually calls the interceptor stack 
directly.

---------------------
ws stack -- pojo interfaces

At least Axis currently provides a servlet that can call pojo web 
services.  I haven't looked at it very hard yet.

If we do not use the axis servlet, I think we could use a similar 
strategy for POJO web services as for ejbs.  We can, for each web 
container, write a ServletHolder-like gbean that delegates to a 
configured ws stack, and gets the invocation object at the other end 
and feeds it to the POJO.  Presumably we can use cglib here to avoid 
reflection.

---------------------

Builder support.

For ejb ws, the web module builder doesn't have to do anything.  The 
ejbs will register themselves with the container to receive requests at 
their url.

The ejb builder needs call the ws builder to get either a serializable 
ws stack object or a factory for the configured ws stack.  To allow for 
different implementations we should expect a factory: it can always be 
something like the DeserializingReference and return a deserialized 
object, or it could construct it from configuration info.

If we write ServletHolder like gbeans for each web container, the web 
module builder can construct one of these for each POJO ws, and 
delegate to the ws builder to get the ws stack factory, and put it in 
the gbean configuration.

---------------------

I don't think there is much of a question about web service client 
service refs.  I think that whatever web service implementation is 
used, its builder will implement ServiceReferenceBuilder and supply 
something to put in jndi.  It can decide what that object is however it 
wants.  Possibly there may be some more work with port links, which I 
don't understand yet.

-------------------

Please comment or ask for clarification.

thanks
david jencks