Title: Message
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.
