Re: [Fwd: Re: [wsbpel] abstract process strawman]

[rkhalaf <rkhalaf@watson.ibm.com>]

Hi Andrew,

Basically they're a specification of one's public behavior.
What people are doing with them is using them to derive an 
implementation as you describe below, or going the other way
to posting your behavior based on your internal implementation.
Also you could do other things like use them to check whether
someone interacting with you is following it or not etc..

I'm not sure what you mean by deploying an abstract process?
For a simple parallel -
How do you "deploy" a Message Sequence Chart, for example?
or a DAML-S (now OWL-S) process? you could
deploy something that implements it but not the abstract
artifact itself. What you could do is possibly pass it to a
verification gateway that see whether the messages being sent
around comply - but that's a use case that will be up to what
you want to do with it and we don't restrict/enforce that.

I hope that clarifies that part.

For parallels you can think of usages of things like Message sequence
charts regarding the behavior of one of the parties,
some usages of petri nets, DAML-S (now OWL-S) processes,
and so on. For references, i'm not sure whether you're looking
for some on conformance in particular or abstract process related
work in general. The literature abounds with definitions on bisumulation
equivalence, tracing semantics, testing equivalence,
public/private process projections based on petri nets, and so on.

We therefore agree that there are many definitions on conformance
and we also talked during the face-to-face meeting in San Francisco
to clarify the definition of observable conformance that
is in the doc that has been circulating. The conformance discussion
will end up in 109 and so we can continue it there. I'll post the 
proposed text there and that discussion can be picked up again there.

Now I'm trying to tackle the easier issues 107 on opacity first, 91,
97, and 99 (in parallel with 82 (abstract proc def)). These are
the issues that drove what's in the document you read today.

tks
Rania

andrew.francis@mail.mcgill.ca wrote:
> Hello Monica:
> 
> 
>>mm1: Compliance raises the bar on an implementation,
> 
> 
> It seems to me that the more fundamental problem is (to
> the best of my knowledge) nobody is writing and deploying
> abstract processes. Heck, the strawman is trying to define
> abstract process and how to use them!!!
> 
> I, myself, am more interested in determining what
> existing theories out there give insights into how
> abstract processes work, determining what are the
> idioms for writing  them, and figuring out best practices
> for deploying them.
> 
> 
>>This is outside of the 'technical' contract. An example
>>is HIPAA where certification is required through a series
>>of tests with  verifiable results before production.
>>It is a mandate through government  regulation.
> 
> 
> Monica, the formal contract builds on top of the
> technical contract. Also I feel you are mixing up
> verification with validation.
> 
> Let us assume that abstract processes, at their minimum,
> are representations of a protocol. Verification consists
> of ensuring that one can properly derive a concrete
> implementation as per the abstract process.
> 
> Validation constitutes whether the implementation actually
> implements some external specification such as HL7, that
> the abstract process is based on.
> 
> 
> Cheers,
> Andrew
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.