Re: [xml-dev] TP Agreement

[Sacha Schlegel <sacha_ml@xxxxxxxxxxx>]

Dear Juerg

In the ebXML framework [1] you can define collaborations (execution of
different types of business transactions in a choreographed way) in
ebXML Business Process. These collaborations reference business
documents, so for example you can reference Universal Business Language
(UBL) XML Schemas there.

So if two or more organisations agree to select that definition of
collaboration they already agree on the business level. Then if the two
or more organisations decide to the collaborations and want to execute
them electronically they do need all the technical information, such as
transport protocols, endpoint addresses, routing ids, security infos
(certificates, encryption and digital signature protocols), reliablity
settings (duplicate elimination, resending messages, sending
acknowledgements).

In the ebXML framework all this technical information is stored in one
XML file called ebXML Collaboration Protocol Agreement (CPA) file.

We provided some instances for the UBL Small Business Subset (SBS) work
(btw Ken is a co-chair of that OASIS TC).

UBL SBS at http://docs.oasis-open.org/ubl/cs-UBL-1.0-SBS-1.0/
ebXML Business Process instances at:
http://docs.oasis-open.org/ubl/cs-UBL-1.0-SBS-1.0/universal-business-process-1.0-ebBP/index.html
and the resulting ebXML Collaboration Protocol Agreement files (building
blocks and samples) at:
http://docs.oasis-open.org/ubl/cs-UBL-1.0-SBS-1.0/universal-business-process-1.0-ebCPPA/index.html

Kind regards

Sacha Schlegel

[1] http://www.ebxml.org

PS: For completeness ... the idea is then that each trading partner gets
a copy of the ebXML CPA XML "configuration" file and "simply" imports it
into their ebXML Messaging System. The CPA configures an ebXML Messaging
System for a particular trading partner agreement.

PSS: Open Source ebXML solutions at: http://www.freebxml.org


On Mon, 2006-08-28 at 16:36 +0100, Fraser Goffin wrote:
> Another thread that appeared to get lost when the servers died, that I
> would like to continue.
> 
> Jeurg said :-
> 
> > Hi,
> >
> > Ken Holman and I were discussing how trading partners can formalize the
> > collection of files used in an agreement to interchange an XML instance that
> > is based on a unambiguous collection of XML schema file versions, genericode
> > file versions, context association file versions, business rule file versions
> > etc.
> >
> > We look forward to your practices and thoughts on this.
> 
> > Regards
> 
> > Juerg
> 
> 
> Jeurg,
> 
> What assertions or conclusions did you reach on how best to ensure
> that both parties are synchronised in terms of the versions of
> messages that they each support.
> 
> Given that one or both parties may support multiple versions does it
> matter (other than for explicit private interactions) whether there is
> apriori knowledge of what any particular party may support so long as
> that version can be identified as part of the message meta-data
> sent/received ?
> 
> We have some issues where, when we *initiate* a conversation with a
> number of  parties (in our case for something like a renewal invite
> for an insurance policy) we *may* not know precisely which versions of
> the renewal invite message that they each support. What thoughts have
> you on this matter ?
> 
> Some suggest that (certainly from a minor revision point of view), we
> should be aiming to create implementations that are *tolerant* to
> mis-matched [minor]versions. What do you think ?
> 
> Many regard that the implementation of a request/reply pattern should
> maintain a *matched* pair of messages, that is, the version of the
> response is the version counterpart of the original request (even when
> the schema which describe these two messages are at different versions
> individually) ?
> 
> Sometimes (actually quite often) we have to deal with *mid term
> changes* to policies (e.g. a change of address). When this occurs the
> business rule is that message for the change MUST be the *same*
> version as the original 'request for quotation' perhaps received some
> months earlier (this is so premium calculations for the change are
> based on the original rules whilst that policy is in force - dont ask
> me why !). The problem this gives us is knowing what that original
> version was once the message has been consumed and the data transfered
> onto back-end databases. I guess we will need to keep the version
> meta-data from the original message somewhere right ?
> 
> Versioning is a real big issue in my world right now :-(, so any tips
> on keeping it simple, greatly appreciated :-)
> 
> Regards
> 
> Fraser.