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

["Tony Fletcher" <tony_fletcher@btopenworld.com>]

Dear Martin Duane and others,

Yes, I agree with this - it is exactly the point I was making  (and I also
acknowledge the other helpful mails from Duane and others).

To synchronise state one must not only set the communicating protocol
machines to complementary states (which is what we tend to concentrate on),
but also align the shared resources (or objects).

And yes I picked up on this from a number of folks including Bob Haugen, it
is my understanding that it is indeed the central idea of the COOL
architecture, but it actually goes back to CMIP as Martin mentions, and
probably way before that too.  In spite of the COOL presentation I am not
sure that the ideas have been properly worked into the UN/CEFACT documents
yet though(?)

But the alignment of protocol state and resource / object state certainly
should be part of BPSS as it goes forward (in my opinion).

Best Regards     Tony
A M Fletcher
Home: 35, Wimborne Avenue, IPSWICH  IP3  8QW
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
  amfletcher@iee.org <mailto:amfletcher@iee.org>      (also
tony.fletcher@talk21.com <mailto:tony.fletcher@talk21.com>   &
tony_fletcher@btopenworld.com)


-----Original Message-----
From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com]
Sent: 20 February 2004 11:00
To: dnickull@adobe.com; tony_fletcher@btopenworld.com
Cc: david@drrw.info; zbarch@rcn.com; ebxml-bp@lists.oasis-open.org
Subject: RE: [ebxml-bp] Manual Operations in BPSS"


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