Re: [wsbpel] Gotos Considered Harmful?

["Monica J. Martin" <monica.martin@sun.com>]

Carpenter, Robert E wrote:

>I think that the discussion of human translation of the business analyst's model into a BPEL model via the skeleton makes a lot of sense, but my questions are: 
>
>(1) Does anyone have an example of a working translation process for other "higher order" BPR tool to/from BPEL ? An example would be SCOR level 3[or possibly SCOR level 4] <---->BPEL.
>
>(2) Does anyone know the "state of the art" around automated conversion between these two modeling paradigms - i.e. SCOR <---->BPEL ?
>  
>
mm1: You may wish to investigate if SCOR is the preferred modeling 
paradigms.  The Common Business Process Catalog Project, under UN/CEFACT 
(now with TBG I believe), looked at SCOR, the Porter Value Chain and 
others and proposed a hybrid model that was more in line with the 
classification of web services. The project lead is Nita Shara, 
nitas@bsil.com.  I have a very rough draft copy but not the final 
paper.  The work was briefed at XML Europe.  Nita should be able to 
provide the brief.

Thanks.

>
>Rob Carpenter
>Intel Corporation
>
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com] 
>Sent: Friday, July 11, 2003 9:56 AM
>To: Frank Leymann
>Cc: wsbpel@lists.oasis-open.org
>
>+1
>
>Frank Leymann wrote:
>
>  
>
>>I absolutely agree with the existence of (at least) two different roles in
>>specifying business processes: A business analyst and a "technical
>>modeller".  Typically what happens is that the technical modeller adds the
>>technical details to the business analyst's results that the analyst
>>doesn't care about (complex data structures, transforming textual
>>conditions into Boolean conditions, adding assignments etc etc).
>>
>>But, please, let me emphasize again that the technical modeller should not
>>(!) redraw/reshape/... the business analyst's process model, but "simply"
>>extend it.  Reshaping the model will mostly result in semantic clashes - on
>>other words, if the business analyst and the technical modeller do not
>>share the same understanding about the behavior of the model ("operational
>>semantics") they do very likely mis-communicate, or the semantics of "the"
>>representation of the business process will change. This is unacceptable
>>for various reasons.
>>
>>Thus, the language that the business analyst uses has to be a "subset" of
>>the language that the technical modeller uses.  The usage of quotes need to
>>be refined:  There are elements in the analyst's language that are to be
>>transformed by the technical modeller (textual conditions into Boolean
>>conditions, for example); and the analyst's language does include elements
>>that are not of interest to the technical modeller at all (e.g. artifacts
>>needed for simulation like cost information etc.).
>>
>>I am fully aware that there are zillions of metamodels and corresponding
>>tools around that do target business analysts, and that these metamodels
>>are only partially (if at all) complying with the ideal sketched before!
>>The relevant artifacts captured by these BPR tools will have to be mapped
>>onto BPEL resulting in a "BPEL skelleton", and this case the technical
>>modeller will have to reshape the skelleton into valid BPEL. This is done
>>today by mapping from BPR tool representation to workflow/process-engine
>>vendor specific "technical formats"; and it is a real pain for the
>>customers if the tools metamodel and the workflow/process-engine metamodel
>>are not close. To cure this pain, a couple of tools already provide "modes"
>>that restrict the modeling capabilities provided by the original tool's
>>metamodel to the ones of the target workflow-system or process engine
>>avoiding the need for "redraw", "reshape" etc..
>>
>>Regards,
>>Frank
>>
>>-------------------
>>Prof. Dr. Frank Leymann, Distinguished Engineer
>>IBM Software Group
>>Member, IBM Academy of Technology
>>
>>Phone 1:  +49-7031-16 39 98
>>Phone 2:  +49-7056-96 50 67
>>Mobile:  +49-172-731 5858
>>-----------------
>> 
>>
>>    
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>
>  
>