Use case 5

Oops. I sent it to Glen, but not to the rest of the tf. Must be getting
sleepy. 

--umit

-----Original Message-----
From: Yalcinalp, Umit 
Sent: Tuesday, Feb 15, 2005 23:54 PM
To: 'Glen Daniels'
Subject: FW: REMINDER : Action Items re: Use Cases

 
>-----Original Message-----
>From: public-ws-async-tf-request@w3.org 
>[mailto:public-ws-async-tf-request@w3.org] 
>Sent: Tuesday, Feb 15, 2005 8:21 AM
>To: public-ws-async-tf@w3.org
>Subject: REMINDER : Action Items re: Use Cases
>
>
>
>Several of us (including me) have use-cases to write up as per last
>week's call.  It would be great if we could get these on the table by
>tomorrow so we can look them over and discuss on tomorrow's call.
>Anish, Marc, Roberto, Umit, do you think you might be able to do this
>today?

Well, here it is. I did not have the time to check for accuracy this
late in the evening, (apologies in advance) but this will illustrate the
point. 

>
>We're looking for: (I think this captures what we discussed last wk)
>
>* Description of the scenario
>


Scenerio: (5) I am borrowing the idea from WS-I Sample Apps scenerios
[1]. I will reutilize a simplified version of the part of the WS-I
Sample Apps to use two separate operations with one-way messages to be
correlated as a callback. 


A warehouse submits a purchase order to a manufacturer. When the
purchase order is ready, the Manufacturer notifies that warehouse by
sending a ShippingNotice to the warehouse that made the purchase order
request to indicate that the order has been shipped. 

Since there may be different warehouses that make purchase order
requests to a manufacturer, it is desirable that this scenerio is
modeled by using two separate one-way message exchanges that are
provided by two separate parties, the requestor and the response
provider respectively. In addition, assume that different warehouses
have different requirements as to how they would like to receive
shipment notifications, via email, via SOAP/http, via snail mail.
Further, the way the purchase order is submitted (binding/transport) is
not necessarily related to how the response/callback
(ShippingNotification) should be delivered. This last requirement is NOT
part of the WS-I scenerio document, but it happens in the real world. 

Typically, relating the submission of a PO expense with the notification
of the shipment is desirable as one message exchange. However, these two
"activities" can not necessarily modeled as a single request response
MEP due to the limitations in WSDL we covered before and also stated
below. This is easily accomplished by two separate one way messages that
are defined by separate interfaces/operations and hence services. 


>* Can we achieve this case now with the current specs?  With how much
>"squinting"?

We can not achieve this scenerio, because 

-- In the current design of WSDL requires this scenerio will have to be
modeled with a single request response where the binding/transport is
the same for both messages (ie for the operation). This means that the
Warehouse will submit its PO to a Manufacturer via a protocol/transport
(i.e. SOAP/HTTP or HTTP) and then it will be notified in the same
manner. If the Warehouse needs a different way of receiving the
ShippingNotification, WSDL can not accommodate this. Therefore there is
no flexibility provided for per message exchange desired by the
participants. 

-- The warehouse can not alter his choice of the notification mechanism
on a per PO submission request basis among many binding/transport
choices that may exist. If this choice was indicated part of the request
per interaction with the manufacturer, i.e. for high profile orders, the
warehouse may choose a different way of receiving the shipping
notification, i.e. via a website vs email, it could be indicated on a
per request basis by the warehouse. Note that this is a much simpler
requirement than Kevin's original use case where the requestor (in this
case the warehouse) always knows which protocol/transport to use for the
callback and indicates it when the PO is submitted. It is not decided by
the manufacturer. 


>
>* What is the minimal change that would be necessary to what spec(s) in
>order to achieve this case?


The minimal change in the specification is probably to introduce a
relationship that relates two one way messages in two separate
interfaces as a "callback pattern" and introduce a clarification as to
how WS-A may be used to accomplish the use case in conjunction with
WSDL. 

I will use a similar approach to what WS-MessageDelivery has already
provided.  See [2]. WS-MessageDelivery allowed both relating two
separate input message exchange as well as two request-response message
exchanges to form a unit of interaction, a callback pattern. I am using
only the former approach in this case to illustrate the point and for
simplicity. The latter can also be used if needed. The actual WS-I
Supply Chain Management document [1] uses the latter choice. 

Details: 

Today a WSDL service in WSDL 2.0 encapsulate different bindings that a
set of message exchanges defined in an interface. This particular
encapsulation allows two separate exchanges in two separate interfaces
to be related as a unit of interaction for a callback while allowing
different binding/transports to be defined in each service definition
component. Separate service elements retain their encapsulation in
providing a different set of endpoints/bindings per WSDL's current
design. Hence, two separate message exchanges that belong to two
separate interfaces can happily utilize two separate
protocol/transports, or choice of delivery for the response as part of
two separate service definition components. 

This observation is the motivation for WS-MessageDelivery's callback
pattern as well. Therefore, I will use an extensibility element defined
by WS-MessageDelivery "wsmd:responseOperation" to relate two different
one way messages in two different interfaces. The wsmd:responseOperation
element determines how one message exchange (via one-way operation) is
related to another that is defined in a separate interface. 

We have two separate interfaces (a) "Manufacturer" and (b)
"WarehouseCallback" as sketched below: 

<interface name="Manufacturer">
    <operation name="submitPO">
        <input element="tns:PO"/>
        <wsmd:responseOperation>
 
<wsdlx:interface>warehouse:WarehouseCallback</wsdlx:interface>
            <wsdlx:operation>shippingNotification</wsdlx:operation>
        </wsdlx:responseMessage>
    </operation>
    ...

</interface>


