RE: Why workflow is NOT just a Pi-process

I agree on the BPM space requiring a stack of specifications, and that's how
it will most likely evolve over time. Obviously both the "new" BPM and the
"traditional" workflow camps have a lot to contribute to these efforts.

Going back to the original discussion on whether workflow is just a
Pi-process, let me pose some questions here.

(1) If we develop a language purely based on Pi-C and nothing more, will it
offer all necessary constructs (at an acceptable high level) to model,
execute and reason about workflows?

(2) Now let us ask the same question about BPML (which is more than Pi-C).

The answer depends on one's definition of workflow and where one is looking
at it from - from 100,000 ft, 10,000 ft or from inside. To me, it is pretty
much a useless assertion, although I do appreciate what Pi-C brings to the
BPM table.

JC Reddy


-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Friday, December 05, 2003 4:00 PM
To: jcreddy@bpmlabs.com
Cc: edwink@collaxa.com; public-ws-chor@w3.org
Subject: 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 Monday, 8 December 2003 02:47:11 UTC