[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 2/7/2005: BSI-Message Service Interface Updated-2 Summary
This is an updated-updated BSI-Message Service Interface summary based
on all inputs up through those proposed late as of 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 four open questions are provided at the end of
the combined summary. Please plan to attend our meeting tomorrow to
discuss.
Thank you to Duane Nickull for his suggestions. Regards.
============================================================================================================
Section 4: Language Overview
================
FROM:
The BSI is completely separate from the Message Service Interface. In
particular an Message Service Interface 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:
<<deleted and moved first paragraph>>
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 <<MAY>> BOUND THE BEHAVIOR OF A
MESSAGE SERVICE INTERFACE IN THE CONTEXT OF THE SHARED COLLABORATION
DEFINITION. THE BSI ALSO PROVIDES REQUIREMENTS TO THE MESSAGE SERVICE
INTERFACE, SUCH AS QUALITY OF SERVICE (SUCH AS NON-REPUDIATION,
AUTHORIZATION, ETC) AND SERVICE CONFIGURATION CAPABILITIES.
<<The LOGICAL BSI MAY BE ASSOCIATED WITH THE MESSAGING COMPONENT. The
BSI MAY BE completely separate from the Message Service Interface (WHICH
IS ALSO ANOTHER ABSTRACT BOUNDARY). [4] They MAY effectively be used
together. Or, the Message Service Interface MAY be used without a BSI.>>
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). [5]
THE SET OF IMPLEMENTATION CHOICES, SUCH AS USE OF JAVA BEANS, WEB
SERVICES, ETC. THAT MAY DEFINE THE BUSINESS
SERVICES ARE NOT <<SPECIFIED. [6]
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. [7]
Implementer's note: The ebXML BPSS technical specification does not
specify how the BSI is implemented. For example, the BSI
<<CONCEPTS>> may be enabled through a BSI-aware business application
or through behavior implemented as part of an Message Service
Interface component. The business application may produce the
business signals that are sent (realized) by the Message Service
Handler.
At a minimum, the BSI <<MAY>> relates to the Message Service Interface
in three ways:
* Provide requirements to Message Service Interface.
* Constrain implementation of the Message Service Interface.
* Provide for auto generation of Message Service Interface.
THE MESSAGE SERVICE INTERFACE <<MAY SUPPORT AND 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 <<MAY>> ACT AS A REFERENCE SET TO DEFINE
THE MESSAGE SERVICE INTERFACE/BSI BEHAVIOR WITH A GOAL TO ALLEVIATE
HUMAN INTERVENTION. AT DESIGN TIME, THE MESSAGE SERVICE INTERFACE MAY
EMBED BSI BUSINESS RULES OR THE MESSAGE SERVICE INTERFACE AND BSI MAY
COMMUNICATE IN EXECUTION. [8] Design and deployment decisions may guide
where an implementation lies on this continuum. In the ebXML BPSS
technical specification, <<CONSTRAINTS OF THE BSI CONCEPTS ARE
RECOMMENDED FOR ANY MESSAGING SERVICE INTERFACE. 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. [9]
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. [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. <<THE>> Business
Service Interface (BSI) <<MAY 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 Message Service Interface to react to specific events
defined in the business process. The Message Service Interface MAY
interact with the BSI that recognizes the state of a business
transaction. This may enable the Message Service Interface 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] ebXML Messaging Service, v2.0, definition of Message Service Interface:
An abstract service interface applications use to interact with the
MSH to send and receive messages and which the MSH uses to interface
with applications handling received messages (Delivery Module).
[6] Yunker
[7] Yunker
[8] Yunker
[9] Schlegel
[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/Message Service Interface dependencies in
greater detail and determine if examples or follow-on documents that
show reference ebMS/CPA/BPSS dependencies for BSI and Message Service
Interface. [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]
4. Do we cohere ebXML Glossary definition, and other understandings
about BSI and Message Service Interface? [Nickull, 2/7]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]