RE: [ws-caf-implement] Discussion on the Demo Application

[Krishna Cheemalamarri <krishna@inventicasystems.com>]

I like the idea of adding Retailer B to the demo because of the fact
that this would enable us how to propagate session/identification
information as Malik had mentioned. 

Regarding the TXN model, I support Mark's idea of using a LRA model.

Cheers!
Krishna


-----Original Message-----
From: Mark Little [mailto:Mark.Little@arjuna.com] 
Sent: Sunday, January 11, 2004 10:47 AM
To: malik saheb; ws-caf-implement@lists.oasis-open.org
Subject: RE: [ws-caf-implement] Discussion on the Demo Application

I think the example looks good. However, I'd like to see an extension to
the 
transaction aspect so that we can use the LRA model and not just ACID 
transactions. I don't think that should be too difficult to do at all,
since a 
variation of the warehousing scenario was used in the original
specifications 
(I think we used a HiFi).

Mark.

>===== Original Message From "malik saheb" <malik.saheb@arjuna.com>
=====
>Hi all
>
>
>A proposal we have at the present time is the Supply Chain Application
>proposed by Simeon.
>The interest we could have with this application is the fact that:
>-          It has been deployed by another standard (WS-I). This could
>give us the possibility to show how an existing application can be
>enhanced using WS-CAF
>-          Source files exist and we could eventually re-use them or
>built our application based on them.
>
>>From the WS-CAF point of view Simeon has proposed a set of scenarios
on
>the way to use the different specifications.
>
>Simeon Proposal below (in blue) with my additional comments
>-----------------------------------------------------------------------
-
>--------
>
>This is how I envision adding WS-CAF to the SampleApps:
>
>- First add WS-CTX by allowing users to place items from the Retailer
>service catalog into a shopping cart using a shopping cart service.
The
>shopping cart service will use Context like a Session object.  Since
>this first phase of the demo does not use the Coordinator, the Context
>will be shared by passing around the uri (pass by reference) and
relying
>on the timeout value to determine that the context is no longer valid.
>When a user first places items in the shopping cart, the shopping cart
>service will begin a new shopping activity and return a reference to
the
>newly created context.  Subsequent additions to the cart will result in
>the shopping cart service augmenting the existing context.  Before
>augmenting the context however, the service will check to see if the
>context is timed out, if it is the cart will be destroyed and the user
>will have to create a new cart with new items.
>
>After reading the SCM documentations it appears that if one product
>(with the appropriate quantity) could be not provided the order fails.
>How about an extension of the application; we could eventually imagine
a
>Retailer asking a second one if it could provide the missing product.
>This could allows us also to use the Context service in order to
>propagate information such the client session/identification,. and the
>product already provided by the previous retailer. This could happen
>eventually if there is partnership between retailers or a company, say
>RetailerA, which buy a second one (RetailerB) and does not to
>restructure its existing application to involve warehouse managed by
>RetailerB.
>This scenario could led to a modification of the Demo Service that will
>offer a call back mechanism to be called by the RetailerB or a
>subsequent for the final response.
>
>- Add WS-CF by allowing all the services involved to register with a
>WS-CAF coordinator.  Once scenario of where this will be useful may be
>allowing a Warehouse service to indicate to other participants in the
>shopping activity that it cannot deliver some of the goods in the
>shopping cart because they suddenly were made unavailable (for example,
>another user in another application has completed an order that removed
>them).  When the user attempts to check out an error should be raised
>because one Warehouse service has indicated it cannot complete the
>activity.
>
>If we consider the transactional behaviour, I think we can prevent
>another user to get the same item. But we can imagine a warehouse
>employee noticed that the ordered TV or DVD does not work!!!!
>
>
>- Add WS-TXM (ACID Transactions - I haven't thought beyond that) by
>allowing the purchase to constitute as real transactions.  Beginning a
>purchase will now mean starting a distributed web service transaction.
>If the context times out, the transaction should be rolled back.  If a
>warehouse cannot ship an item, the transaction should be rolled back.
>Only when the Retailer and the Warehouses return successful completion
>outcomes should the entire transaction be committed.
>
>The activity launched by a retailer to access the warehouses could be
>long. We could consider accessing a warehouse in a separate
transaction.
>Compensations mechanisms will be needed. We could also consider the
>Retailer's activity accessing its own warehouses as one ACID
>transaction, while collaboration between retailers (if we choose such
>option) as a long running activity.
>We can demonstrate here more that one transaction model.
>
>Within the WS-I, implementers have build entirely the sample
>application. We could do eventually the same thing. (???)
>
>Your comments are obviously welcome, including if you agree or not to
>use this application.
>
>Malik