"EJBs will die"? Alternativen? SOA?

[ps]

Ich habe mir heute die JAX Keynote von Rod Johnson angesehen und mir gefällt die Richtung welche SUN mit JavaEE 6 einschlägt doch ziemlich gut. Die Profile sind sinnvoll, das Einbinden innovativer Technologien in den "Standard" lange überfällig.
Was mich allerdings sehr verwundert hat ist die Aussage das EJBs an Bedeutung verlieren werden. Ich bin gerade dabei ein größeres System zu bauen und setze auf eben diese, möchte aber natürlich nicht auf ein sterbendes Pferd setzen. Langlebigkeit ist zudem eine der Hauptanforderungen.

Als EJB 3.1 "Light" erwähnt wurden dachte ich mir, das könnte genau das sein was ich brauche. Ohne den kompletten Appserver... allerdings bringen mir nur "Local Session Beans" garnichts - es gibt einen Rich- und einen Webclient.

Alle Welt spricht heutzutage von SOA - aber ich finde es irgendwie wesentlich komplizierter WebServices zu bauen als einfach EJBs zu benutzen. Auch zwischen den einzelnen Subsystemen im Server. Die Architektur ist sowieso recht nahe an SOA Prinzipien... überhaupt verstehe ich den wirklichen Unterschied zwischen SOA und EJB nicht -> irgendwie ändert sich doch nur das Protokoll der Datenübermittlung?
Oder habe ich irgendwie irgendwas essentielles verpasst?

Und wenn nicht: Gibt es alternativen zu EJB welche leichtgewichtiger sind? Ich möchte im Prinzip nur entfernte Methoden aufrufen und ich möchte wissen "Wer" mich aufruft. Ist es vielleicht sogar der beste Ansatz einfach RMI zu benutzen und was eigenes darum herum zu bauen?
Spring ist für mich keine Option.

 

[byte]

Spring ist für mich keine Option.

Und warum, wenn man fragen darf? Spring ist genau die Antwort auf Deine Frage und der Quasi-Standard im JEE-Bereich.

Rod Johnson ist übrigens CEO von SpringSource.

 

[ms]

Alle Welt spricht heutzutage von SOA - aber ich finde es irgendwie wesentlich komplizierter WebServices zu bauen als einfach EJBs zu benutzen.

Hier liegt der Denkfehler.
SOA != Webservices

Man kann genauso mit RMI, HTTP, Sockets, einfachen Files, EJBs, Webservices (oder alles gemischt + ESB) eine SOA aufbauen. Bei SOA kommt es auf die Eigenständigkeit der einzelnen Services an. Das Protokoll ist in meinen Augen zweitrangig.

ms

 

[Niki]

überhaupt verstehe ich den wirklichen Unterschied zwischen SOA und EJB nicht -> irgendwie ändert sich doch nur das Protokoll der Datenübermittlung?

EJBs kannst du nur in Java nutzen. Bei WebServices bist du sprachunabhängig, da ja XML versendet wird. Ist für mich schon ein gewaltiger Unterschied

 

[Gast]

Hallo,

Spring ist für mich keine Option

Rein aus Interesse koenntest du das bitte kurz begruenden. Kenne eigentlich nur wenige wirklich treffende Argumente fuer den Einsatz von EJB.

 

[ps]

Spring ist für mich keine Option.

Und warum, wenn man fragen darf? Spring ist genau die Antwort auf Deine Frage und der Quasi-Standard im JEE-Bereich.

Da gibt es für mich mehrere Gründe, einige davon überholt - die meisten wahrscheinlich persönlich:
a) Es gibt genau eine Implementation - vendor lock-in!
b) XML Konfiguration (anscheinend gibts mittlerweile auch Annotationen..)
c) alles andere als "leichtgewichtig" - Spring ist IMHO mittlerweile genauso komplex wie EJB - eher noch komplexer (in der Benutzung)
d) immer wenn ich mir Spring angeschaut habe um irgendein Probleme zu lösen habe ich mich wieder entsetzt abgewandt und eine Alternative gesucht... (DI, Security)

