geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <hemap...@gmail.com>
Subject Re: Axis GBean is deployable?
Date Wed, 02 Mar 2005 03:27:59 GMT
Sorry for the late answer, David Blevins say he will move some ews
code in to the geronimo (I think that is the commit David's mention).
Thanks David for clarification as I too trying to catch up the things 

Venket If you can lend a hand I will also try to help if I can to get
around the things
Thanks
Srinath

On Tue, 1 Mar 2005 12:00:29 -0800, David Jencks <david_jencks@yahoo.com> wrote:
> 
> 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
> mapping.
> 
> 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
> started.
> 
> 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
> fits.
> 
> 
> >  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
> > <david_jencks@yahoo.com> wrote:
> >> <snip>
> 
>

Mime
View raw message