7:21 p.m.
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: Remoting Transport Transaction Inflow Design Discussion"
To view the discussion, visit: http://community.jboss.org/message/621530#621530
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/621530#621530]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]