Re: [wsbpel] Federated Processes and BPMS Topology

Carpenter, Robert E wrote:

>An interesting discussion. Here is my take - at least for the
>foreseeable future:
>
>1. The reality is that most large companies will end up with more than
>one "process control engine". Some of these will be BPEL based and some
>may not be BPEL based.
>2. The individual "process control engines" will find domains based upon
>the service layer offerings they incorporate. This is the value
>differentiator which defines, by ROI compulsion, the reality of
>capability boundaries.
>3. Viewed as isolated "objects", these process engines can result in a
>level 1 integration at the message level. WS is a good candidate for
>that messaging/event propagation role as it matures -> ws-*. Level 1
>will be needed anyway.
>  
>
That is also our understanding.

>4. Everyone knows that a "real business process" is more than simple
>event integration of semantically isolated process engines. As with most
>things, the beauty of pi-c is also its weak point -- it is business
>semantic and ontologically blind. Nonetheless, it is useful.
>  
>
I could not agree more. I believe pi-calculus provides the most 
compelling foundation for a model of interconnected processes/services. 
That's where we see the value in using it. That is not the entire 
problem we're trying to solve, just a significant piece of the puzzle. 
Other problems do require additional capabilities, including business 
semantics, ontologies, QoS, security, etc. These are introduced at other 
layers in the process definition, or layered separately. But they are an 
important component of the overall solution.


>5. Given that processes will execute in a heterogeneous process
>execution environment, the need is to develop a process correlation
>approach which goes beyond the present thinking of BPEL Correlation
>Sets, and which allows
>	a. Access and expose the state of a process as reflected in the
>monitoring and management environment of the individual process control
>engines;
>	b. Reconstruction of the process from the correlation
>information;
>	c. Allows the correlation information to be "adorned" with
>process specific value information; and 
>	d. enables data mining of the process information.
>  
>
That is basically the coarse grained requirement list for a 
specification such as BPQL.

Assaf


>The implication of a. is that the individual tool must be able to
>expose, respond to queries, based upon the CorrelationID. b. is a little
>more interesting and c./d, essential to provide a bridge from
>orchestration structure to business process content.
>
>Rob Carpenter
>Intel Corporation
>
>
>
>-----Original Message-----
>From: Harvey Reed [mailto:hreed@sonicsoftware.com] 
>Sent: Wednesday, December 03, 2003 9:14 AM
>To: 'Howard N Smith'
>Cc: public-ws-chor@w3.org; wsbpel@lists.oasis-open.org; 'Andrew Berry'
>Subject: RE: [wsbpel] Federated Processes and BPMS Topology
>
>My 2 pennies follow:
>
>  
>
>>Howard wrote:
>>
>>Now, this is quite different from the issue of interoperability
>>    
>>
>between 
>  
>
>>different BPMS products. 
>>I think the approach we took at BPMI.org was to assume that, as with 
>>databases, end users would
>>be less interested in BPMS to BPMS interoperability then they would
>>    
>>
>the 
>  
>
>>opportunity to consolidate processes
>>from multiple systems (as with RDBMS data aggregation). 
>>    
>>
>
>Yes, most companies will buy sets of software from a vendor. The biggest
>value of a standard will be in the design/implement language (like SQL,
>XQUERY, BPEL) for the purposes of enabling a workforce. Making products
>work
>vendor-to-vendor will happen over time.
>
>
>  
>
>>Howard wrote:
>>
>>We saw BPMS as being the enabler to practically
>>share processes, as Web Services allows the sharing of functions and
>>    
>>
>RDBMS
>  
>
>>the sharing of data. In this
>>respect we were not in the p2p, b2b, very extended, very
>>    
>>
>loosely-coupled 
>  
>
>>camp. Although, we accept some
>>vendors might be. Rather, we would see a gorilla in an industry
>>    
>>
>managing 
>  
>
>>BPMS operations on behalf of
>>a trading group, and, last mile connectivity into the value chain
>>    
>>
>might be
>  
>
>>provided by, for example, deploying
>>an agent based approach at the periphery. 
>>    
>>
>
>Our products are in the loosely coupled/distributed arena. Personally I
>see
>both models being very useful and complimentary. The trading group
>example
>is similar to a VAN like GEIS/EDI, except much more sophisticated.
>
>BTW, I'm glad we abandoned pi-c for this thread.
>
>++Harvey
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
>oup.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Wednesday, 3 December 2003 14:29:21 UTC