Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
From: "James M Snell" <jasnell@us.ibm.com>
Importance: Normal
To: axis-dev@xml.apache.org
Subject: Re: Resolver
Message-ID: <OFDF6E55BD.5DA91EDB-ON88256AE6.0052DB90@boulder.ibm.com>
Sender: "James M Snell" <jasnell@us.ibm.com>
Date: Mon, 15 Oct 2001 08:07:54 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I can't give a complete picture since it's not completely done yet, but 
there will be a different XML format, it will be pretty J2EE centric, and 
in some cases will involve multiple files.   We could come up with a new 
config manager but the resolvers would let us plug support in much easier. 
 

- James M Snell/Fresno/IBM
    Web services architecture and strategy
    Internet Emerging Technologies, IBM
    544.9035 TIE line
    559.587.1233 Office
    919.486.0007 Voice Mail
    jasnell@us.ibm.com
=================================================================
Have I not commanded you?  Be strong and courageous.  Do not be terrified, 

do not be discouraged, for the Lord your God will be with you wherever you 
go.  
- Joshua 1:9

Please respond to axis-dev@xml.apache.org 
To:     axis-dev@xml.apache.org
cc: 
Subject:        Re: Resolver


James,
  Can you give us a clue as to how the deployment after JSR 109 might
looks?  Does it define how a client deploys new services as well as
how a server should do it?  Does it just define a new XML format?
If someone plugs in a new configMgr and stores the deployment
info in some new JSR109 format - does that satisfy the req?
What's up?
-Dug


James M Snell/Fresno/IBM@IBMUS@IBMUS on 10/15/2001 02:33:22 AM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: Resolver


Glen...

Comments inline....

- James M Snell/Fresno/IBM
    Web services architecture and strategy
    Internet Emerging Technologies, IBM
    544.9035 TIE line
    559.587.1233 Office
    919.486.0007 Voice Mail
    jasnell@us.ibm.com
=================================================================
Have I not commanded you?  Be strong and courageous.  Do not be terrified,

do not be discouraged, for the Lord your God will be with you wherever you
go.
- Joshua 1:9

Please respond to axis-dev@xml.apache.org
To:     <axis-dev@xml.apache.org>
cc:
Subject:        Re: Resolver


>Hi James!
>
>OK, I've finally had a chance to look over this stuff.
>
>I don't want to be a wet blanket, but I'm not sure I see the need for all
>this complexity, and I think I may disagree with (or perhaps just don't
>understand) some of the core architectural ideas.
>

I think you're only seeing complexity here because you're thinking the
resolver stuff is in addition to the deployment and WSDD stuff that is
already there.  You're thinking "Why do we need this additional
stuff?".... The resolver stuff is meant to completely replace what is
there.  And if you really look at it, it really isn't doing much more than
what we've already got but it is doing it will less code, and greater
flexibility.

>Comments/questions in no particular order (some of these are quite 
minor):
>
>* Is it really a good thing to transparently deploy things like EJBs as
web
>services?  It seems to me that the choice to export a given EJB via SOAP
>should be a conscious one and that a mechanism that automatically deploys
>all EJBs as SOAP services seems dangerous.
>

In all actuality, they wouldn't be transparently deployed as Web services
callable by a client.  In most cases, the AxisServlet will serve as the
gateway into the engine, only things like JWS files or SD files would be
mapped to that servlet, so one would have to create a JWS or SD file to
expose the Web service.  The resolver just makes it easier to use the
EJB's within the Web service that is being deployed.

Think of it this way.  I'm a Web services client using SOAP over HTTP.  I
can only access what the Web server lets me access -- which means I can
only access valid URL's.  The only URL's that the Web services web server
will let me see are .sd and .jws files.  These are mapped to the Axis
Servlet.  The Axis Servlet dispatches to the Axis engine, the Axis engine
asks the resolver to figure out which service is being called.  If an EJB
is being used, the resolver will do the work to figure out which EJB to
use, etc etc.  This approach doesn't open any new security holes in the
system.

>* It makes a lot of sense to me to have the Axis engine configuration in
one
>place (a single XML file/data model).  The suggested code seems to
>potentially split it up all over the place, which may lead to brittle and
>potentially unsecure systems.  I don't think it's unreasonable to expect
>people to do a one-time conversion of their SOAP 2.2 deployment over to
>Axis, for instance, rather than potentially being confused about where a
>given service comes from.
>

