[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] A Topic for the F2F?
Assaf I agree with you when you say ... >>>The best solution in my opinion is to have the visual definition in a separate document which references the BPEL definition with notation-specific information.<<< ... however you also provide very valid use cases of different approaches to the layout of a BPEL definition, for example ... >>>One may want it to be more like a flowchart, while another would prefer it to look like a statechart diagram. One may like to have a top-to-bottom flow, while another may prefer a left-to-right flow ...<<< My whole reasoning for wanting to keep some positional information about a visual representation of a BPEL definition was that no matter what the visual representation was (e.g. any of the ones you suggest) it could be preserved when moving the BPEL definition from one development environment to another. David -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Tuesday, May 27, 2003 9:48 AM To: Maciej Szefler Cc: David RR Webber - XML ebusiness; Sadiq, Waqar; Rajesh Pradhan; Burdett, David; WS BPEL (E-mail) Subject: Re: [wsbpel] A Topic for the F2F? The truth probably lies somewhere in between. No two business analysts are the same. Some of them are expert in a particular field, but they can't sit down and write a process definition at the level that BPEL expects it to be modeled. And even if they could, it could be a waste of their time. If they are expert in production, customer management, quality, etc their time is better spent given a higher-level view of the process rather than messing with the detailts. On the other hand, some are very technical capable. Down to the level that they would be writing E/R diagrams for the database, rulesets for the rule engine, and yes, also the logic for an executable process. In fact, I had the opportunity to work once for a company run by two business analysts that were expert in their particular field (insurance). One was a business analyst of the first category, you had to explain to him how to use Excel and Word to get the best of them. The other was a business analyst of the second category, and in fact wrote down the business process definition and data model to a very fine detail with only minor help from the engineers. Unfortunately, while he could produce good E/R diagrams and let the engineers deal with the more technical SQL issues (like tablespaces, stored procedures and query plans), his ability to write processes was limited to the modeling capabilities of the time - hardcopies. This would then be translated into code that did nothing more than execute the hardcopy definition to the letter. So let's not put all business analysts in the same category, but recognize that some would never use a modeling tool to create BPEL processes regardless of how good it is, while others would be doing exactly that and do need the modeling capability. Which brings me to the second issue. Should BPEL include a visual notation as part of the language? The business analyst or engineer or whatever you want, that goes about creating BPEL definitions may have their needs meet by a visual modeling tool. We find out that generically this is the case and only in some cases do they actually venture to look into the generated XML. Working with the visual diagram seems to be sufficient for the majority of cases. But they may want to have different visualizations for the same process definition. One may want it to be more like a flowchart, while another would prefer it to look like a statechart diagram. One may like to have a top-to-bottom flow, while another may prefer a left-to-right flow. In some cases you would like to have fault and compensation handlers presented in a separate page, but in other cases you would like to see them as part of the larger flow and in the same page. You may elect to use one tool and one notation to view it in all these different ways. There's a benefit there, though I doubt if we can all agree to use the same notation ;-) But you may want to have different visual definitions based on that notation. Writing visual information into the BPEL definition prevents you from doing that. The best solution in my opinion is to have the visual definition in a separate document which references the BPEL definition with notation-specific information. arkin Maciej Szefler wrote: >>I do not see too many business analysts - aka visual tool >>users - would want to be down in this level of the weeds, >>even using a visual tool. Creating procedural code with >>event handlers and error handlers are programmic tasks. >> >> > > > >>DW. >> >> > >True, but this is what everyone wants (everyone buying BPM tools). As it is unlikely that business analysts would be capable of producing BPEL directly (even with a naive mapping to a visual representation), the BPEL tools should facilitate a collaboration between analysts and engineers as well as providing higher level abstractions suitable for manipulation by an analyst untrained in the voodoo of xpath manipulations, correlation sets, and compensation handlers. > >Maciej Szefler >Vice President - Product Development >FiveSight Technologies Inc. >213 N. Morgan Street >Suite 1A >Chicago, Illinois 60607 >phone: 312-432-0556 ext 226 >email: mbs@fivesight.com > > >--------------------------------------------------------------------- >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]