Enterprise Java-Anwendungen

Enterprise Java-Anwendungen

ETECTURE bietet das komplette Spektrum einer Enterprise Java Anwendung

  • funktionale Website mit JSF, klassischen JSPs oder als schlanke AngularJS-Applikation
  • flexible und leichtgewichtige EJB-basierte Microservices für Ihre Business-Logik
  • performante Persistierung mit klassisch-relationaler Datenbank, aber auch NoSQL-Datenbanken, wie MongoDB oder Neo4j
  • skalierbare Integration Ihrer bestehenden Informationssysteme (z.B. SAP, Oracle, etc.)
  • Ressourcen- (ReST) oder Serviceorientierte (SOA) Schnittstellen für die Kommunikation mit Drittsystemen
  • Adaption zum Betrieb in einer Cloud (z.B. Amazon WebServices u.a.)

jee1_2

Enterprise Java Anwendungen haben sich im Laufe der letzten 10 Jahre entscheidend verändert. Während man mit J2EE noch richtig viel Aufwand in die Auswahl und Adaption der passenden Technologie investieren musste, ist JEE – wie es nunmehr heißt – ein Pool von zielführenden und leichtgewichtigen Standards (sog. JSR’s – Java Specification Requests).

Die in der JEE-Spezifikation zusammengefassten Standards werden in einem Prozess von Oracle und der Java Community entwickelt und stellen somit den größten gemeinsamen Nenner aller Interessen dar. Jeder – ob Firma oder Privatperson – kann sich an diesem Prozess beteiligen und seine Ideen und Interessen einfließen lassen. So wächst auch die Akzeptanz von JEE innerhalb der Java-Entwickler-Gemeinde stetig weiter. Dies ist ein entscheidender Fortschritt gegenüber der proprietären Konkurrenz, hinter der meist ein einziges Unternehmen steht.

Zusätzlich definiert die JEE zwei Compliance-Profile, mit denen die Hersteller von JEE-konformen Applikationsservern entscheiden können, wie viele einzelne Technologien ihre Produkte tatsächlich unterstützen. Damit grenzen sich Web-Applikationsserver (sog. „Web-Profile“, wie z.B. Tomcat) von voll-ausgestatteten Applikationsservern (sog. „Full-Profile“, wie z.B. Glassfish oder Wildfly) ab.

Für die letzten drei Evolutionsschritte (beginnend mit Java EE 5 bis zur aktuellen Java EE 7) wurden vor allem zwei Ziele verfolgt: Einfache Entwicklung und klare Spezifizierung. Es gibt kaum noch Ungereimtheiten, wie sich Applikationsserver in bestimmten Szenarien verhalten sollen, sondern eine Vielzahl von Richtlinien und Regeln, die die Hersteller in ihren Produkten berücksichtigen müssen. Auch eine Konformitätsprüfung wurde eingeführt, um sicher zu stellen, dass eine JEE Anwendung mit allen verfügbaren Applikationsservern ausgeführt werden kann.

Die Vereinfachung der Entwicklung ist es aber, die den entscheidenden Durchbruch zum Erfolg der JEE gebracht hat. Erreicht wurde dies vor Allem durch eine konsequente Festlegung von Konventionen. Erst wenn man von diesen Konventionen abweichen muss – sei es, weil man ein anderes Transaktionshandling braucht, oder um ein Datenbank-Schema vom Test-System zum Produktivsystem wechselt – erstellt man eine Konfiguration. Dabei bleibt die bereits entwickelte Geschäftslogik weitgehend gleich und somit unabhängig von der zu verwendenden Technologie.

Als vereinfachtes Kredo kann man formulieren: „Die Technologie liefert der Applikationsserver, der Entwickler konzentriert sich auf die Geschäftslogik“. Das wirkt sich positiv auf das Projektbudget aus, denn aufwändige Integrationstests fallen weg; Prototypen lassen sich schnell erstellen und somit die Anforderungen für die Geschäftslogik frühzeitig validieren.

jee2_2

JEE passt somit auch ideal in die agile Vorgehensweise, denn durch die saubere Spezifikation, wie ein Entwickler die Anwendung bauen muss und durch den großen Vorteil, dass die Technologie nur ein Querschnittsaspekt ist, lässt sich die sog. „Technical Debt“ (deutsch: technische Schuld, also ein Maß dafür, wie genau die bereits erstellte Lösung ist und wie stark sie von der idealen Lösung abweicht) vom Anfang des Projekts an klein halten.

Aber auch die Architektur von JEE Anwendungen hat sich gewandelt. Während man früher Augenmerk auf die fachliche Verteilung seiner Anwendung in dedizierte Hardware-Systeme (den sog. Tiers) gelegt hat, also z.B. für die Datenhaltung, die Geschäftslogik und die Präsentationslogik jeweils einen eigenen Server verwendet hat, entwickelt man in JEE heute schichtenorientiert und kapselt somit die Fachlichkeit nicht mehr durch Hardware, sondern durch programmatische Aufteilung in Komponenten. Eine JEE Anwendung läuft heute prima komplett auf einem einzigen Server.

Doch diese Entwicklung geht noch weiter: Mit den sogenannten Microservices „schneidet“ man die Anwendung nicht mehr horizontal in Schichten, sondern vertikal in Module die jeweils einen dedizierten fachlichen Zweck erfüllen und flexibel und leichtgewichtig austauschbar sind. Die Module können dabei völlig unabhängig voneinander auf einem Server laufen oder auf je einen Server pro Modul verteilt werden. Die Kommunikation unter den Modulen erfolgt problemlos per ReST über HTTP, so dass die Anforderungen an die Infrastruktur im Rahmen bleiben. Die Vorteile einer Cloud lassen sich so auch für JEE Anwendungen nutzen. Letzteres ist neben vielen kleinen und großen Vereinfachungen und Verbesserungen der Fokus der im September begonnenen Spezifikationsarbeiten für die nächste Version: Java EE 8.

Den Vergleich mit anderen Lösungen wie z.B. dem Spring Framework braucht die JEE nicht zu scheuen. Das Schöne an JEE ist, dass die Applikationsserver bereits alles quasi „out-of-the-box“ mitbringen, was zum Betrieb einer Enterprise Anwendung benötigt wird. Die zu deployenden Artefakte sind klein, schnell ausgeliefert und installiert. Die Konfiguration der Anwendung erfolgt über die Administrations-Konsolen der Applikationsserver und damit ohne dass ein erneutes Kompilieren und Zusammenstellen der Anwendung notwendig wird.

Wir bei ETECTURE verwenden JEE bereits seit Gründung unseres Unternehmens in vielen unserer Projekte und können dabei auf einen großen Erfahrungsschatz zurückgreifen. Nicht nur, was die Entwicklung angeht, sondern schon für die Konzeptionsphase haben wir viele Ideen und Lösungsmöglichkeiten parat. Hinzu kommt, dass auch wir uns an der Weiterentwicklung der Spezifikation beteiligen.

Dabei sehen wir vor Allem den folgenden Trend: Zunehmend werden die Projekte nicht mehr als reine Website, sondern als integrative Gesamtlösung verstanden. Diese sog. „Middleware“ koordiniert neben der Ausführung von Geschäftslogik auch den Datenfluss zwischen der Website und den bereits vielfältig vorhandenen Systemen in Unternehmen. Ein Content Management System oder ein Portal z.B. wird dabei nicht mehr als das einzige System angesehen, in das sich die Geschäfts- und Adaptionslogik einbinden muss, sondern nur als eine Komponente einer kompletten Enterprise Anwendung, die sich in das Zusammenspiel der anderen Komponenten der Anwendung integrieren muss. Das Zauberwort dabei heißt „Separation of Concerns“ (etwa: „Aufteilung der Verantwortlichkeiten“) – jede Komponente bedient dabei nur einen einzigen bestimmten Zweck. Im Falle des CMS oder Portals ist dies eben die Präsentation und nicht die Ausführung der Geschäftslogik oder Anbindung an vorhandene Enterprise-Information-Systeme wie z.B. eine SAP Debitorenverwaltung oder ein CRM-System von Oracle.

ETECTURE bietet das komplette Spektrum einer Enterprise Java Anwendung: von der funktionalen Website über EJB-basierte Microservices bis hin zur Adaption zum Betrieb in einer Cloud. Wir beraten Sie gerne!

[Fachbeitrag von Robert Herschke, Software Engineer, ETECTURE 2014]

Redaktion
von