On Feb 7, 2005, at 3:45 PM, David Blevins wrote:
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 processing.
The WSContainer (the web service stack), in turn, delegates to an EJBContainer.
Essentially, the number of GBeans required to support EJB Web Services is:
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 best.
This is already implemented for jetty and appears to work in a simple unit test. No additional gbeans needed.
yes
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 WebServiceInvoker.
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.yes
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.
From another reply David wrote:
I should state more clearly what I mean by this. CMP/BMP EntityBeans or Stateful SessionBeans will not have a Web Service Stack, neither will Stateless SessionBeans that only have Local or Remote interfaces.
In fact, in the case where people are just chatting from Servlets to EJB's through Local interfaces, we don't need any protocol stacks at all, e.g. no CORBA, no EJBd, no HTTP/SOAP. This is partly why it weirds me out to add protocol specific things into the GenericEJBContainer class.
now that you put it that way I agree. I might change my mind at any time... but this seems like a very strong argument.
thanks david jencks
-David
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
