Re: FW: Conversations, or BP alignment with TR&P and Architecture

[Duane Nickull <duane@xmlglobal.com>]

Bob Haugen wrote:

> with the Transport, Routing & Packaging and Architecture
> specifications?

Yes - we have reviewed the data in great detail.

>
>
> The BP metamodel assumes the need for long-running
> conversations.  So does TR&P, and (maybe) Architecture.
> However, the responsibility for defining the software
> that manages these conversations is not clear.

This is within the scope of software vendor architect.  maintaining state (and an audit trail) are both mandated by
tech Arch.  It is core functionality for an ebXML application.  We are not designing the application at this time.
There is not enough information to build upon at this time, however,  my company (XML Global) has issued a
statement to support ebxml in it's next generation of XML tools.

> ebXML TR&P specifies in diagrams an Integration System
> where Business Rules and Document Choreography from
> Business Process Modeling are supposed to take place.
> However, this Integration System is then declared out-of-scope
> for TR&P.

Again - we are not designing the software.  Just the ebXML specification.  An SV will then look at possible use
case scenarios that it must comply with in order to be ebXML compliant and build the app.

> In the TR&P diagrams, instances of the Integration System
> live at both ends of a message exchange. The Integration
> Systems have their own private repositories, which can
> access a Master Repository.
>
> The ebXML Architecture documents use these same
> diagrams.  However, Architecture goes on to propose
> an "ebXML Application" at each end of a message
> transmission which uses a Business Process model.
> Architecture does not mention transaction semantics
> or long-running conversations.

First - it is not a private repository.  It is a cache built of repository objects which is used to lessen the
overhead required for each transaction.  The layer we are focused on right now is the data element layer.  The
transactional layer is built upon that.  i.e. - for the process "Purchase Order",  there may be 5 messages
required.  We will provide the architecture for constructing these messages (TRP) and the architecture for
referencing repository objects (Tech arch/reg rep) and the business methods that dictate the necessity for each
message (BPM),  but we do not specify what mechanism must be used to maintain state and archiving of these
messages.  The SV's can implement that at point of deployment.  This is because there are several different models
for ebXML adoption.  Not everyone will have their own ebXML app.  Some may use an ASP type model for all their
invoicing only (partial adoption).


Duane Nickull


=======================================================================
= This is ebxml-architecture, the general mailing list for the ebXML  =
= Architecture project team. The owner of this list is                =
= owner-ebxml-architecture@oasis-open.org                             =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-architecture                                 =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-architecture myname@company.com              =
=======================================================================