geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Axis GBean is deployable?
Date Tue, 01 Mar 2005 20:00:29 GMT

On Mar 1, 2005, at 4:42 AM, Venkat Reddy wrote:

> David, Thanks for the valuable clarification !
> I thought Geronimo will use Axis core for its SOAP stack and EWS code
> for JSR-921 support.

When I looked at EWS it looked to me as if it did 2 things:
1) code generation of stubs
2) partial translation of jaxrpc-mapping file to wsdd xml file. As far 
as I can tell this mapping translation is completely ignoring the 
javabean property to xml element name mapping and the exception 

After examing the generated code it looked to me as if it would be 
easier to use a cglib proxy solution than to compile the generated code 
from EWS.
One of the basic principles behind geronimo is that we "compile" all 
xml deployment descriptors into binary gbean configurations ready to be 
loaded and started at runtime.  Following this principle, if we were to 
use wsdd, we would have to preprocess it during deployment into the 
actual objects that configure axis, and serialize those.  AFAICT this 
would involve major surgery on the axis deployment system.  I believe 
it is much simpler simply to process the j2ee deployment descriptors 
directly into the appropriate axis configuration objects, entirely 
skipping the wsdd file format.  We've done this, and I don't see 
anything else in EWS that we can use.

In particular we have some code that, using the XmlBeans schema type 
model, completely analyzes the jaxrpc mapping and attempts to set up 
the correct TypeDesc and exception mapping for axis.  The exception 
mapping in particular is not quite complete for simple types.

Lets consider our use of Axis.

We are attempting to set up each service reference and web service 
(POJO or EJB) as an independent entity.  I think this is more or less 
required by the independent lifecycles of j2ee components.  For 
instance, a service reference gets "compiled" during deployment into a 
Service instance that is serialized to be bound into jndi.  This 
serialized object includes all the axis configuration objects needed to 
run the service reference, and some setup code to build the 
non-serializable parts of axis.  In particular it includes the type 
mapping info and the TypeDesc objects.

The service-reference code is fairly far along and I think deals with 
pretty much everything required.  I'm sure there are plenty of bugs but 
these are not yet too evident without much working on the server side.

For the server-side, we have some code to dispatch from jetty to POJO 
and EJB web services, and some wiring in place to deploy this properly, 
but the actual code to configure axis is not yet committed: David 
Blevins is IIUC progressing rapidly and we may see something in the 
next few days.  I believe he is following the same path of setting up 
an independent entity for each web service, configured for exactly the 
needs of that web service.

POJO web services, being part of a web app, get deployed as a gbean 
similar to the servlet gbean.  For jetty, the servlet gbean is 
JettyServletHolder, and we have a JettyAxisPOJOWebService gbean 
subclass that is (or, more accurately, will be) specialized to hold the 
axis ws stack and the actual web service object.  Deployment of a POJO 
ws proceeds from the web app deployer (JettyModuleBuilder) which 
recognizes that a servlet is not a servlet but a POJO ws, copies a 
template of this JettyAxisPOJOWebService gbean, and hands the resulting 
GBeanData to the AxisBuilder together with the relevant info from the 
webservices.xml deployment descriptor.  AxisBuilder is expected to 
configure this GBeanData with whatever is necessary to construct the 
fully functional axis stack when the gbean is started.

EJB web services are not part of a web app.  Therefore we have an 
adapter, JettyWebServiceHandler, that plugs into jetty and forwards 
calls to the web service to the EJB container.  To jetty, this looks 
like a web app, but the important point is that it gets only calls to 
the specific ejb.  Currently the xfire implementation is hooked up to 
use this, although the architecture there with a ws gbean separate from 
the ejb container gbean is not compatible with the JACC security 
requirements.  To meet the JACC requirements that the security be 
checked before the handler chain is entered, we think we will have to 
install the ws stack inside the EJBContainer, and use a partially 
separate interceptor chain for ws invocations from that for "regular" 
ejb invocations.  In any case I anticipate deployment proceeding by the 
OpenejbModuleBuilder handing the partially configured EJBContainer 
GBeanData to AxisBuilder together with the relevant portions of the 
webservices.xml deployment descriptor: AxisBuilder will add whatever is 
needed to construct the fully functional axis stack when the gbean is 

I think this architecture will let us support multiple web containers, 
multiple web service stacks, and possibly multiple ejb containers.  We 
can handle multiple web containers by each providing a template gbean 
like JettyAxisPOJOWebService as  "servlet" holder, one for each web 
service implementation, and each providing an ejb invoker similar to 
JettyWebServiceHandler.  We can handle multiple web service 
implementations by each knowing how to configure a POJO "servlet" 
holder gbean and an ejb container gbean.  We might be able to support 
multiple ejb containers through standardization of the invocation 
interface between the JettyWebServiceHandler-like object and the ejb 
container, and through standardization of the interface between the 
ends of the ws stack and the space in the ejb container in which it 

>  I'm aware that both need tailoring to fit into
> Geronimo architecture. Is there any document or discussion that talks
> more about this? I'm interested in contributing in the areas of
> integrating Axis and EWS with Geronimo. What's the to-do list for this
> area of work? How is the webservices support for Geronimo is being
> planned ?

Any contribution would be most welcome.  I'd certainly appreciate your 
opinion from the axis side about how much sense this makes.  A code  
review would be very good.    You may spot some large holes we've 
fallen into without noticing :-)

One relatively minor point that you could probably clear up quickly is 
as follows.  I noticed that the generated EWS code waited until the 
first Call object is constructed to install the type mappings for the 
service. Is this required or would it be possible to install the type 
mappings as soon as the service is deserialized and the appropriate 
internal components created and initialized?  My cglib-based code 
follows this, but could be noticeably simpler if we could set up the 
type mappings sooner.

Many thanks,
david jencks

> Thanks
> Venkat
> On Mon, 28 Feb 2005 08:19:47 -0800, David Jencks 
> <> wrote:
>> <snip>

View raw message