On Sat, 5 Feb 2005 16:25:33 -0800, David Jencks <[EMAIL PROTECTED]> 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. yes
> ----------------- > > 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. yes > --------------------- > 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 Thanks Srinath
