[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: The DSML 2.0 proposal is not yet transport independent.
At the face to face, we agreed that transport independence was a goal of the DSML 2.0 effort. However, it seems to me that the current proposal does not satisfy that goal. There is an assumption of a connection oriented transport, with reliable delivery of messages which are guaranteed to be in order. I think we may want to support other forms of transport, such as SMTP or various message oriented middleware products. If an envelope of requests is sent and an envelope of replies is received, the sender is not dependent on a synchronous connection in order to reliably associate the former with the latter. Note that RFC2251 does not have this inherent limitation. It associates a message ID with each request and response. I think that DSML 2.0 should do the same. This also cleans up a feature of the current design that seems ugly to me, which is that the association of requests and responses is positional within the envelope. If connectionless transports are to be supported, the call-and-response model is not the only processing model in which DSML 2.0 can be used. A series of requests can be queued up, and the responses may be received asynchronously. This processing model is also useful when a synchronous connection is present: for example, LDAP over TCP supports this model today, and therefore if we also adopt it in DSML 2 we preserve RFC2251 function with fidelity -- another goal we adopted at the face to face. Further, if processing models other than call-and-response are supported, there is no reason not to support unsolicited notifications, and no additions to DSML 2.0 would be needed to support, for example, LCUP. LCUP relies on unsolicited notifications, and (when completed) it will be a very useful means of ensuring a certain level of data consistency, so DSML 2.0 should not prevent its use. If an application must operate in the call-and-response model, that application can still poll periodically for unsolicited notifications, where the polling frequency would correspond to the level of data consistency required, -- John McGarvey, IBM
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC