Title: RE: [wsbpel] A Topic for the F2F?
David,
I
agree that at least many of those who define BPEL processes will want to do it
interactively, with graphical tools. However, I think we need to separate
BPEL, the execution language for business processes, from the implementation of
BPEL for interactive modeling of processes.
OMG
has issued an RFP for a Business Process Definition Metamodel. This is a
model that shares the core facilities of UML, but represents the concepts used
for specification of processes. The expectation is that this metamodel
will capture the concepts represented in BPEL and other process modeling and
execution languages. At the same time, this metamodel will be compatible
with UML and related specifications to support integration with other
models.
UML
has a standard XML form for exchanging models between tools called XMI (XML for
Model Interchange). There are currently specifications under development
(at OMG) for preservation of graphical layout information in the exchange of
models. The Meta Object Facility (MOF) defines a repository for models,
and there are specifications under development for querying and transforming
models.
Consequently, a BPEL process expressed in UML
could be exchanged between tools and be the subject of other common facilities
by virtue of being expressed in this UML-based meta model. In OMG terms,
the generation of BPEL (the XML form) is then a matter of transforming the UML
process model to a platform-specific-model that either directly or indirectly
produces the BPEL XML.
I
think the WSBPEL technical committee should focus on BPEL and its XML notation,
while relying on these other standards for the modeling aspects of
BPEL.
Fred
-----Original Message-----
From: Burdett, David
[mailto:]
Sent: Tuesday, May 27, 2003
1:38 AM
To: 'Rajesh Pradhan'; 'David RR Webber - XML
ebusiness'
Cc: 'WS BPEL (E-mail)'
Subject: RE: [wsbpel] A
Topic for the F2F?
What this really boils down to is end-user cost-of-ownership
and choice.
I agree with both of you that process definitions could end up
being very complex with 100s of processes in a definition. I also think that a
typical business will eventually have hundreds or more of these
definitions.
Now just suppose that you have created these definitions using
a graphical tool that uses it's own extensions to define the layout. You will
then find it expensive to change to another tool vendor as you will lose the
graphical information and have to re-create it.
Is this type of "customer lock-in" a vendor goal of this TC? I
don't think so and I doubt very much users of such BPEL tools would want
this.
On the other hand, I don't think that we should aim for the
lowest common denominator so that all tool vendors are forced into a
straight-jacket and have to produce more-or-less identical interfaces as there
would then be no opportunity for competitive differentiation.
So what we need is a half-way house that provides both
transportability AND the opportunity for vendor differentiation. Bottom line,
I think it worthwhile:
1. Making "BPEL definition tool transportability" a
requirement of this working group, and
2. Setting up a
sub-group that can take this on as a work-item.
David
-----Original Message-----
From:
Rajesh Pradhan [mailto:]
Sent: Monday, May 26, 2003 7:13 PM
To: 'David
RR Webber - XML ebusiness'
Cc: 'WS BPEL
(E-mail)'
Subject: RE: [wsbpel] A Topic for the
F2F?
Hi David,
Good point! Visual extensions should be the headache of the
tool vendors. I
don't think the current scope of the
TC includes the standardization of the
visual
representation of the BPEL artifacts. However, it would be
interesting to see if TC members have any thoughts about what
extensions
will need to be added ( if any ), to
support the diagramming of the BPEL. (I
presume, folks
from Collaxa and Intalio, Maciej and Sadiq will have some
valuable inputs here)
In reference to your earlier mail, I still think, we should
look at the
other standards ( competing or
complementary ) to see how we can leverage
their work.
Then, build as you have suggested - with suitable levels of
de-coupling using the power of XML.
Thanks,
Rajesh.
-----Original Message-----
From: David
RR Webber - XML ebusiness [mailto:]
Sent: Monday, May 26, 2003 6:39 PM
To: Maciej Szefler
Cc: WS BPEL (E-mail);
Burdett, David; Jim Webber; ;
Sadiq,
Waqar;
Subject: RE: [wsbpel] A Topic
for the F2F?
Contrary-wise - one could argue that for BPEL to succeed - it
will
make managing such complex interactions simple by
providing
components that manage those complexities
and limit them,
so that average mortals can quickly
and easily construct
robust and replicatable systems -
reliably - without regard to
what vendor is behind the
BPEL they have written.....
And I agree - that we do not need to solve vendors
problems
for them. Visual representations -
while stimulating intellectually -
are probably a
bottomless ocean depth to be plumbed. I'd
much rather have clear simple components and behaviours,
and let other people build sets of pictures - that allow
end
users to manipulate and express those.
DW.
==================================================
Message text written by "Maciej Szefler"
>
If the promise of BPEL is to be fulfilled
it is to be expected that process
descriptions will
grow to be quite complicated, on par with what can
currently be seen in traditional workflow implementations. I would
imagine
that one point of differentiation among
vendors of BPEL technology would be
in the area of
presentation and constructions of such process descriptions.
Perhaps it would be wise to include a completely opaque vendor
extension
area in the process descriptor for whatever
visual annotation the vendor
requires, rather than
developing specific visual annotations.
Maciej Szefler
Vice President -
Product Development <
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional
commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional
commands, e-mail:
