Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

Usual tags ;-)

> Comments intermixed []
>
> Mark Little wrote:
>
> > Comments in the usual "xml-lite" tags.
> >
> > > > > Can you make your questions explicit .. I only see highlighted
text ??
> > > >
> > > > It's the way that Word shows that a comment has been assigned to
that
> > text.
> > > > If you move over the text the you should see the comment.
> > > >
> > >
> > > > >
> > > > > I very disappointed that you feel that I do not answer your
questions
> > ??
> > > >
> > > > Sorry, but this is just based on past experiences. If you go back
over
> > the
> > > > mail archive you will see that we sent out several messages asking
for
> > > > clarification on issue 89 between 2 and 3 weeks ago and got nothing
back
> > > > from you.
> > > >
> > >
> > > [ This MUST have fallen through a hole .. as I always *try* and
provide an
> > > answer be it verbal or written ]
> >
> > <ml>OK</ml>
> >
> > >
> > > >
> > > > >
> > > > > Always happy to elaborate .. I feel a conf call my serve as a
better
> > > > medium ...
> > > > > I will be unable to make the conf call next Wednesday as I will be
> > with a
> > > > client
> > > > > .. therefore, please provide some suitable dates / times ....
> > > >
> > > > If it's to be a conference call then I'd prefer it to be one of the
> > official
> > > > ones. My preference is email since that is archived. I'm not too
happy
> > about
> > > > discussing this (or any issue) behind closed doors.
> > > >
> > >
> > > [ I understand this, there is NO activity going on behind closed doors
..
> > I
> > > prefer a conf call as the medium is better for resolving disputes ]
> >
> > <ml>The problem I have with a conference call is that many people on the
TC
> > find it difficult to attend them and if we are to vote on this then we
> > really should try to reach the largest audience possible. An educated
vote
> > is obviously what we would want to achieve. So, if we did a
teleconference
> > then we would have to minute it in detail and send that round and then
get
> > feedback from people on the mailing list and ...
> >
> > And purely on a personal basis, at the moment I'm spending more than
enough
> > time on teleconferences. Email I can do from home or anywhere.
> > </ml>
> >
>
> [ I know the feeling - we can work quicker verbally, agree or not on the
issues
> then doc them ]

<ml>Perhaps we should schedule this for the next BTP teleconference?</ml>

>
> > [
> > <ml>I'd just like to stress a couple of point again:
> >
> > (i) we have never said that this functionality isn't required, only that
it
> > may already be possible in another way and that we should take it one
step
> > at a time: let's learn to walk as a specification committee before we
try to
> > run. IMO the 1.0 version of the specification will be like any other 1.0
> > I've ever seen: people will look at it and find fault with it and the
1.1
> > version will be the one that most people will use. So, let's do this in
a
> > 1.1 timeframe where we have more time to carefully consider our options.
> >
> > (ii) the business case you briefly outlined does look at first glance
like
> > it could be done using interposition (subcoordination). From a protocol
> > point of view I'd like to see this explored to see why (and if) it
doesn't
> > match your requirements.
> >
> > </ml>
> >
>
> [ I am VERY open to exploring your ideas, I need this functionality in
version 1
> ]

<ml>Do you need this from an implementation point of view or a model point
of view? I can see why you might want to do something like peer-level
replication, but I don't see people calling out for it for heterogeneous
systems. And if we're living in a homogeneous environment then implementers
can do this in a more efficient manner than serialising XML. Large-scale
replication (large in big physical separation) cannot be done efficiently if
you want to maintain strong consistency. Using SOAP and XML almost
implicitly ties you to having to use a weak consistency replication protocol
and in which case there is (essentially) no lock-step. If we're not talking
about large-scale (e.g., the peers are close together on the same LAN) then
I'd much rather replicate states using RMI/IIOP/tcp-ip/or pretty much
anything other than SOAP and XML to get better performance and
efficiency.</ml>

<ml>On a requirement point, can you say at what stage you would expect the
state to be transferred from one peer to another? Are you talking about
transferring the state during the termination protocol or at some quiescent
points? How do you prevent multiple peers attempting to terminate the same
set of participants?</ml>

>
> >
> > >
> > > >
> > > > Mark.
> > > >
> > > > >
> > > > > 9pm PST works on the 25th / 29th April.
> > > > >
> > > > >
> > > > >
> > > > > Mark Little wrote:
> > > > >
> > > > > > Geoff, I'd be happy if you could also answer all other queries
in
> > the
> > > > marked
> > > > > > up Word document and previous emails on this subject. They are
all
> > meant
> > > > to
> > > > > > be constructive, despite what you may feel. As I have said time
and
> > time
> > > > > > again, if you can show that this is a useful thing to do then I
> > believe
> > > > we
> > > > > > should consider it. However, you have not done that and perhaps
that
> > is
> > > > > > simply down to mis-communication. I know that HP is not the only
> > company
> > > > on
> > > > > > the committee that feels the same and that others have expressed
> > this in
> > > > > > same concern in face-to-face meetings.
> > > > > >
> > > > > > The fact that you continue not to answer these real issues does
not
> > do
> > > > this
> > > > > > issue any good. I know that we are all busy with other things,
but
> > if
> > > > you
> > > > > > feel strongly about this issue then I hope you will find the
time to
> > try
> > > > to
> > > > > > convince myself and others.
> > > > > >
> > > > > > Mark.
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Geoffrey Brown" <Geoffrey.Brown@oracle.com>
> > > > > > To: "WEBBER,JIM (HP-UnitedKingdom,ex1)" <jim_webber@hp.com>
> > > > > > Cc: "Bt-Spec" <bt-spec@lists.oasis-open.org>; "Brown,Geoffrey"
> > > > > > <GEOFFREY.BROWN@oracle.com>
> > > > > > Sent: Thursday, April 18, 2002 7:42 PM
> > > > > > Subject: Re: [bt-spec] FW: Issue 89
> > > > > >
> > > > > > > Hi Jim,
> > > > > > >
> > > > > > > As this is a constructive request from yourself (HP) I am
happy to
> > > > > > elaborate
> > > > > > > elaborate. Considering that the BTP contains a huge amount of
TP
> > Gurus
> > > > > > this
> > > > > > > should make sense .. I hope ;-)
> > > > > > >
> > > > > > > The issue :
> > > > > > > -----------
> > > > > > >
> > > > > > > It is very attractive to gain "peer" level inter operability
with
> > the
> > > > BTP
> > > > > > TM, by
> > > > > > > "peer" level inter operability I mean the ability of a non-BTP
TM
> > to
> > > > > > collect the
> > > > > > > state ( on demand ) and therefore continue execution within a
> > > > traditional
> > > > > > TP
> > > > > > > infrastructure.
> > > > > > >
> > > > > > > A natural by-product of this approach is that it provides much
> > greater
> > > > > > levels of
> > > > > > > HA.
> > > > > > >
> > > > > > > Where this comes from :
> > > > > > > -------------------------
> > > > > > >
> > > > > > > My experience with integrating transactional application and
> > > > navigating
> > > > > > supply
> > > > > > > chains ( i.e. vendors apps et al ) is that one has to "patch"
> > together
> > > > > > > transactional state across TPMs. This is a well known problem
that
> > > > many
> > > > > > SIs
> > > > > > > face, due to limitations with TP monitors this is usually
> > addressed by
> > > > > > > asynchronous messaging. Ironically this is exactly why TP
monitors
> > can
> > > > not
> > > > > > be
> > > > > > > used across the web today ; I architected Oracle's Message
Broker
> > for
> > > > this
> > > > > > very
> > > > > > > reason.
> > > > > > >
> > > > > > > Summary :
> > > > > > > -----------
> > > > > > >
> > > > > > > This is not rocket science .. this is common sense. Bindings
allow
> > > > > > > "client-server" inter operability only. Let me be clear that
> > bindings
> > > > are
> > > > > > needed
> > > > > > > but I feel they do not address the aforementioned problem ..
*IF*
> > the
> > > > BTP
> > > > > > > committee want a truly *OPEN* transaction infrastructure then
this
> > > > > > proposal
> > > > > > > addresses the problem.
> > > > > > >
> > > > > > > Again I propose this approach as an "optional" part of the BTP
> > spec -
> > > > for
> > > > > > large
> > > > > > > scale complex transactional infrastructures. The BTP TM should
> > only
> > > > render
> > > > > > its
> > > > > > > current state in XML on DEMAND and not for every single
operation.
> > > > > > >
> > > > > > > If there are any constructive alternatives please let me know
as I
> > > > will be
> > > > > > very
> > > > > > > happy to apply these to the real-world problems that the
industry
> > > > faces.
> > > > > > >
> > > > > > > Geoff.
> > > > > > >
> > > > > > >
> > > > > > > "WEBBER,JIM (HP-UnitedKingdom,ex1)" wrote:
> > > > > > >
> > > > > > > > Hi everyone,
> > > > > > > >
> > > > > > > > I've just read Geoff's document and Mark's comments. Now I
am
> > > > perfectly
> > > > > > > > willing to accept that I might be being naïve here, but
could
> > > > someone
> > > > > > please
> > > > > > > > clarify for me what precisely the benefits of sharing state
in a
> > > > common
> > > > > > > > format are? I can well enough see the drawbacks for myself,
but
> > I am
> > > > > > rather
> > > > > > > > finding the benefits difficult to quantify.
> > > > > > > >
> > > > > > > > I don't have an objection to J2EE (or any other platform for
> > that
> > > > > > matter)
> > > > > > > > interop with BTP, but does sharing of state (as opposed to
say
> > > > defining
> > > > > > > > standard bindings at the message level) really achieve that
> > > > objective in
> > > > > > a
> > > > > > > > straightfoward way?
> > > > > > > >
> > > > > > > > Again, this isn't a rebuttal to the Oracle/Choreology
> > suggestion,
> > > > more
> > > > > > of a
> > > > > > > > plea for help in understanding its value.
> > > > > > > >
> > > > > > > > Ta.
> > > > > > > >
> > > > > > > > Jim
> > > > > > > >
> > > > > > >
> ----------------------------------------------------------------
> > > > > > > > To subscribe or unsubscribe from this elist use the
subscription
> > > > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>