[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]