Axis scenarios and application server integration (long)

[Roberto Chinnici <ro...@eng.sun.com>]

In Tuesday's IRC chat we mentioned three or four high-level scenarios
for Axis, in particular with respect to application servers. They are:

(1a) standalone application processing a SOAP request -- no server;
(1b) Axis on a servlet engine, business logic implemented directly
     using the Axis framework;
(2) Axis on a servlet engine delegating to business logic on an
    application server;
(3) Axis integrated with an application server and quasi-transparent
    to developers.

Now, in (1ab) developers would develop their own handlers or reuse some
predefined ones, and they would also write their business logic so that
it can be directly invoked (in the same process) by an Axis dispatcher.

In (2) developers would use the Axis framework to write handlers, then the
dispatcher would delegate to, say, a stateless session EJB component in a
different server using public APIs. To the application server, the Axis
engine would look just like any other servlet client.

In (3) developers would write components of a pre-existing type, and when
they deploy their applications they would select a checkbox and the deployment
tool would generate and configure all the necessary glue code/descriptors.
Ideally, developers would be able to get by knowing next to nothing about Axis.


Perhaps I'm asking the question just because I missed the original Axis design
sessions, especially those leading to the requirements document, but it seems
to me that the current Axis design is very much focused on (1) and (partially)
on (2).

As I mentioned on Tuesday, (2) is a bit of a compromise, and we know that
we won't achieve a high level of integration (not to mention performance) at
that level. (1) is a fine scenario and is certainly needed in many applications,
but to fit in well with the J2EE model we need to enable (3).


So what I'm arguing for is to take (3) into account more closely.

First of all, in (3) we can assume to have a set of private interfaces to the
container at our disposal to do things like security, threading and dispatching
to a target object.

Moreover, (3) gives us the luxury of having a separate deployment phase during
which we can generate all the code that is needed to handle a given request
on the server (including stubs).

Needless to say, that's a very powerful weapon, and in many cases we could
manage to streamline the parsing and handling of a request and get by using
a much less sophisticated (=> faster) SOAP message representation, especially
when coupled to a real streaming (or pull) parser.

For instance, by knowing (i) exactly which headers entries are allowed in a
request and which handlers are intended to consume them (often just a couple
of header entry types with just one handler assigned to each), (ii) if we
should expect hrefs from the header entries to the body (or viceversa),
(iii) the type of all arguments for a request, we could essentially process
the request in its natural order all in one go, without recording SAX events
or doing chaining or anything like that.


In the short term, I'd like to see Axis provide a direct path to handling
a request without bringing in all of the heavy artillery. This could be seen
as following the "do the simplest thing that could possibly work" principle.
On top of this very basic infrastructure we could easily layer the current
Handler/Message code.

The basic plan is to
    - let the Message class handle all the common details, such as the handling
 of MIME parts and headers, but essentially delegate to a SOAP
 envelope abstract class and its subclasses the representation
 of the contents of a SOAP envelope
    - create different SOAPEnvelope subclasses using different representations
 and implementation strategies (such as pure SAX handling, SAX with
 threads, SAX with recorded events, DOM, streaming/pull parsing, JDOM...)
    - define a MessageContextProcessor with a subset of the methods
 currently in Handler (no undo, possibly more abstract deployment data)
    - let a concrete MessageContextProcessor choose the representation
 of a SOAP envelope that it thinks is most appropriate
    - recreate the Handler/Chain model on top of MessageContextProcessor
    - define a simple deployment descriptor to match the MessageContextProcessor
 abstraction, then extend it to support the present WSDD format

This way we could
    - keep and evolve the current Message/Handler model
    - clearly define a "shortest path" to request handling inside Axis
    - make it possible to use the XML representation best suited to
 handling a given type of request
    - let other people test and possibly integrate their own XML parsing
 and request handling approaches
    - enable the creation of the kind of tools envisioned in (3)

I'd be happy to come up with a more detailed proposal if there is enough
interest.

Roberto

--
Roberto Chinnici              roberto.chinnici@eng.sun.com
Java Software
Sun Microsystems, Inc.