Singletons, Spring und EJBEine interessante Sache, die ein Eindruck von der Änderung im Java EE Bereich bringt, ist die Evolution des Verständnisses von Singletons.
Ursprünglich war es ja ein Pattern, dass in dem guten, alten Design Patterns Buch veröffentlicht wurde. Damals war es eine sinnvolle Möglichkeit, um eben nur einen Instanz von einem Objekt zu haben. Später gab es dann die Probleme in nebenläufigen Umgebungen, wo die Implementierung des Patterns nicht trivial wird, wenn man wirklich garantiert nur eine Instanz erzeugen will.
Bei EJB wurden die für Singletons notwendigen statischen Variablen verboten, was dazu führt, dass man eigentlich keine Singletons bauen kann. Allerdings geht es vor allem darum, dass man im Cluster eben nicht garantieren kann, dass es nur eine Instanz des Singletons gibt. Ob das nun wirklich ein Problem ist, sei mal dahingestellt.
Gleichzeitig änderte EJB das Programmiermodell in die Richtung, dass die Beans sich nicht mehr mit Nebenläufigkeit beschäftigen müssen: Es gibt einen Pool von Instanzen, jeder Thread bekommt eine und das war's. Im Prinzip ist das eine gute Idee, weil es den Entwickler entlastet und gleichzeitig die Anzahl der neu zu instanziierenden Klassen gering hält. Auf der anderen Seite ist es unflexibel: Man kann dies Verhalten nicht ausschalten. Außerdem ist es ausgesprochen fraglich, ob es sinnvoll ist. Bei Stateless Session Beans gibt es keinen State - warum sollte die Bean nicht Thread-Safe sein? Wo sind die Ressourcen, bei denen es Konflikte geben kann? Bei Stateful gibt es einen State, aber der ist Client-abhängig und kann daher nur von einem Thread bearbeitet werden. Bleiben Entity Beans - na ja, die sind eh nicht mehr interessant in der Form, weil sie sich in EJB 3 ändern.
Und Spring? Bei Spring sind die Spring Beans per default Singletons, was eben sinnvoll ist, weil man bei Diensten, wie sie in Stateless Session Beans oder DAOs vorkommen, die Objekte als Singletons implementieren kann - sie sind fast immer automatisch thread-safe. Falls nicht, kann man Pools benutzen oder immer ein neues erzeugen lassen - nur eine Frage der Konfiguration. Wobei Pools für leichtgewichtige Objekte (dazu können Stateless Session Beans durchaus gehören) eventuell gegenüber Neuerzeugung keine Vorteile bringen.
Was bedeutet das? Nun ja, dass EJB Komponentenmodell ist möglicherweise noch weniger sinnvoll, als man glaubt. Und Spring bietet flexible Konfiguration in diesem Bereich. Außerdem werden Singletons mit Spring genauso behandelt, wie andere Spring Beans, so dass Testbarkeit nicht leidet und der Charakter einer globalen Variable nicht mehr hat. Spring bringt eben OO zurück und bietet gerade für den Aufbau von Objektnetzen viele Vorteile....
Rap goes Nerds
Hier einige komische Links von hier.
Die rappende Antwort auf C++ ist nicht Java, sondern MC Plus+.
Und hier die rappenden Hobbits.
Sehr sehenswert:
Represent!
Java Champion
Ich bin einer von weltweit 20 Java Champions . Andere Champions sind zum Beispiel James Gosling, Bill Burke und David Flanagan.
Was ist ein Java Champion? Hier das Zitat von der Web Seite:
Java Champions are people who are external to Sun Microsystems who have made significant contributions to the Java Platform. These Champions are industry luminaries: authors, professors, senior architects, and java community members.
EJB und Spring
Gestern habe ich gerade an verschiedenen Passagen meines Spring Buches gearbeitet, an denen es um die Beziehung zwischen EJB und Spring geht. Heute hat hier Floyd Marinescu einen Blog Eintrag geschrieben, der die Schwächen von EJB auflistet. Ich muss gestehen, dass sich bei mir nach einigen Jahren Beschäftigung mit der EJB Technologie - ich bin seit 1.0 dabei - langsam ein Desinteresse an EJJB einstellt. Mir ist im Rahmen des Schreibens an meinem Buch auch deutlich geworden, das die Frage eigentlich sein sollte, warum man EJB überhaupt einsetzten will.
Die Eleganz des Programmiermodells ist bei Spring genauso gut wie EJB 3. Wenn ich nun EJB 3 nutze, lege ich mich auf einen Application Server fest. Warum sollte ich das tun? Mit Spring habe ich die Flexibilität, auch andere Infrastrukturen zu verwenden, ohne dabei die Features von EJB wie verteilten Zugriff, Instanz Pooling, deklaratives Transaktionshandling usw. zu verlieren. Wo ist nun das Feature, das EJB Spring vorraus hat? Der einzige Grund, den ich mir vorstellen kann, ist, dass man aus irgendwelchen Gründen (welchen?) RMI nutzen muss. EJB bietet hier eine Infrastruktur, in der ich Load Balancing, Fail Over usw. mit RMI bekomme. Aber wenn ich hier flexibler bin und z.B. Hessian als Protokoll nutzen kann, bin ich mit Spring mindestens genauso gut. Und Spring kann ich heute nutzen, während EJB 3 immer noch in der Standardisierung ist.
Beim EJB 2.1 Programmiermodell ist es völlig klar, dass Spring um Klassen eleganter ist - ohne XDoclet und andere Hilfsmittel ist es völlig unerträglich. Ein mögliches Hilfsmittel kann übrigens wieder Spring sein...
Distributed Computing in Zukunft?Die Erfahrungen, die man mit Web Services machen kann, sind immer noch frustrierend. In der Realität gibt es immer noch Probleme mit Interoperabilität, auf der Java Seite eine unabsehbare Vielzahl an APIs (JAX-RPC, Axis, XFire, JSR 181, EJBs als Web Services ...) und das ganze nur, um verteilte Aufrufe zu implementieren? Ich versuche eigentlich nicht, einer der ewig-gestrigen zu sein, aber wir haben diese Problem schon mit DCE und CORBA gelöst. CORBA zudem mit einem effizienteren, binären Protokoll. Nun kann man einwenden, dass XML ein einfacheres und lesbares Format darstellt. Das mag ja sein, aber SOAP und WSDL sind nicht das, was man wirklich lesen will. Das nun auch bei den Web Services sich die Ansicht durchgesetzt hat, dass man mit dem Interface, also WSDL, starten soll, macht die Sache noch etwas unschöner.
Was bedeutet das? Auf der einen Seite zeigt es, dass auch suboptimale Techniken sich durchsetzten können. Dann zeigt es, dass es in der IT Industrie offensichtlich nicht möglich ist, bei einem Standard zu bleiben, sondern es muss dann einen neuen geben, der das Rad auch nochmal standardisiert. Web Services haben sicher einige Vorteile, aber viele Probleme erinnern doch sehr an CORBA. Gleichzeitig finde ich den Ansatz, einen Web Server auch für verteilte Kommunikation zu nutzen sehr attraktiv, denn sie bieten mit der Servlet API eine elegante API, die tatsächlich die Unterstützung beliebiger Protokolle bietet. Durch die API bekommt man recht billig eine gute Skalierbarkeit und Ausfallsicherheit, mit der Web Server Cluster ja glänzen können. Gleichzeitig sind die Server in der Komplexität noch beherrschbar. Dies bedeutet, dass man auf Protokolle wie Hessian oder Burlap einen Blick werfen sollte, die auch die Servlet API verwenden, aber auf dem Draht ein sehr einfaches und im Falle von Hessian sogar ein binäres Protokoll verwenden.
Auf der anderen sind die RPC Mechanismen langsam langweilig. Nach Sun RPC, DCE, CORBA und RMI haben wir jetzt eben Web Services. Viel interessanter ist Grid Computing und damit auch P2P Ansätze für Business Systeme. Hier könnte sich wirklich ein Paradigmenwechsel ankündigen.
Spring: Der Enterprise BaukastenDie wirkliche Bedeutung von Spring liegt meiner Meinung nach in der Integration der verschiedenen APIs. Dadurch ist Spring ein umfangreicher Baukasten für Java Anwendungen. Dies bedeutet, dass man durch Spring auch einen guten Eindruck bekommt, welche Technologien sich für einen Einsatz in einem Java Projekt lohnen und zwar ohne, dass man unbedingt Spring benutzen muss.
Natürlich ist es ausgesprochen sinnvoll, Spring wegen Dependency Injection und der Integration der Frameworks auf jeden Fall zu nutzen, aber in einem bereits laufenden Projekt kann man dies vielleicht nicht so ohne weiteres. Dennoch werden auch hier die Probleme auftreten, die Spring mit den integrierten Frameworks löst. Und die Integration eines der Frameworks könnte durchaus leistbar sein. Da gerade diese (Open Source) Frameworks den Vorteil der Java Plattform darstellen, ist Spring nicht nur das zentrale Framework für Java, sondern Spring ist auch die Schlüsselqualifikation für Java EE Entwickler und Consultants.
Java One Sessions: Folien onlineDie Folien der Java One Sessions finden sich jetzt
hier. Ab Ende August gibt es dann auch die Videos auf der Side.
Java Puzzles
Ein Nachtrag noch zur JavaOne: Ein recht interessantes Thema, zu dem
es auch ein Buch gibt, sind Java Puzzles. Im Web finden sich unter dem
Stichwort einige Dinge, wie z.B. hier. Es gibt aber auch ein ganzes Buch.
Die Sachen sind wirklich überraschend. Das Beispiel, das mir noch im
Kopf herumschwirrt:
while ((i<=j) && (j<=i) && (!(i==j))
Wann wird das eine Endlosschleife? Tipp: Es geht nur mit JDK 1.5.
Die spannende Frage ist natürlich, wann Java so komplex geworden sein
wird wie C++...
Generierung und Kultur
Modell-getriebene Entwicklung hängt sehr wesentlich von Code Generierung
ab. Jedoch ist diese Code Generierung deutlich anders als z.B. die
Generierung mit XDoclet. Dieser Unterschied ist so groß, dass es schon
fast falsch erscheint, dass Wort Generierung überhaupt in diesem
Zusammenhang zu verwenden. Generierung wie mit XDoclet ist jedoch unter
Entwicklern weit verbreitet und wird auch als eine echte Hilfe
angesehen: Man muss eben die häufig wiederkehrenden Dinge nicht mehr
selber schreiben. Aus diesem Kontext gibt es zum Beispiel auch die
Empfehlung aus dem Buch "Der Pragmatische Programmierer" nur Generatoren
zu verwenden, die man auch selber versteht. Generatoren in diesem
Kontext sind also eine Hilfe für DRY (Don't Repeat Yourself).
Die Frage ist nun, ob dieses Verständnis von Generatoren dem
modell-getriebenen Ansatz im Wege steht. Denn bei modell-getriebenen
Ansätzen geht es eben gerade nicht mehr darum, nur DRY zu ermöglichen,
sondern neue Ausdrucksformen mit höherer Abstraktion zu finden. Dies
setzt bei den Entwicklern ein Umdenken vorraus, das jenseits des
Erlernens einer neuen Sprache liegt und vor allem die bisherige Idee
der Generator Verwendung, aber auch z.B. dem wenigen großen Erfolg der
CASE Tools überwinden muss. Dazu kommt dann noch die häufig sehr große
Komplexität der typischen MDA Werkzeugen, die den Blick auf die
existierenden, pragmatischen Lösungen verstellen. Mir fehlt allerdings
ein Gefühl dafür, wie groß dieses Problem in der Realität ist.
Interessanterweise kann Microsoft aus meiner Sicht hier mit Visual
Studio .NET 2005 und dem Pushen der Software Factories einen
wesentlichen Beitrag zur Lösung des Problems leisten...
Java vs .NET: The Revenge of the coffee shop?
Noch vor ein paar Jahren - es muss wohl 2003 gewesen sein - habe ich auf der JAX Konferenz für ein .NET Statement in der Kategorie von "Es gibt da draußen keine großen .NET Systeme" erhebliche Prügel bezogen und das wohlgemerkt auf eine Java Konferenz. Überhaupt hatte ich das Gefühl, dass Microsoft ein sehr geschicktes Marketing zeigt: Sie treten auf Java Konferenzen auf und zwar mit der Aussage "Hey, guck mal, ist fast Java, ist doch auch nett, oder?" und bei den Entwicklern herrscht - berechtigterweise - die Stimmung vor, dass man eben die Technologie wählt, die passt, und .NET ist eben schon eine sinnvolle Technologie.
In letzter Zeit mehren sich allerdings aus meiner Sicht die Anzeichen dafür, dass .NET anscheinend im Enterprise Bereich ein Problem hat. Viele Firmen scheinen ein strategisches Commitment zugunsten von Java zu haben und haben kein Interesse, auch .NET noch zu unterstützen. Während dies nur bedeutet, dass Java eben früher da war und dadurch schwer zu verdrängen ist, gibt es dann sogar Firmen, die ein solches Commitment haben, um einen Vendor-Lock-In zu vermeiden. Firmen mit Mainframe Erfahrung wissen häufig, wo so ein Vendor-Lock-In endet.
Ich selber muss auch immer noch gestehen, dass es mir schwer fällt, zu glauben, dass man mit Windows wirklich große Server betreiben kann. Dies ist allerdings deutlich ein Vorurteil: Ich habe noch nirgendwo gesehen, dass soetwas schief geht, und es gibt Referenzkunden, bei denen soetwas funktioniert.
Wo ist also .NET einzuordnen? Wahrscheinlich im Mittelstand, bei denen Windows Skills vorhanden sind und die mit Microsoft Server einen recht umfangreichen Application Server im Betriebssystem integriert bekommen und auch eine leichte Integration von Exchange usw. Wer also eine Integration in die Microsoft Plattform sucht - und damit meine ich die anderen Microsoft Server Produkte - ist mit .NET gut bedient.
Die andere Stärke von .NET sind ja scheinbar Client Systeme. Ob das wirklich so sinnvoll ist, sei mal dahingestellt: Mit Eclipse RCP gibt es in der Java Welt eine aus meiner Sicht attraktive Lösung, die auch über eine GUI Bibliothek hinausgeht und eine Struktur einer Client Anwendung vorgibt. Ob es soetwas auch im .NET Umfeld gibt, ist mir unklar. Und eine Fernsteuerung von Office zumindest mit Groovy (Java Skriptsprache) ist genauso einfach wie mit .NET. Dennoch ist es natürlich so, dass man mit .NET hier die "offizielle" API hat.
Was bedeutet das? Die Argumentation ist - wie man sieht - nicht sehr technisch - hier gibt es wohl kaum einen klaren Sieger. Ein wichtiger Punkt ist Plattform-Gedanken und die dahinter stehenden Namen: Es geht Microsoft mit .NET Plattform und den verschiedenen .NET Servern und auf der anderen Seite um die Java EE Plattform, auf die z.B. auch Oracle, SAP und IBM ihre weiteren Produkte aufbauen.
Strategisch scheint es zum einen schwerer als gedacht zu sein, Java aus den Unternehmen herauszudrängen, und es kann auch sein, dass bei CIOs doch die Angst vor proprietären Lösungen zu groß ist. Also sollte man das ganze weiter beobachten und wenn man Microsoft in der Vergangenheit studiert hat, weiss man, dass sie auch nach einem ersten, weniger erfolgreichen Versuch, nicht locker lassen. Für Java EE ist das Ziel natürlich, auch im Mittelstand und bei weniger komplexen Projekten eine gute Alternative zu sein: Genau dies soll die Vereinfachung in Java EE 5 und Java SE 5 bringen. Konkurrenz und Pluralismus belebgen das Geschäft, führen zu besseren Produkten und machen das Business spannend. Ich bin schon auf die weiteren Schachzüge in diesem Spiel gespannt!
Vortrag TU Dresden
Der Vortrag an der TU gestern war nicht ganz so gut besucht, was aber wohl primär dem Wetter geschuldet war. Am Ende hatten einige der Besucher noch Fragen, die darauf schließen liesen, dass das Thema wirklich interessant ist und auch Interesse existiert, bei Saxonia zu arbeiten. Von daher emfand ich den Vortrag als einen Erfolg. Anschließend gab es noch Musik, Essen und Trinken, wobei ich mich dann wegen meines Flugs recht schnell ausklinken musste.
Spring und Annotationen
Nachdem Spring vor allem für sich in's Feld führt, auf POJOs zu fokussieren und die Entwicklung deutlich zu vereinfachen, sollte man ebenfalls einen Blick auf alternative Ansätze in diesem Feld werfen. Eine Sache, die mit Java SE 5 uns gegeben wurde, sind Annotationen. Nach meiner Meinung wird dieses im Vergleich zu den anderen Features wie Generics, typesafe Enums usw. die Programmierung mit Java am deutlichsten beieinflussen. Wenn man nun Spring in die Gleichung einbezieht, so ergeben sich teilweise Synergien. Annotationen eignen sich beispielsweise hervorragend, um Methoden für Aspekte zu markieren. Hier kann man mit Spring AOP dann auf die jeweiligen Annotationen reagieren. So kann man dies Verfahren zum Beispiel nutzen, um Transaktionen zu steuern. Auch sonst befruchten sich die Ansätze: Durch die Annotationen in EJB 3 ist es leichter, ein Spring POJO zu einem EJB zu machen. Man muss nur noch die Annotationen hinzufügen - fertig.
Auf der anderen Seite wird durch dieses Modell die Entwicklung auch ohne Spring vereinfacht. Die Integration von EJB, RMI, Web Services usw. in Spring ist keine so große Erleichterung mehr.
Was bedeutet dies nun? Die wesentliche Basis von Spring nämlich Dependency Injection und AOP ist und bleibt der große Vorteil. In den anderen Gebieten - und dies gilt zum Beispiel wohl auf für Hibernate 3 - lernen die anderen dazu. Dennoch ist Spring in der Vollständigkeit der Lösung immer noch ein einzigartig. So oder so ist es für Entwickler auf jeden Fall positiv, wenn man aus mehreren guten Ansätzen den besten auswählen kann.
Intel und Mac: Die Hintergründe?Was einen als Mac Benutzer in letzter Zeit beschäftigt, ist die Frage, warum Apple auf Intel Prozessoren umschwenkt.
Dieser Artikel versucht darauf eine Antwort zu geben: Im wesentlichen läuft es darauf hinaus, dass Apple von IBM eine ausgesprochen gut behandelt werden will und dass dies zu einem schwelenden Konflikt geführt hat, so dass IBM Apple nicht wirklich nachweint. Gleichzeitig soll ein Motiv sein, dass Apple alle Produkte (also auch den iPod) mit Intel (dann eben XScale) Prozessoren ausstatten will und dadurch hohe Rabatte bekommen will.
Die Argumentation hört sich für mich sinnvoll an, weil es mir schwer fällt, an die öffentlichen Gründe schlechte Performance pro Watt und mangelnde Roadmap zu glauben. Die entscheidene Frage ist aber immer noch, wie Apple sich von "Yet Another PC Vendor" unterscheiden will. Wobei der Artikel hier noch den Gedanken einbringt, dass der Mac nicht mehr das wichtige Produkt ist, sondern der iPod und der iTunes Music Store. Dann wäre dieses Thema eben nicht mehr so wichtig.
Ich bin jedenfalls gespannt!
BPEL: Das zentrale SOA Element?
Im aktuellen Java Magazin gibt es einen Artikel, der die Frage stellt,
ob BPEL Hype oder Realität ist. Das hat mich zu der Frage geführt, ob
BPEL wirklich der zentrale Bestandteil einer SOA ist. Die Antwort, die
JBI gibt, ist gerade im Gegenteil die, dass BPEL nur ein Service unter
vielen ist. Es ist eben nur ein weiterer Service, der seine Leistungen
durch die Komposition mehrerer anderer Services erbringt. Der zentrale
Bestandteil, den JBI sieht, ist die Konvertierung in standardisierte XML
Nachrichten das zentrale Thema. Und hier denke ich, dass JBI auch recht
hat. Meines Wissens geht MS Biztalk einen ähnlichen Weg. Das labidare
"Bei BPEL muss eben alles ein WSDL zugreifbarer Service sein" ist nicht
ausreichend. In der Realität gibt es zu viele Integrationen durch
Dateiübertragungen oder Datenbanktabellen usw. Von daher ist BPEL
wirklich nur ein Teil von SOA: Ein wichtiger, aber eben nicht der zentrale.
Java Magazin: AspectJ Interview und Jenseits von Java
Im aktuellen Java Magazin ist zum ein Interview enthalten, dass
Alexander Neumann vom Software und Support Verlag und ich mit Adrian
Colyer am Rande der JAX gemacht haben. Adrian leitet das AspectJ Projekt
und hat auf der JAX eine sehr interessante Keynote zum Thema gehalten.
Das spannende für mich war, dass IBM intern auch AspectJ z.B. im
Websphere Bereich verwendet.
Außerdem hat Johannes Link die neue Artikelserie "Jenseits des
Tellerandes" im Java Magazin untergebracht. Dort geht es darum, auch mal
andere spannende Themen zu untersuchen. Als eine Art Motivation und
Einleitung gehe ich im ersten Teil der Serie der Frage nach, was nach
Java kommen wird, wenn es eine solche Zeit überhaupt gibt. Dabei geht es
um Technologien wie MDSD, AOP, .NET, Skriptsprachen und funktionale
Sprachen.
Also: Ins Java Magazin Reinschauen lohnt sich (wie immer)!
Software Entwicklung: Ameisen, Fabriken und Handwerker
Am Dienstag, den 13.7., werde ich an der Informatikfakultät TU Dresden
von 16:00 bis 17:30 Uhr in Hörsaal 172 zum Thema "Software Entwicklung:
Ameisen, Fabriken und Handwerker" sprechen.
Der Abstract ist mit Absicht ein wenig abstrakt gehalten:
Die Entwicklung von Software Systemen ist ein Bereich, in dem es viele,
sehr unterschiedliche Ansätze gibt und sich auch immer wieder neue
Methoden etablieren. Der Vortrag zeigt einige dieser Möglichkeiten auf
und gibt einen Einblick, welche Erfahrungen die Saxonia Systems
AG mit ihnen gemacht hat.
Ich bin mal gespannt, wie das Thema so ankommt...
Digital Divide?
Ein Thema auf einer der Java One Keynotes war der Digital Divide. Dabei geht es um die Aufteilung der Welt in Digital-Have-Nots und solche, die eben Zugang zu Computer- und Kommunikationstechnologie haben.
Intuitive hatte ich erstmal ein anderes Verständnis des Begriffs. Der wesentliche Punkt bei digitalen Waren ist, dass sie beliebig häufig ohne Qualitätsverlust und mit sehr niedrigen Kosten vervielfältigt werden können. Eigentlich gibt es also auch eine Art Digital Divide zwischen jenen, die digitale Inhalte produzieren und dadurch extrem reich werden können, und jenen, die dann die Inhalte konsumieren. Was eigentlich dazu führt, dass diejenigen, die Inhalte produzieren klar im Vorteil sind. Allerdings ist hier auch wieder ein Digital Divide: Weil man die digitalen Sachen so gut, kostengünstig und schnell kopieren kann, können sehr wenige Leute sehr viel produzieren und damit einen großen Teil des Markts abdecken. Auf der anderen Seite gibt es viele, die nicht so erfolgreich sind. Ein Beispiel in diesem Bereich, das schon aus der vor-digitalen Welt kommt, sind Musiker: Es gibt einige wenige, die sehr viel Erfolg und Geld haben und viele, die von Musik noch nicht einmal leben können.
Was bedeutet das für Software? Es gibt auf der einen Seite Ansätze, bei denen einige wenige Leute Produkte entwickeln, die dann millionenfach verkauft werden und sie zu Millionären macht oder zumindest ein gutes Leben garantieren. Auf der anderen Seite gibt es vor allem im Enterprise Umfeld Ansätze, bei denen individuell entwickelt wird. Hier spielt die Kopierbarkeit keine Rolle, weil es sowieso nur einen sinnvollen Einsatzkontext für die Software gibt. In diese Richtung spielt auch der Services Gedanken, bei dem eben der Service und nicht die Software im Mittelpunkt stehen. Eigentlich sind diese Leute sowas wie die Verlierer des Software Digital Divide...
Also sollte man als Enterprise Entwickler möglichst schnell auf Consumer Produkte umstellen, um davon viele Kopien zu verkaufen und reich zu werden. Allerdings muss man aufpassen: Der Markt - vor allem bei Windows - kann ein Problem sein. Interessante Perspektiven (mit Apple Fokus) finden sich hier:
http://developers.slashdot.org/developers/05/07/04/1116230.shtml?tid=181&tid=8
Java EE und EinfachheitIch glaube, eines der nächsten spannenden Themen ist Java EE und Einfachheit. Im Moment steht ja im Mittelpunkt von Java EE 5 die Vereinfachung und auch an vielen anderen Stellen spielt es eine Rolle. Gleichzeitig habe ich vor kurzem bei der XP User Group mitbekommen, welche schlechten Ruf Java EE zum Teil hat. Ich glaube aber, dass man da mal einen genaueren Blick drauf werfen muss. In meinem Kopf schwirren zu dem Thema noch einige Gedanken dazu umher. Ich habe daher das Thema jetzt zur WJAX und zur JAOO Konferenz eingereicht. Ich bin mal gespannt, was dabei raus kommt. Vielleicht ergibt sich ja auch eine Diskussion. Das Gefühl, dass der Schuh drückt, habe ich aber schon auf der Java EE Kummerkasten BoF mit Peter Rossback mitgenommen.
JBI
In der aktuellen Computer Zeitung gibt es einen Bericht, in dem auf die Java One eingegangen wird. Dort wird unter anderem behauptet, dass die Veröffentlichung des Sun Application Server als Open Source zu spät kommt und auch die Übernahme von SeeBeyond wird nicht entgültig positiv gesehen, weil zu spät. Ebenfalls finden sich dort weitere Bedenken gegen JBI / JSR 208, da BEA und IBM offensichtlich ihr eigenes Süppchen kochen wollen. Auf der Seite des Entwickler Magazins findet sich ein Kommentar, in dem bereits viele JBI Unterstützer (u.a. IONA) aufgeführt sind: http://www.entwickler.com/itr/news/psecom,id,22665,nodeid,82.html
Was bedeutet das? Es kann gut sein, dass wir hier mal wieder eine kleine Auseinandersetzung um den alleine glücklichmachenden Standard haben werden. Eigentlich wäre es schön, wenn uns solche Sachen erspart blieben...
Java One: FazitLeider mussten wir die Java One noch vor dem eigentlichen Ende verlassen. Der Vorteil der Veranstaltung ist mit Sicherheit die örtliche Nähe zu Sun und überhaupt dem ganzen Silicon Valley. Dadurch kommen viele Leute, die dort in den Forschungs- und Entwicklungsabteilungen arbeiten. Die Besetzung ist sehr hochkarötig. Die technischen Informationen sind ebenfalls sehr spannend.
Allerdings gibt es auch Nachteile. Die extrem große Anzahl als Teilnehmern führt zu einer unpersönlichen Atmosphäre. Direkte Interaktion ist dann auch schwierig. Ein weiteres Problem ist die Begrenzung auf Java: Es gibt auch andere Technologien und viele Dinge wie z.B. modell-getriebene Ansätze sind sehr interessant, werden aber auf der Java One nicht oder kaum behandelt. Was außerdem auffällt, ist der Einfluß von Sun. So gibt es z.B. weniger Eclipse als NetBeans Sessions. Dies kann im Extremfall ein echtes Problem werden, denn leichtgewichtige Ansätze wie Spring können ein Vorteil der Java EE Plattform sein, aber es ist eben nicht im Interesse des Java Establishments Interesse, diese Frameworks massiv zu pushen.
Was bedeutet das? Die Java One ist mit Sicherheit die beste Konferenz für den Bereich der Java Technologien. Ich habe sehr viele Eindrücke mitgenommen, mehr als von vielen anderen Konferenzen, was aber auch daran liegen kann, dass ich hier nicht als Speaker war. Ich würde auf jeden Fall gerne wiederkommen. Vielleicht habe ich dann auch die Chance, früher zu kommen oder länger zu bleiben, so dass alles etwas entspannter ist.
SOA with JBIDiese Session war unter anderem mit John Grupi von Sun, der schon einen recht guten Namen im Java EE Umfeld hat. Er begann mit der Motivation und sagte dabei, dass es in den Unternehmen eine "Accidential Architecture" gibt. Den Begriff finde ich recht passend. Er beschreibt den Fakt, dass in den Unternehmen die Systeme unkoordiniert miteinander reden und irgendwann dann ein echter Drahtverhau entsteht, in dem praktisch jeder mit jedem redet. Das ganze ist dann komplex und teuer.
Für das Einführen einer SOA muss es seiner Meinung nach einen Top Down Ansatz geben, bei der das Business entscheidet, wsa wie umgesetzt wird. Das ist ja auch logisch, denn die SOA muss sich an den Services orientieren und die werden eben durch die Fachlichkeiten definiert.
Dann ging es um JBI konkret technisch. Die Idee von JBI ist es, ein Meta Container für Services zu sein. Das bedeutet, dass er Platz für einzelne Container bietet, die jeweils Dienste implementieren können. Dort kann man zwei unterscheiden:
- Service Engines. Die sind dafür zuständig, eine Ablaufumgebung für Services zu bieten. Ein Beispiel kann ein EJB Container sein. Er ist im wesentlichen das Ziel eines Deployments. Der JBI Container bietet auch die Möglichkeit, neue Service Engines dynamisch zur Laufzeit einzubinden.
- Die Binding bieten Unterstützung für bestimmte Dienste. Dazu zählen SOAP, FTP, REST usw. Er muss die Daten vom Protokoll entgegen nehmen und in das normalisierte Format umwandeln.
Dieses normalisierte Format wird dann vom Message Router genommen und einem anderen Endpunkt weitergegeben.
Das ganze ist ein zusammengesetztes Event-basiertes System, d.h. die Komponenten kommunizieren Asynchron miteinander. Die einzelnen Elemente haben in WSDL definierte Schnittstellen und sind lose aneinander gekoppelt.
Konkret kann es also sein, dass über ein SOAP Binding eine Nachricht in das System kommt. Die wird dann an ein Service, also z.B. eine BPEL Engine, weitergeleitet. Die wiederum legt über ein FTP Binding ein File irgendwo hin. Die interne Kommunikation läuft dabei immer über die normalisierten Nachrichten und den Message Router. Das ganze läuft typischerweise in einer JVM.
SkalierungUm wirklich hohe Durchsätze zu erreichen, muss man JBI Implementierungen miteinander kombinieren können, um einen Cluster zu erreichen. Dazu kann man einzelne JBI Instanzen mit einem Enterprise Service Bus (ESB) zusammenschalten. Das ist konkret eine Message-Oriented Middleware (MOM) wie z.B. JMS. Die genau Implementierung ist jedoch proprietär.
AdministrationEin weiterer wichtiger Teil des Standards ist die standardisierte Installation. Dazu dienen Service Assemblies (SA), die in einem portablen Archivformat ausgeliefert werden. Sie bestehen aus mehreren Services.
Ein Service wird in einer Service Unit (SU) ausgeliefert. Das bedeutet also, dass in einem SA mehrer SUs für die Services sind.
Nicht standardisiert ist das Thema Monitoring, dass hier zum einen vor der Herausforderung steht, viele Container zu monitoren, bei denen auch dynamisch noch welche dazu kommen können. Außerdem muss man die Geschäftsprozesse monitoren.
ZusammenfassungDie abschließende Zusammenfassung hat nocheinmal deutlich gemacht, was JBI ausmacht: Standardisierung. Und zwar bei
pluggable Integration Components
Administration
Nachrichten Austausch zwischen den Komponenten
Das ganze kann einen neuen Markt schaffen, in dem solche Komponenten miteinander konkurrieren.
Mein FazitDas ganze erinnert mich stark an Biztalk, das im wesentlichen auch eine Schaltstelle für den Austausch von XML ist. Damit ist eigentlich die Frage, warum man sowas erst jetzt standardisiert und so in den Mittelpunkt stellt. Es löst mit Sicherheit einige Problem. Allerdings macht der Ansatz eher einen schwergewichtigen Eindruck: Es gibt nicht einen Container, sondern gleich ganz viele. Allerdings kann man die Probleme wohl auch nicht anders lösen. Mit dem Kauf von SeeBeyond stellt Sun klar, dass dieses Thema für sie sehr wichtig ist. Jetzt muss man nur noch mal einen Blick darauf werfen, wie sich das ganze praktisch anfühlt.
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
