[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] FW: Issue 89
> Using the tag standard ;-) Ditto. > > Mark Little wrote: > > > Tags again. > > > > > Comments intermixed [] > > > > > > Mark Little wrote: > > > > > > > > > > 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. > > > > > > > > > > > > So you want to export a BTP TM state and import it to, say, CICS? > > > > > > > > > > Yes, although naturally I need it to interoperate with Oracle's DTC. > > > > > > > > So how many strict 2PC transaction engines out there do you know could > > cope > > > > with taking a cohesive datastructure and import it and continue to run > > it as > > > > a cohesion? I can count only one (ours) but that's not a reason for > > adding > > > > such a feature. I can see that you are proposing this from an > > implementation > > > > point of view, which is fair enough. However, I'd much rather see a good > > > > abstract case for this first and foremost. We don't see anyone calling > > out > > > > for such a feature - I don't see many people (anyone) asking for > > > > CICS-state-to-Tuxedo-state either. > > > > > > > > > > [ I see no 2PC transaction engines out there ( production today ) that > > could > > > cope with taking a cohesive datastructure, import it and continue to run > > it as a > > > cohesion .. That is why Oracle et al proposes a solution to 89 ... by your > > own > > > admission without this ONLY HP would have this feature on the market. ] > > > > <ml>And I have to admit we have had no requirement for this. It just happens > > to be the case. We can also do many other things that BTP can't but I > > wouldn't want to try to add them to the specification at this late stage. > > Perhaps later, but not now.</ml> > > > > > > > > > > > > > > > > > > > > > > > > > > > A natural by-product of this approach is that it provides much > > greater > > > > > > levels of > > > > > > > HA. > > > > > > > > > > > > If this is why you would want to do this then we should look at HA > > > > > > techniques in general. If it's for "interoperability" then that's > > > > something > > > > > > else entirely. > > > > > > > > > > > > > > > > Both "inter operability" and "HA". > > > > > > > > We don't need this feature for high-availability. If you look back > > through > > > > the archive you'll see one of the first emails I sent on this subject > > shows > > > > that. > > > > > > > > As for inter-operability, I don't think it's possible to take a BTP > > state > > > > from a BTP coordinator and import it to a traditional TP system > > coordinator > > > > and expect it to work. It's an interesting research topic, but it's > > > > certainly not something that I would expect to work today: traditional > > TP > > > > systems have their own internal data structures, assume certain things > > about > > > > participants that aren't necessarily true about BTP participants, ... > > There > > > > are lots of issues around this that simply cannot be solved by saying > > "let's > > > > export a BTP coordinator state and import it elsewhere." It may be part > > of > > > > the "solution", but it ain't the whole thing. I'd rather see us step > > back > > > > and see what it is we (you) want to accomplish and start again from > > there. > > > > If you really want to accomplish some kind of state-binding for Oracle's > > DTC > > > > then that's a different issue again IMO. > > > > > > > > > > [ I diagree, I think this is very possible ] > > > > <ml>Based on experience? Please ellaborate because if it is then it's > > something we as a committee should know about in order to make this > > decision.</ml> > > > > <gb> Yes, based on experience ... purely in the interests of time, I ask to > cover this on a conference call .. </gb> <ml>If we have to then it'll really need to be one of the regular tcs.</ml> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > What do you mean by "transactional state"? Do you mean tracking down > > > > where > > > > > > the context flows to? What the format of the context is? Do you have > > a > > > > > > worked use case on this? > > > > > > > > > > > > > > > > [ Current TRX state for the controlling TM which inherently points to > > > > > transaction flow ] > > > > > > > > Again, comments above apply and also the comments in the marked-up > > document > > > > on security. The coordinator in any transaction is an implicit trusted > > > > third-party and to now say that it can export its state to someone else > > who > > > > the end-points in the business transaction don't necessarily know, is > > > > definitely not a good idea. > > > > > > > > > > [ I am not saying the state should be exported / imported to end points > > (nodes) > > > .. I am saying that the state should be proxied to the controlling TM's ] > > > > <ml>OK, I think we need a diagram. What do you mean by "proxied"? Copied? > > Shadowed? What's a controlling TM? The root of the transaction tree, a leaf, > > ...?</ml> > > > > <gb> Yes - I owe everyone a diagram. By "proxied" I mean that the controlling TM > ( TM that is responsible for the entire transaction chain ) *passes* > responsibility to another Peer level TM. Proxy is probably the wrong word here > </gb> <ml>OK, I got confused by the "proxy" term. But then, as I asked in a previous email, when is this assumed to happen, how do we ensure multiple coordinators don't try to terminate the same transaction, and I keep coming back to the security implications. None of this is insurmountable; I just don't think we can cover this in the time remaining.</ml> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > Sorry, but we still don't get it. This definitely makes BTP more > > "open", > > > > but > > > > > > that's a bit like saying that in order to make operating systems > > open > > > > lets > > > > > > remove all security restrictions and give everyone root access: it's > > > > > > possible but why would we want to do that? BTP is "open" in the > > > > traditional > > > > > > sense of the word (the sense that, say, the OMG would use, or the > > OSF > > > > would > > > > > > use). This keeps boiling down to us not seeing the use case for it. > > And > > > > > > that's not to say that there isn't one, just that we can't see it. > > So, > > > > if > > > > > > there is such a beast, please show it in detail so we can examine > > the > > > > > > protocol implications. Simply saying that BTP isn't "open" without > > it > > > > isn't > > > > > > sufficient I'm afraid. > > > > > > > > > > > > > > > > [ ??? you acknowledge that this approach makes the BTP more open. > > > > > > > > No, not in the sense of "open" we'd like to continue to use (as the OMG, > > OSF > > > > etc do.) "Open" in the sense that it's less secure, perhaps. > > > > > > > > >So let me be > > > > > explicit, BTP is an OPEN standard, however one can not operate on a > > peer > > > > level > > > > > as the TM's state is locked in the BTP infrastructure ... if I use > > J2EE TM > > > > / > > > > > CICs et al how can I actually inter operate between TMs ( not using > > > > bindings ). > > > > > ] > > > > > > > > In the same way that I can interoperate between CICS and J2EE now (and > > in > > > > fact, BTP makes this even easier by requiring all participants to have > > the > > > > same interface): you use sub-coordination. A transaction started in one > > > > domain (e.g., BTP) can flow to a J2EE domain, be imported, the J2EE > > domain > > > > creates a sub-coordinator (looks like a JTS transaction as far as the > > > > participants in the J2EE domain are concerned, but looks like a > > participant > > > > as far as the BTP domain is concerned) and then flows within the J2EE > > > > domain. Only the importing entity "knows" that there is a mapping > > between > > > > BTP and J2EE. Simple. > > > > > > [ Mark, This is the difference between being a Client to a TM and being a > > peer > > > to a TM. You are describing 'binding" based behaviour. ]. > > > > <ml>Definitely need a diagram. I thought from what you were describing that > > you want the ability for some entity (X) to say to a coordinator "give me > > your state" and then for that entity to say to another "blank" coordinator > > "take some state" and then to tie the two together into the transaction tree > > so that we can see the flow of the transaction. What I described is > > certainly about subordinate TMs and not peers, but then if you are really on > > about peers we're back to the requirement and use case.</ml> > > > > <gb> I understand fully your discussion about sub-coordinators and I do mean > PEERs so your quite right we need a use case </gb> <ml>OK</ml> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again I propose this approach as an "optional" part of the BTP > > spec - > > > > for > > > > > > large > > > > > > > scale complex transactional infrastructures. > > > > > > > > > > > > So why can't we leave this as deferred, discuss it in a lot more > > detail > > > > (I > > > > > > think it requires it) and then add it to the 1.1 version if we as a > > > > committe > > > > > > agree it's good? > > > > > > > > > > > > > > > > [ So, please explain HOW I can inter operate at a peer level with > > other > > > > TM's ?? > > > > > How do I daisy chain / proxy TRX context ] > > > > > > > > See above. End-to-end transactionality is possible without requiring > > > > modifications of BTP. If you are interested, I can point you at several > > > > papers on the subject, a couple of which go into implementation detail > > > > (there's even an OMG Success Story on this on the OMG web site.) > > > > > > > > > > [ As mentioned you still addressing "client-server" bindings .. the real > > issue > > > to TM Peer level interoperability ] > > > > <ml>OK, but why. Sorry to belabour this point but we just don't see the > > need. And we certainly don't see the need to add this complexity now to the > > specification when we are supposed to be 3 weeks away from a final vote. Q: > > Do we need this? A: who knows. Q: Do we need this now? A: no (IMO). Q: > > Should we add this to the 1.1 list of things to do? A: why not (and make it > > top of the list if we have to).</ml> > > <gb> Honestly, I can not make it any clearer - other than a use case </gb> <ml>Fair enough. Can you cover the aspects of timing and TM-to-TM coordination as well?</ml> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The BTP TM should only render its > > > > > > > current state in XML on DEMAND and not for every single operation. > > > > > > > > > > > > And what about the security implications? As I said in the previous > > > > email: > > > > > > please answer the questions in the marked-up Word document. We can > > only > > > > have > > > > > > an informed discussion if *both* parties engage in it! > > > > > > > > > > > > > > > > [ What security implications are there ???? BTP is assumed to run on a > > > > trusted > > > > > secure network - The spec avoids security issues on purpose ] > > > > > > > > Erhm, no it isn't. Unfortunately due to time limitations we as a > > committe > > > > decided pretty early on (way before Oracle joined) that we couldn't > > address > > > > security but that we would need to eventually (post 1.0 probably). > > That's > > > > why the spec avoids security issues. We can't make the assumption that > > the > > > > network is trusted: this is a Web Services world afterall. > > > > > > > > > > [ As I said, and you admit to - the spec avoid security issues - this was > > also > > > confirmed at the Oracle FTF and the following conf calls ] > > > > <ml>No, what you said was that "BTP is assumed to run on a trusted secure > > network", which isn't the same thing as making no assumptions.</ml> > > <gb> We need to get a vote on this as it is very important - in our world when > we mean secure we mean it to military level .. eitherway, clarification is > needed </gb> <ml>I'm sure we can all learn a lot from Oracle about security.</ml> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are any constructive alternatives > > > > > > > > > > > > Lots if you're just after HA (see email of about 3 weeks ago that > > you > > > > didn't > > > > > > respond to either). > > > > > > > > > > > > > > > > [ Snide remark - being constructive again I see ] > > > > > > > > No, constructive remark: please go away and answer the emails. How can > > we > > > > have a conversation if I keep talking to the ether? Please do not read > > > > specific emotions into plain ASCII text: it invariably ends up being > > wrong. > > > > > > > > > > [ You not talking to ether .. and your comment was taken as a snide remark > > not > > > just by me but by others here ] > > > > <ml>Unfortunately whether or not my previous emails of 3 weeks ago fell > > through cracks, they did not get answered. Subsequent followup emails also > > did not get answered. If you want to consider it as a snide comment the > > sobeit, but in order to have a discussion on this or any issue we need to > > have all parties engaged.</ml> > > > > <gb> Mark, other than the questions which we run though are there any others I > may of missed </gb> <ml>I think I've put the main ones in the previous emails. However, what kind of time frame would you expect for the 1.1 specification? We (HP) are assuming it won't be as long as the 1.0 specification.</ml> > > > > > Mark. > > > > ----------------------------------------------------------------------- > > SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs > > PHONE : +44 191 206 4538, FAX : +44 191 206 4203 > > EMAIL : mark@arjuna.com | mark_little@hp.com > > > > > > > > > > > > > Mark. > > > > > > > > > > > > > > > > > > > > > As for alternatives for other requirements - it's difficult to say > > since > > > > we > > > > > > still don't understand why you need this. > > > > > > > > > > > > > please let me know as I will be very > > > > > > > happy to apply these to the real-world problems that the industry > > > > faces. > > > > > > > > > > > > > > Geoff. > > > > > > > > > > > > Mark. > > > > > > > > > > > > ---------------------------------------------- > > > > > > Dr. Mark Little, Distinguished Engineer, > > > > > > Transactions Architect, HP Arjuna Labs > > > > > > Email: mark_little@hp.com > > > > > > Phone: +44 191 2606216 > > > > > > Fax : +44 191 2606250 > > > > > > > > > > > > > > > > > > > > > > > > > > > "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> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC