axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: Proposed modifications to Handler/Service registry mechanism
Date Tue, 25 Sep 2001 11:12:36 GMT
Still isn't clear to me...(comments in-line):

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

So, how does Axis know which EJBs to expose?  There still has to be some
sort of deployment data that tells Axis specifically which *one* to expose,
right?  If so, there's still a "sort-of" deployment descriptor so I don't
see the difference.

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

So, we have a Resolver that points to a specific DD.xml file - ok, so
there's still an extra step of deploying it - so instead of a deploy.xml
(like today) we create a Resolver - still an extra step.

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

"two different types of handler registries..." This sounds like you want
to have multiple handler registers and if so, then someone/thing would
have to know which registry it wants to search.  I'd prefer if there
were just one registry and regardless of how a handler is deployed or
written *any* lookup in *the* registry will find it.  Am I missing

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

Actually, they should.  Not all EJBs will want to be exposed as
There MUST be an extra step involved that tells Axis exactly which
EJBs are available - even if there's some sort of "deploy all"
mechanism there still MUST be something.

It sounds like you're mixing deploying and resolving handlers.
I like the idea of having multiple ways of deploying services (JWS,
v2 DD.xml files, deploy.xml, WSDD, WSDL...) and I think having a
pluggable Deployment mechanism could be handy.  Right now we have
a config system that is pluggable, I believe Glen made it so that
you could plug in any *single* config system to store/retrieve
the deployment data.  Extending this so that we could have
multiple ones (ie. one that looks for server-config.xml AND one
that looks for deployed EJBs) at the same time could be really
handy.  But that's the deployment side of things.

On the resolving Handlers, I'm still wondering why we need more
than one registry or why handlers themselves can't just do this
job?  Looking at the JWS example, there's Handler that sort of
acts like one of your resolvers - it takes the URL maps it to a
file on the file system and runs it.  There is no explicit need
to deploy it - the handler handles all of it for us.  I'm still
not clear on why more is needed.


View raw message