Re: Why workflow is NOT just a Pi-process

JC Reddy wrote:

>Edwin,
>
>Broadly speaking, that's a good description of the gap between the two camps
>(Workflow and BPM). I would like to see the goals and features of both merge
>into one standard to enable fast development and composition of applications
>that lie within and span across the organizations.
>
>IMO, a BPM standard should be more than a web-services orchestration and
>choreography standard - it also needs to incorporate  business semantics.
>This is especially true if we intend BPM standards and standard-based BPM
>products to subsume the current workflow systems.
>
>  
>
IMO the BPM space should consist of a stack of specifications, each 
targeting a well defined problem, In much the same way we approach the 
WS space. Rather than doing everything inside WSDL or SOAP, we have 
specialized specifications that deal with specific issues, like 
security, reliable messaging, addressing, coordination, policies, 
portals, management, etc. Similarly, we need to look at the BPM space as 
a space allowing for the existence of multiple specifications, and at 
specifications like BPEL/BPML as specialized specifications in this 
space. They are important, but they are part of a larger picture. Trying 
to solve all problems in one specification, in my opinion, leads to less 
capable specifications. Building a stack allows you target specific 
problems with the best possible tool, and combine all these tools into a 
powerful toolbox.

Assaf


>JC Reddy
>
>
>-----Original Message-----
>From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
>Sent: Friday, December 05, 2003 9:19 AM
>To: jcreddy@bpmlabs.com; public-ws-chor@w3.org
>Subject: RE: Why workflow is NOT just a Pi-process
>
>
>JC,
>
>Sorry for intruding but I really like your terminology. I think that the gap
>between the 2 camps is that:
>
>- BPEL/BPML is not as rich model wise as the proprietary workflow languages
>  (the model does not include user, access control, form, data validation,
>   Organizational model, security, etc...).
>
>- But BPEL/BPML offer a richer support for XML, a richer set of
>  orchestration primitives, a more transparent interaction model and
>  therefore a better composition model (star, peer-to-peer, ring, etc...).
>
>The end result is that vendors will adopt BPEL/BPML as a foundation and
>complement it with additional models to deliver a full solution of
>developers and customers (Workflow, ERP, XYZ).
>
>The key benefit of that approach is that given that the foundation in terms
>data and interaction models is consistent across vertical solutions provided
>by multiple vendors, the composition across those verticals is greatly
>enhanced. This translates in enterprises being able to finally *easily*
>customize business processes both within a solution as well as across
>solutions.
>
>Finally, for us to actually deliver on this promise, we not only need
>BPEL/BPML, WSDL, invocation frameworks such as WSIF and JSR 208 but also a
>richer language for describing the interface of one process and mapping 2 or
>more of such interfaces into peer-to-peer collaborations. This is all the
>more important in the case of collaborations being designed across the
>boundaries of organizations: without ws-cdl, business process integration
>will stop at the boundary of an organization and enterprise will not be able
>to leverage the richness of BPM across the internet.
>
>Edwin
>
>-----Original Message-----
>From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
>On Behalf Of JC Reddy
>Sent: Friday, December 05, 2003 6:57 AM
>To: public-ws-chor@w3.org
>Subject: Re: Why workflow is NOT just a Pi-process
>
>
>
>
>  
>
>>I can confirm this. The Intalio implementation of BPML/BPEL is quite
>>    
>>
>stunning in this respect.
>  
>
>>In fact, in many project models I have seen at CSC, many of the swimlanes
>>    
>>
>are users or imaginary
>  
>
>>white space processes. Change mgt processes are a great example.
>>    
>>
>
>Yes, you can do it, i.e., model users as processes. However, the "user"
>notion is not explcit, and hence applications  will need to build the
>semantics (in creating worklists, mapping to access control systems, and
>such). Different vendors may support this in their own ways, but it is not
>in the model.
>
>JC Reddy
>
>
>
>
>  
>

Received on Friday, 5 December 2003 19:04:42 UTC