Mark Little wrote:
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.
See below.
Mark Little wrote:
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!
Well that's what I'm talking about: this is the direct functional replacement for the Remoting 2.x-based UnifiedInvoker stuff, and the JRMPInvoker before it. This is the functionality we're carrying over. I can tell you with absolute certainty that porting this stuff over directly is not a viable option. We can discuss the details offline if you like.
This is really bleeding over into another topic at this point. Remoting 3.x is the transport layer that we're using for AS management; the plan was to bring over a JSR-160 implementation plus EJB remote invocation which allows all these things to run over the same channel, and to leverage JBMAR, to get an optimally-performant invocation layer which supports all kinds of security strategies, and works with even the stupidest of firewalls. In other words, replace the old broken stuff with a combination of a bunch of existing good stuff. This in turn gives us a nice springboard for nicely supporting EE app-client, getting this multi-tier transaction stuff for free (or at least, that was the plan) and at the same time giving us a shiny new bullet point to throw up against the competitors who have a similar sort of transport already. Also it gives us a nice path forward to allow EAP 4 and 5 applications (and even applications running on third-party appservers) to talk to EAP 6 applications using this protocol simply by way of a client JAR which is something that has been requested of us more than once. We know that JBMAR outperforms everything else out there which claims any level of compliance to the serialization spec; we can choose to use it, or not.