RE: [ws-rx] Issue 060 ammendment to current proposal

["Duane Nickull" <dnickull@adobe.com>]

Although I favor removing them, as an alternative, I would highly
recommend that we at least clarify the abstract nature of AD in the
model and make a normative statement allowing multiple implementation
scenarios.  I feel it is too restrictive as written and prone to similar
interpretation.  At present, we claim this is a concrete specification
and the word "abstract" appears in only two places in the specification.
Delivery is defined fairly concretely IMO.

D

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 


-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
Sent: Thursday, December 08, 2005 12:10 PM
To: Duane Nickull
Cc: Doug Davis; ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Issue 060 ammendment to current proposal

Duane,

AS, RMS, RMD, AD are part of the abstract model and does not necessarily

reflect the underlying implementations architecture. I would think that 
your example of the RMD delivering 1st message to "endpoint" 1 and the 
2nd message to "endpoint" 2 is quite valid per this model, as this model

would consider "endpoint" 1 and 2 as a single entity: AD. The abstract 
model is based on functionality/responsibility of various 
parties/entities involved in the protocol. It allows us to 
define/describe the protocol and specify responsibilities/contracts.

-Anish
--

Duane Nickull wrote:
> Part of me wonders if we should just be talking about RMS and RMD and 
> not AS/AD at all.
> -Doug
> 
> All of me wants to drop AD/AS.
> 
>    1. Implementers should be free to design and control how they
process
>       messages "in order".  As long as they understand the intentions
of
>       the RMS (re-create the stream) and can make decisions on that,
>       that is all we should care about.
>    2. The WS-RX spec should not constrain all service implementations
to
>       a specific model or pattern of AS -> RMS -> RMD -> AD
>    3. We should not constrain service by mandating that any message or
>       message sequence received by the RMD cannot be divided to
multiple
>       endpoints.  The way AD is worded now, it appears that all
messages
>       of one sequence must be "delivered" to another single actor in
>       order.  What if someone wants to have the first in a sequence go
>       to endpoint #1, the second go to endpoint #2 etc?  The RMS
should
>       not care as long as the "externally visible aspects" of the
>       service match their expectations.
> 
> There are several other reasons but for these alone I would prefer to 
> drop AD, AS from the spec and perhaps replace it with some words that 
> reflect the real intention which I believe is to allow the RMD to 
> understand the sequence intentions of the RMS yet leave implementers 
> free to handle the intentions in a way they see fit.  We should stick
to 
> "externally visible properties" only and not dictate specific models 
> behind a service interface.
> 
> Duane
>