Re: On the Operation Name Mapping requirement

This is an excellent example. If the interfaces had been specified as follows:

<definitions targetNamespace="nac:interfaces:initiator">
  <interface name="Player">
    <operation name="GameOver"
pattern="http://www.w3.org/2004/08/wsdl/out-in">
      <output element="nac:game-over" />
      <input element="nac:game-over-response" />
    </operation>
  </interface>
</definitions>

<definitions targetNamespace="nac:interfaces:reactor">
<interface name="Player">
  <operation name="GameOver"
pattern="http://www.w3.org/2004/08/wsdl/in-out">
    <input element="nac:game-over" />
    <output element="nac:game-over-response" />
  </operation>
</interface>

<interface name="Player" extends="initiator:Player reactor:Player" />

i.e. the response to a GameOver operation had its own distinct element
name, then you wouldn't run afoul of the ONM!

It's quite logical, after all: with the interfaces as originally defined,
if you see a nac:game-over message coming your way and you implement
the Player interface, without a correlation facility you cannot know
if it's a request or a response. So, when programming purely to the
abstract (=interface) layer, you need some extra bit of information.
The ONM requirement is that you have to tell the world (your clients,
that is) what that is.

Glen seems to bring up the point that a conflict between in-out and
out-in operations should be treated differently than, say, one
between an in-out and an in-only operation for the purposes of the
ONM. Unfortunately, given the extensibile nature of MEPs, I have a
hard time coming up with a general rule that won't cause problems
later on and that will still catch a in-out/in-only conflict.

>>We can think of other business cases where it is the service 
>>logic that determines the dispatching of a particular 
>>operation (based on contents, protocol, etc.) and not the 
>>uniqueness of the wire format.

So do I. But you have to state that in the WSDL, for the benefit
of your clients (ahem, I meant to say "requester agents" ;-) ).

Roberto


Glen Daniels wrote:
> 
> Hi Savas, all:
> 
> The idea of the ONM requirement is that the description should, in some
> way, give you a hint as to how a particular operation is determined in
> the absence of unique wire signatures.  In the case below, there is no
> conflict, since one operation is in-out and the other is out-in.
> Therefore, from the service's point of view, it is either going to
> receive a GameOver message (and therefore the operation is
> reactor:GameOver) or itself decide to send one (and therefore the
> operation is intiator:GameOver).  The wire signatures are enough to
> determine which is going on.  If both send them at the same time, I
> would imagine that both operations would be invoked simultaneously,
> generating a pair of equivalent messages in response.
> 
> To extrapolate out a little from what you say below, if you're
> interested in modeling a system which has a complex state machine
> involving lots of decision points based on arbitrary ordering of
> incoming messages, I don't think WSDL is really what you want.  I would
> think you'd use something like BPEL or BPML for this.  WSDL is
> essentially about Web Service *operations* and that's why we have the
> ONM requirement - if you can't distinguish which operation you're
> talking about, you may as well just have an undifferentiated bag of
> messages and not use WSDL at all.
> 
> --Glen 
> 
> 
>>-----Original Message-----
>>From: www-ws-desc-request@w3.org 
>>[mailto:www-ws-desc-request@w3.org] On Behalf Of Savas Parastatidis
>>Sent: Monday, October 04, 2004 4:51 AM
>>To: www-ws-desc@w3.org
>>Subject: On the Operation Name Mapping requirement
>>
>>
>>Dear all,
>>
>>Jim Webber and I are trying to get our heads around the 
>>Operation Name Mapping (ONM) that exists in the current draft 
>>at the interface level but will be moving to the service 
>>level, as I read in one of the threads, in the next draft. 
>>
>>We have been working on a very simple Noughts-and-Crosses 
>>(tic-tac-toc) example for using SOAP and WSDL. The two 
>>players are effectively two services exchanging messages. The 
>>description of each of the services has to be symmetric, if 
>>we are to reason about their ability to meaningfully exchange 
>>messages. This means that we have to describe both the 
>>"initiating" and the "reacting" message exchanges. Here's 
>>what I mean...
>>
>><definitions targetNamespace="nac:interfaces:initiator">
>>  <interface name="Player">
>>    <operation name="GameOver"
>>pattern="http://www.w3.org/2004/08/wsdl/out-in">
>>      <output element="nac:game-over" />
>>      <input element="nac:game-over" />
>>    </operation>
>>  </interface>
>></definitions>
>>
>><definitions targetNamespace="nac:interfaces:reactor">
>><interface name="Player">
>>  <operation name="GameOver"
>>pattern="http://www.w3.org/2004/08/wsdl/in-out">
>>    <input element="nac:game-over" />
>>    <output element="nac:game-over" />
>>  </operation>
>></interface>
>>
>>A Web Service that supports both these roles is described as:
>>
>><interface name="Player" extends="initiator:Player reactor:Player" />
>>
>>What do the above interfaces mean? The first one tells us 
>>that the service at some point will send a <game-over> 
>>message and will expect to receive a corresponding 
>><game-over> message as a result. The second interface tells 
>>us that if a service receives a <game-over> message, it will 
>>respond with the same message. It's just happens that the 
>>logic of the services requires that the messages are the same. 
>>
>>Since we are in a loosely coupled world, we don't really know 
>>which of the two players will send the <game-over> message 
>>first, so we need to support both behaviours at each service. 
>>This is absolutely fine since the logic of the two services 
>>can cope with the scenario. "Oh... I just received a 
>>'game-over' message. The other player is telling me 
>>something. I have to reply accordingly". Or, "Oh... I just 
>>received a 'game-over' message as a reply to the one I 
>>previously sent. That's the other player's response". And 
>>"what if both endpoints send the same message, at the same 
>>time?" you ask. Well, we use WS-Addressing to cope with this 
>>situation ("ReplyTo" header).
>>
>>
>>However, the ONM requirement doesn't allow our services to be 
>>described in this way since the wire format is the same for 
>>both GameOver operations. The service logic requires us to 
>>send messages <game-over> messages on the wire (and this 
>>works in our implementation) but WSDL 2.0 doesn't allow us to 
>>describe it. Should WSDL be so restrictive and direct us 
>>towards a particular way of describing our services?
>>
>>We can think of other business cases where it is the service 
>>logic that determines the dispatching of a particular 
>>operation (based on contents, protocol, etc.) and not the 
>>uniqueness of the wire format.
>>
>>We'd be interested in the WG's comments.
>>
>>Regards,
>>Savas & Jim

Received on Monday, 4 October 2004 18:35:31 UTC