Title: 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:
