|
Steve,
I find this comparison of BPEL (process orchestration
language) with Java
(a programming language) a bit out of
context of this discussion.
BPEL is obviously not a replacement of Java and no one is
denying that
you as a "developer" can write Java (or CSharp) code to create
business
processes involving Webservices and other
end-points.
BPEL does define "Process Orchestration" in a vendor
independent way
- allow processes to be abstract business processes to be
defined using
Vendor A's tools and "implemented" using Vendor B's
tool.
"Implementation" in this context refers to actually connecting
to external
entities participating in the business process and making them
"talk"
to the business process engine.
If the enternal participants are already web-services, then
this "implementation"
is built into BPEL semantics itself.. However, as most
existing applications are
not already WebService enabled, most BPEL vendors have
extended their
tools to provide a configuration driven approach for exposing
a wide range
of 3'rd party applications as Webservices.
Hope the above clarifies the level of portability supported by
BPEL semantics.
Ofcourse, you can create the entire process by writing Java
Code - and some
developers will like to do it this way.. But most business
analysts would like
to work at a higher level of abstraction (as those provided by
BPEL tools)...
You made a few comments like:-
a) BPEL is not scalable beyond couple of services
b) BPEL does not support recursive model well
c) BPEL is centralized execution model
I think these are likely due to your experience with a
particular BPEL tool, as
most commercial grade BPEL engines suffer from none of the
limitations you
have outlined above.
BPEL itself neither helps, nor limits the scalability..
Scalability is simply
a function of how well a particular BPEL engine is architected
and implemented.
Similarly, BPEL does not hinder recursive execution... Some
tools may.
Would appreciate "examples" of the kind of things you think
are NOT
possible due to inherent limitations of BPEL
And finally, the market today is starting to see a number of
products which
are offering "distributed BPEL" - where a large business
process, spanning
multiple BPLE processes running on a network of
machines, from a single
node in the network.
Thanks,
Amit Gupta
Fiorano Software Inc.
----- Original Message -----
Sent: Sunday, January 15, 2006 8:39
PM
Subject: Re:
[service-orientated-architecture] BPEL+
Interesting questions and answers. Let me try to
ground it in what
Architects want as opposed to
what vendors suggest we
want. And here I have my architect hat on as
opposed to any of the
other
multitude that I wear.
See inline ....
On 15 Jan 2006,
at 06:02, Amit Gupta ((FSI)) wrote:
> Patrick,
>
> Please read on for my comments on some of your
questions:-
>
> > Does any other implementation provide
JavaSnippet?
> >
> I think most BPEL implementation provide
mechanism to include "Java"
> Snippet.
> Either directly as Java
code embedded within BPEL process translated
> to Java
> code
during "compilation" of BPEL - or as pluggable components (which
>
in
> turn can be written in Java).
>
> Fiorao's BPEL,
Oracle's (collaxa) BPEL, BEA's etc.. all provide
> it...and I
am
> assuming that this is supported in other BPEL engines as
well.
>
SRT> I am not interested in suppositions. Either it is
portable and
vendor neutral or it is not.
SRT> Java in itself may
well be a language I prefer to use but it does
not mean as an
architect
SRT> I am free to use it. If I have a large .NET legacy what
use are
Java snippets to me?
SRT> If we agree that the world is
divided into two, the .NET route and
the Java route then
SRT> BPEL
is not at all interesting if it does not provide me with
interop and
vendor
SRT> neutrality. If it does not what does it give me that Java
does not
(and presumably CSharpe)?
SRT> For example in Java I can
write orchestrations and interact with
Web Services. This is
SRT>
what BPEL is supposed to do. If it doesn't do it in vendor neutral
way
then what compelling
SRT> reason, as an architect, do I have to use it?
(You can regard that
as a challenge).
>
> > What
good is BPEL since every implementation seems to have multiple
>
> extensions?
> >
> This is an often asked question.. Here's
how I look at it.
>
> BPEL is a language standard for
Process "Orchestration" - not process
> implementation. So while most
vendors claiming BPEL compliance have
> completely standard based
process orchestration capabilities, the
> implementation capabilities is
where most of the extensions are.
>
> As such BPEL value is
portable "Process Orchestration" - but not
> necessarily portable
"Process implementation" (unless each end-point
> of the process is
already Web-service enabled).
SRT> What do we mean by "Process
Orechstration"? Is it really no more
than
SRT> Composition of Web
Services into new services such that the new
service
SRT> controls
(as a broker does) interactions with the other services
in
order
SRT> to realise a new service? If so again it is what do I get
that
Java (and CSharpe)
SRT> do not provide me?
SRT> If
"Process Orchestration" does not mean this centralised
brokering of
interaction
SRT> and the associated control then does it mean that BPEL
can
describe some sort
SRT> of design blue print for interaction of
a collection of services?
This is something
SRT> that BPEL cannot do
in any scalable way. It breaks down after two
services. If
SRT> you
have three services then the partner links and control become
far too
complex
SRT> to get any real benefit because you have to describe from a
single
service
SRT> perspective. It has not global model. It was
never designed to
have one and was
SRT> designed for recursive Web
Service composition, whereas WS-CDL was
designed
SRT> to describe
(hence the D in CDL) the blue print interactions.
SRT> BPEL is somewhat
constrained in its execution model. It is
centralised, hence
the
SRT> vendor implementation that exist today. As an architect I
certainly want to describe
SRT> interactions but I do not want to
mandate a particular execution
style.
SRT> If anyone has clear
referencable evidence that BPEL is better than
Java I and many
SRT>
other would like to understand why? The only thing that makes BPEL
attractive is the
SRT> dollars behind it and not the technology nor
the standard (in
waiting) that underpin
SRT> it.
>
> Thanks,
> Amit Gupta
> Fiorano Software
Inc.
>
>> ----- Original Message -----
>> From: Logan,
Patrick D
>> To:
[email protected]
>> Sent: Sunday,
January 15, 2006 2:15 AM
>> Subject:
[service-orientated-architecture] BPEL+
>>
>>
>>
"IBM... has... Process Server (a BPEL+ engine)"
>>
>> I
cannot tell for sure looking through some of the results of a
google
>> search. Is BPEL+ a standard beyond BPEL or just a name for
IBM's
>> extensions?
>>
>> There appear to be
multiple implementations beyond IBM that mention
>> BPEL+. Are they
implementing the same extension?
>>
>> IBM's BPEL+ mentions
JavaSnippet. Is this the same as BPEL/J? Does any
>> other
implementation provide JavaSnippet?
>>
>> What good is BPEL
since every implementation seems to have multiple
>>
extensions?
>>
>> Are there any non-trivial in-production
orchestrations that are
>> represented as pure
BPEL?
>>
>> Are there any reported cases of a team moving
BPEL representations
>> from
>> one implementation to
another beyond the trivial?
>>
>> Thanks
>>
-Patrick
>>
>>
>>
>>
>> YAHOO!
GROUPS LINKS
>>
>> ▪
Visit your group
"service-orientated-architecture" on the web.
>>
>>
▪ To
unsubscribe from this group, send an email to:
>>
[EMAIL PROTECTED]
>>
>> ▪
Your use of Yahoo! Groups is subject to
the Yahoo! Terms of
>>
Service.
>>
>>
YAHOO! GROUPS LINKS
| 