Re: [service-orientated-architecture] BPEL+

[Keith Harrison-Broninski]

Amit Gupta ((FSI)) wrote: Let me try and explain the difference between BPMN and BPEL with an example.   If we have to represent a simple banking transaction with BPMN, where we need to DEBIT $100 from 'Amit' account and CREDIT the same to 'Steve' account.   In this case, the BPMN based graphical semantics will simply state the steps as Start of Process --> "Validate" Input ---> DEBIT Amit's account --> Apply Transformation of data --> CREDIT Steve's account --> end of Process.   The above BPMN semantics do not define the DATA associated with each of the steps in above process flow. It simply shows a SHEMATIC of the process flow.   However, when this BPMN compliant flow is converted to BPEL, one can add specifics of the "format" of data "going in" or "coming out" of each of the steps defined above (and details of the actual transformation applied as well).  Besides, each of the "steps" can be represented as a WSDL invocation (which may or may not be implemented using WS over SOAP)..   As such, I see BPMN as simply the "visual face" of BPEL. to which Steve Ross-Talbot replied: Interesting. I'm not at all sure that BPMN see it like this. And Steve is absolutely right (however the Fiorano software produced by Amit's company operates).  To see this, let's quote from the BPMN spec (v1.0 of 3 May 2004): (p.43) Modeler-defined Properties MAY be added to a Process. These Properties are "local" to the Process. All Tasks, Sub-Process objects, and Sub-Processes that are embedded SHALL have access to these Properties.  The fully delineated name of these properties are "<process name>.<property name>" (e.g., "Add Customer.Customer Name"). If a process is embedded within another Process, then the fully delineated name SHALL also be preceded by the Parent Process name for as many Parents there are until the top level Process. (p.282) B.11.7 Property The following table displays the set of attributes of a Property, which is used in the definition of attributes for a Process and common activity attributes: Name : String Each Property has a Name (e.g., name="Customer Name"). Type : String Each Property has a Type (e.g., type="String"). A Property may be of type Set, which allows child Properties [Type = "Set" only] Correlation (0-1) False : Boolean If the ConditionType attribute is set to _expression_, then the ConditionExpression attribute MUST be defined. Otherwise, it is not valid.  This attribute is included for mapping to BPEL4WS. The Property will map to a correlationSet and the child Properties will be properties of that correlationSet. In other words, a BPMN process is intended to contain enough information to specify all elements required to form a service invocation.  It was certainly never intended as merely the "visual face" of anything, but as a complete graphical process description language.  You can use it with BPEL, yes (and the designers allowed for this specifically in the case of Set properties), but you don't need anything underneath to complete the process description. Directly as a result of BPMN, BPEL has become the Caliban of the IT world - the ill-formed and unlovable product of an unholy alliance, destined for no good ... and the original dream of a universal, pi-calculus-based BPM layer for enterprise IT now looks very unlikely indeed ever to become reality.  What we will get from the BPM work to date is better graphical, deployment and analysis tools for component technologies - not a bad thing, of course - and the focus of BPM will inevitably move towards areas not covered by such component technologies (i.e., human interaction). -- All the best Keith http://keith.harrison-broninski.info SPONSORED LINKS Service-oriented architecture Computer monitoring software Free computer monitoring software YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.