Maybe a little bit of historic background on BPEL helps in the discussion
(having been in the driver seat for IBM in creating BPEL - as Sanjiva pointed
out):
I am the workflow/BPM business for more than two decades. I worked on WfMC from
the very beginning on but phased out mid 90ies when I came to the conclusion
that we won't succeed in this huge set-up to standardize features supported by
most vendors - we just attempted to much in one shot.
When we began working on BPEL we consciously decided to focus on the most
needed features in a particular application area, i.e. to take a step-by-step
approach. This area was "automatic workflows" where the implementations of the
activities of the workflows are given by operations of Web services; note, that
the support of asynchronous operations in BPEL is of utmost importance because
automatic workflows are often used in EAI environments which are based on
message queuing, ie. asynchronous interactions. In addition, we decided to
allow to render such a workflow again as a Web services. Alltogether, we
created what is sometimes called a "recursive aggregation model for Web
services": create new Web services from Web services, such that you can use the
services created in a new aggregation and so on. So, I find the phrase "21st
Century Visual Cobol" not so bad ;-)
We wanted to stay as long as possible in this automatic world, i.e. we needed
fault handling features in BPEL to avoid human intervention when something went
wrong. Thus, we added scopes to BPEL. And fault handling should have the
abilitly to automatically repair broken situations allowing you to retry other
ways to complete a business process in an alternative way; this is why
compensation handlers are in BPEL.
Is this all simple, trivial? No, not at all! Parallel, asynchronous,
recoverable programming isn't simple... But you can start very simple by
stitching together a few services and achieve things that have been very
difficult before - and customers are doing it quite successfully. When you got
familiar with the basics of BPEL you can start making use of more advanced
features but you will add more complexity - as usual.
Is BPEL "complete"? No, not at all! As I said above, we started by focussing on
automatic flows. If you take a look at proprietary workflow environments they
go much further by offering the support for human interactions in workflows, by
supporting subprocesses, monitoring of business processes and so on and so. And
many real world business processes make use of all of these features: i.e. that
do not only consist of automatic workflows but they do include automatic parts
mixed with people interactions, they do not only use Web services but Web
services that are again processes subordinating them as subprocesses etc etc.
Thus, it is obvious that BPEL needs extensions to cover all of this. For
example, IBM and SAP published white papers that sketch how BPEL may be
extended to support human interations ("BPEL4People") and subprocesses
("BPEL-SubprocessExtension"), for example.
If you need similar features today, you have to rely on proprietary extensions.
If you have to create and run automatic workflows you can do that via standard
BPEL today.
As the acronym already says, BPEL focusses on Execution of workflows. As such,
it has a crisply defined operational semantics, i.e. when you specify BPEL
process you know how it will be run in a BPEL-compliant engine. But specifying
non-trivial processes in BPEL via a text editor is no fun for business users
;-) Thus, you need a graphical tool allowing you to author BPEL processes. But
if you take a look at the various BPEL modeling tools it becomes apparent that
they all use different graphical notations. Since the original BPEL authors
wanted to stay focused, we did not invent a special graphical notation for BPEL
by will.
Thus, a separate standard for graphical notations for the elements of a
business process metamodel was due. This is when BPMN came in. But from a BPMN
perspective, BPEL is one of many possible workflow languages (although no other
process language comes even close in terms of numbers of products supporting
it). Consequently, BPMN abstracted away from BPEL making it more easier for
business users to model business processes. But the price is that abstraction
looses semantics, i.e. there is no one-to-one mapping from BPMN onto BPEL.
Similar is true for all the other process modeling approaches (e.g. UML
activity diagrams etc etc).
So, "is BPEL fundamentally flawed"? Not surprisingly, I don't think so. As of
now, it achieved its goal: it provides a language to specify executable
automatic business processes. It is supported by the vast majority of vendors
in this space - first time in the history of workflow/BPM products. It is
extensible, and can be used to base further features like human interactions,
subprocesses etc on top of it (see the white papers I mentioned before). You
can use BPEL today to solve integration problems that have been very difficult
to realize before. And it will take its time to support more and more features
you are used today from your propriatary workflow systems/BPM environment in a
standardized manner mid-term.
Frank
----- Ursprüngliche Mail ----
Von: Steve Jones <[EMAIL PROTECTED]>
An: [email protected]
Gesendet: Samstag, den 13. Januar 2007, 15:37:25 Uhr
Betreff: Re: [service-orientated-architecture] Re: Forrester Create a Long
Acronym
On 13/01/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> On 1/13/07, Steve Jones <[EMAIL PROTECTED]> wrote:
> > Which is fine for certain elements, but there is another scenario and
> > that is where an application is calling a bunch of things in a similar
> > manner to straight Java code and where BPEL is a more sensible
> > _programming_ language than Java, for instance if there is quite a bit
> > of async.
>
> But do we really need something as complex as BPEL to do this type of
> simple app?
I'm not seeing a great deal of other solutions out there right now for
async. Doing a quick 6 step BPEL that co-ordinates 3 async points
isn't complex from the _developers_ perspective. BPEL only gets
complex when people start using it for things that it shouldn't do.
So far that has been trying to do rules processing in BPEL rather than
the distributed process challenges (which are much rarer).
>
> >
> > That is where I've tended to see BPEL used very successfully. Surely
> > the question here on the various different solutions is what works for
> > a given scenario, elements such as non-repudiation and debugging are
> > going to become more tricky in a rules/state scenario I would expect
> > which may be justifiable for certain project areas but not for others,
> > the other challenge is that of tooling and product support. While
> > there might be architecturally more elegant answers these are pretty
> > mute until their is the tooling and support to make those choices
> > economically feasible for the majority.
>
> I totally agree. The majority requires product implementations. I just
> wish that the vendors had invested their effort into something a bit
> different.
You and me both, I'd like to have seen them concentrate on modelling
abstractions for SOA at the business level.
> As you say, BPEL works pretty well for simple apps, but as
> soon as you try to do something a bit more complicated, you get into
> proprietary extensions. So why even bother with BPEL? I don't really
> see that the BPEL standard adds any value. You use a modeling tool to
> define the process, and for the most part people use either BPMN or
> UML as the modeling notation.
BPMN I'll give you, but UML to model _business_ process isn't
something I'd like to walk through with business people. So while you
do have to use proprietary extensions right now this is exactly the
same as the early days of Java where each IDE, App Server Vendor,
framework required you to use their extensions. Over time the
successful extensions were rolled back into the standards. Neither
BPEL nor BPMN are 100% there yet, but that doesn't mean we should
start from scratch.
> So these standards are valuable.
> Unfortunately, BPEL cannot express the richness of the modeling
> notations.
But BPEL isn't a modelling notation its an execution language, I see
it as the JVM to BPMN as Java. Standardisation of both pieces is
required but there isn't anything that says they have to be _one_
thing.
BPEL can suck, but I have seen successful projects using it and right
now the alternative is to roll your own which is rarely a good idea
unless you've got some of the people on this list working for you.
> Therefore it fails to meet the basic requirements of a
> XML-based model exchange language (as in XMI).
And of course the interesting thing here is that in reality for SOA
none of these really help anyway as BPMN relegates service to a
secondary position and decides that process is the way forwards. For
the state and rules based approach to work you will need a way of
describing service first and then describing motivations for
interactions, this means that the notation needs to deal with
abstractions of interaction rather than ordering of steps, which is
what both BPEL and BPMN do.
BPEL and BPMN are 21st Century Visual Cobol, good for some
implementations but a poor way to model and build a successful
enterprise.
>
> Anne
>
> >
> >
> > On 13/01/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> > > Not really. Orchestration and choreography are different.
> > > Orchestration defines a process, while choreography defines an
> > > interaction between two or more parties.
> > >
> > > My preferred approach to orchestration is one based on state and rules
> > > versus an execution plan. e.g., "Given the current state, what should
> > > happen next?" versus "This step just completed (or failed to
> > > complete), so this is supposed to happen next."
> > >
> > > A state/rules-based system has no requirement for a centralized engine
> > > to manage the process.
> > >
> > > Anne
> > >
> > > On 1/12/07, Stefan Tilkov <[EMAIL PROTECTED]> wrote:
> > > > So Anne, would it be fair to say that you think "orchestration" is
> > > > fundamentally flawed, and only "choreography" is useful?
> > > >
> > > > Stefan
> > > > --
> > > > Stefan Tilkov, http://www.innoq.com/blog/st/
> > > >
> > > >
> > > > On Jan 12, 2007, at 4:03 PM, John Evdemon wrote:
> > > > > BPEL is an orchestration language – you seem to be describing
> > > > > choreography.
> > > > >
> > > > >
> > > > > From: [email protected]
> > > > > [mailto:[EMAIL PROTECTED] On Behalf
> > > > > Of Anne Thomas Manes
> > > > > Sent: Thursday, January 11, 2007 4:57 PM
> > > > > To: [email protected]
> > > > > Subject: Re: [service-orientated-architecture] Re: Forrester Create
> > > > > a Long Acronym
> > > > >
> > > > > I think BPEL is fundamentally flawed.
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
> Yahoo! Groups Links
>
>
>
>
Yahoo! Groups Links
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
