Re: p2 family

Some comments.  Hope you don't mind.

On Sun, 20 Jul 2003 22:30:09 -0700
Umit Yalcinalp <umit.yalcinalp@oracle.com> wrote:
> We think that the client is the supplier of these information  items
> to the service and the client determines whether the response, for
> example, is returned back to the client or to the third party. Hence
> the utility 

I'm not at all certain that this is always true.  One of the commonest
examples I can think of is email ("retrieve lost password").  Send an
email to the service.  Email goes to a pre-specified address, which may
or may not be the address of the requester.  It is *not* communicated to
the service, and indeed, allowing the client to specify the recipient of
the response undermines the whole purpose of the decoupling of request
and response.

> receipent's address(es). When the client application wants to send the
> 
> response to a third party, the receipent's address will be supplied by
> 
> the client's application explicitly.  We can envision that the service
> 

Or in some other pattern-specific fashion?

> -- WSDL wg specifies these addional information items as part of the
> pattern-- how they are communicated between the client and the server
> is defined.-- default cases (if any) are clarified for variations.

This looks pretty good to me, and I think this can be used to start the
discussion on what conclusions to report.

> p2e are likely to be used most. It seems to us that the multicast 
> responses may be modeled as combinations of more than one patterns, 

*sigh*

Careful, please.  It is also possible to characterize request response
as input-only followed by output-only.  If there is a good *reason* to
state "these patterns do not belong to the family," I think we need to
hear that.  If the reason is "it can be defined another way," I don't
think that that's convincing.

> 3. Wrt modeling faults, we think that the fault is useful only to the 
> recipient of the response. Therefore, we can collapse the rules to
> favor 

I disagree.  Emphatically.  Loudly.

> "message triggers fault" rule. This makes the utility of some of the 
> patterns questionable where the ResponseRecipient and the
> ErrorRecipient are different.

In general, faults should go *either* to the target receiver (the
semantic associated with "fault replaces message") or to the sender of
the message which caused the fault (the semantic associated with
"message triggers fault").  Message triggers fault, in general, is *not*
designed to send faults to the designated recipient.  It is designed to
return faults to the sender of a fault-causing message.  In a number of
cases, the difference is significant.

> 5. We think that the patterns that the WSDL document defines is
> written with respect to the application's perspective.   Therefore, it
> is likely that "different" MEPs may occur in the binding&transport
> layer in modeling an application MEPs. So, the correspondence of the
> two sets will require some further thinking. One example we have is
> the one way pattern that can be implemented over HTTP binding and will
> generate a response. In this case, the application will not be
> expecting a "response". It will be the client infrastructure's
> responsibility to consume the "response", but not the client
> application's.

I'm sorry, but I don't quite understand this paragraph.  Could you
clarify, please?

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

Received on Monday, 21 July 2003 13:03:42 UTC