RE: [ebxml-bp] Manual Operations in BPSS"

[<martin.me.roberts@bt.com>]

My understanding of the original COOL architecture presented at the
ebtwg in Seattle was that the state was held in objects, and that the
synchronising of object state is what B2B would be about.  In this case
if an object is updated manually the state would be sent irrespective of
the transaction model being supported.

	In some ways this is a useful model and creates and shared
object model.  The telco world used this model with the invention of
CMIP which was a protocol that has at its heart a set of managed objects
that can be synchronized over the wire when ever they change.  It has
useful concepts of filters and scopes that allow the partners to come to
some agreements as to what attributes to synchronize within each object.
The advantage of this approach is that it is not transactional but can
be used to indicate transactions,  e.g. I create an order on my system.
The public part gets sent to my partner who responds with the necessary
data and we have a transaction.  The fact that there may be time delays
etc is reflected by the underlying protocol.  It also allows for a
partner to work all day updating their system offline and to come online
when the system load is light and expose all the objects that have
changed and the other systems are updated appropriately.

	This is where the UN CEFACT model is going I understand.  With
the loose coupling of web services and the extra resources available to
computers today this type of system could work.  Bandwidth could well be
a problem still although the effects of a 37 baud line really hampered
our early implementation which where trying to operate a follow-the-sun
scenario.

Martin Roberts 
xml designer, 
BT Exact
e-mail: martin.me.roberts@bt.com 
tel: +44(0) 1473 609785  clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki