Re: [bt-spec] Possible xml for btp node state

[Mark Little <mark_little@hp.com>]

> I introduced the idea/requirement for B2B state information to be
transportable
> between other superiors and nodes via a well defined, concise XML
definition, this
> moves onto a more attractive P2P model ( rather than a single controlling
TM ).

Fine, but what state, why, under what conditions, ...? I don't have a
problem with the concept, but it's the underlying model/implementation that
needs work. Currently this issue should already be marked as deferred and
I'd like to see it stay as such until after 1.0.

> The discussions at Redwood Shores centered around XML inter operability in
the
> context of state management, enhanced High Availability, and pure
integration/inter
> operability.

"High availability"? You don't actually need to share state to accomplish
this. High availability fault-tolerance using active or passive replication,
coordinator-cohort, quorum concensus, (strong or weak consistency) or
whatever your favourite replication protocol, it doesn't mandate state
sharing. It might, but it needn't. This is just one example of why I'd like
to see a longer and wider discussion on this point. The BTP protocol is
implementable as it stands and IMO initially people aren't going to be
looking at sharing of state between different implementations - there's only
going to be a couple for a while and hopefully a 1.1 will not be that far
behind 1.0.

> Implicit to this is the fact that the BTP will *have* to inter operate
with existing
> infrastructure to not do so will limit the adoption of the BTP standard
severely.

Agreed and it already is. Why do you think it isn't? We're doing
interoperability with J2EE within the specification. I don't think the lack
of this issue in 1.0 will affect adoption of BTP at all.

> Experience dictates that the XML state generation has to be "cheap" ( low
resource
> overhead ).

Definitely.

> As peter mentions, Choreology have documented an initial interpretation
and I will
> be working with them to complete and bring to the group for action.

I'd much prefer to see this discussed in a wider forum rather than behind
closed doors. This could well be a significant addition to the specification
and as such should be examined by the entire committe before any attempt to
"impose" a "solution".

Mark.

>
> Bill - I have feedback on the SOAP bindings, please call to discuss.
>
> Rgds,
>
> Geoff.
>
> William Z Pope wrote:
>
> > Excellent question and I don't know the answer.  If we want to include
this
> > there has to be some guidelines for use.  Would there be a conformance
item
> > for this?
> >
> > The discussion at the Redwood Shores face-to-face was around being able
to
> > share BTP state information.  So a simple minded translation of that is
that
> > this defines a state externalization format that can be used to share
state with
> > external entities.  I don't think that it's unreasonable to have an
internal
> > serialization format and another externalization format.
> >
> > =bill
> >
> > -----Original Message-----
> > From: Mark Little [mailto:mark_little@hp.com]
> > Sent: Monday, April 08, 2002 10:35 AM
> > To: Peter Furniss; BT - spec
> > Subject: Re: [bt-spec] Possible xml for btp node state
> >
> > This is for what reason? I certainly don't want the specification to tie
my
> > hands as to how I serialise and deserialise my state internally.
> >
> > Mark.
> >
> > ----- Original Message -----
> > From: "Peter Furniss" <peter.furniss@choreology.com>
> > To: "Mark Little" <mark_little@hp.com>; "BT - spec"
> > <bt-spec@lists.oasis-open.org>
> > Sent: Monday, April 08, 2002 3:14 PM
> > Subject: RE: [bt-spec] Possible xml for btp node state
> >
> > > Mark,
> > >
> > > Yes, it was a bit veiled, and since you weren't able to be with us at
the
> > > Redwood City f-t-f, there is more of the context missing.
> > >
> > > The following includes elements of hearsay, so should be taken only as
my
> > > current understanding :-)
> > >
> > > The remaining issue (89, from Oracle), can be addressed by including
xml
> > > specification that allows a btp actor to be transferred from one
system to
> > > another, in some way. Geoff Brown has been hoping to provide some
draft
> > text
> > > for this but has been snowed by other stuff.  I am not fully aware of
all
> > > the details of the requirement, but it did seem that defining an xml
> > > serialisation of the state of a btp node (i.e. cooordinator, composer,
> > > sub-coordinator, sub-composer, participant) might be a useful
component of
> > > this. In editting the section in the normative text on persistent
> > > information to take out the bits that were now in the model, I found I
was
> > > left with a text description of this information, and with Tony's help
> > we've
> > > made a draft of the xml definition.  The cryptic remarks about "not
> > anything
> > > other than a Choreology suggestion" were because I didn't want to
claim
> > that
> > > it was the answer to issue 89, because I wasn't sure enough about the
> > > details of that. But I did mention it at the conference call, and
people
> > > asked us to make available what we had.
> > >
> > > Peter
> > >
> > >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>