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?


David:

> 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. 

I disagree. Given a BPEL script, you should be able to parse the graph and
create a graph in your particular tool's style.
 
> 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.

I don't think that a standard version of BPEL actually provides any lock-in.
It would be where non-standard extensions are added that lock-in would
occur.


> 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.

I'm not sure I get this. Why would any two vendors provide identical
interfaces? Sure the underlying constructs will be the same (BPEL actors),
but there is no reason for the visual interface not to abstract these. For
instance one tool migt use a dataflow paradigm, one might use a the "jigsaw"
style. Others may choose spreadsheet style languages, or for that matter
some might choose French :-) The point is that these are just views onto the
underlyign BPEL script, and providing a tool can export a pure BPEL script
(sure as it must to do drop onto an execution engine), then there is no
lock-in.

> 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. 

This is probably just me being dim, but I can't see why BPEL in the raw
doesn't provide both transportability (everyone understands it) and
differentiation (the way the model is presented across tools is bound to be
different, and the best presentation wins out in the market).

That being said, I can perhaps see a reason for wanting to keep comments
(and even perhaps colours and absolute locations) for a visual graph.
However, promoting this ability at this fundamental level I believe will
have the tendancy to homogenise tool support, not provide fruitful
differentiation. This is apparent if one vendor wants to implement a
data-flow style visual interpretation and another wants to implement a
spreadsheet-style language. What do these two have in common? Certainly
things like comments, but outside of that things like absolute location of a
visual node start to have less commonality between the two. The only thing
you can say without a doubt that they have in common is the process
definition.

So, I think the risk of pursuing this is that, not only is it a great deal
of work, but that work might end up coercing tool providers into building
very similar tools.

Jim



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