Re: Summary: 22-24 Sept 2003 WS Desc FTF

On Wed, 01 Oct 2003 00:30:47 +0600
Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:

> Hi Amy,
> 
> > I wasn't asked to supply justification for the outbound-first
> > operations, which TIBCO *has* advocated, strongly.  The
> > disappearance of the old multicast solicit response is a result of
> > changes in the definitions, such that the outbound-first operations
> > are now, theoretically (apart from the trifling problem that fault
> > replaces message is probably inappropriate), modeled by existing
> > outbound-first patterns.
> 
> I'm more confused. We still have the old solicit-response and 
> output-only patterns, at least as of the Sept. F2F! What's the
> diff between what we have now and what was in WSDL 1.1? 

Better definition.  Note, thought, that I said "old multicast
solicit-response", referring to the pattern that was listed last in part
two for a long time.  It was separate from the output-input pattern.

> Clearly I haven't understood this pattern stuff at all. I wonder
> how users will deal with it.

The multicast solicit-response pattern was "rolled into" the
solicit-response pattern on the basis of the language that was
introduced to say that, basically, we only reflect information into a
pattern description if it is important to more than one participant. 
The service cares that it is sending a message multicast.  Each of the
receivers doesn't care; the rules that they follow are to send [no
response] or [one response] or [one fault].  Multicast solicit-response
does *not*, in fact, really work terribly well with the existing
output-input pattern; it would be better to change it by saying 1) it
uses message-triggers-fault, and 2) the input message is optional.

If things are truly so confusing, then I will propose adoption of a
pattern that uses the above modifications, since *that's* what I'm after
(well, that and a notification pattern with message-triggers-fault).  In
pub/sub, the *publisher* is the service, and output-first patterns are
the norm.

Neither I nor anyone at TIBCO has ever advocated the serial unicast
"multi" patterns (which I, personally, thought of as simply clouding the
issues, but I probably shouldn't cast nasturtiums).  Apparently they
confused lots of people, who associated them with the arguments I've
made for multicast-capable patterns.  They are completely unrelated. 
They are *not* my fault.  That we have removed confusion, by removing
the serial unicast patterns (unless someone else steps forward to offer
defense), is probably an advantage to the readers of the spec, who won't
have all the backstory about multicast and the rest of it.  I do not
regard this decrease of confusion as a good reason for removing the
material that *does* support multicast.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 30 September 2003 15:12:52 UTC