RE: [wsbpel] Federated Processes and BPMS Topology

["Carpenter, Robert E" <robert.e.carpenter@intel.com>]

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.
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.
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.

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.