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

 


Help: OASIS Mailing Lists Help | MarkMail Help

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...


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


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