axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <NAKAM...@jp.ibm.com>
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
architecture.
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
architecture
and get its role-based access control over multiple containers, etc.
As for transaction, a collection of handlers could run in a transaction
context.
I hope that it makes.
Best regards,

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


From: Roberto Chinnici <roberto.chinnici@eng.sun.com> on 2001/05/03 10:06

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

To:   axis-dev@xml.apache.org
cc:
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
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.






Mime
View raw message