I am studying,m developing small sample applications, new possibilities offered by Java EE 6, especially
relative to EJB of which (personal taste) i'm a fan.
It 'obvious that the EJB 3.1 have been so simplified compared to earlier specifications,
that there is no real good reason not to use them ...
In my humble opinion, however, it seems to me that these facilities have focused mainly
on simplification of Use EJBs in the context of "pure" web applications...
while for external use by the JVM (mainly from Swing client), it seems to me that significant steps
forward an integration that is really "simple" haven't been made.
Let's think about how a swing client may connect to a remote EJB. Using JNDI lookup means deploy, with each client,
an Application Client Container or a lot of jars derived from Application Server runtime. These jars may be
patched when you patch the application server, to keep classes compatible (expecially with ORB support classes),
so you have the need to upgrade your clients.
Exposing EJBs via webservices or using HTTP request calls seem to me an easier solution, but has HTTP protocol
good performance with respect an RMI-based communication ? The fact that HTTP opens and closes communications may
lead to bad usage of network resources.
What do you think ? I'd like to read your opinions..
When dealing with client applications, such as swing, you might want to consider using the embeddable EJB container (http://download.oracle.com/javaee/6/tutorial/doc/gkcrr.html). This is easier than using JNDI, avoids server installation, has a smaller footprint and starts faster than a server based container. It also avoids some of the protocol related issues you referred to.
AS far as I know, EJB lite container is a very useful way to test own's ejbs without the 'boring' cycle of deploy-debug-redeploy with an external Java EE app server... And this feature may be effectively a great resource because no matter how fast your appserver is, redeploying is quite time-consuming. The problem is, what about accessing via embedded container from Java SE to a remote EJB ? How to make the lookup ? Moreover, to create an embedded container, one must make Appserver jars (or a part of them) available to client's classpath..
My idea (perhaps a foolish idea... I don't know !) is that it would be nice if EJB would be accessible via a general and portable protocol, application-server neutral. The same thing happens when you use HttpConnection to connect with a remote web server. No matter what's actually the web server: the protocol is the same. A similar thing has been done with unified JNDI names... that are now no more vendor specific. It would be nice to have a 'virtual' protocol like 'ejb://server:port/nameBean' to lookup the remote EJB and, once you have got your remote reference, invoke methods on them.
Maybe only a dream.... but for example .NET remoting is more 'ready to use' and doesn't require other dlls than those supplied with the framework.
At least, these are my two cents.
Thank you again for your reply !
All the best,
of course on a functional point of view, I think nothing... what I had in mind, is that a new protocol to interact with EJB may be more effective on a networking point of view.
SOAP, Web Services and so on are really great things, but they rely upon http protocol which opens and closes connections at each request (as far as I know). A persistent socket may avoid network jitter, latency and so on...
Of course, this should be measured with tests.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Some considerations about EJB and swing integration