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)
- From: "Jan Alexander" <alex@systinet.com>
- To: "'Newcomer, Eric'" <Eric.Newcomer@iona.com>,"'ws-caf'" <ws-caf@lists.oasis-open.org>
- Date: Mon, 5 Jan 2004 17:31:43 +0100
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.
--Jan
Hi,
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
-------------------------------------------------------
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]