News: lmappletserver - use EJB3 from within applets
Lightminds AS has announced the release of their open source solution lmappletserver. The framework allows for transparent access to EJB3 objects as if they were local resources within your applet.
- Posted by: Jon Åkerström
- Posted on: December 15 2005 10:08 EST
The client libraries are lightweight - no more RMI, EJB3, Webservice client libraries or similar are needed just code as the remote objects where local within your applet, it will dramatically improves development time.
It runs over port 80 like a Webservice avoiding firewall issues etc, but without the overhead. Server side objects are exposed to the applet simply by using annotations. With the automatic applet packaging and deployment feature it is possible to just write your applet code within your favourite IDE and have it automatically packaged and deployed within your J2EE application for immediate use by calling clients. Deploy your J2EE app and all your applets and their integration layers are deployed as well.
You do not have to code any applet-server communication protocols and/or servlets to handle interaction.
You can easily expose objects and resources by using annotations. It also features automatic dependency loading, i.e., you do not have to worry about remote dependencies, just code as if your objects where local and use annotations to tell the security system which resources that should be available to whom.
The framework is available for download from Lightminds and is distributed under the GPL license.
- lmappletserver - use EJB3 from within applets by Mileta Cekovic on December 16 2005 04:49 EST
- easy communication by Mario Linke on December 16 2005 06:38 EST
This is very interesting.
We also developed (in 2002) transport agnostic (but Java specific) remoting 'framework' with client footprint of 20KB commpressed jar (with HTTP transport).
So as I understood you are basically stuck with JBoss/EJB3 ?
What about a lightweight Java2 +Tomcat deployment ? I think thats not possible ?
Last time I checked, Tomcat wasn't an ejb container so your point is rather ignorant considering this product specifically states Applet -> [EJB3]. If you want an answer, it seems this product will work with any [EJB3] compliant app server. Just makes sense doesn't it?
You are not stuck with JBoss. But as the title of the article says it is currently targeting EJB3, so you will need a EJB3 compliant application server. In the next release we will also support invoking traditional "Tomcat" objects through the framwork - but we have a security challenge to solve before that feature will be released. Meanwhile you could use the "JBoss microcontainer / Embeddable EJB3" from JBoss which allows you to run EJB3 standalone or from within tomcat as an application.
Right, you are not stuck with JBoss. There are other servers that target the EJB 3 specification, e.g. GlassFish. Although the spec is not final yet, so no server, not even JBoss, can claim EJB 3 compliance today.
'Which transport technology is suitable for my project?'
This is a frequently asked question.
The solution can be an abstraction communication layer. The developer must don’t knows, that the invocations are remote. This layer can hide the complexity of remote technologies and makes it possible to change every time the transport provider. This is the intention from the open source project Crispy (http://crispy.sourceforge.net).
While I am all for hiding the transport and as many of the protocol and other commmunications details from the developer as possible, I want the developer to be very aware of the fact or possibility that the calls are not local. Why? Because I want the developer to minimize the communications to remote or possibly remote objects and services.
This is a very interesting aspect. But is this not a general problem by an abstraction layer. An Object Relation Mapper hide the complexity from the database. A load method, how: dao.load(customerId) can be equals with many select statements, to load a complex object graph?
Thank you for your observation. lmappletserver is meant to be as minimalistic / easy to use as possible and what you get in addition with lmappletserver is the automatic package / deploy feature. It allows you to just code the applet and dont worry about getting it out - since it gets deployed within the J2EE container inside you application. Just consentrate on coding / debugging - when you hotdeploy your J2EE app the applets are also packaged and deployed without any need for configuration. This is very efficient and reduces development times alot.