Using WarehouseCallback interface, a warehouse can get receive shipping
notification messages when the manufacturer company sends the shipping
notification. 


<interface name="WarehouseCallback">
     <operation name="shippingNotification">
          <input element="tns:shippingNotice"/>
     </operation>
      
     ....

</interface>

 

The WarehouseCallback interface is separate from the interface that a
Warehouse will provide for other interactions. The WarehouseCallback
interface is used only for getting Shipping notifications. 

Note that the warehouse may choose to notified in one of many different
ways, via email, snail mail, soap/http... A separate binding has to be
defined for each such different delivery option. 

In order to accommodate the different bindings of ShippingNotification,
several binding declarations for each different binding for the
interface WarehouseCallback that defines the shipping notification.  

<binding name="email" interface="warehouse:WarehouseCallback"
type="http://soap..."/>
     
...
...

In order to accommodate the use case, two different services are needed,
ManufacturerService and WarehouseCallbackService. There may be other
manufacturers and warehouses that may use the same interfaces and/or
bindings to create additional services to provide their own endpoints,
etc. I am trying to keep it simple by constraining the problem to a
single manufacturer and warehouse. 

<service name="ManufacturerService" interface="man:Manufacturer">
    <endpoint name="soap-binding" binding="man:soap"
              address="http://manufacturer1.com"/>
</service>

<service name="WarehouseCallbackService"
interface="warehouse:WarehouseCallback">
    <endpoint name="email" binding="warehouse:email"
              address="mailto:shipments@mywarehouse1.com"/>
   <endpoint name="snail-mail" binding="warehouse:snailmail"
              address="..."/>
   <endpoint name="soaphttp" binding="warehouse:soap"
              address="http://warehouse1.com/shipments"/>
</service>



Please note that the WarehouseCallback and Manufacturer interfaces may
potentially be defined by the same party, probably the Manufacturer who
defines the messages for PO and ShippingNotification. This is also true
for bindings that are defined for WarehouseCallback interface. Having
said that, ultimately the two services, WarehouseCallbackService and
ManufacturerService will be provided by two separate providers,
respectively the requestor and the response provider that participate in
the callback scenerio as these providers provide their endpoints to one
other. 

Some of you may argue that the same effect can be modeled by outbound
operations by the same service. There are pros and cons to that specific
approach which we may discuss separately if needed. 

WS-Addressing in the scenerio: 

When the warehouse sends its PO using the WS-A, it provides an EPR for
the callback using the wsa:ReplyTo element. The replyTo EPR may contain
additional metadata about WarehouseCallback service, such as the
specific interface, "WarehouseCallback" and the service endpoint used. 

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
  xmlns:wsa="http://www.w3.org/@@@@/@@/addressing" ....>
  <S:Header> 
  <wsa:MessageID>http://example.com/someuniquestring</wsa:MessageID>
  <wsa:ReplyTo> 
     <wsa:Address>mailto:shipments@mywarehouse.com</wsa:Address>
     <wsa:InterfaceName>warehouse:WarehouseCallback</wsa:InterfaceName>
     <wsa:ServiceName
EndpointName="email">mywarehouse:WarehouseCallbackService</wsa:ServiceNa
me>
  </wsa:ReplyTo>
    <wsa:To S:mustUnderstand="1">http://manufacturer1.com</wsa:To>
    <wsa:Action>...</wsa:Action>
  </S:Header>
  <S:Body>
    <tns:PO>...   </tns:PO>
  </S:Body>
</S:Envelope>

I did not have enough time to craft the details of all the message
properties that pertain to the two separate one-way messages that
comprise the callback pattern, but it seems that it will not be hard to
extend Section 4 [3] of WSDL binding of WS-A spec to do this.  

Summary of Changes to Specifications:

-- WSDL will need to provide an additional extensibility element that
establishes relationships between two separate interface/operations that
are one-way, inbound messages. The same logic can apply to both WSDL 1.1
and WSDL 2.0. 

-- The callback pattern had to be explicitly spelled out wrt to the
responsibilities of each party (requestor and callback provider), what
they must provide (a service definition component), how they use the
extensibility, etc. This is basically the defn of the pattern.  

-- WS-A WSDL Binding document Section 4 [3] would require an additional
table for both WSDL 1.1 and WSDL 2.0 to reflect this pattern for each
one-way message. 

>
>* What would be the "ideal" solution if we could change anything to get
>this case covered?
>

IMO, the ideal solution would be that this problem is solved within
WSDL. I believe that using an orchestration and/or choreography for this
type of interaction is an overkill for the problem. One needs to be able
to assign different bindings to separate messages for the overall
"callback MEP" that is defined here,  it is just linkage of two separate
one-way message exchanges as a single pattern to indicate a single
building block. Hence, it does not belong to these specifications.
Further, it is an overkill to require these high level specifications
for those who would like to accommodate this small step in their apps. 

One way this may be achieved is to define such an extension in WSDL
without changing the current design of WSDL. We could even explore
putting this extension as part of Part 2 as a well defined extension
provided by the spec. Since it is such a common pattern (as illustrated
by the WS-I Sample Apps example which inspired this), it would be very
useful for the community to actually utilize this pattern without
resorting to expensive solutions such as BPEL, etc. which are in a
different abstraction level. 

The changes that are required to accomplish this are outlined above. 

>Thanks,
>--Glen
>

--umit

[1]
http://www.ws-i.org/SampleApplications/SupplyChainManagement/2003-12/SCM
Architecture1.01.pdf

[2] http://www.w3.org/Submission/ws-messagedelivery/#callback-pattern

[3]
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html
#WSDLMEPS
>

Received on Wednesday, 16 February 2005 08:10:51 UTC