axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James M Snell" <>
Subject Re: Proposed modifications to Handler/Service registry mechanism
Date Tue, 25 Sep 2001 05:42:55 GMT
It increases the flexibility of the deployment mechanism.  You can 
register multiple types of resolvers into Axis at once so that handlers 
may be initialized from many different sources without having to go 
through the explicit registration step we have currently. 

For example, imagine that Axis is deployed into the WebSphere environment 
and that we've already deployed several EJB's using WebSphere's standard 
deployment mechanisms.  Now, we want to expose those as Web services. With 
the current Axis Handler Registry code, we would need to create a 
deployment descriptor for the EJB service and manually deploy that to 
Axis.  With the resolver architecture I'm proposing, we could have an 
EJBResolver that initializes the EJB directly from the WebSphere 
deployment, eliminating the extra steps of creating and deploying the 
deployment descriptor. 

Another example.  Let's say that we already have an Apache SOAP 2.x 
deployment that we want to migrate over to Axis.  With the current Handler 
Registry approach, we'd have to redeploy all of the SOAP 2.x deployment 
descriptors into Axis.  With the Resolver approach, we can create a 
SOAP2xResolver that points directly to the SOAP 2.x deployment registry 
(dat file, xml file, whatever) that contains the deployed service so that 
we never actually have to redeploy the services in order to migrate them 
over to Axis.

Now, you might make the claim that we can do each of these things in the 
registry interfaces we currently have, and I'll agree with you -- we can. 
I know this because I did it.  But there were some limitations:

1. it wasn't pluggable.  what I mean by that is, what if you want to do 
both of the examples above at the same time?  There is no mechanisms 
currently in Axis to allow two different types of handler registries to be 
used concurrently.  The resolver architecture provides it.

2. the semantics don't quite match up.  For the EJB example, the 
HandlerRegistry add and remove operations don't make any sense.  EJB's 
will be added through the Web application server deployment.  Invoking 
those EJB's as handlers in Axis shouldn't require the extra steps of 
creating and deploying the deployment descriptor.

Anyway, it's late and I gotta get working on something else.  We can talk 
more about this later ;-)

- James Snell
     Software Engineer, Internet Emerging Technologies, IBM
     James M Snell/Fresno/IBM -
These things I have spoken to you, so that in Me you may have peace. 
In the world you have tribulation, but take courage; I have overcome the 
- John 16:33

To:     James M Snell/Fresno/IBM
cc:, Sam Ruby/Raleigh/IBM@IBMUS, Doug 
From:   Steve Graham/Raleigh/IBM@IBMUS
Subject:        Re: Proposed modifications to Handler/Service registry mechanism 

Can you be more precise on how these proposed changes moves the ball 
forward?  What (precisely) does this improve?

Steve Graham
(919)254-0615 (T/L 444)
Emerging Technologies

   James M Snell                09/24/2001 06:49 PM

cc:     Steve Graham/Raleigh/IBM@IBMUS, Sam Ruby/Raleigh/IBM@IBMUS, Doug 
From:   James M Snell/Fresno/IBM@IBMUS
Subject:        Proposed modifications to Handler/Service registry mechanism

Ok, after giving it some thought, I'd like to propose some significant 
modifications to the current deployment registry mechanism in Axis.  I'd 
go ahead and make these changes, but the delta would be significant.  So I 
want to run them through the filter of public opinion first.  If I don't 
hear any complaints by the end of the week, I'll get started on these 

Below is the summary of the changes.

The Resolver interface is a replacement for the HandlerRegistry mechanism 
that makes the deployment of services, handlers and transports much more 

Resolver Interfaces

public interface Resolver {
  public Handler resolve(ResolverContext context);

public interface ResolverContext {
  public String getKey();
  public Object getParameter(String name);
  public Iterator getParameters();

Axis Resolver

public class AxisResolver implements Resolver {

   private Vector resolvers = new Vector();

   public void registerResolver(Resolver resolver) {

   public Handler resolve(ResolverContext context) {
      for (Iterator i = resolvers.iterator(); i.hasNext();) {
         Handler h = ((Resolver);
         if (h != null) return h;
      return null;


Planned Resolver Implementations (I may not be able to get to all of these 
SOAP2xResolver (for backwards compatibility)

How would resolvers be configured?
Resolvers would be registered during the Axis configuration step.  A 
global AxisResolver instance would be initialized and access through the 

Where/How would the AxisResolver be used?
The Resolver interface is an inline replacement for any HandlerRegistry 
instance being used.

What is the ResolverContext?
The ResolverContext provides access to all of the information necessary 
for resolving a handler/service.  This would need to be prepared by Axis.

Resolving a Java class:

    AxisResolver.registerResolver(new JavaResolver());
    Handler h = AxisResolver.resolve(new 

Resolving a JWS:

    AxisResolver.registerResolver(new JWSResolver());
    Handler h = AxisResolver.resolve(new 

Resolving a WSDL defined service

    AxisResolver.registerResolver(new WSDLResolver());
    Handler h = AxisResolver.resolve(new 

Resolving an EJB service

    AxisResolver.registerResolver(new EJBResolver());
    Handler h = AxisResolver.resolve(new 

Resolving a COM service

    AxisResolver.registerResolver(new COMResolver());
    Handler h = AxisResolver.resolve(new 

Resolving a SOAP 2.x deployed service

    Handler h = AxisResolver.resolve(new 

Resolving the Input/Output chains for the SOAP over HTTP transport

    AxisResolver.registerResolver(new TransportResolver());
    TargetedChain tc = (TargetedChain)AxisResolver.resolve(new 

Thoughts? Concerns?

- James Snell
     Software Engineer, Internet Emerging Technologies, IBM
     James M Snell/Fresno/IBM -
These things I have spoken to you, so that in Me you may have peace. 
In the world you have tribulation, but take courage; I have overcome the 
- John 16:33

View raw message