axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: TypeMappings - lifecycles and locations
Date Sat, 09 Jun 2001 21:20:54 GMT
> Before commenting further, I want to make sure that we are speaking the
> same language.

Good call - I think perhaps we're not. :)

> To me a "MessageContext" is the "Content in which a Message is to be
> evaluated".  I don't see a one to one mapping here, in fact, I do see any
> reasonable application (particularly one concerned with performance) as
> reusing the message context between messages.

OK.  I don't necessarily agree with this, but I'm open to the idea.  IIRC, the
original conception of a MessageContext was more like "the bag-o-stuff that
goes along with a particular message, and a way to relate a response to a
request."  In other words, a MessageContext was conceived to be, rather than
reusable, a very lightweight object (much like a ServletRequest), containing
the messages and various properties set by the transport layer and any Handlers
who wish to put stuff there, but all about THIS PARTICULAR request.

There's some specific stuff that EVERY message needs, like
targetService/serviceHandler - that gets pulled out into actual member
variables.  The rest is properties in the bag.

> The way that the AxisServlet is currently written, there is a new
> MessageContext created per Message.

As we'd spec'ed it originally.

> The way that the SimpleAxisServer is currently written, a MessageContext is
> reused for each message.  This currently requires the application to be too
> aware of the internals of a MessageContext currently, but I was hoping that
> we would move much of the logic that resets the internal elements into a
> single "reset" method in the MessageContext.

This is an interesting tack to take, but I might toss it back by asking "what
are we currently doing that makes a MessageContext expensive, and how can we
change that?" instead.

For instance, some of the stuff we're putting in there (for instance, the
handler/service registry references, the class loader, etc.) really belongs
elsewhere - IMHO, in the AxisServer, since that's the scope where we actually
define registries and such.  I'd rather see the MessageContext get a pointer to
the AxisServer as the first result of AxisServer.invoke(), and then get to this
kind of stuff by asking the server ("reg = myServer.getHandlerRegistry()").

Since this is true on the client also, I believe (and have always believed, in
fact) that there's call to factor an AxisEngine class out as follows:

class AxisEngine {
  public HandlerRegistry getHandlerRegistry() { ... };
  ... other common stuff ...
  abstract public void invoke(MessageContext msgContext);

class AxisClient extends AxisEngine {
  public void invoke(MessageContext msgContext)
      (serviceReq, globalReq, transportReq, sender,
       transportResp, globalResp, serviceResp)

class AxisServer extends AxisEngine {
  public void invoke(MessageContext msgContext)
      (transportReq, globalReq, serviceReq, service,
       serviceResp, globalResp, transportResp)

Incidentally, we might want to have the option for the class loader in
particular to be service-specific instead of server-specific....  This gets
into a larger question about whether we envision Axis Web Services to be always
deployed in the same webapp as an Axis engine, or whether each webapp can have
services that share an Axis engine.

So that's my take - make the MessageContext as lightweight as possible.  That's
not, as I think about it, incompatible with re-using them; it's just perhaps a
difference in how we think about it.  If a given transport is doing one message
at a time, it could certainly clear and reuse an MC as the SimpleAxisServer is


View raw message