OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Application data scenario (RE: [ws-caf] Context example assignments)

Here is my example use case using WS-Context for providing state of business process/activity.
Every business process or activity is performed by one or more participants usually representing individual systems or components in the enterprise which are involved in the activity. When the activity starts all its participants are in an initial state. The state of the participant changes based on the messages received from other participants in the scope of the activity. Let's define the state of the business activity as a sum of all messages exchanged in the activity scope among its participants. Anyone is able to determine the current activity state by looking at the messages exchanged during the activity assuming the he or she knows the initial state of the activity participants.
One possible way to capture the messages exchanged among participants during the activity is to install an intermediary which will mediate all the communication among activity participants. The activity state keeping intermediary will make the content of the messages available to the participants of the activity. The participants, which are aware of the activity state keeping intermediary would be able to interact directly with it and would be able to augment the activity state directly.
If all participant would be aware of that intermediary and would interact solely with it, the result would be very similar to the classical space-based programming model (as we know for example from Linda, T-Spaces or JavaSpaces). The state would be automatically stored on the intermediary and participants will never talk to each other directly. This model has many advantages over classical RPC-like systems, because it makes the participants more loosely coupled. In fact, only the data format of the shared state has to be negotiated and often even this can be partially overcome by using transformations of the state content customized for individual participants.
In reality, not all participants would be aware of the state keeping intermediary, often existing services and systems would be participants of the activity and it would be problematic to make them aware of the activity state. Therefore we would need to integrate both state-aware and state-unaware participants. The WS-Context specification seems to be ideal for propagating activity state identification to the existing participants (assuming that they would understand WS-Context spec). Using the WS-Context, the state keeping intermediary would be able to place the message to the right activity state storage according the the context ID inside the WS-Context header. Information from the WS-Context header can be used by state-aware participants to augment the state directly. This would require, that a resolvable identification of the state keeper would be stored in the header additionally with other state-access related data.
The state keeping intermediary would take advantage of WS-Context "activity start" and "activity end" events to manage the activity state in a proper way.
Finally, the management tools can use state-keeping intermediary to access, monitor and influence the complete state of the activity in a single place and can use WS-Context to address and manipulate the activity state.
In my opinion, WS-Context would nicely fit in this use case to propagate activity state identification to web services via regular SOAP messages and to allow them to leverage this information by interacting directly with the state content.

From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
Sent: Thursday, December 11, 2003 9:16 PM
To: ws-caf
Subject: [ws-caf] Context example assignments

For Monday's concall it would be great to have some of the context examples circulated to the email list far enough in advance to be able to discuss them on the call.
In no particular order:
-- User Context example, Jan Alexander
-- Security context example, Eric Yuan
-- Database/File/Device example, Eric Newcomer
-- Cluster group membership example, Mark Little
-- Session state example, Greg Pavlik
I think that's it, someone let me know if I've forgotten to include them.  Apologies for the delay in getting the reminder out.
Eric Newcomer
Chief Technology Officer
IONA Technologies
200 West Street Waltham, MA 02451 USA
Tel: (781) 902-8366
Fax: (781) 902-8009
Making Software Work Together TM

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]