tamie message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [tamie] Updates on lts xml for input to script compiler, some questions about monitoring for condition guard values...
- From: "Jacques R. Durand" <JDurand@us.fujitsu.com>
- To: "Moberg Dale" <dmoberg@axway.com>, <stephen.green@documentengineeringservices.com>
- Date: Tue, 31 Mar 2009 12:00:10 -0700
Inline
<JD>
>But as they say "the devil is in the detail": what
do we mean, and what
>does the process definition mean, by "the
transitions". For instance, does
>it include:
>1. document
included in definition actually conforms to the definition of the document as
defined in the business process definition
>2. signals - that these
match the definition of their structure (schema
valid) as specified in the
business process definition
>3. timetoperform - looks like this one is
clear if time to perform is included in "occur in accordance with the
conditions"
>I'm guessing that we are use case #3 is including 3. and
more but not,
>perhaps, 1. and 2. ??? Or is validation of the documents
and signals in
>scope for uc3?
<JD> As I
see it the LTS is intended as a basis to generate eTSM scripts that will monitor
conformance of an event sequence to the state machine specified by a process
definition.
These events are primarily
the reception or capture of messages exchanged by both
parties.
But all of the above "challenges"
(1)(2)(3) need to be handled in addition to the mere message-based transitions,
and call for us to decide of a specific "LTS best practice" or LTS
"extension", in order to handle them:
About (1) "documents":
that looks like an LTS "extension" to me: a regular LTS graph would need to be
extended with more advanced business document validation rules (e.g. XML schema
validation, or more). At each node of an LTS, such rules would trigger, and if
fail would lead to an error state. So when receiving a message, a first
quick check would only involve a superficial "guard condition" to discern which
is the next state - like Dale's expressions inside his <Label2Xpath> elements. But then
when in this new state, more complete document validation rules would
trigger.
About (2) "signals" : Here, two possible approaches:
(a) these signals are treated exactly like business messages as far as LTS
transitions are concerned: they are transition-causing first-class events. Or
(b) an LTS definition could make "abstraction" of such signals - e.g. in case
every single business exchange in a collaboration must be followed by a Receipt
message coming back, it could be cumbersome to define two states for each one of
such exchanges, and it could be simpler to see the Message+Receipt as a single
event causing a single transition in the LTS. Now in that case if the
Receipt is missing, one would transition directly to an error state (or we keep
transitioning "normally" and generate an error notification in the monitoring
log?)
So I think we have some choice here in
how signals are handled in the LTS. But at eTSM level, all of these (signals,
messages) would show as events and be treated about the same I think.
About (3) timing
conditions: they also require a consistent approach to "extend" LTS.
Here also we have some choice : (a) Time constraints could be handled as a
special form of scheduled events that can intervene at any state of the LTS
graph, and cause transition to an error state (or just an error notification in
the monitoring log). (b) Time constraints could be handled as just additional
"validation" checks enforced at any state node (e.g. a time counter that is
carried along the LTS path), and that could be ahndled in the same way as the
additional validation check that verifies the integrity of a business doc in (1)
above, or the timely reception of a receipt in (2b)
above.
To conclude: I have the feeling that the LTS
graph itself could be kept simple, mostly reflecting transitions based on
business messages, but that each "state" of an LTS should probably be augmented
with an additional "integrity check" mechanism.
This integrity check mechanism would be the one handling
non-workflow related constraints like:
- full business doc validation (1). Meaning if you reach
the "RequestPO" state after capturing a message that looks like a PO, you are
not "safe" yet: a further immediate check on this PO material can lead to
an error state from here (without any "event").
- validation of low-level receipts protocols (2). Meaning
if you reach the "RequestPO" state after capturing a message that looks like a
PO, this state will have built-in the knowledge of what Receipt must be obtained
and within what time. This "internal" check would not show-up in the LTS
graph.
- handling of timeouts (3). Meaning if you get in the
"RequestPO" state , a "time token" may be associated with this transition and if
nothing happens within this time credit (e.g. no transition to "Acceptance" or
"PORejection" state) , a general time-check mechanism associated with each LTS
node can directly transition to an error state from here - or generate an error
notification in the monitoring log.
Jacques
-----Original Message-----
From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Saturday,
March 21, 2009 11:34 AM
To:
stephen.green@documentengineeringservices.com
Cc:
tamie@lists.oasis-open.org
Subject: RE: [tamie] Updates on lts xml for input
to script compiler, some questions about monitoring for condition guard
values...
Hi Stephen,
Remember that the uc3 exercise is to show
how a BP description can be used to generate TaMie scripts. Using ebBP is just
an example for this exercise. Others have shown that WS-CDL, BPEL and MSC (and
perhaps other
notations) can be used to generate LTS like transitions. I
would guess that UML sequence diagrams, activity diagrams, collaboration
diagrams, and that XPDL and BPMN could also be used. So we are generating LTSes
that are subsets of information in these process descriptions. From there, we go
on to produce the scripts. The idea is to show that given a LTS, a TaMie script
can be generated. Because ebBP already has XPath as a language for its "labels,"
it is more straightforward to produce LTS inputs of use to the TaMie script
production.
Your recent questions seem to be aimed at larger questions
about conformance to specifications with respect to all of their content. For
ebBP, there is a lot of other content. For this other content, it might be
better to generate TAG style assertions or perhaps other conformance or
interoperability testing materials. That is far beyond the scope of what uc3 is
for TaMie TC.
As far as what is included in the transitions goes, the
criterion is partly what information is found in ConditionExpressions (when they
are found in the ToLinks and FromLinks -- so currently we ignore the ebBP
variables, OK?) It should be obvious that these links (which are the transitions
among
states) are the ones to investigate for the content of
labels.
And there are several allowed ConditionExpression languages--
currently the investigation is restricted to ebBP instances where the languages
are either the DocumentEnvelopeLanguage and the
ConditionGuardLanguage.
DocumentEnvelopeLanguage is of direct use when it
has been defined using XPaths. And that subclass of ebBP instances is what we
are starting with.
Lately to handle ConditionGuard values on the edges,
the signals were added because these "operationalize" the ConditionGuard values
features of messages sent on the wire. Examples were posted last week of what
seems reasonable to extract for mappings of ConditionGuard expressions (such as
"AnyProtocolFailure") into XPaths on signals.
The TTP information (and so
far only the Collaboration TTP information has been extracted) goes straight to
define a transition to the Failure state. Why? That is the semantics of this
information.
But as they say "the devil is in the
detail": what do we mean, and what does the process definition mean, by "the
transitions". For instance, does it include:
1. document included in
definition actually conforms to the definition of the document as defined in the
business process definition
2. signals - that these match the definition
of their structure (schema
valid) as specified in the business process
definition
3. timetoperform - looks like this one is clear if time to
perform is included in "occur in accordance with the
conditions"
etc
I'm guessing that we are use case #3 is including
3. and more but not, perhaps, 1. and 2. ??? Or is validation of the documents
and signals in scope for uc3?
2009/3/21 Moberg Dale
<dmoberg@axway.com>:
> That the transitions that do occur are in
accordance with the ones
that
> are specified as being allowed to
occur, and that these transitions
> occur in accordance with the
conditions (Boolean propositional
functions
> over events) that need to
be true for those transitions to occur.
>
Stephen
Green:
>
>
> But what is it about these LTS states, etc (the
subset extracted from
> process definition) which need to be
tested/monitored?
> The sequence? That the messages conform to these
states?
>
> 2009/3/20 Moberg Dale
<dmoberg@axway.com>:
>> Stephen writes many
questions:
>>
>> I'm still a little in the dark about what
aspects of the ebBP's
>> definition of a process are intended to be
tested or monitored with
>> TaMIE/eTSM. The exercise of thinking what a
conformance profile
>> (perhaps expressed as test assertions) might
look like if the ebBP
>> definition was written as a conformance
profile, such an exercise
>> might help determine what the eTSM script
would have to test. Then
>> it's a mapping exercise to match those eTSM
features to the profile
>> and thence to the ebBP. Then it's a matter
of generalising this, etc.
>>
>> So: Q1. an ebBP says what
about a process? and Q2. which (if not
>> all) of those things
(things=assertions, if you will) is to be of
>> interest to the script
writer/generator?
>> Q1. what assertions does an ebBP definition make
about an endpoint,
> etc
>>
>> <dm>ebBP would not
exactly make assertions about endpoints in the URL
>> sense of that
term, but only about the roles and business
transactions
>> among
whatever occupies those roles (CPPA calls them parties)
>
Endpoints
>> used by the parties might differ for different parts of
the business
>> collaboration
>>
>> But putting aside
these fine points, the ebBP instance is mainly
>> providing a subset of
information that is extracted from it and
placed
>> into the LTS.
The LTS is written out as a bunch of states that can
>> transition to
other states under certain conditions (their "labels").
>>
>>
For starters, the label languages are restricted to the document
>>
envelope language and the condition guard language and the XPath2
>>
language. The states are the BusinessTransactionActivites, which are
>>
particular ways of carrying out what is described in the
>>
BusinessTransaction (a kind of reusable pattern of interaction).
Each
>> BusinessTransaction has a structure that could be captured in a
UML
>> sequence diagrams involving documents exchanged and signals that
may
> or
>> may not be produced.
>>
>> There
are also "gateways" that glue together states in various
>>
collaboration patterns, such as Transition, Fork, Join, and
Decision.
>> There are certain modifiers such as "waitForAll" on Join
(which means
>> that all conditions must be true before transitioning
to the next
> state)
>> or "type" on Fork (which can be XOR or
OR).
>>
>> Beyond this transition information, see the
specification or the
> schema
>> and look at attribute groups
such as documentSecurity and quality or
> the
>> element,
TimeToPerform. These information items indicate QOS aspects
>> that are
specified for the business collaboration. They are not part
>
of
>> process, narrowly understood, but are part of the ebBP
specification
> for
>> business
processes.
>>
>> I will have to get to your other questions in
a different block of
> time.
>>
</dm>
>>
>
>
>
> --
> Stephen D.
Green
>
> Document Engineering Services
Ltd
>
>
>
> http://www.biblegateway.com/passage/?search=matthew+22:37
.. and voice
>
--
Stephen D. Green
Document
Engineering Services Ltd
http://www.biblegateway.com/passage/?search=matthew+22:37
.. and
voice
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that generates this
mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]