geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Runtime and deployment time web services architecture -- please comment
Date Tue, 08 Feb 2005 00:15:08 GMT

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


Mime
View raw message