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?


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]