geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Runtime and deployment time web services architecture -- please comment
Date Mon, 07 Feb 2005 23:45:47 GMT
Just to clue people in on what has been implemented thus far:

We have an HTTP "server" that delegates to an "listener" that looks up 
a WSContainer using URL and sends that input/output streams for 
The WSContainer (the web service stack), in turn, delegates to an 

Essentially, the number of GBeans required to support EJB Web Services 
1 HTTP "Server"
1 HTTP "Listener"
1 WSContainerIndex (URL to WSContainer mappings)
N WSContainers, where N is equal to the number of EJBs with 
ServiceEndpoint interfaces.

The "Server", "Listener", and Index GBeans could and should be replaced 
with Jetty or Tomcat support--they handle HTTP and URL mappings the 

The contract between a WSContainer (web service stack) and an 
EJBContainer should be cleaned in some way to support POJO web services 
as well as EJBs.  This is what David J. is referring to as 

David, I think you and I agree on all points except that we should 
change the web service stack from being a GBean to being an object 
owned by (an attribute of) the EJBContainer for the sake of minimizing 
the number of GBeans in the system.

Logically, every Web Service Stack needs a Container, but not every 
EJBContainer needs a Web Service Stack.  Do you think this might be a 
case where we are letting bad design creep in because we are trying to 
avoid our own infrastructure?

The whole "supporting XFire and Axis at once" was just my poor attempt 
to illustrate that an EJBContainer can have zero to many protocol 
stacks and it doesn't care what they are.


On Feb 5, 2005, at 4:25 PM, David Jencks wrote:

> 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

View raw message