Configuration will still occur in a single place (the configuration
provider).  The resolver stuff doesn't change that.

If a one-time conversion is preferred, then we do a one-time conversion
and forget about the the SOAP2x resolver.  No big deal there.

>* What about name collisions between SOAP 2.2 services, EJB JNDI names,
>and Axis WSDD names? Couldn't that also get pretty hairy?  If I
understand
>your idea correctly, names (such as in the URL) would get resolved by a
>series of resolvers, right?
>

Name collisions can be easily handled through use of the resolver context.
 Simple mechanisms can be used, such as prefixing the key like I do with
the JavaResolver, where all of the keys have to start with "java:".  The
SDResolver checks to see if the key ends with ".sd", the JWS resolver
checks to see if the key ends with ".jws".  Simple mechanisms yes, but
effective.

For the most part, there will be a very few number of resolvers being used
so this won't be a problem.

The resolver context is passed through a sequential list of resolvers. The
first one to return a non-null the result stops the process and the
handler is returned.  It's pretty simple.

>* I don't like the idea of making the AxisServlet much/any smarter (i.e.
in
>order to detect .sd and .jws files).  The whole point of the Axis
>architecture is to put as much smarts as possible into Handlers so they
can
>be easily shuffled and combined in different ways.  The AxisServlet (and
in
>fact all transport listeners) should do the minimum amount of work
necessary
>to set up the MessageContext, and then let Handlers do the rest, which
lets
>people build systems that are as lean or as rich as they want.
>

This doesn't add any intelligence to the Axis Servlet.  In fact, we could
get away with making all of the changes in the Axis engine and not
touching a single line of code in the servlet file.  That may actually be
better.

Want a dumb AxisServlet..... get a dumb AxisServlet.  Notta problem sir.

>* Our codebase is already big, and this seems like a lot of mechanism
(both
>in terms of code and yet another pattern to understand) for a payoff
which I
>can't quite see/agree with as yet.  I mean, doesn't the idea of
configurable
>providers already pretty much do what you're after?
>

There's actually very little mechanism being introduced here.  Considering
this code could cause everything in the deployment package to go away, we
actually have a significant savings in size and complexity.  We increase
efficiency, cut down on code, lower the complexity, and make it easier to
deploy services.  There are wins all the way around.  I personally see no
losses here.

One thing is that we'd actually be able to get rid of the fact that we
need to maintain several stateful instances of the handler registry class
for transports, handlers and services (each one being a separate
instance).  We could have just a single collection of resolvers that may
or may not be stateful.  The code is simplified and there are less objects
that we have to hold on to at any given time.  With the current code, all
handlers and services and transports are instantiated just on the fact
that the registry is loaded; with the resolver code, only the handlers,
services and transports that are explicitly called up need to be
instantiated and optionally maintained in memory (resolvers have the
option of turning off in-memory caching).  This does simplify the code a
great deal.

As for having a large codebase, well, I have my own opinions on how we can
pare down a few other areas to make the code much more simple.  Replacing
the existing deployment stuff with the resolver stuff is one way (we get
by with a far fewer number of classes).  Another would be to make the
Handler, Chain and TargetedChain interfaces into abstract base classes and
getting rid of the BasicHandler, SimpleChain and SimpleTargetedChain
classes altoghether.  That would get rid of a few extra non-necessary
classes.  Another has to do with the message and encoding stuff but I'm
not going to get into that right now.  I'll wait until after release one
to tackle that one.


>* Is it really a good idea to attempt to introduce Yet Another XML format
>(the sd) when we're trying to get a release done in a resonable
timeframe?
>We've already dragged our heels long enough getting WSDD integrated....
>This concerns me.  Some of this is really about getting a solid "to-do"
list
>which we all agree on for 1.0 - which I'd like to see soon in any case.
>

With the introduction of the simplified SD format, WSDD could go away
completely.  I've never been happy with WSDD's complexity for deploying
services.  SD pares down that complexity quite a bit.  Additionally, the
SD code is smaller and removes the dependency on DOM (it's completely
SAX-based).  It's much more efficient and smaller.  The syntax is easier
to use.  WSDD can go bye bye.

>* Why introduce the ResolverContext?  Why not just use the MessageContext
>like we already do?  It seems like any work needed to set up the
>ResolverContext would usually be just copying stuff from the
MessageContext
>anyway, right?
>

The ResolverContext allows services to be resolved independently of any
message processing.  Say, perhaps when the Axis engine is initialized,
etc.  And no, if you look at the SD code, ResolverContext's are being
created based on information provided by the SD file, not the message
context.

The message context should deal with getting access to the message..
dealing with the message.. etc.  If we're following proper separation of
concerns, the message context should not have anything to do with figuring
out which service that message is being dispatched to unless there is no
other choice (i.e. there is no out-of-band information you can use to
figure out the target service and you have to parse the message to figure
it out).  The ResolverContext adds too little overhead to really be
concerned about.

The ResolverContext can also help us to communicate additional information
about the handler that we're looking for.  For instance, the EJBResolver
uses various Resolvercontext properties to communicate all of the
information necessary for initializing the options on the EJBProvider.

>Personally, I would prefer that this stuff not get hooked in until we've
>discussed it further.  I'd also like other folks with Axis architectural
>clue to weigh in on this before it happens.  I actually have a few other
>comments as well, but this is getting kind of long so I'll bring them up
>later as appropriate.
>

There is at least one significant advantage to the resolver code.  Axis is
going to be out in version 1.0 prior to JSR109's finish date.  When JSR109
emerges, it will have a different deployment scheme that what we are doing
with Axis.  With the resolver architecture, we will be able to do
something that we cannot do with the current code:  *plug in* support for
JSR109 deployment while still maintaining the existing, already in
production Axis deployment scheme, and support both simultaneously.  The
ability to plug in different deployment mechanisms will have other
advantages -- say like when we want to migrate people from .NET over to
Axis -- it is conceivable to have a ASMX resolver that would allow
developers to drop an ASMX file into their Web environment and have Axis
automatically wrap those files as Handlers.  Imagine something like:

  Resolver resolver = engine.getResolver();
  Handler h = resolver.resolve(new ResolverContext("/helloworld.asmx");
  h.invoke(msgContext);

And have it automatically wrap the .NET classes as Axis handlers.  That
would be cool, and could happen simply by plugging in an ASMX Resolver. No
new deployment descriptor necessary.  .NET developers would be able to
migrate over to Axis without having to learn anything new.  Just take
their existing ASMX files, drop them into the Axis web environment and off
ya go.  That would be quite cool in my opinion.  If we keep things the way
they are, the developer would have to write a WSDD file and manually
deploy the service before it would work.  Bah humbug!  I already have an
ASMX file, why in the world should I have to do anything else!?

And just think, using URL based deployment, they may actually be able to
get it so that the URL of their service never has to change.  If in the MS
.NET web environment, they're service URL was: http://www.acme.com, and
they decided to change their MS web evironment to an Apache web
environment at the same domain name, they could simply map the .ASMX files
to the Axis servlet and use the exact same Web address.  We add in the
proper support for creating the WSDL files and the autogenerated
documentation and coolness, we've just completely replaced .NET without
forcing the developer do write any new deployment descriptors or learn any
new XML syntax.  Bonus.

If you really sat down and sketched this out, the resolver architecture is
not that complex.  It adds just a single layer on top of what we already
had with the HandlerRegistry.  Rather than asking a single type of
registry for a service, or handler, etc, we ask a several.  Whichever one
comes back with an answer first is the one we use.  For the most part,
this will have an extremely low impact on the day-to-day developer, who
will use the default collection of resolvers that we will ship and
configure.  They will use JWS and SD based service deployment and not
really think anything about it.  For those that need more complex
behavior, or need to integrate a slightly different deployment technique
(such as JSR109) the ability to do so without adversely affecting the
established environment will be there -- again without adding any
significant complexity.

Getting back to WSDD... the code that is there... the creation of WSDD
files, the deployment of those files to the registry, yadda yadda --- all
of that is far more complex that anything the resolver architecture is
introducing.  Especially when we get into thinking about how it all might
have to change for JSR109 support.  In the end, keeping things as they are
currently and then later trying to work in changes for JSR109 will cause
much more problems than anything this resolver approach will do.


>Comments, thoughts, opinions, flames?
>

Of course! I always have comments, thoughts, opinions and flames.  They're
not always worth a damn but I've always got 'em!  In fact, if you ever run
out of opinions, let me know, I'll sell you some cheap. $19.95 for a box
of 20.

>--Glen