ebBP 2/7/2005: Updated Combined Summary of BSI-MSI

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

This is an updated BSI-MSI summary based on all inputs up through those 
proposed today 7 February 2005. Changes to our previously agreed upon 
text are in UPPER CASE TYPE. Attribution is given to the section 
fragments that have been changed. Additional references and three open 
questions are provided at the end of the combined summary. Please plan 
to attend our meeting tomorrow to discuss. Thank you.

============================================================================================================
Section 4: Language Overview
================
FROM:
The BSI is completely separate from the Message Service Interface (MSI). 
In particular an MSI MAY be used without a BSI. A CPA, which contains a 
reference to a ebBP definition serves as the basis for the configuration 
of the BSI to enforce the protocol and semantics of the ebBP definition, 
as depicted in Figure 1.

TO:
The BSI is completely separate from the Message Service Interface (MSI). 
They may effectively be used together even though the MSI MAY be used 
without a BSI.

The BSI is a logical definition for a party's actions, EXPOSED AS 
BUSINESS SERVICES. IT MAY BE SEEN AS A LOGICAL SHARED
DEFINITION AT DIFFERENT NODES.[1] LOGICALLY, A BSI IS A PARTNER'S 
IMPLEMENTATION OF THE SHARED DEFINITION OF BUSINESS STATES AND ACTIONS 
RELEVANT TO A COMMON BUSINESS GOAL. IN THE CONTEXT OF EBXML BPSS, ONLY 
THE SHARED BUSINESS PROCESS IS BEING MANAGED.

IN EXECUTION, THE BSI USES THE CURRENT STATE OF THE BUSINESS PROCESS, AS 
DEFINED IN THE BUSINESS COLLABORATION
MODEL, TO GUIDE [??DIRECT OR PRESCRIBE] ACTIONS AND REPORT THE STATE 
CHANGES. THE EBXML BPSS DEFINES THE BSI
BEHAVIOR WITHIN THE BOUNDARIES OF THE SHARED COLLABORATION DEFINITION, 
BUT DOES NOT DICTATE ITS TECHNICAL IMPLEMENTATION. [2] ITS REALIZATION 
MAY BE ACCOMPLISHED BY USING OTHER SUPPORTING FUNCTIONS. [3]

AS DESCRIBED IN THE EBXML BPSS TECHNICAL SPECIFICATION, THE BSI IS THE 
LOGICAL SET OF TRANSACTIONS NECESSARY
TO ACHIEVE A COMMON GOAL. THE BSI BOUNDS THE BEHAVIOR OF A MSI IN THE 
CONTEXT OF THE SHARED COLLABORATION DEFINITION. THE BSI ALSO PROVIDES 
REQUIREMENTS TO THE MSI, SUCH AS QUALITY OF SERVICE (SUCH AS 
NON-REPUDIATION, AUTHORIZATION, ETC) AND SERVICE CONFIGURATION CAPABILITIES.

A BSI IS, THEREFORE:

    * A DISCRETE SET OF BUSINESS PROCESS STATES (RESULTS OF BUSINESS
      TRANSACTIONS) SHARED AND ALIGNED BETWEEN TRADING PARTNERS.
    * A DISCRETE SET OF BUSINESS TRANSACTIONS.
    * A DISCRETE SET OF TRANSITIONS BETWEEN BUSINESS TRANSACTIONS.
    * THE BUSINESS RULES GOVERNING (1) THROUGH (3). [4]

THE SET OF IMPLEMENTATION CHOICES, SUCH AS USE OF JAVA BEANS, WEB 
SERVICES, ETC. THAT MAY DEFINE THE BUSINESS
SERVICES ARE NOT SPECIFIED NOR A PART OF THE BSI. THEY MAY COMPRISE THE 
BUSINESS SERVICES THAT THE BSI UNDERSTANDS, LOGICALLY ENVELOPES AND 
ABSTRACTS. [5]

A CPA specifies actually the interface with access points defined by the 
business process specification used. The CPA, which contains a reference 
to an ebBP definition, serves as the basis for the configuration of the 
BSI to enforce the protocol and semantics of the ebBP definition OR, IN 
CERTAIN CASES, OVERRIDE SUCH RULES, as depicted in Figure 1. [6]

<<Implementer's note: The ebXML BPSS technical specification does not 
specify how the BSI is implemented.  For example, the BSI may be enabled 
through a BSI-aware business application or through behavior 
implemented  as part of an MSI component. The business application may 
produce the business signals that are sent (realized) by the Message 
Service Handler.>>

