-----Original Message-----
From: Prasad Yendluri
[mailto:pyendluri@webmethods.com]
Sent: 14 June 2004 23:50
To: Rossomando, Philip
Cc: wsbpel-abstract@lists.oasis-open.org
Subject: Re: [wsbpel-abstract]
where is the dividing line?
Phil,
I went back and reviewed the discussions and I am in agreement with SAP (Ivana)
and Satish etc.
If we agree on the nature of the beast and the users of one, the details
of what we would take out
of executable bpel or what we would add to abstract BPEL that would not be part
of executable
one etc. can be worked on.
I was trying to address the first part in my note (esp. the demarcation
aspect).
The use cases you enumerated later do seem to capture the typical uses. All
three
are good though I am mainly concerned with 1 and 2 (like Ugo).
Regards, Prasad
Rossomando, Philip wrote:
Prasad:
You can’t hide. J That is the
problem as Martin was saying we have different
Users. In a later posted
not I identified three. Each can expect to see something
Different as far as what
is visible. Ok, let’s say you are at the SAP level in my
Previous email and you
want to distinguish that level from executable bpel.
What would you drop out
of executable bpel to achieve the SAP level?
Phil
PS. Only 2 Yen?
Phil Rossomando
Research Director,
Technology & Architecture
Unisys Corporation
Unisys Way, B-330
Blue Bell, PA 19424 USA
Philip.rossomando@unisys.com
215-986-3998
FAX
413-0215-2043
-----Original
Message-----
From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
Sent: Monday, June 14, 2004
2:34 PM
Cc: wsbpel-abstract@lists.oasis-open.org
Subject: Re: [wsbpel-abstract]
where is the dividing line?
Hi,
I guess this aspect had been discussed adnauseam but, for me the dividing line
for abstract process (vs executable) lies where the descriptions of abstract
process confine to publicly observable behavior of a process, without getting
into any executable (private) aspects. Abstract process descriptions need
to be limited to describing the aspects needed by external parties, viz.
end-users and other (complementary) business processes that interact
with the process. All the language constructs that go beyond the above
requirements need to be placed out-side the scope of the abstract process
definitions. If a process description goes beyond the abstract level and
includes constructs that are not classified as abstract level in the
specification, then the process description is no longer at the abstract level.
The difficult part then is to factor in different uses cases that fit the above
definition and identify, limit as needed and perhaps add more constructs to
BPEL to facilitate the above.
My 2 yens on this (ducking for cover:)
Prasad
-------- Original Message --------
Phil,
Trying to define abstract bpel is where part of my problem stems from.
I agree to the requirements and the use cases, I don't even have much of
a problem with Sally's
defintion (aside from Business protocol stuff, but that's another
point).
The problem is executable bpel can fullfill these requirements depending
on
a customer's policies. If we are to have executbale and abstract, we
have to define a single dividing line in order to define two sets (where
one may be a pure subset of the other).
Martin.
>-----Original Message-----
>From: Rossomando, Philip [mailto:Philip.Rossomando@unisys.com]
>Sent: 14 June 2004 15:19
>To: Martin Chapman
>Cc: wsbpel-abstract@lists.oasis-open.org
>Subject: RE: [wsbpel-abstract] where is the dividing line?
>
>
>
>Ok Martin, I assume that your definition is a single language
>And we leave it up to the customer as to how to simplify it.
>I don't think there is a single dividing line. To look for one
>Is to search for a Holly Grail. I would like to see from you
>and Others within the TC their definition of what abstract BPL
>is And the requirements for use. As was said in last week's
>meeting A hopeful consensus definition and requirements list will be
>Put together. Hopefully by the f2f. Some of our group
>definitely See a place for abstract BPEL (e.g., SAP, et. al.).
>
>Phil
>
>PS. Your input is definitely appreciated.
>
>Phil Rossomando
>
>Research Director, Technology & Architecture
>Unisys Corporation
>Unisys Way, B-330
>Blue Bell, PA 19424 USA
>Philip.rossomando@unisys.com
>215-986-3998
>FAX 413-0215-2043
>
>
>-----Original Message-----
>From: Martin Chapman [mailto:martin.chapman@oracle.com]
>Sent: Monday, June 14, 2004 10:07 AM
>To: wsbpel-abstract@lists.oasis-open.org
>Subject: [wsbpel-abstract] where is the dividing line?
>
>
>
>I've been listening with great interest to the discussions on
>abstract BPEL as contracts, abstract BPEL as templates, and
>abstract BPEL as an intermediate language, and I agree each
>use case is valid. What I am having trouble with is how we can
>define a single language to meet all these goals; where is the
>single dividing line between abstract and executable BPEL?
>
>When a company exposes a definition to another company surely
>it is up to the company to decide how much detail it wants to
>expose. If a company chooses to expose an executable BPEL
>definition who are we to stop them? In fact there is no way of
>stopping them. Internally, a company may want to expose more
>detail between analyst and programmer then they would to
>external parties, and different companies will have different
>rules about what can be exposed and where. Some people may
>want to make extensive use of <opaque> to inform others that
>something internal will happen, others may stick to plain old
>extensibility.
>
>My point is that all these use cases are valid, yet they
>appear to have different exclusion requirements on the
>language, and that different companies may have different
>polices as to what gets exposed (or not). Is it really
>possible to define a single syntax under the abstract BPEL
>umbrella, which all vendors support and which precisely
>matches a variety of customer usage policies. Sounds more than
>a single language to me; it sound like a family of syntaxes.
>Wouldn't it be better just to define a single language (BPEL)
>and let tool vendors support customisation that allows each
>*Customer* to decide what features are in and out?
>
>Look forward to your feedback,
> Martin.
>
>
>
>_________________________________________________________________
>Martin Chapman
>Consulting Member of Technical Staff
>Oracle
>P: +353 87 687 6654
>e: martin.chapman@oracle.com