geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <>
Subject Re: Runtime and deployment time web services architecture -- please comment
Date Tue, 08 Feb 2005 02:13:23 GMT
On Sat, 5 Feb 2005 16:25:33 -0800, David Jencks <> wrote:
> 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.
yes there should be a some way to  direct the Web Service call from
the servlet to EJB, I was using the ContinerIndex to call EJBs (see
org.apache.geronimo.axis.AxisGeronimoUtils), but there may be a better
way to do it.
> 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.
If the Axis Servlet is used, all the WS calls go through a one
servlet, and it is bit tricky to enable the configurations that are
defined for each WS via the web.xml file. there was a thread that talk
about theis more or less on the list Subject of thread [Writing dummy
Servlet to redirect HTTP/SOAP requests]

> ---------------------
> 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