RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)

[Harvey Reed <hreed@sonicsoftware.com>]

Steve,

Satish is right, could you create an outline of a use case? This will keep
this thread productive, as well as add to our use cases.

++Harvey


-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Thursday, October 23, 2003 1:32 PM
To: Steve Capell; Furniss, Peter; ygoland@bea.com; John Evdemon;
wsbpel@lists.oasis-open.org; Dave Welsh
Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)

Steve,

You ask some very good questions.  Perhaps this is best explored further
in the use cases group that John and others are driving where we could
work through examples of what collaborative use cases need to look like.

Satish

-----Original Message-----
From: Steve Capell [mailto:steve.capell@redwahoo.com] 
Sent: Thursday, October 23, 2003 12:16 AM
To: Satish Thatte; 'Furniss, Peter'; ygoland@bea.com; John Evdemon;
wsbpel@lists.oasis-open.org; Dave Welsh
Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)

Thank you Satish,

I have just joined this group (as an observer) so have not seen where
"abstract" bpel strategy is going.  I can see that BPEL4WS does not
handle abstract collaborations today but I admit that I had thought that
"abstract" ws-bpel was going to address the same space as ebXML BPSS -
namely a single schema that describes the roles of all parties
(typically just two parties) in a collaboration.  

Do I understand from your response that "abstract" ws-bpel will not be
doing that?  If not then I am having some conceptual difficulty
understanding how I might "generate" the process schema from a bcf model
- which is definitely a multi-party collaborative model.  Maybe (as you
suggest), the generation produces multiple ws-bpel schema and a
"governing" ws-policy schema.   Seems a bit messy and "hard" compared to
ebXML BPSS?  Wouldn't it be simpler (for users of the spec) to provide
bpel support for abstract multi-party collaborations than to define set
of standard ws-policy assertions  to deliver that "manifest" of separate
bits & pieces?

Sorry if I am talking rubbish - just trying to get my head around how I
can deliver an Australian national B2B interoperability framework using
WS instead of ebXML....

Regards,

Steve Capell
RedWahoo
Sydney, Australia
Tel : +61 410 437854
This email message and any accompanying attachments may contain
information that is confidential and is subject to legal privilege. If
you are not the intended recipient, do not read, use, disseminate,
distribute or copy this message or attachments. If you have received
this message in error, please notify the sender immediately, and delete
this message. Any views expressed in this message are those of the
individual sender, except where the sender expressly, and with
authority, states them to be the views of Red Wahoo Pty. Ltd.
Before opening any attachments, please check them for viruses and
defects. We do not accept any liability for loss or damage which may
arise from your receipt of this e-mail.



-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Thursday, 23 October 2003 4:40 PM
To: Steve Capell; Furniss, Peter; ygoland@bea.com; John Evdemon;
wsbpel@lists.oasis-open.org; Dave Welsh
Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)


Steve,

I completely agree with the way you described a potential formalization
of a PIP.  Do note that you will need as many abstract processes as
there are participants and you will also need to ensure that their
relationships are expressed through some sort of "global model".
Abstract processes are in my opinion necessary but not sufficient for
defining business protocols.  In addition to the artifacts you listed a
global manifest/model that expresses all the relationships is required
since partnerLinks will have independent QNames in each process' private
namespace.  One could imagine using WS-Policy for expressing this.

Satish

-----Original Message-----
From: Steve Capell [mailto:steve.capell@redwahoo.com] 
Sent: Wednesday, October 22, 2003 11:15 PM
To: Satish Thatte; 'Furniss, Peter'; ygoland@bea.com; John Evdemon;
wsbpel@lists.oasis-open.org; Dave Welsh
Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)

Satish

Are we confusing a "Business Domain" (eg supply chain) with a business
process (eg "purchasing")?  In business process modelling (such as the
UN/CEFACT BCF methodology) the collaborative "business process" is
typically quite granular (eg an order and order response).  The process
is a small part of a business domain such as supply chain. To describe
the entire domain with an abstract bpel is a huge challenge but to
describe a fairly granual collaboration strikes me as quite do-able and
quite useful.

>From my perspective, I would like to be able to completely define a
"public process" using machine readable WS schema in a similar way to
ebXML specifications.  For example, to describe a simple order / order
response process such as resettaNet PIP3A4 using WS schema I would need:

1	An abstract ws-bpel defining the simple collaboration
2	A ws-policy assertion schema definin the QOS attributes of each
activity (non-repudiation, time to acknowledge, etc)
3	Two XSD schema (one for each message) representing the order and
orderResponse messages defined by the model.
4	Two wsdls (one for each party) with references to the xsd schema
(import), ws-policy (policyRef extension), and ws-bpel role
(partnerLinkType extension).  

