EJBs von Lift aufrufen

Lift ist das Web-Framework für Scala. Da Lift in WARs gepackt wird, sollte es kein Problem sein, von dort auf EJBs zuzugreifen. Hier in schneller Weg zum proof of concept mit Netbeans, maven, Lift und Glassfish 3:

Das Enterprise Projekt

Einfach mit Netbeans ein neues Projekt „Maven Enterprise Application“ anlegen. Als Projektnamen nehmen wir „hellolift“ und als Paket und GroupId „demo.hellolift“. Im folgenden Dialog verzichten wir aus das Web Modul, denn das wird mit Lift erstellt. Ein EJB Modul und das Ear Paket nehmen wir aber.

Lift Web Modul

Netbeans sollte jetzt einen Ordner „hellolift“ mit einer pom und Unterordnern für die Module erstellt haben. Dahin wechseln wir und bauen eine leere Lift Application aus dem Archetypen:

mvn archetype:generate -U  -DarchetypeGroupId=net.liftweb \
      -DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=1.0 \
      -DremoteRepositories=http://scala-tools.org/repo-releases \
      -DgroupId=demo.hellolift -DartifactId=hellolift-war -Dversion=1.0-SNAPSHOT

Das sollte einen Ordner mit dem Web Modul erstellen.

Die EJB

Ok, die einfachste Bean die irgendetwas mach reicht für unser Beispiel:

package demo.hellolift;

import java.util.Date;
import javax.ejb.Local;
import javax.ejb.Stateless;

@Stateless
@Local(HelloEJBLocal.class)
public class HelloEJB implements HelloEJBLocal {

    public String sayHello(String name) {
        return "Hi " + name +" its's " + new Date().toString();
    }
}

und das Interface

package demo.hellolift;

public interface HelloEJBLocal {

    String sayHello(String name);
}

Wichtig ist hierbei dass die Local Annotation nicht im Interface steht, damit das „sauber“ bleibt.

Damit das Web Modul auch weiß, was es aufrufen soll, muss das EJB Pom noch erweitert werden:

(...)
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ejb-plugin</artifactId>
    <version>2.1</version>
    <configuration>
        <ejbVersion>3.1</ejbVersion>
        <generateClient>true</generateClient>
        <clientExcludes>
            <clientExclude>demo/hellolift/*EJB.class</clientExclude>
        </clientExcludes>
    </configuration>
</plugin>
(...)

Damit wird ein EJB Client jar erzeugt, das nur das Interface enthält.

Lift Applikation

In dem Web Modul wird jetzt einfach das erzeugte HelloWorld Snippet in demo.hellolift.snippet angepasst:

package demo.hellolift.snippet

class HelloWorld {
  def getBean () = {
      val c = new _root_.javax.naming.InitialContext();
      val l = c.lookup("java:global/hellolift-ear/hellolift-ejb-1.0-SNAPSHOT/HelloEJB" +
                       "!demo.hellolift.HelloEJBLocal");
      l.asInstanceOf[demo.hellolift.HelloEJBLocal]
    }

  def howdy = <span>EJB says {getBean().sayHello("Lift Web") }</span>
}

Das JNDI-Name ist hier im Beispiel nach EJB 3.1 Standard. Und ja, das Programm kümmert sich nicht einmal um die Exception. 🙂 Jetzt brauchen wir noch die Abhängigkeit zum EJB Client jar und ergänzen das pom um:

<dependencies>
    <dependency>
        <groupId>demo.hellolift</groupId>
        <artifactId>hellolift-ejb</artifactId>
        <version>1.0-SNAPSHOT</version>
        <type>ejb-client</type>
    </dependency>
(...)
</dependencies>

Und alle zusammen…

Im übergeordneten pom muss das Web Modul eingetragen sein, was Netbeans aber schon für uns erledigt haben sollte. Jetzt muss nur noch dem EAR die Referenz auf das Web Modul mitgegeben werden:

<dependencies>
(...)
    <dependency>
        <groupId>demo.hellolift</groupId>
        <artifactId>hellolift-war</artifactId>
        <version>1.0-SNAPSHOT</version>
        <type>war</type>
    </dependency>
</dependencies>

Fertig. Das so erzeugt EAR lässt sich jetzt deployen. Man kann also ziemlich unproblematisch mit Lift auf ein bestehendes EJB Backend zugreifen.
Hier das erzeugteProjekt zum Runterladen und Selberspielen: hellolift.zip

Sun Übernahme – ein paar Gedanken

Nun ist es endlich geschafft. oracle hat sich die Sonne einverleibt. Es bleibt recht spannend. Es gibt noch keine Aussagen zum JCP und vor allem die Testsuites für das JDK. Wer die Testsuites für das JDK kontrolliert, kontrolliert die Java Entwicklung. Das sorgte bereits in der Vergangenheit für einigen Unwillen, war aber noch relativ unproblematisch mit der „Non Profit Organization“ Sun. Oracle ist da schon ein anderes Kaliber. Der Punkt wird entscheidend sein für ein weiteres Java Engagement der Großen.

Glassfish wird weiterhin die Referenzimplementation bleiben. Das war auch zu erwarten. Es soll auch weitervertrieben werden für unkritische Anwendungen. Wie weit sich das auf den Clustersupport und OpenESB auswirkt bleibt abzuwarten.

Netbeans soll insbesondere für die Entwicklung für Mobile Endgeräte erhalten bleiben. UML und BPEL Support sind ja bereits seit einiger Zeit aus Netbeans verschwunden und werden so ziemlich sicher nicht wieder auftauchen.

Das angekündigte Oracle Konzept von der Hardware/Software Blackbox – also der Kiste, die ich einfach nur an Netz und Strom anschließe klingt für viele von meinen Kunden extrem gut. Klar, die sind komplett geschädigt von Lösungen, die mit einer Hundertschaft von Consultants kommen. Dass das nicht ganz billig ist auf Dauer, kann man sich vorstellen.

Das Problem bleibt aber: Egal, ob ich meine Lösung „live“ von einer Armee Externer stricken lasse oder eine fertige Appliance kaufe – die Kontrolle befindet sich außerhalb meiner IT. Wenn etwas schief geht, bin ich auf Hilfe angewiesen und ein Umstieg von einem geschlossenen System zu einem anderen ist üblicherweise teuer. Keiner meiner externen Anbieter hat ein Interesse daran, mir den Umzug zu einem anderen Anbieter leicht zu machen. Es wird jedenfalls sehr interessant zu beobachten sein, wie sich die beiden Großen bei den Großkunden duellieren werden. 🙂