transport protocol independence, sessions, asynchronous transmission

[John McGarvey <mcgarvey@us.ibm.com>]

I have been thinking through what it means to support programming models
other than call and response, and what it means to support persistent
search (LCUP) and unsolicited notifications.

1. SOAP is actually not limited to the call and response model.  It is also
intended for use in asynchronous transports, and SOAP bindings for such
transports (e.g. message oriented middleware) exist today.  However, the
prescribed SOAP bindings for DSML v.2 would not support asynchronous SOAP.
I suggest the following minimally disruptive change: We need to rename the
SOAP DSMLv2 binding to the SOAP RPC DSMLv2 binding.  This leaves room for a
future asynchronous SOAP binding.

2. I have another transport independence concern.  The current draft is
adequate for reliable transports.  For unreliable transports, we need, in
addition to DSMLRequest and DSMLResponse, a DSMLAcknowledge.  Are we
limited to reliable transports for DSML v2, or do we want to add this
additional DSMLMessage?

3. Suppose we want to support persistent search (e.g. LCUP) and/or
unsolicited notifications. I believe this support is important! But it
takes quite a lot of work.  To support LCUP we  need to have persistent
sessions.  There are only two ways I can think of to support persistent
sessions.  (1) We could assert that the session derives from a persistent
transport protocol session, and that the DSML gateway is aware of that
session.  This works for session oriented transports like, say, TCP.
Frankly, there aren't that many such transports, and these may not reach
the kinds of pervasive devices that DSML v2 is intended to support.  (2) We
associate an optional sessionID with each and every DSMLMessage.  This is
what all session oriented protocols do, so I think this is what we have to
do.

The next decision point is, which programming models are to be supported
with persistent session?  I think we should support both call and response
and asynchronous messaging models. To support call and response, we need a
new type of DSMLMessage, which is DSMLOpenSession.  The client uses this
request to get a unique session ID from the server.  In the asynchronous
messaging model, one might be able to do without this: Each message must
contain addressing information to tell the server how to send the reply, so
the client could just assert a session ID. There are no such shortcuts for
call-and-response.

For consistency, we require that DSMLOpenSession always be used to
establish a persistent session, if one is needed.  The server replies
DSMLSessionEstablished, including a unique sessionID (a string).  This
sessionID is then used by the client for all requests associated with the
session. The server will need to save some state in order to route LCUP
updates or unsolicited notifications to the right place.  It associates
with the sessionID the handle of a persistent LDAP session.  For
call-and-response, it also associates a queue with the sessionID, and
esponses to the client will be queued and returned on subsequent requests
from the client.  For asynchronous messaging, it associates with the
session ID the addressing information that describes how to send
asynchronous updates to the client associated with the session.

For call-and-response, we need a way to get the data back to the client.
Since all transfers are initiated by the client, that means we need another
new message, DSMLPollSession.  The possible responses to DSMLPollSession
are: BatchResponse, DSMLAcknowledge, DSMLCloseSession.  DSMLAcknowledge
would be used to indicate that there is nothing in the queue for this
session.  For either call-and-response or asynchronous messaging, we also
need a way for the client or server to end the session: DSMLCloseSession.
We also need some new error codes.

Let's catalog the necessary additions to the spec needed for LCUP etc.:

New optional attribute of DSMLMessage: sessionID
New DSMLMessages: DSMLOpenSession, DSMLSessionEstablished,
DSMLCloseSession, DSMLPollSession, DSMLAcknowledge
New error codes

So -- this ain't entirely cheap, and I imagine a few on this list will barf
to see our lovely spec weighed down in this way.  On the other hand, I
don't think I have made it unnecessarily baroque, and this isn't all that
hard either.  If you want to do LCUP, this is what you have to do.  The
only alternative for LCUP support that avoids all this foofaraw is to
support it only on session oriented protocols for which the programming
model is asynchronous messaging.  I think that's way too limiting.

Regards,
John