Vielleicht habe ich mich mit Spring aber auch bisher nur zu oberflächlich auseinandergesetzt - ich bin mit JavaEE 5 in die "Enterprise" Welt eingestiegen.. vielleicht liegt es daran (ich habe das "Leid" mit JEE4 nicht miterlebt).

Mir geht es prinzipiell eigentlich nur ums Remoting...
Am liebsten wäre mir weder EJB noch Spring zu benutzen... für DI bin ich mit der Lookup API sehr glücklich, für die Security brauche ich sowieso was eigenes (One size fits all ist hier wohl nicht zu machen)

 

[maki]

Vielleicht habe ich mich mit Spring aber auch bisher nur zu oberflächlich auseinandergesetzt

Bestimmt

Dinge wie DI gibt's auch im EJB3 Standard, lohnt sich aber wirklich die zu verstehen, ist im Prinzip sehr sehr simpel.

Ein genauerer Blick lohnt auf jedenfall.

 

[ps]

Vielleicht habe ich mich mit Spring aber auch bisher nur zu oberflächlich auseinandergesetzt

Bestimmt

Dinge wie DI gibt's auch im EJB3 Standard, lohnt sich aber wirklich die zu verstehen, ist im Prinzip sehr sehr simpel.

DI habe ich schon verstanden Ich benutze in meinen Webanwendungen (Struts2) hauptsächlich Google Guice. In letzter Zeit setze ich aber auch im Server vermehrt auf die Lookup API aus der NetBeans Platform. Ich habe weder in Guice noch in Spring bisher eine Möglichkeit gefunden wie man diese Funktionalität erhält (Ein Interface, mehrere Implementationen...) Aber das wäre evtl. einen eigenen Thread wert

Zudem: Es gibt DI auch im Java Standard. Ob ich jetzt XML Dateien editiere oder Dateien in META-INF anlege...

 

[maki]

Kenne Google Guice nicht, aber bei DI geht es doch darum, ein Interface zu haben, und die Implementierung austauschbar zu machen bzw. dass das DI Framework sich darum kümmert, welche konkrete Imeplmentierung zu laden ist, einzustellen über Konfig Dateien, oder Annos.

Für DI braucht man nichtmal ein Framework, geht aus zu Fuss.

 

[byte]

Mir geht es prinzipiell eigentlich nur ums Remoting...

Und genau da ist Spring so leichtgewichtig, wie man nur sein kann. Du schreibst einen einen Service als Pojo + 4 Zeilen XML-Konfiguration und schon ist der Service Remote verfügbar. EJBs kannst Du nur auf eine Weise bereitstellen: auf einem Application Server. Spring schreibt Dir da gar nichts vor. Ob Du die Services nun per HTTP, RMI, Hessian, Burlap oder als Webservice bereitstellen willst, ist einfach nur eine Frage der Konfiguration.

Zum Rest: Du solltest Dich wirklich mal ein bißchen mehr mit Spring beschäftigen. Es ist wesentlich leichtgewichtiger als EJBs, die sich im übrigen beim Sprung von 2 auf 3 ne Menge von Spring abgeguckt haben. Sun hinkt im JEE Bereich bei vielen Spezifikationen einfach nur hinterher... (siehe auch Hibernate und JPA).

 

[byte]

Ich habe weder in Guice noch in Spring bisher eine Möglichkeit gefunden wie man diese Funktionalität erhält (Ein Interface, mehrere Implementationen...)

Verstehe nicht, was genau Du meinst. Wo ist denn das Problem, mit Spring verschiedene Beans desselben Interfaces zu konfigurieren? Kannst dann halt nur kein Autowire by Type mehr machen.

 

[ps]

Kenne Google Guice nicht, aber bei DI geht es doch darum, ein Interface zu haben, und die Implementierung austauschbar zu machen bzw. dass das DI Framework sich darum kümmert, welche konkrete Imeplmentierung zu laden ist, einzustellen über Konfig Dateien, oder Annos.

Das ist richtig - oft habe ich aber die Situation das ich mehrere Implementierungen für ein Interface habe und dann programmatisch diese durchgehen möchte (zB. Bezahlmöglichkeiten in einem Webshop). Spring und Guice helfen mir da nicht weiter. Mit der Lookup API kann ich sowohl den simplen case lösen (Ein Interface, Eine Implementation) sowie auch den etwas komplexeren (Ein Interface, Mehrere Implementationen).

