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

[Greg Pavlik <greg.pavlik@oracle.com>]

I would second the idea that cross-organizational boundary transactions should not be ACID; if we want to profile ACID transactions it should be an "internal" detail of one of the endpoints that is exposed for the demo.


Mark Little wrote:

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