At a minimum, the BSI relates to the MSI in three ways:

    * Provide requirements to MSI.
    * Constrain implementation of the MSI.
    * Provide for auto generation of MSI.

THE MSI SUPPORTS AND MAY ENFORCE THE BSI IN MANY WAYS, INCLUDING THROUGH:

    * MESSAGES THAT MAP TO BUSINESS TRANSACTIONS
    * SIGNALS THAT ALIGN STATE
    * BEHAVIOR UPON RECEIPT/NON-RECEIPT OF MESSAGES AND SIGNALS
    * ENFORCEMENTS OF SECURITY CONSTRAINTS

THE EBMS, CPA AND EBXML BPSS SHOULD ACT AS A REFERENCE SET TO DEFINE THE 
MSI/BSI BEHAVIOR WITH A GOAL
TO ALLEVIATE HUMAN INTERVENTION.  AT DESIGN TIME, THE MSI MAY EMBED BSI 
BUSINESS RULES OR THE MSI AND BSI MAY COMMUNICATE IN EXECUTION. [7] 
Design and deployment decisions may guide where an implementation lies 
on this continuum. In the ebXML BPSS technical specification, option 2 
is recommended. As a design choice, the ebXML architecture, and this 
specification, modularizes and separates these different process and 
messaging functions.

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. [8] 
BROADLY, THESE DEFINITIONS ARE CONSISTENT WITH THE EBXML TECHNICAL 
ARCHITECTURE, V1.04.[9] WHERE THESE BOUNDARIES LIE, IRRESPECTIVE OF 
HANDLERS OR INTERFACES, MAY BE A PRODUCT OF THE TRADING PARTNER DESIGN 
CHOICES AND CONSTRAINTS, RATHER THAN A CONCRETE BOUNDARY OF SOFTWARE 
COMPONENTS. [10]

THE SHARED COLLABORATION DEFINITION, THAT INCLUDES THE BUSINESS 
TRANSACTION SET(S), THE APPLICABLE BUSINESS TRANSACTION PATTERNS USED, 
QUALITY OF SERVICE CAPABILITIES AND OTHER SERVICE CONFIGURATION DETAILS, 
MAY
RESULT IN PROFILES RELEVANT TO A GROUP OF TRADING PARTNERS, INDUSTRY OR 
DOMAIN. [11]

Section 4.7: Core Business Transaction Semantics
Additional text proposed for the first paragraph or a second paragraph 
after the first.

FROM:
The ebXML concept of a business transaction and the semantics behind it 
are central to predictable, enforceable commerce. It is expected that 
any Business Service Interface (BSI) will be capable of managing a 
transaction according to these semantics.

TO:
The ebXML concept of a business transaction and the semantics behind it 
are central to predictable, enforceable commerce. It is expected that 
any Business Service Interface (BSI) will be capable of managing a 
transaction according to these semantics.  As the BSI is a logical 
definition, design and deployment choices are not specified (See Section 
4).  For example, the BSI may be instantiated or provide requirements 
that guide or generate the MSI to react to specific events defined in 
the business process.  The MSI may interact with the BSI, that 
recognizes the state of a business transaction. This may enable the MSI 
to implement rules when specific steps occur. The semantics defined in 
the ebXML BPSS technical specification enable the BSI to constrain and 
guide design and deployment based on the business transaction semantics.

[1] Moberg
[2] Yunker
[3] Moberg
[4] Yunker
[5] Yunker
[6] Yunker
[7] Yunker
[8] Schlegel
[9] BSI = An ebXML collaboration that is conducted by two or more 
parties each using a human or automated business service that interprets 
the documents and document envelopes transmitted and decides how to (or 
whether to) respond. [definition provided by Nickull, 4 Feb 2005].
[10] Martin
[11] Webber

==============
Additional references:

    * TC discussion 2/1:
      http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/event.php?event_id=6485&;
      (See Meeting Minutes attached to Calendar Event)
    * Agreed upon definition prior to series of emails:
      http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200502/msg00012.html
      (3 February 2005)
    * wd 06 technical specification (we have an update to be provided by
      tomorrow):
      http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=11266

==============
Open questions:
1. Where does the BSI sit? [Schlegel 2/4]
2. If required, discuss BSI/MSI dependencies in greater detail and 
determine if examples or follow-on documents that show reference 
ebMS/CPA/BPSS dependencies for BSI and MSI. [Yunker 2/4]
3. In the future, a BS[H] ideally (one day) present a standardised 
interface (BSI) to the next layer which is the private process execution
engine (eg a BPM configured with a BPEL).  The BSI is important to 
address. [Capell 2/4] [note: This is scoped for post-v2.0. -Martin]