@byto:
wie kann ich das in Spring realisieren?

 

[maki]

pragmatisch betrachtet: ich habe bisher eigentlich nie eine Implementierung in einer meiner Anwendungen ausgetauscht... ihr?

Ständig, hauptsächlich zum Testen(!).

Selbst wenn man EJB3 Entity Beans ohne Container Testen kann, gilt dies nicht für SessionBeans, ein echter Nachteil imho.

Nebenbei, wenn überhaupt irgendetwas EJB sterben lässt, dann nur Spring

"POJOs in Action" gibt imho eine gute Übersicht zwischen EJBs und Spring.

 

[byte]

@byto:
wie kann ich das in Spring realisieren?

Wie gesagt: ich verstehe offenbar nicht, was Du machen willst. Denn DI von unterschiedlichen Beans mit dem gleichen Interface ist trivial. Du kannst soviele Implementierungen eines Interface konfigurieren, wie Du lustig bist. Du referenzierst sie doch innerhalb der Konfiguration über eine eindeutige ID. ???:L

 

[ps]

Mir geht es prinzipiell eigentlich nur ums Remoting...

Und genau da ist Spring so leichtgewichtig, wie man nur sein kann. Du schreibst einen einen Service als Pojo + 4 Zeilen XML-Konfiguration und schon ist der Service Remote verfügbar.

Aber ich gewinne auch nicht viel im Vergleich zu RMI... Ich brauche eine RemoteException bei jedem entfernten Aufruf, und mein Interface muss "Remote" erweitern.
(Wenn ich das in der doku jetzt richtig rausgelesen habe)

EJBs kannst Du nur auf eine Weise bereitstellen: auf einem Application Server.

Oder zB. mit OpenEJB und Tomcat. Auch die EJB Implementation von JBoss kann man AFAIK herauslösen, da bin ich mir aber nicht ganz sicher.

Spring schreibt Dir da gar nichts vor. Ob Du die Services nun per HTTP, RMI, Hessian, Burlap oder als Webservice bereitstellen willst, ist einfach nur eine Frage der Konfiguration.

Das wäre in der Tat ein Pluspunkt.. nur benötige ich an dieser Stelle so hohe Flexibilität eigentlich garnicht.

Zum Rest: Du solltest Dich wirklich mal ein bißchen mehr mit Spring beschäftigen. Es ist wesentlich leichtgewichtiger als EJBs, die sich im übrigen beim Sprung von 2 auf 3 ne Menge von Spring abgeguckt haben. Sun hinkt im JEE Bereich bei vielen Spezifikationen einfach nur hinterher... (siehe auch Hibernate und JPA).

Ich weiß das EJB3 sehr von Spring beeinflusst wurde. Hinterherhinken würde ich aber nicht behaupten...

 

[ps]

Wie gesagt: ich verstehe offenbar nicht, was Du machen willst. Denn DI von unterschiedlichen Beans mit dem gleichen Interface ist trivial. Du kannst soviele Implementierungen eines Interface konfigurieren, wie Du lustig bist. Du referenzierst sie doch innerhalb der Konfiguration über eine eindeutige ID. ???:L

Hmm. Eigentlich ist es mehr als "nur" DI.. aber das wird eben auch nebenbei miterledigt
-> http://openide.netbeans.org/lookup/

 

[tfa]

Mir geht es prinzipiell eigentlich nur ums Remoting...

Und genau da ist Spring so leichtgewichtig, wie man nur sein kann. Du schreibst einen einen Service als Pojo + 4 Zeilen XML-Konfiguration und schon ist der Service Remote verfügbar.

Aber ich gewinne auch nicht viel im Vergleich zu RMI... Ich brauche eine RemoteException bei jedem entfernten Aufruf, und mein Interface muss "Remote" erweitern.
(Wenn ich das in der doku jetzt richtig rausgelesen habe)

Muss man nicht, macht man auch nicht.

http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-rmi
|Remote Method Invocation (RMI). Through the use of the RmiProxyFactoryBean and the
|RmiServiceExporter Spring supports both traditional RMI (with java.rmi.Remote interfaces and
|java.rmi.RemoteException) and transparent remoting via RMI invokers (with any Java interface).

