I was rather excited to learn that JBoss 4.2 now uses the Unified Invoker by default, which in turn uses JBoss Remoting. Of course I assumed that JBoss Remoting’s thrilling features would be available to the Unified Invoker. I was wrong.
Some of which are Pluggable transports (e.g. “Socket, HTTP, HTTPS, Multiplex” and more), Pluggable data marshallers, Pluggable serialization, Automatic discovery, Server grouping, Callbacks, Asynchronous calls, Local invocation (“will automatically make this call by reference, to improve performance”), Remote classloading, Clustering (“seamless client failover”, note that that includes failover among servers using different transports), Data Compression. See JBoss Remoting Guide, JBoss Remoting version 1.4.0 final (pdf) or the more up-to-date JBoss Remoting version 2.2.0 GA (pdf).
I started dreaming of a slick universal invoker that would allow to transparently encapsulate both EJB remote calls and access to naming services (and much more). Just fancy a single deployment within a server that clients could uniformly connect to either efficiently or through (http-) firewalls using a transport of choice that would fit their requirements the most.
Eventually, after 2 days of struggling, the shiny coach of my dreams suddenly turned back into a dull pumpkin again.
Compression: I found no pluggable marshallers that I would dare to use. The only ones I was able to get hold of are the org.jboss.invocation.unified.marshall.InvocationMarshaller and the org.jboss.invocation.unified.marshall.HTTPInvocationMarshaller (Google). And out of those two, the only one that works is the plain one.
HTTP: Using the HTTP transport as described at UnifiedInvoker and UnifiedInvokerHA - Changing UnifiedInvoker transport will promptly fail with java.lang.NoClassDefFoundError: org/apache/coyote/Adapter, because org.jboss.invocation.unified.marshall.HTTPInvocation(Un)Marshaller needs Tomcat components which are not accessible to JBoss Remoting, see JBoss.com - Forums - access to tomcat jars for remoting. And if you try to cheat by moving jbossweb-jar from the root.war to lib, you’ll end up with java.lang.StackOverflowError instead. HTTP support for the Unified Invoker has been postponed several times and is now scheduled for JBoss 4.2.1.CR1, see [#JBAS-2766] tomcat libraries not available to remoting when using http transport - jboss.org JIRA.
Naming: I tried in vain to expose the JBoss Naming Service in a way, so that the ultimate transport (as determined by JBoss remoting) would be transparent to the client. There may be fragments of this within the current configuration files, but right now I have to conclude, that such features are not included off-the shelf.
Architecture: With the advent of encapsulating the transport within JBoss Remoting I had hoped for a way that would allow a single EJB-deployment be accessed using arbitrary transports. Even with the Unified Invoker I do not see a way how that might be accomplished in a transparent manner. I’m not at all an EJB or JBoss expert, but I suspect, that the descriptor of a particular bean in conjunction with the container configuration ultimately results in a fixed predetermined transport to be used.
What I’m still missing is some place where it would be possible to configure the transport being used in a comfortable and aspect-oriented manner, say by providing rules that could be be extended by plugins, so that requests from distant locations (i.e. traversing firewalls) would use compressed HTTP and local requests would use uncompressed socket transports or call-by-reference invocations when issued from within the same VM.
I may be asking for too much 