ebBP 5/30/2005: Collaborative and Internal Processes (wd-2-0-1-10)

[Monica J Martin <Monica.Martin@Sun.COM>]

In Tuesday's call, we discussed more about the monitoring of 
collaborative processes and the internal or private processes that 
occur. There was a valuable discussion and as asked, I added descriptive 
text to the v2.0.1, Appendix C. Reassess in v3.0.

Change from:
In execution, an implementation (i.e. an engine) may have a specific 
interface with a MSH and another defined one to domain-specific 
applications (such as backend systems), services or other engines. Where 
these logical boundaries lie when implemented, irrespective of actual 
handlers or interfaces, may be a product of the trading partner design 
choices and constraints, rather than a concrete boundary of software 
components.

Change to:
A collaboration monitoring engine maintains the state of the 
collaboration. If mature, it may drive creation of messages if need be. 
In order to allow the messaging and collaboration layers work together, 
events are created/consumed between them. Each layer has 
responsibilities. Private or internal, and collaborative
processes are decoupled.  The monitoring engine for the collaboration 
watches state transitions of the shared view.  For example, an 
Acceptance Acknowledgement signal may not be generated until successful 
business logic processing of a business document.  The monitoring engine 
for collaboration may receive a notification that processing is complete 
in order to generate the Acceptance Acknowledgement. The potential  
implementation options could depend on the maturity of the involved 
systems, the intent of the parties involved and the 
flexibility/capability to decouple these activities. For example,  some 
options include:

1. BSI implement business rules to either accept or not accept. That may 
be preferred to decouple from backend applications.
2. Develop the Message Service Interface able to look for internal 
events, generate messages and have collaborative engines to recognize 
those messages.
3. Have adapters look for those events, and drive creation of the 
messages by querying services from those systems.

In execution, an implementation (i.e. an engine) may have a specific 
interface with a MSH and another defined one to domain-specific 
applications (such as backend systems), services or other engines. Where 
these logical boundaries lie when implemented, irrespective of actual 
handlers or interfaces, may be a product of the trading partner design 
choices and constraints, rather than a concrete boundary of software 
components.

Reference
Meeting Minutes: 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200505/msg00033.html