Title: RE: [wsbpel] A Topic for the F2F?
Fred,
you said ...
>>>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.<<<
... maybe, but I think that BPEL needs to do its "due
diligence" first. I *think* this would involve the
following:
1. Agreement of the problem to be solved. It seems to me that
the scope is expanding from how to represent BPEL definitions graphically in a
transportable way, to understanding: the methodology (e.g. UML/Rational) used to
develop solutions/systems; the role that BPEL has in this development process,
and the different needs/requirements of the participants, e.g. business analysts
vs programmers vs process operators
2. Analysis of the existing initiatives, e.g.
the ones in OMG and BPMI that others have stated are already adressing this
problem
3. Deciding how the existing initiatives will
help. We need to work out how the existing initiatives *will* (or
won't) solve the problem that we think needs to be solved for
BPEL
4. Work out how we co-operate. If we decide
these initiatives will meet our needs then we need to determine what, if
anything, the BPEL activitity needs to do, for example some kind of formal
liaison.
I am *not* saying that we would necessarily do all of
the things above, but if we do decide that this TC wants to look into this area,
then I think this or some similar process that we can agree is what we will need
to do and that this should be the first task of any sub-committe we decide to
set up.
My $0,02c.
David
-----Original Message-----
From: Cummins, Fred A
[mailto:]
Sent: Tuesday, May 27, 2003 9:32
AM
To: Burdett, David
Cc: 'WS BPEL
(E-mail)'
Subject: 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:
