RE: i009 Cardinality of properties and their values

Following the discussion on last week's telcon[1] and in fulfilment
of my AI, i withdraw proposal #1 and offer an alternative proposal
with 3 options and an adjunct option to resolve issue 9 
- "Cardinality of properties and their values".

Please note that the aim in raising this issue is not to prevent 
addressing from being used in load balancing, distribution lists,
and other scenarios which require multiple endpoints. The aim is 
to prevent this working group from becoming bogged down discussing
such scenarios or anointing one particular processing pattern to
handle multiple recipients. I suggest that an extensibility or 
layering mechanism should be used to express such processing. 

Also i see this issue is separate to i026, which proposes multiple 
addresses within a single EPR to identify multiple routes to the 
*same* endpoint.

So i offer the following options for the cardinality of the message 
informational headers (destination, source, reply, and fault):

  Option#1  Status quo from the WS-Addressing member submission.
            Cardinality of EPRs constrained in the core to 
            0 or 1 and therefore also in any derived bindings. 

  Option#2  Original proposal - preclude use of multiple recipients
            in our current bindings. Unconstrained in the core,
            but no specific processing defined for multiple EPRs.
  Option#3  Cardinality of EPRs unconstrained in the core spec or 
            bindings. No processing model defined for multiple EPRs.
If we select Option#3, i'm unconvinced that the MEP alone is 
sufficient to constrain the number of EPRs which could legitimately 
appear in a message, given even a simple in-out MEP could use 
multiple EPRs to provide fail-over or load-balancing.

I therefore propose that if Option#3 is selected, we also provide
an EPR 'processingStyle' URI value. This would default to a value 
indicating the current action for formulating a reply message should
be undertaken with an undefined behaviour for multiple items.
Extensibility could then provide a URI for mailing-list, 
load-balancing, fail-over, etc processing.

For Option#3 the processingStyle could be exposed in our SOAP and 
WSDL bindings as an optional value. 





Received on Wednesday, 1 December 2004 15:34:36 UTC