David Lloyd wrote:
Mark Little wrote:
Could you outline the pros and cons of the current approaches we have in AS5/AS6? I know we've discussed them elsewhere already, but it would be good to capture it all here. For instance, why you believe that IIOP isn't right.
When it comes around to transaction control for the native invocation layer, as far as I am aware AS 5/6 only has the ClientUserTransaction approach (basically equivalent to "solution 1"). This is fine as far as it goes, but as I have said previously, integrating this at a server level is problematic.
Understood.
The cons of the AS5/6 native approach are obvious: no transaction propagation, limited transaction control. And the problems in the existing transport implementation are well-known.
Humour me and put them here explicitly.
As far as IIOP goes, I don't believe that it's "not right" per se; I do believe that there are valid use cases which make IIOP (in general) less than opimal, for example in the case where network topology or security environment makes it undesirable (either in terms of security, performance, configurability, etc.; for example to run many different protocols across a single physical connection or to use OTP-style authentication). CORBA is complex no matter how you slice it, sometimes prohibitively so. But that's my opinion which is really irrelevant here; as I said if we decide as an organization (via the proper channels) to completely ditch the native transport in favor of a full investment in CORBA/IIOP then I will do so happily (I definitely have a lot of other stuff to be working on), though I do personally believe that in this case that we would be passing up the opportunity to make something really special which perfectly fits a real need.
So what about using one of the existing transports over which transactions are supported, rather than implement yet another one? Of course the performance of, say, HTTP isn't as good as JBR or any binary protocol, but I've yet to see any performance requirements being made against this particular requirement. In fact as far as I can tell, we're talking about the requirement to support a case that we couldn't support in 5/6 based only on the fact that would couldn't support it, not on the fact that we need to support it and with N tx/sec.
Yes SOAP/HTTP is equally slow (can be slower) than HTTP, but SOAP/JMS is an option. I suppose if there was enough reason we could even consider a SOAP/JBR, though at that point I'd be first in the queue to recommend removing SOAP from the equation entirely!