- From: Tom Rutt <tom@coastin.com>
- Date: Sun, 05 Jun 2005 17:30:26 +0200
- To: tom@coastin.com
- CC: Rich Salz <rsalz@datapower.com>, Marc Hadley <Marc.Hadley@Sun.COM>, "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Sorry for the typo in the first sentence below. I would like to clarify that a simple messageId structured type which has a mandatory global URI and an optional Integer is backwards compatible with the LC draft of ws addressing, and provides to ws-RX a message ID which is suitable for their needs. Adding other elements should be justified by a requirement for messageId, which I have not yet seen. The integer index in the messageId is required for scalability and potential ordering. I provided the extensible schema as an example to illustrate how complex the messageId could become. Remember, ws addressing echoes the entire messageID in the correlation header. Information not needed for correlation would be wasted in transmission. Tom Rutt Tom Rutt wrote: > If we decide we an extensible messageId strucutre (which I do not see > as required) we could change the schema to someting like the following > , using an attribute for mandatory globalID, on an extensbile sequence > > <xs:complexType name="MessageIdType2"> > <xs:sequence> > <xs:element name="Index" type="xs:unsignedLong" > minOccurs="0"/> > <xsd:any namespace="##other" processContents="lax" > minOccurs="0" maxOccurs="unbounded"/> > </xs:sequence> > <xs:attribute name="globalId" type="xs:anyURI" use="required"/> > </xs:complexType> > > > Tom Rutt wrote: > >> >> >> >> Rich Salz wrote: >> >>>> If we go this route I'd like to suggest we also add an optional >>>> timestamp field. I've had several requests for WS-addressing to offer >>>> support for such a thing separate from the message id itself. >>>> >>> >>> >>> >>> Can we point to wsu:Timestamp from OASIS WS-Security? >>> >>> >> I had thought about this kind of extensibility, and one option would >> be to make the messageId complex type extensible in some way. >> >> Before we get carried away, however, I think we should consider >> keeping the messageId type just having semantics of identity. >> WS-Reliability has a messageId complex type which has other >> information carried beyond idenity (e.g., first message insequence, >> last message in sequence), which was done for "efficiency" purposes. >> However, this extra information is not necessary for the uniqueness >> of identity. >> >> One reason to have a message id which has a globalId with an integer >> index is for scalability purposes. For examle, an endpoint could >> obtain its globalID URI at bootup time, using an integer counter of >> messages sent as the index. This avoids generating a new globalID >> for each mesage, while keeping the messageId globally unique for each >> message sent. >> >> Another reaons for an integer index is to enabline ordering of ids. >> Both WS reliability and WS- Reliable messaging use the pair as their >> identity. They both also add semantics of sequence to the messageID >> (i.e., they specify that the index must increase by one each time a >> new message is sent, and that the global ID represents a particular >> messageSequence) This sequence ID can be used for >> control opeations pertainig to that sequence (eg. to terminate it). >> >> . >> >> However, in some cases the sequentiality might not be required. Thus >> ws-addressing does not need to include the ordering >> semantics for the integer index . >> >> Now adding a timestamp is going beyond identity, and, for >> orthoganlity purposes, might be better to put somewhere else other >> than in the MessageId structure. >> >> If we do not need extensibility, then ws addressing can have a >> message ID structure as follows (which is backwards compatible with >> the last call messageId syntax): >> >> >> </xs:complexType><xs:complexType name="MessageIdType3"> >> <xs:simpleContent> >> <xs:extension base="xs:anyURI"> >> <xs:attribute name="index" type="xs:unsignedLong" >> use="optional"/> >> </xs:extension> >> </xs:simpleContent> >> </xs:complexType> >> >> >> Tom Rutt >> >>> /r$ >>> >>> >>> >> > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
Received on Sunday, 5 June 2005 15:32:29 UTC