Transports

[Glen Daniels <gd...@macromedia.com>]

There are two fairly different kinds of transports - senders and listeners.

Listeners are server-side, and are essentially entry points into the system.
So some external piece of code (such as a servlet) would act as a listener,
and its responsibility is to a) create a MessageContext containing whatever
information it wants to throw in there (including its own name), and b) hand
it off to an AxisServer instance which it somehow locates.

Senders are "client-side", though they can certainly exist on the server as
well.  The core is a piece of code which is the actual "sender" - i.e. the
HTTPSender, for instance.  This guy might actually wait around for a
response (as in the HTTP case), or might just be responsbile for sending a
one-way message (i.e. an SMTPSender).

Now, in both of these cases, there are likely to be transport-specific
request and response Handlers associated with the listener/sender.  It would
be nice if we could associate this stuff together with a deployment pattern
which looks something like this:

<listener name="HTTPAdmin" request="HTTPAuth,URLMapper"
response="MessageSigner" />
<clientTransport name="SecureMailOut" request="MailSigner"
sender="SMTPsender" />

These descriptors could easily turn into classes like the following:

class ListenerTransport extends SimpleTargetedChain {
   // pivot is either blank (because the engine handles splitting the
input/output work)
   // or a Handler which calls the global/service chain logic (will get into
this more in
   // another msg).
}

class ClientTransport extends SimpleTargetedChain {
   // pivot is the sender
}

And then we can have Transport registries where they live, referenced by a
single name instead of separate "request" and "response" names.

I think this is a much cleaner architecture, and would like to make these
changes.  In fact, I've already got a basic version of this working on my
system, including the ability to enable particular services over particular
listeners (I may have mentioned that last part on Friday too).

On a related note, we'll need to make sure we're careful about synchronizing
the right stuff once multiple threads can be running through the AxisServer
at the same time.  Essentially, I think the pattern is probably to make the
server multithread-safe except for deployment changes - i.e. N requests can
be serviced at a time, until someone grabs the "changing stuff" lock, at
which point everyone else blocks until that update is complete.  But this
issue probably warrants more thinking and a separate thread.

Glen Daniels
Macromedia
http://www.macromedia.com/
                                Building cool stuff for web developers