p2 family

Folks,
Let me reiterate Oracle's views on the pattern discussion that I 
promised to write with respect to some of David's questions [1]

1. In order for a pattern to be useful from a client's perspective, we 
think it is best to a pattern based on client's expectations as to 
whether a message that serves as a response is expected to be delivered 
to the client or it is sent to a third party. This is quite different 
than having a pattern where the response may or may not return back to a 
client. In our opinion, a pattern where such an undeterministic 
behaviour is implied has too many degrees of freedom (and hence 
probability for error) for tools to assist in generating automatic code 
generation for clients.

Per remaing issue p2c1 vs p2e, we think that p2c1 is a useful pattern. 
It can encapsulate several other patters, such as p2d, p2d1, p2e. We 
agree with this. In order to "drive" this pattern, however, two other 
information items, such as ResponseRecipient and ErrorRecipient must be 
present in the communication protocol between the client and the 
service. Depending on the identities of these parties we get a variation 
of the pattern based on p2c1, such as p2e. One possibility is to provide 
this information in the header(s) during message exchange.

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 
of these two specific information items in the message exchange must be 
clearly specified in order for p2c1 to be useful and to be also used as 
a basis for modeling p2e, and other patterns.

If the pattern requires the service's contract to contain the addresses 
of the response and error recipients, we can imagine that the contract 
will be further specified by the pattern to indicate when and how these 
information items will be present, and the specific behaviour (p2e, 
p2d1, etc.) that the client can expect based on the presence of these 
items. As a result,  the tools can make use of this information and 
generate client specific code. For example, in the classical request 
response case, a client's infrastructure can generate the necessary 
headers by relieving the client application code to specify the 
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 
code will remain the same provided that the receipent's addresses are 
always present in the contract, but additional configuration information 
will need to be supplied to client code generation tools to assume any 
of the sub patterns, such as p2e.

In this manner, one pattern (p2c1) can aid in formulating a variety of 
different patterns by clearly specifying the contract. We are in favor 
of adopting the generalized pattern p2c1 ONLY if

-- 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.

We think that this is the only way we could obtain a useful, but general 
contract that can be tailored depending on what the client needs while 
allowing the service to support multiple variants. Without the details 
of the specific contract, however, we think the contract is not complete 
and we can not use p2c1 only.

Among the other variations of the p2 family, we think that the p2c1 and 
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, 
instead of  categorizing them into the same family. The p3 familiy makes 
only sense as a variation of p2, and can not apply everywhere. So, it is 
more useful to indicate this variation in the p2 family when "sharing" 
can be assumed  as a special case, but not treat it differently.

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 
"message triggers fault" rule. This makes the utility of some of the 
patterns questionable where the ResponseRecipient and the ErrorRecipient 
are different.

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.

Cheers,

--umit

[1] 
http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0016.html

-- 

Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com

Received on Monday, 21 July 2003 01:30:18 UTC