OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [bt-spec] FW: Issue 89


> Comments intermixed <gb>

Ditto.

>
> Mark Little wrote:
>
> > 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>
> >
>
> <gb> At the moment I will not be able to attend the next BTP call </gb>

<ml> I'll probably be late arriving at it too as I have another meeting to
attend.</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>
> >
>
> <gb> Interoperability between the BTP and the Oracle DTC ( for example )
is
> heterogeneous, I agree that homogeneous interoperability would be limited
in
> scope </gb>

<ml>OK, but then we come back to the use case and business case.</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>
> >
>
> <gb> State should be transferred at the time of demand / invocation, the
only
> way you can stop multiple peers attempting to terminate the same set of
> participants is via precdence tracking ( i.e. weighting system )  </gb>

<ml>Great, so this would imply the implementation I sent at the weekend
would solve this exactly?</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>
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC