Notes from tea with Glen

[Rob Jellinghaus <ro...@unrealities.com>]

Over the weekend Glen visited San Francisco, and on Saturday morning he and
I met in a Haight Street coffee shop to talk about Axis.  Here are my notes
from our conversation.  Any errors are fully my responsibility.

I also know that much of this may be already underway.  Hopefully I'll get
some more visibility on our design roadmap through responses to this email :-)

------------------------------------------

Most of our discussion revolved around transports and sessions.  We started
off talking about WSDL.  WSDL is mainly used for description (describing
valid types and messages).  There are some parts of WSDL (mainly the
bindings) that are relevant to deployment.  The usual use case for Axis
will be generating ServiceDescriptions from WSDL, but it's a remotely
possible use case that someone could have a fully fleshed out WSDL file
with binding information that could be used for service deployment.

In general, we need a way, for any transport, to add, remove, or change
endpoints for that transport.  In general, a transport endpoint may be:
- bound to a single service, or bound to multiple services selected somehow
(from SOAP header, or URL, or HTTP header, or some other transport context)
- configured to support a continuing session, or configured to be stateless
(an entire service might also be optionally configured as session-aware or
not)
- bound potentially to a different transport chain than other endpoints
over that transport (i.e. if one endpoint requires authentication while
another is a public service)
- disabled (stopped) without being undeployed

So the transport listeners need some notion of endpoint and per-endpoint
chains.  Or else, we have multiple transport listener objects [as per
Glen's mail from a little while ago], one per endpoint.

Glen mentioned JMX, Java Management Extensions.  JMX provides a simple
interface for starting, stopping, and enumerating services, and allows
arbitrary method calling and hence arbitrary management.  He would like
there to be JMX interfaces to:
- the Axis engine itself (to enable message processing to be started /
stopped / thread-managed)
- each transport listener (to allow turning off selected transports, or
managing properties such as polling time)
- each Axis service (to allow individual services to be turned off and on,
or updated and tuned, while remaining deployed)
- each Axis provider (to allow tuning of session pools, etc.)

Right now deployment implies turning a service on permanently.  It would be
good to change that.

Right now Axis has no session support.  In general, session management is
about writing a handler that takes some context (from the transport (i.e.
cookies, URLs), or from the message (i.e. in a SOAP header)), and mapping
that context into some message state that can be referenced by the rest of
the chain.

We could add a sessionContext field to MessageContext.  sessionContext
would be a bag of properties associated with sessions -- whatever is
appropriate for the particular session system being used.  The
sessionContext field would be filled out by some handler that understands
session semantics, and most other handlers would never need to know that
the message is part of some session.  (Rather like how the SOAP action is
handled now, with one handler setting it and most other handlers never
referencing it.)

There may be provider-specific state relating to sessions.  There could be
a SessionData object which is maintained by a particular provider with
respect to a session using that provider.  Or, maybe the sessionContext is
passed into the provider, and that's all Axis knows.  [RobJ: We need some
use cases here but I'm not the best person to write them, as I'm more
clueless than I should be about app servers....]

We could potentially implement "application scope" for a particular chain
by defining a handler that always provided the same session context for
invocations on that chain's endpoint.  Or maybe there's a better way.

We then slid over to the client side.  On the client side, there are a few
use cases for session management:
- the session may be kept completely by the transport (opaquely to the
client), as with cookies
- the client may need to track the session state in a transport-specific
way (as with URL rewriting, see
http://www.weblogic.com/docs51/examples/jsp/URLEncode.jsp)
- the client may need to track session state in a transport-independent way
(as with SOAP headers)

Perhaps there is a ServiceClient object.  

ServiceClient stock = new ServiceClient(new
HTTPEndpoint("http://localhost:8080"), new
ServiceDescription("http://localhost:8080/stock.wsdl"));

If the service is a session-oriented service, the ServiceClient itself is
what keeps the sessionContext on the client side.  For instance, if the
service performs URL rewriting, the ServiceClient's chain contains
transport input and output handlers that use or store the relevant URL
fragment in the sessionContext.  A new ServiceClient, when first called,
passes an empty sessionContext down the chain (in its new MessageContext);
when the chain's invoke returns, the ServiceClient keeps the returned
sessionContext.  A subsequent invoke on that ServiceClient will use the
updated SessionContext. 

This basically keeps the handlers as stateless as possible, and allows us
to have many client-side sessions with each session's state kept in only
one object (the ServiceClient).

OK, now that that's sorted out, what about service descriptions?
Basically, service descriptions are as minimal as possible to give Axis the
information it needs.  Sometimes service descriptions are used to avoid
needing xsi:type declarations on all returned fields.  They also allow some
validation before sending on the client side.  (I am now realizing they may
also ultimately describe the service's session policy.  Glen suggests that
WSDL extensions might subsume a lot of Axis deployment information....)

I need to move the functional test .xml files to xml-axis/java/test so they
aren't confusing the issue.

Glen and I (anyone else? :-) would also like to see some UML diagrams for
all this.  Are there any decent Windows freeware or cheapware UML tools?
Or, any freeware UML templates for Visio (which I own)?  ...I have a pretty
old Visio version though, sigh....

------------------------------------------

Yes, those notes are somewhat disorganized, but so was our conversation :-)

I am interested in building out the initial "transport endpoint" support
(though it sounds like Glen's already been working in that direction).
After that, perhaps an SMTP listener, and then session support?  Who else
is involved in session-related or transport-related work at the moment?

Cheers,
Rob