Title: Message
Satish,
I'm
delighted that you disagree with that <slightly provocative> comment
becuase I too would like to see bpel address the collaboration
stuff....
I
guess the next step is some use cases. I'll have a stab at
it..
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: Friday, 24 October 2003 9:38
AM
To: Steve Capell; Jean-Jacques Dubray; Furniss, Peter;
; John Evdemon; ; Dave Welsh; Monica
J. Martin
Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel]
FAQ)
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.
