axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <>
Subject Re: Axis scenarios and application server integration (long)
Date Thu, 03 May 2001 13:28:07 GMT

Hi Robert,
A few weeks ago, I proposed a configuration in which we have a transport
listener on servlet engine,
and have an AxisEngine on EJB, off course taking account of J2EE
Does this configration correspond to your (3)?  At least we have two
benefits here:
security and transaction.  As for security, you can rely on J2EE security
and get its role-based access control over multiple containers, etc.
As for transaction, a collection of handlers could run in a transaction
I hope that it makes.
Best regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668

From: Roberto Chinnici <> on 2001/05/03 10:06

Please respond to

Subject:  Axis scenarios and application server integration (long)

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
tool would generate and configure all the necessary glue code/descriptors.
Ideally, developers would be able to get by knowing next to nothing about

Perhaps I'm asking the question just because I missed the original Axis
sessions, especially those leading to the requirements document, but it
to me that the current Axis design is very much focused on (1) and
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)
that level. (1) is a fine scenario and is certainly needed in many
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
container at our disposal to do things like security, threading and
to a target object.

Moreover, (3) gives us the luxury of having a separate deployment phase
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,
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
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
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
as following the "do the simplest thing that could possibly work"
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
 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
 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
 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


Roberto Chinnici    
Java Software
Sun Microsystems, Inc.

View raw message