Re: "From the point of view of the service"

Amelia A. Lewis wrote:

>The use of the phrase (see subject header) caught my attention over the weekend, and out of idle interest and a desire to stir up the trout pond, I investigated.
>
>On investigation, it seems to me that the only reason that we need to say that a WSDL instance describes interactions "from the point of view of the service" is because of the <input> and <output> elements.  Without this "point of view" context, "input" and "output" are problematic.
>
>Suppose, instead, that operation looked something like this?
>
><operation mep="http://www.w3.org/2003/13/wsa/meps/request-response"
>           xmlns:rr="http://www.w3.org/2003/13/wsa/meps/request-response">
>  <message name="rr:request" direction="toService" [other attrs] />
>  <message name="rr:response" direction="fromService" [other attrs] />
>  <fault name="rr:xyzzy" direction="fromService" [other attrs] />
></operation>
>
If  the element <message name="rr:request"> has a "direction" attribute 
set to "toService", then
the elements <message name="rr:response"> and <fault name="rr:xyzzy"> 
must have a "direction" attribute set to "fromService". Why ? the 
rr:request going to the service, the service is then the rr:responder 
node and then reading the rr MEP spec, we know that the rr:responder 
node will send either a rr:response or a rr:xyzzy fault... Therefore, 
defining the directionality of one message gives the directionality of 
all messages (at least for the 7 patterns we envision) => potential 
redundancy and inconsistency if direction of all messages is made explicit.
Personly, I prefer factorizing this information by identifying the node 
that the service wants to be at the operation level (i.e. have a 
required node attribute at the operation level and optional 
directionality attributes at the message level).

Some entities might nevertheless be interested in explicit 
directionality information of messages in WSDL, the use case being 
firewalls. If the firewall knows the mep, it does not need this info, 
but what if it does not know the MEP ?
IMHO, all that is needed is an xml schema that will add the following 
constraint (example of the rr mep) :
    - if the "node" attribute is set to "rr:responder", then :
            - the <message/> element whose "name" attribute is 
"rr:request" has a "direction" attribute which is optional and whose 
fixed value is "input"
            - the <message/> element whose "name" attribute is 
"rr:response" has a "direction" attribute which is optional and whose 
fixed value is "output"
            - the <message/> element whose "name" attribute is 
"rr:xyzzy" has a "direction" attribute which is optional and whose fixed 
value is "output"
    - if the "node" attribute is set to "rr:requester", then :
            - the <message/> element whose "name" attribute is 
"rr:request" has a "direction" attribute which is optional and whose 
fixed value is "output"
            - the <message/> element whose "name" attribute is 
"rr:response" has a "direction" attribute which is optional and whose 
fixed value is "input"
            - the <message/> element whose "name" attribute is 
"rr:xyzzy" has a "direction" attribute which is optional and whose fixed 
value is "input"
This schema could for instance be part of the rr MEP spec.
All the firewall needs then is this schema (and the wsdl) to get the 
direction of each message.
This schema allowing the attributes to be optional, the wsdl can contain 
explicitly or not the direction of messages.
This schema would also be useful for wsdl authoring tools to 
validate/prefill <wsdl:message/> elements (including their directions) 
for unknown MEPs.

>MEPs are already defined in terms of the service (that is, because they use "input" and "output" they are also required to state that the MEP is from the point of view of a 
>
IMHO, SOAP MEPs are NOT defined in terms of the service. For WSDL MEPs 
definition, we should choose either to follow SOAP's definition or to 
define them in terms of  the service.

>service).  This linguistic adjustment, using "toService" and "fromService", makes that explicit.  An additional benefit of placing direction into an attribute (no matter what the content of the attribute; one could imagine continuing to use the ambiguous "input|output" pair) is that fault directionality can now be described as well.
>
>This may annoy some folks who like the mirror model, but I submit that there are a fair number of MEPs in which the capabilities of the service and the capabilities of the service partner are clearly distinguished, so that it is not inadmissable to designate them server and client.  The requirement that every MEP has a mirror presumes a service-to-service (or peer-to-peer) model, in my opinion, and unnecessarily restricts the universe of services that may be described.
>
I am not sure to understand...
MEPs are supposed to be abstract at the WSDL layer,  will there still be 
any notion of server and client at this level ?
 From a SOAP perspective, all partners in a MEP are defined as nodes. 
Does a MEP, in which a service cannot take the identity of a particular 
node, exist ?

>However, please take this as observation, rather than a proposal.  Should someone find this interesting enough to make a proposal of it, I'll back it, but I don't feel strongly enough to want to argue about (err, I mean "discuss") it.
>
>Amy!
>  
>