RE: Message Expiry & the WS Architecture

David,

I completely agree with you that, as we address more and more elements of the Extended Web Services Architecture, we will inevitably encounter many cases of overlapping Features. In some of these cases it might make good sense to identify and extract the overlapping parts as self standing elements that could be used in combination with other Features, as you mention below.

It might be time to address the issue of Features combination within WSA. One natural place to discuss this could be the Web Services Extension Framework document at [1], which Chris Ferris has been working on.

Chris, have you had a chance to give any thoughts to the subject of Features Combination so far? (There might actually be some commonality with the Composition discussions you have been participating in within the WS-I Basic Profile).

Ugo

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-ext.html


> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Sunday, December 15, 2002 11:51 AM
> To: www-ws-arch@w3.org
> Subject: Message Expiry & the WS Architecture
> 
> 
> 
> I want to start a new thread on an Architectural issue and 
> use the idea of
> Message Expiry to illustrate it. Note that I could just as 
> easily have used
> other concepts as it is the principle that I want to bring out.
> 
> Recently there has been a lot of discussion on Reliable 
> Messaging. One of
> the ideas in LEVEL 1 of Reliable Messaging that I described, 
> was the idea
> that a message expired and should not be processed after a 
> certain point in
> time.
> 
> Now the obivous way to identify when a message expires is to 
> include an
> "ExiresAt" header in a SOAP Feature/Module in a message that 
> contains the
> time after which the message must not be processed - this is 
> what ebXML
> Messaging did with its TimeToLive header.
> 
> Now for some questions ...
> QUESTION 1. Is the idea of Message Expiry **exclusive** to Reliable
> Messaging?
> If the answer is yes, then you can easily include how Message 
> Expiry works
> in the RM spec. But I don't think so this is likely. I can 
> quite imagine
> sending a message that has an expiry time, but not care if 
> the message was
> delivered. So there is another question ...
> 
> QUESTION 2.  If the definition of Message Expiry is not in 
> the RM spec, then
> where should it be defined and who should define it?
> You *might* argue that some very basic headers like 
> MesssageId goes in the
> XMLP spec to support some of the ideas that Assaf has been 
> putting forward,
> but should Message Expiry be included in XMLP as well? If it 
> does not go in
> the XMLP spec, then it must go somewhere else, but where and 
> what group
> should be responsible for defining it. Some options include:
> 1. It's own spec, developed by a separate group - which one
> 2. It's own spec developed as part of RM
> 3. Part of the RM spec 
> 
> This doesn't just apply to Message Expiry and Message Id, it 
> applies to many
> other areas as well such as:
> 1. Message Routing & Addressing
> 2. Message Content lists
> 3. Choreography Managment
> etc, etc ...
> 
> I could go on, but I would like other people's views.
> 
> David
> 
> Director, Product Management, Web Services
> Commerce One
> 4440 Rosewood Drive, Pleasanton, CA 94588, USA
> Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> 
>

Received on Monday, 16 December 2002 12:14:01 UTC