[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] 6/28/2004: Work Item 21 - Summary for ConditionalConstraints-beginsWhen, endsWhen!!
OASIS.ebBP.WI-21-Pre- and postConditions;
Topic|;
Point|Summary of influence of conditional constraints on state alignment
and transitions;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200405/msg00100.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200406/msg00087.html;
Attachmenthttp://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/7465/ebbp-special-session-state-alignm-web-services-mm1-062504.txt;
Attachment|http://www.ebpml.org/state.html;
mm1@
In Friday's special session to continue our discussion on state
alignment, business collaboration and web services, we
identified several relevant use cases and gained a clearer understanding
of state alignment, transitions and conditional
constraints (beinsWhen, ends When). As I indicated in last week's call
and in the session on Friday (25 June 2004), below
is a summary that compiles most of the discussion including the use
cases identified Friday:
Originally these conditional constraints were identified (definitions
attached). Each attribute has existed in ebBP for quite
some time as xsd:string (i.e. they were not computable attributes). [1]
* beginsWhen: A description of an event external to the
collaboration that <<<normally causes this collaboration to commence>>
* endsWhen: A description of an event external to this collaboration
that <<<normally causes this collaboration to conclude>>>
* PreCondition: A description of a state external to this
collaboration that is <<<required before this collaboration can
commence>>> [1]
* PostCondition: A description of a state external to this
collaboration that is <<<required before this collaboration can
conclude>>>
Our quandry in February, when we briefly touched on these attributes,
was identifying the intent and use of these attributes, and their
relationship to the condition expressions, transitions and pseudo
states. These attributes were originally cited as external
events, not associated with the included activities. [2]
In order to use these attributes, they must be visible to the process.
They can occur anytime during the process.
Moving these to documentation was considered as well although this may
have been confusing to developers.
Below is a summary of the objectives surrounding these conditional
constraints that may levy requirements on ebBP:
* preCondition + other variables = beginsWhen
* postCondition + other variables = endsWhen
* These optional conditional attributes can put constraints on the
business agreement. The ebBP state model both "monitors" the collaboration
and "specifies event visibility" of the service layer model. It can
(will) enumerate the semanitic business events), and the complexity is
forced
onto the mapping of service events (and technical events) onto
business events (semantic business occurrences).
This allows incremental improvements in both service and business
layer. Technical implementations can also have a simple binding to the
business layer. [Yunker]
* These can support business dialog (or a constrained BPSS). Anders
Tell has suggested that specific effects (and other variables) could be
used with these conditional
constraint attributes. He indicated that a business Dialog governs a
pattern of information exchanges which infers obligations and rights on
the parties.
The dialog includes collaboration conduct and persistent share
memory. It is with the latter that the constraints
of beginsWhen, endsWhen, and pre-post conditions are necessary. UBAC
sits above. [Tell]
* It is legal to declare a constraint on an action that maps onto
information that is produced on that action.
Use beginsWhen and base on content of the business message that is
delivered on that action. [Yunker]
* When support for business entities is provided in ebBP, these
conditional constraints become very important.
For example, a deliverydate is specified elsewhere, in a BE or BO
and the obligation to notify before delivery is also defined
there but the notification details are describe in a business dialog
specification. [Tell]
* If constraints are placed on beginswhen, it doesn't place undue
burden for monitoring and verification.
It only places choreography constraints. Concepts apply to use of
web services as well. Eventually, ebBP could
have a semantic label and have implementers implement a mapping from
semantic tag to the implementation.
Then, ebBP could add a section to map names to implementations that
are context aware.
For example, Semantic: Non-zero, third-tier inventory. In the CPPA,
relate that semantic tag to the actual implementation
scheme. Could have special document, semantic constraints (such as
for context). It could be built dynamically based on the other part of the
document that did the mapping. Calculate document types. XSL could
be simple to write. [Yunker]
* Post condition is the business success. The requester says
business success.
The status that you report to the choreography is derived from those
conditions (success, failure).
Person sending the message sets success failure for post condition.
It could also be in the business document.
* Yunker use case for endsWhen: Usage of endsWhen for retryCount:
Use if the action repeated in the case of a failure. If you have
endsWhen=true
and try to retry, you should not retry. For example, if you have 3
tries to get right; otherwise you fail. In an academic setting, you try
certification
three times as a health care provider. Submit a certification
request. Do a registration step. Submit certification.
It is returned and I fail. I then check my error messages and
increase insurance. I get more staff and I retry.
I fail again. I do another action and fail. I then re-registrer and
have to start over again.
This is actually a use case. Look at Amazon self-service
registration. When these attributes are used,
when you receive the document, you do additional checks [Moberg].
It is QoS and evaluate business transaction status. Status is
computed after you receive the document.
See how to compute status values to these conditions.
Given the discussions in February, May and last Friday in the special
state alignment session, the possible, recommended
changes to the technical specification for v2.0 are:
* We make them optional elements so we can apply more
characteristics which
will allow them to be used with effects, variables, etc. in the
future. This could also support multiple usages: business dialog and
constrained ebBP and business entities or
constrained objects. [Tell] [3]
* We make clear these are external events and put some user hints to
encourage their appropriate use. Differentiate execution language
from the business semantics and conditional
constraints used in ebBP. Differenitate public and visible vs.
private process. Specify how this helps achieve
state alignment. Therefore, in ebBP, our monitoring capability is
used to evaluate key execution constraints without
calling out actions, such as kicking off a business application.
* Recognize that state alignment requires multiple actions, and how
these conditional constraints can
also support that. See JJ's valuable paper on state alignment at:
http://www.ebpml.org/state.html.
Recognize that business state alignment occurs when, for example,
you send a delivery receipt. If the information
is in your system, you are responsible. Need to clearly
differentiate HTTP OK, other data exchange from business failures.
Acknowledge need for failure specification as well as other
constraints and QoS factors for business state alignment.
* Recognize that enforcement of business agreements is done only on
information visible to both parties.
The requirements for the documents are the constraints on business
failure, success and transitions.
* Use a semantic label and mapping using XPath directly. Also create
a subcontent model in CPPA.
Use the conditional expressions that currently exist on the document
and provide an optional overlay that can
be used if desired.
* Specify what beginsWhen goes with which transition in the binary
collaboration. The beginsWhen is on the activity
(action). From a petriNet or UML perspective, you are at the next
node because you have constraints that are not satisfied. You have taken
the transition.
Explain how to look at beginsWhen for the document on transition
that the conditional constraints were satisfied.
This allows you to express constraints and check as they move
across. You can flag and try to accommodate (even if it is too
late to stop/change). Ensure this is explained in the technical
specification.
Open discussion questions:
* Can beginsWhen and endsWhen be folded into preCondition without a
loss of expressiveness? Can preCondition
+ effect = postCondition? Using 'effect' can facilitate use of
business entities in near future. [Tell]
* Are there other use cases for endsWhen and post condition?
* Evaluate any differences for use with web services.
[1] This is not to be confused with production rules for UML=>XML
transformation and the fact we are looking to develop well-formedness rules.
[2] David Webber has used beginsWhen and endsWhen as a complement to the
guards.
[3] Per Tell: Business entities or constrained businss objects such a
resource, commitments, obligation, etc. at design time / contract
signing time the business requirements expressed in business dialog,
BPSS, CPA, TPA, BLA drive the service level implementationand required
features.
an example: the definition of DataMessage::Reach::Event may stipulate
that this event may not be generated unless condition a,b,c has been
fullfilled and validation checks such as completness testing,
verification of sender identify, etc.
[4] Many thanks to John Yunker, Dale Moberg, David Webber, JJ Dubray,
and Tony Fletcher and Anders Tell (who both provided comments over the
weekend).
Other discussions in May / June 2004 on beginsWhen, endsWhen, and pre-
and post-conditions:
Textual references and general questions concerning use of attributes.
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00083.html
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00084.html
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00096.html
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00097.html
Use in choreography, doubts
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00102.html
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00103.html
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00119.html
Use in choreography, theory and proposals
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00100.html
http://lists.oasis-open.org/archives/ebxml-bp/200406/msg00104.html
@mm1
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]