[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: transport protocol independence, sessions, asynchronous transmission
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC