Title: Message
The only comment I disagree with is “it is better to leave BPEL for what it is designed to do - the
executable "private process" part of our architecture”
If you read the introduction to the
specification, it is hopefully quite clear that the specification is designed
to provide a common set of modeling concepts for use in both public and private
process descriptions.
Satish
From: Steve Capell
[mailto:]
Sent: Thursday, October 23, 2003
3:25 PM
To: 'Jean-Jacques Dubray'; Satish Thatte; 'Furniss, Peter'; ; John Evdemon; ; Dave
Welsh; 'Monica J. Martin'
Subject: RE: [wsbpel] Abstract
BPEL (was RE: [wsbpel] FAQ)
Dear all,
Thank you for all your responses. Everyone
has a good point, not the least of which is that I should go away and document
a use case....
Just to clarify a few things:
Yes, I am
simplifying things a bit - reason is we need to deploy something now that
works for small & medium businesses and we can afford to simplify
things. Part of the reasons we can simplify things is that we are in
a position to define the "public process" for/with industry
sectors and also to build corresponding "private" process
components (pre-packaged) for specific back-office applications. The
idea is that we can target simple collaborative processes and common
back-office applications.
I agree that basic
WS cannot address QOS for B2B collaborations. However I see no
reason why the extended stack inclusing things like WS-RM, WS-Security,
WS-Transaction, etc - governed by a WS-Policy assertion cannot achieve the
required result. For those familiar with ebXML, I (perhaps
incorrectly) see SOAP+WSRM+WS-Security = ebXML MSH and that WSDL+WS-Policy
= CPP and (I had hoped) "Abstract" BPEL = BPSS. Lets not
get into a discussion about whether things like WS-Policy are genuinely
part of the WS stack (since it is still a vendor specification)....Also I
do realise that WS-Policy itself is just a syntax to express policies and
that some specific semantics (assertions) would need to be developed to
address this need.
BPEL is certainly an
"execution" language first and maybe needs to stay that
way. The discussion is really around the question of whether or not
WS-BPEL is going to "evolve" into another specification that
also addresses the B2B collaboration space. Frankly I'm not too
worried whether it does or not. If not then we'll adopt some other
suitable protocol for that part of the stack. Perhaps as many have
suggested it is better to leave BPEL for what it is designed to do - the
executable "private process" part of our architecture.
For the short term,
the "private process" (essentially a bpel and associated xsd,
xslt, xforms running on compliant runtime engine) will be hand crafted to
bridge the gap between a back-office application and a public
process. I had envisioned a time when I could import a public
collaboration definition and backoffice API into a visual design time tool
and efficiently create the bpel, xslt, xforms etc to bridge the
gap. I have not thought enough about how realistic that
is. Nevertheless, whether hand crafted or created with a nifty
tool, our intention is to try to demonstrate reusability of the private
process schema accross a community that shares the same back-office and
"public process". Even in a small country like Australia,
there are communities like that with member numbers in the 10,000's.
Re-use of private process content can obviously deliver enormous potential
savings.
For those that might be interested to
understand what we are trying to do here in Australia, please take a look at www.bizdex.com.au. Comments welcome.
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: Jean-Jacques Dubray
[mailto:]
Sent: Friday, 24 October 2003 7:33 AM
To: 'Steve Capell'; 'Satish Thatte'; 'Furniss, Peter'; ; 'John Evdemon'; ; 'Dave
Welsh'; 'Monica J. Martin'
Subject: RE: [wsbpel] Abstract
BPEL (was RE: [wsbpel] FAQ)
Steve:
I don't
know if I am able/allowed to publish to this list (I just joined :-). IMHO, you
will never be able to have a continuum between public and private choreography,
let alone abstract and executable orchestration.
Since you
mention BPSS, I feel that I might throw some comments about it. Ancient
specifications (based on internet times) like BPSS have long established that
most B2B interactions require a certain quality of service that only certain
protocols can provide. Traditional QOS protocols, part of the ws-stack are
helpless with that matter.
For
instance BPSS offer at least two levels of protocols: what I call a
"business reliable messaging" protocol and a "business
transaction protocol" (Bob feel free to jump in to keep me honest on what
I say). These protocols are essentials to carry some business activities (not
all I grant you, something like the travel agent example does not need that).
Assuming that the private chorerography or the deep orchestration layer will
implement these protocols is not the best use of your choreography or
orchestration resources. These protocols are far better handled by the
"Business Service Interface" concept described in the ebXML
architecture and the ebXML BPSS specification. I can only speak for myself, but
more protocols are needed at the B2B level, I am assuming that the ebBP group
will continue enriching these protocols that cannot be handled by your private
choreography, before it touches your orchestration layer.
Hope that
helps.
Jean-Jacques
tel: 425-649-6584
Cell: 508-333-7634
-----Original
Message-----
From: Steve Capell [mailto:]
Sent: Wednesday, October 22, 2003
11:15 PM
To: 'Satish
Thatte'; 'Furniss, Peter'; ; 'John Evdemon'; ; '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:]
Sent: Thursday, 23 October 2003 11:36 AM
To: Furniss, Peter;
; John Evdemon;
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:]
Sent: Wednesday, October 22, 2003
4:42 PM
To: ; John Evdemon;
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:]
> Sent: 22 October 2003 23:09
> To: 'John
Evdemon';
> Subject: RE: [wsbpel] FAQ
>
>
> Some comments
>
> > -----Original
Message-----
> > From: John Evdemon [mailto:]
> > Sent: Tuesday, October 21, 2003
12:44 PM
> > To:
> > 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_workgroup.php.
