OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] A Topic for the F2F?


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:fred.cummins@eds.com]
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:david.burdett@commerceone.com]
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:rajesh@iopsis.com]
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:Gnosis_@compuserve.com]
Sent: Monday, May 26, 2003 6:39 PM
To: Maciej Szefler
Cc: WS BPEL (E-mail); Burdett, David; Jim Webber; edwink@collaxa.com;
Sadiq, Waqar; doron@collaxa.com
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: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org





---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]