[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