Comments on the status of Axis

[James M Snell <ja...@us.ibm.com>]

Below is an off the cuff listing of issues I have currently with the Axis 
code.  Can somebody (Glen, Sam, Doug, others...) please review and 
comment.

Current Issues with Axis (IMHO)
=================================

(Based on the requirements doc)

1. Service and Operation Identification
   (#30) Dispatch by transport URL 
      - Does this actually work for all services, or just JWS services?
      - It's not clear how this works
      - In my opinion, we should be able to do this regardless of the
        handlers we have on the chain.
      - It seems wasteful that we have to walk through the chain in order
        to figure out which service to call when we may have enough 
information
        at the start to figure this out.
      - I really think we should figure out a better way to do this
      - Put to a vote, I'd -1 the current method unless somebody can give 
me a compelling reason why it's the only good way

2. (#80) Installation and deployment of both the engine, components, and 
services should be simple 
   The requirements doc says "done!" ... is it really done?  I know we 
have some interim stuff (the Admin and ConfigProvider stuff) but I don't 
think that these are actually done yet.

3. (#81) Support a WebServiceArchive format which associates the 
executable and the description files
   Something like this will be coming with JSR109.  I'm not sure this is 
still a requirement for us.

4. (#82) Support .asmx-like drop-in service deployment 
    JWS is wierd.  Why does this belong in Axis?  This seems like a 
duplication of JSP done in a very poor way.  If we really wanted something 
like ASMX, the closest analog is to create something based on the already 
existing JSP architecture.  It can be done and it's actually quite simple 
to do.  Put to a vote, right now I'd -1 the JWS approach unless someboy 
has a really compelling reason why it's betterthan the JSP model.

    When I say "JSP model", I mean that we could very easily adapt the JSP 
architecture for this, either by creating custom tags or by customizing 
JSP (Greg Truty may be able to offer some insights into how this could be 
done as he's the one that pointed it out to me in the first place ;-) ...)

5. (#83) A single SUPER TINY .jar file must be enough for a client to 
communicate via SOAP
    We've already blown this one.  The number of dependencies is growing.

    Anyway we can make dependencies on log4j.jar, wsdl4j.jar, and 
activation.jar and mail.jar (when the attachments stuff comes in) optional 
at runtime? 

6. (#102) Must not name general classes as SOAPWhateverDoer 
    This one isn't being met either.  In several places in the Message API 
the code relies on classes named "SOAPxxxx".

7. (#103) Simultaneous support for multiple message protocols
    See my message api notes below.  Not only is this not done, it would 
require a major  change, IMO, to make happen.

8. (#113) Handlers need to be allowed to reach raw message data 
    Done, but not in a very good way.  See my message API notes below

9. (#144c) Extend WSDL with information on where to get components for 
stuff 
    What does this mean??

10. (#160) Extensible support for encodings
    "Done!" Is it really?  Sure, we can plug in new serializers and 
deserializers, but how do I plug in a completely new encoding style?  Does 
the encoding architecture include support for multiple encoding styles 
used within a single message?  Can a single QName be mapped in two 
different encoding styles at the same time?  I think this needs more work

11. Message API
    The Message API falls way short, IMO, of what we had original 
discussed way back when we started this project.  It is not simple, nor is 
it pluggable.  Currently, it relies heavily on SOAP specific semantics and 
is not clear how exactly I would go about plugging in support for a new 
protocol (XML-RPC for example). 

    The object model/hierarchy is confusing and poorly laid out, 
especially if we are shooting for pluggability.  The code itself is overly 
complex and its not clear which classes do what.  This makes it hard to 
trace what is going on where.

    A SOAP message may use multiple encoding styles, each encoding style 
may define a different type mapping for QName's.  I might have missed it, 
but I don't see any support for handling this case.  Right now, the code 
seems to assume a single encoding style for all cases (an encoding style 
being a collection of type mappings).

12. Core Handler/Chain architecture
    Too many classes.
      - Why do we need Handler and BasicHandler, why not
        make Handler an abstract class so we can get rid
        of the extra class (BasicHandler)
      - Same thing with Chain/SimpleChain, 
        TargetedChain/SimpleTargetedChain
      - Handler, Chain and TargetedChain do not have to 
        be interfaces.

13. Configuration
    I Don't like the push-style configuration (doEngineConfig()...) I'd 
prefer a pull-style configuration (getHandlerRegistry()...)
    Is there a really compelling reason to have the push-style 
configuration?  If not, I'm going to -1 it and change it to a pull.

14. Strategies?? 
    What the heck are these? What exactly are they for? It's not clear.

15. Overall object model
    I think that a lot can be done to clean up the overall object model.


I've got my fireproof parka on so you can start flaming me now ;-)

- James M Snell/Fresno/IBM
    Web services architecture and strategy
    Internet Emerging Technologies, IBM
    544.9035 TIE line
    559.587.1233 Office
    919.486.0077 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