OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]