"A->B->C yes is possible, however this is really (A client -> B server -> (a bunch of existing stuff) -> B client -> C server); which is to say that if we verify that we follow the rules for what we implement, then it's up to JBTS to follow the rules for what itimplements."
How do you expect to prevent the context from flowing from B server to B client? A per-thread interceptor doing the disassociation, for instance?
"Well, all of this is predicated on the assumption that we still need some kind of remote control of transactions from server to server when using the Remoting-based transport in order to fulfill our obligations for existing functionality. If we can work it out or establish that this is not the case, then sure, we can revisit this discussion at a later time, assuming that such time would ever arrive. I would very much like the opportunity to be able to work on establishing requirements for such an abstraction. Such a discussion should come hand in hand with fixing the shortcomings of XATerminator in the JCA specification as well though, as these seem to me to be two faces of the same problem."
Whatever happens now, I think it's clear that we need to look at this for the future. And a realistic future at that, i.e., not "years and years from now".
"I don't think I said it wasn't possible, or at least I didn't intend to. I think supporting trees or linear chains of appservers is fine. I just don't think we necessarily have to support A->B->A kinds of scenarios or other non-tree (especially cyclic) directed graphs as this is not generally a good fit for Remoting in the first place; one would normally choose IIOP or JRMP for this kind of topology."
OK, but this then comes back to my first question above: how do we prevent these things? Leaving it up to the developer of the application/business object/EJB isn't going to work.
"That said, I think that a proper implementation ought to be able to mix and match the approaches. A linear chain of app servers and their resources using the Remoting transaction approach could terminate an a JTS "cloud" of appservers, which in turn could enroll more linear chains of app servers and their resources, so long as the contstraints we place aren't broken (for example if we don't support shared resources in the Remoting chains then we simply don't)."
Agreed, and in fact this sounds very much like the genesis of the bridging work that I keep mentioning Jonathan has been doing (has done). The idea there was that a transaction could start out over, say, SOAP, inflow to a container and then be sent out over another transport, etc. Graphs of arbitrary size and complexity could be supported, with extensibility to support arbitrary transports.
"Could we drop a native transport in favor of SOAP+IIOP? Absolutely. But it would suck, IMO. I think a native transport is an essential tool, and it's something we've provided in the past, but it's not up to me to make that call in any case. Even if we dropped it though, I'd probably develop it in my free time anyway just because I have no inclination to use SOAP or IIOP for my personal projects, and it's something I believe in. Granted my free time projects have this way of winding up back in the middle of things these days."
Yes, I understand the trade-offs. I mentioned it in order to determine if there was some intermediate step(s) that we could take to help address the issue.