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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-abstract message

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


Subject: RE: [wsbpel-abstract] Potential requirements and use case


I will be a bit late for the call this morning.  My apologies.

________________________________

From: Satish Thatte
Sent: Thu 7/15/2004 10:19 PM
To: wsbpel-abstract@lists.oasis-open.org
Subject: RE: [wsbpel-abstract] Potential requirements and use case


I would add that in real scenarios external views are often linked with modeling requirements.  A large company may specify a "required external view" in the form of an abstract process for its partners' processes without dictating how such a process is completed by the partners.  The partners may need to take their required external view and use it as input into a modeling environment for completion and implementation in their own environments.  However, it is extremely unlilely that the large company will dictate exactly how the process is to be completed by specifying the exact places where it must be extended.  Each partner may of course complete and implement the process differently, so long as all maintain the externally visible contract specified by the abstract process.
 
We would therefore be better off specifying the base techical notion of abstract processes as partial processes and we should avoid attempts to narrow the space of use cases artificially.
 
Satish

________________________________

From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Thu 7/15/2004 9:41 PM
To: Ashwini Surpur; wsbpel-abstract@lists.oasis-open.org
Subject: RE: [wsbpel-abstract] Potential requirements and use case



Aren't you confusing a use case with a set of "requirements" marked with "MUST"?

I am not opposed to the use of abstract BPEL for supporting modeling tools, if it suits.

I am opposed to structuring abstract BPEL in such a way that it is ONLY or PRIMARILY focused on supporting modeling tools.

There are several reasons for this.

1.  This is inconsistent with the current spec which expresses the intentions of the original authors rather clearly, as well as the charter.  All of these emphasize the public view aspect of abstract BPEL and it is not at all clear that the use of OPAQUE is suitable for that.

2.  The *technical* motivation for this push away from the original intentions is not clear -- it would be helpful to have that explained.

3.  At a technical level, we recognize that abstract processes are partially specified executable processes.  One can provide an external view as a partially specified process by eliminating all unnecessary detail.  One can also use the very same partial specification as the basis for representing intermediate states in a modeling exercise. 

In both cases you need a notion of faithful completion.  I do not buy that faithful completion is a purely syntactic matter of specifying OPAQUE syntactic elements.  This may be adequate for some narrow use cases but is clearly suboptimal for the technology as a whole. 

It is not, and has never been our charter to specifically address the requirements of (visual or other) tools for process modeling.  I simply see no reason to bring that in as the canonical use case.

It is time we moved beyond this.  Let us use the call tomorrow to do so.

Satish



________________________________

From: Ashwini Surpur [mailto:Ashwini.Surpur@oracle.com]
Sent: Thu 7/15/2004 4:49 PM
To: wsbpel-abstract@lists.oasis-open.org
Subject: [wsbpel-abstract] Potential requirements and use case



Hi,

Here is a  use case and some requirements that we feel should be
satisfied. If needed, we can discuss this at tomorrow's conf call.

Thanks,
Ashwini








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