This complete machine readable "public process" can then be used to
configure testing tools (for certification or compliant application,
design time tools (for creating "private process" orchestrations, and
runtime tools (for managing compliance to public process QOS
requirements). 
 
On behalf of the Australian government I am certainly hoping that
ws-bpel will provide the capability to describe at least simple
collabroative processes - otherwise we will have to fall back on things
like ebXML BPSS - but then we'd lose the potential to glue together the
"public collabroation" and "private orchestration" in one set of
specifications & tools.

Regards,

Steve Capell
RedWahoo
Sydney, Australia
Tel : +61 410 437854
This email message and any accompanying attachments may contain
information that is confidential and is subject to legal privilege. If
you are not the intended recipient, do not read, use, disseminate,
distribute or copy this message or attachments. If you have received
this message in error, please notify the sender immediately, and delete
this message. Any views expressed in this message are those of the
individual sender, except where the sender expressly, and with
authority, states them to be the views of Red Wahoo Pty. Ltd. Before
opening any attachments, please check them for viruses and defects. We
do not accept any liability for loss or damage which may arise from your
receipt of this e-mail.



-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Thursday, 23 October 2003 11:36 AM
To: Furniss, Peter; ygoland@bea.com; John Evdemon;
wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)


As I argued during my presentation at the first F2F, the idea that a
neutral description of multi-party interaction is essential for business
protocol definition is erroneous, and worse, too restrictive.  In
particular protocols using full duplex communication are almost
impossible to describe without separately describing the external
behavior of each party, because the number of states corresponding to
races becomes unmanageable and incomprehensible.  Think of a supply
chain protocol where an order may be canceled at arbitrary points.  Most
neutral protocol descriptions tend to be reduced to finite state
machines that are also very poor at describing data dependent aspects,
error recovery protocols, etc.  I expect this is what Peter is referring
to when he speaks of "heading towards somehting much like on abstract
bpel".

I therefore consider Yaron's objection to be groundless and advocate
keeping the paragraph as is.

-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] 
Sent: Wednesday, October 22, 2003 4:42 PM
To: ygoland@bea.com; John Evdemon; wsbpel@lists.oasis-open.org
Subject: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)

Some of Yaron's comments on the FAQ (most of which I agree with) seem to
relate to the power of abstract BPEL 

paragraph from the proposed FAQ:

<quote>
The Business Process Execution Language is a XML-based language for
formally describing interoperable business processes and business
interaction protocols.  It defines how web services are connected
together and in what sequence in order to accomplish a particular task 

</quote>

to which Yaron comments :

<quote>
BPEL only provides a description of the behavior of a single player in a
business process protocol. Since protocols require, by definition, more
than one player BPEL is by definition unable to completely describe a
business process protocol or to specify how different processes interact
beyond describing the behavior of a single participant. Therefore I
think this paragraph should be struck. 
</quote>

which was very much my view until I had a conversation with Tony Andrews
and got a better understanding of his presentation from the first
face-to-face (
http://www.oasis-open.org/archives/wsbpel/200305/msg00172.html). It
seemed some things I had thought would be necessary, and which I hadn't
seen stated, and so assumed were not in view, were definitely
intended/expected:

	- there can be multiple abstract definitions for a single
executable, each specifying the dynamic behaviour of one (or set of
related) interfaces, with the other interfaces handled by opaque
assignment; the choice of how many of these there are, their level of
opacity and the interfaces covered is a design/viewpoint question

	- there can be (and need to be for the "global" picture)
abstract bpel definitions for processes that are never going to be in
bpel - not least because some are "leaf" processes in the web-service
world, and do real work on databases or visible effect on GUIs etc.
rather than just defer to yet another web-service, which is all
executable bpel can do

	- there can be multiple executable processes matching a single
abstract definition - this is just an interface:implementation
relationship

(Apologies to Tony if I've mis-represented him). They obviously have
some exciting implications for what bpel tools in general might do
(especially the middle one - how on earth do you show compatibility
between abstract bpel and a legacy app written in cobol with a
web-service front end)

But these don't seem to be in the spec. (last one might be). Should it
be left to interpretation (and, no doubt, some books) ?  

There's also the possibility of stating the rules (guidelines ?
constraints ?) involved in the two abstract bpel definitions that make
up either side of a business protocol.


(I should possibly mention that I was for a long time very sceptical
about whether bpel or things like it was the way to do this, and thought
it could be done with a simpler, less procedural approach. but gradually
I found my vague "ideal" was getting necessarily more complex and
needing more functionality - in fact heading towards somehting much like
on abstract bpel)
	
Peter (speaking for himself)



> -----Original Message-----
> From: Yaron Goland [mailto:ygoland@bea.com]
> Sent: 22 October 2003 23:09
> To: 'John Evdemon'; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] FAQ
> 
> 
> Some comments
> 
> > -----Original Message-----
> > From: John Evdemon [mailto:jevdemon@microsoft.com]
> > Sent: Tuesday, October 21, 2003 12:44 PM
> > To: wsbpel@lists.oasis-open.org
> > Subject: [wsbpel] FAQ
> > 
> > 
> >  <<WSBPEL DRAFT FAQ.txt>> Hello all,
> > 
> >  A while ago I asked for feedback on a TC FAQ.  I have attached a 
> > draft that incorporates some initial feedback from Monica and Ugo.
> > Please respond with any additional questions or concerns.
> > 
> > If there is no feedback by 10/28 I will assume the TC is happy with 
> > the current version (attached) and submit it to OASIS.
> > 
> > Thanks!
> > 
> > John
> > 
> > 
> 

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_workgr
oup.php.




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_workgr
oup.php.





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_workgr
oup.php.





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.