EJBs kannst Du nur auf eine Weise bereitstellen: auf einem Application Server.

Oder zB. mit OpenEJB und Tomcat. Auch die EJB Implementation von JBoss kann man AFAIK herauslösen, da bin ich mir aber nicht ganz sicher.

Bei Spring brauchst du überhaupt keinen eigenen Server, nur eine simple RMI-Registry aus dem JRE.
Ein enormer Vorteil für kleine Anwendungen.

 

[ps]

Muss man nicht, macht man auch nicht.

http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-rmi
|Remote Method Invocation (RMI). Through the use of the RmiProxyFactoryBean and the
|RmiServiceExporter Spring supports both traditional RMI (with java.rmi.Remote interfaces and
|java.rmi.RemoteException) and transparent remoting via RMI invokers (with any Java interface).

Hmmm - ich hatte mir das Code Beispiel auf dieser Seite angesehen:

public interface RemoteAccountService extends Remote {
    public void insertAccount(Account account) throws RemoteException;
    public List getAccounts(String name) throws RemoteException;
}

Bei Spring brauchst du überhaupt keinen eigenen Server, nur eine simple RMI-Registry aus dem JRE.
Ein enormer Vorteil für kleine Anwendungen.

Stimmt.

 

[tfa]

Ja, die Seite verwirrt da etwas. Das selbe Beispiel steht ohne Remote und RemoteException direkt darüber.

 

[byte]

Mir geht es prinzipiell eigentlich nur ums Remoting...

Und genau da ist Spring so leichtgewichtig, wie man nur sein kann. Du schreibst einen einen Service als Pojo + 4 Zeilen XML-Konfiguration und schon ist der Service Remote verfügbar.

Aber ich gewinne auch nicht viel im Vergleich zu RMI... Ich brauche eine RemoteException bei jedem entfernten Aufruf, und mein Interface muss "Remote" erweitern.
(Wenn ich das in der doku jetzt richtig rausgelesen habe)

Falsch. Du weisst was POJO heisst? Du hast bei Spring keine Abhängigkeiten im Code. Die Abhängigkeiten werden injiziert, daher der Begriff Dependancy Injection.

Spring schreibt Dir da gar nichts vor. Ob Du die Services nun per HTTP, RMI, Hessian, Burlap oder als Webservice bereitstellen willst, ist einfach nur eine Frage der Konfiguration.

Das wäre in der Tat ein Pluspunkt.. nur benötige ich an dieser Stelle so hohe Flexibilität eigentlich garnicht.

Erst ist Dir Spring nicht flexibel genug, nun ist es zu flexibel. Entscheide Dich mal, was Du willst.
Natürlich braucht man meistens nur 1-2 dieser Implementierungen, aber der große Vorteil ist eben, dass Du davon im Code überhaupt nichts findest.

Ich weiß das EJB3 sehr von Spring beeinflusst wurde. Hinterherhinken würde ich aber nicht behaupten...

Wie würdest Du es sonst nennen, wenn man die Spezifikation (JPA) von der Implementierung (Hibernate) "abschreibt"?

 

[ps]

Ok ok - ich sehe schon, hier sind sehr viele Leute sehr glücklich mit Spring

Werde mir also wirklich die Zeit nehmen müssen mich da mal näher mit auseinanderzusetzen - wenn das Remoting ohne die Exceptions abläuft ist es ja auch genau das was ich gesucht habe

Wie würdest Du es sonst nennen, wenn man die Spezifikation (JPA) von der Implementierung (Hibernate) "abschreibt"?

Das JPA sehr von ORM Mappern wie Hibernate und Toplink beeinflusst wurde ist logisch: Am JSR haben diese Leute mitgearbeitet Allerdings sah Hibernate _vor_ JPA ganz anders aus... das JSR war aber halt eine weile im Entstehen, in dieser Zeit hat sich Hibernate an die Spec adaptiert.

Der Eindruck die Spec wurde von Hibernate abgeschrieben ist aber falsch.. Toplink und andere hatten mindestens genausoviel Einfluss. Mit JPA wollte man die vielen Mapper unter einen Hut bekommen.