computerwoche.de

Archiv

Java versus .NET/Übergreifende Entwicklung mit der Model Driven Architecture

Kluft zwischen Java und .NET überbrücken

29.08.2003
Technologisch liegen J2EE und .NET nicht weit auseinander. Aus strategischer Sicht wäre es dennoch ideal, wenn sich eine voreilige Festlegung auf eine dieser Plattforrmen vermeiden ließe. Die Model Driven Architecture stellt dem Endanwender ein gewisses Maß an Flexibilität in Aussicht.Von Gerhard Versteegen*

Bevor man sich zwischen J2EE und .NET entscheidet, sollte man zunächst überlegen, ob man lieber von einem einzelnen Hersteller oder einer einzelnen Technologie abhängig sein möchte. .NET ist ein Produkt des Microsoft-Konzerns, J2EE hingegen wird von vielen Herstellern unterstützt. Dazu zählen nicht nur der Erfinder Sun, sondern auch IBM, Oracle oder Bea. Betrachtet man die Historie von MS-DOS, so ist man geneigt, sich lieber auf Microsoft einzulassen, denn letztendlich konnte Bill Gates dank seiner Monopolstellung schon die eine oder andere Konkurrenztechnologie vom Markt verdrängen. Auf der anderen Seite kommen Zweifel auf, ob Java und damit J2EE wirklich noch verschwinden werden, schließlich ist Java in einigen Bereichen zum Standard geworden.

Doch zeichnet sich die IT-Branche insbesondere dadurch aus, dass nichts beständiger ist der Wandel - heute noch up to date, morgen schon Schnee von gestern. Eine Vielzahl von Technologien fiel den raschen Veränderungen bereits zum Opfer. Viele Unternehmen begegnen anstehenden Entscheidungen mit "Was wäre wenn"-Planspielen. Meist sind sie danach jedoch genau so schlau wie vorher.

Wenig hilfreich sind bei der Entscheidung zwischen Java und .NET die Prognosen der Analysten. Die Evans Data Corp. hat hier das folgende Ergebnis ermittelt: Während im Jahr 2002 noch 51 Prozent aller Anwendungen in den USA für Java und 40 Prozent der Anwendungen für .NET geschrieben wurden, sollen 2003 bereits 61 Prozent auf Java und 63 Prozent auf .NET beruhen (einige Unternehmen entwickeln parallel für beide Plattformen).

Angesichts dieser Zahlen scheint eine konsequente Festlegung auf eine der beiden Technologien kaum möglich. Es muss also ein anderer Ausweg gefunden werden - dieser wird derzeit von der Object Management Group (OMG, www.omg.org/mda) proklamiert und ist in aller Munde: die Model Driven Architecture (MDA) oder auch das Model Driven Development (MDD). Leider werden heutzutage diese Begriffe meist als Marketing-Instrument genutzt und nicht als das, was sie wirklich darstellen: Ein methodisches Hilfsmittel, das Unternehmen vor Entscheidungen zwischen J2EE und .NET bewahrt und ihnen die Möglichkeit in Aussicht stellt, die Kluft zu überbrücken.

Der theoretische Hintergrund

Was bedeutet MDA? Im Prinzip nichts anderes als: Man modelliere die zu erstellende Applikation mit Hilfe der Unified Modeling Language (UML) und beschreibe dort auch alle über die (bisherige) Modellierung hinausgehenden Details, insbesondere solche, die plattform- und zielsprachenunabhängig sind. Erst so spät wie möglich und so früh wie nötig konzentriere man sich dann auf die Erstellung des Codes, um systemspezifische Festlegungen zu vermeiden.

Man erhält also zunächst ein Platform Independent Model (PIM) und begibt sich dann zum Platform Specific Model (PSM). Dies klingt auf Anhieb einleuchtend und einfach. In der Realität sieht es jedoch anders aus, denn solche Vorgehensweisen erfordern auf der einen Seite spezielle Werkzeuge und auf der anderen eine gewisse Erfahrung. Führt man den MDA-Ansatz weiter, so können auch Altsysteme (zum Beispiel von Mainframe-Anwendungen) auf diese Art und Weise migriert werden.

MDA hat eine Vielzahl von Vorteilen - nicht nur bei der Entscheidung, ob man nun J2EE oder .NET einsetzt. Ursprünglich hat sich die OMG mit MDA beschäftigt, um eine Unabhängigkeit von Applikations-Servern zu erreichen. Der Markt war damals sehr unübersichtlich, es existierte eine Vielzahl dieser Produkte. Mittlerweile hat hier die notwendige Bereinigung stattgefunden, und MDA wird genutzt, um künftig generell unabhängiger von Zielsprachen und Betriebssystemen zu sein.

Was ist ein Werkzeug, das den Stempel "MDA-Tool" zu Recht trägt? Die Antwort auf diese Frage soll helfen, Marketing-Tricks von Herstellern zu entlarven. Viele Firmen nutzen das Interesse an MDA, um in die Jahre gekommenen Produkten ein neues Image zu verpassen. Es geht nicht darum, solche Hersteller an den Pranger zu stellen, sondern es soll darauf hingewiesen werden, dass bei einer entsprechenden Tool-Auswahl sehr genau darauf geachtet werden muss, wie weit die MDA-Aspekte innerhalb eines Werkzeuges wirklich berücksichtigt wurden. Denn betrachtet man das Problem von der rein technischen Seite, so ist bereits Microsofts "Powerpoint" in gewisser Hinsicht ein MDA-Werkzeug, schließlich lässt sich damit ein plattformunabhängiges Modell erstellen - wenn auch mit viel Aufwand und wenig Nutzen. Dies verdeutlicht auch die Bandbreite von derzeitigen MDA-Werkzeugen - angefangen von reinen Malwerkzeugen bis hin zu Produkten, wo man überhaupt nicht mehr händisch in den Code eingreift und ein und dieselbe Applikation für unterschiedliche Plattformen auf Knopfdruck aus dem Modell generiert. Auch Änderungen werden niemals am Code direkt, sondern ausschließlich im Modell ausgeführt.

Basis aller Werkzeuge ist dabei die Unfied Modeling Language (UML). Die Version 2.0, die mittlerweile verabschiedet wurde, berücksichtigt mit ihren neuen Features besonders MDA. Insgesamt war es aber ein langer Weg von den ersten objektorientierten Schritten mit UML 0.8 (plattformspezifisch) im Jahre 1995 bis zur plattformunabhängigen Model Driven Architecture im Einklang mit UML 2.0 im Sommer 2003.

Einsatz in der Praxis

Die OMG verleiht in regelmäßigen Abständen Awards - hier werden Projekte hinsichtlich Innovationen bei der Verwendung von Methoden und Technologien analysiert und prämiert. In diesem Jahr konnte die Deutsche Bank Bauspar durch den Einsatz von MDA den ersten Platz erzielen, auch die Österreichische Bundesbahn erhielt eine Auszeichnung. Dies belegt, dass MDA keine graue Theorie ist, sondern tatsächlich genutzt wird.

Wie muss man sich den praktischen Einsatz von MDA vorstellen? Im Idealfall entwirft man also mit Hilfe eines Werkzeugs die Logik der Anwendung in einem Modell, und zwar zunächst Technologie-unabhängig. Anschließend erweitert man diesen Entwurf um technologiespezifische Informationen und kann auf Knopfdruck je nach Bedarf eine J2EE- oder .NET-Applikation erzeugen. Das ist leider nur die Theorie - denn irgendwann kommt immer der Punkt, wo auch im Modell plattformspezifische Aspekte integriert werden müssen. So unterscheidet sich zum Beispiel die Nutzung von Web-Services bei J2EE deutlich von jener bei .NET.

Cartridges als Hilfsmittel

Eine Möglichkeit, den Anwender von der Komplexität unterschiedlicher Technologien zu abzuschirmen, stellt das Konzept der Cartridges dar. Dabei handelt es sich um ein plattformspezifisches Hilfsmittel. Die Cartridges beinhalten also Wissen über technische Spezifika und Generierungsvorschriften, wie ein Modellelement für eine bestimmte Technik abzubilden ist - etwa als C++- oder Java-Klasse oder als Enterprise Javabean.

Derartige Cartridges können von Herstellerseite nur in einer Art Basisversion ausgeliefert werden, ihre Reife erhalten sie in der kontinuierlichen Verwendung und Anpassung durch den Endanwender. Mittlerweile existiert auch schon eine Art Community oder Open-Source-Portal für den Austausch solcher Cartdriges, mehr Informationen dazu sind auf www.mda-at-work.com verfügbar.

Ausblick

MDA ist noch eine sehr junge Technologie, die alleine dadurch, dass sich UML 2.0 zum Politikum entwickelt hat und immer noch nicht offiziell verabschiedet wurde, auf etwas unsicheren Füßen steht. Besonders Softwarefirmen müssen hier noch viel Arbeit in die entsprechenden Werkzeuge investieren. Will man wirklich eine (notwendige) Unabhängigkeit von J2EE und .NET erreichen, ist MDA aber der richtige Weg. (ws)

*Gerhard Versteegen ist Inhaber von High Level Marketing Consulting in München. Der Autor hält auf dem iX-Kongress (www.ix-kongress.de) einen Vortrag zu diesem Thema.

Angeklickt

Viele Unternehmen können nicht ausschlie?lich Java oder nur .NET einsetzen, sondern werden beide Systeme nutzen. In diesem Fall ist es günstig, wenn bei der Softwareentwicklung plattformspezifische Festlegungen erst möglichst spät erfolgen. Die Model Driven Architecture repräsentiert ein Verfahren, das die plattformübergreifende Programmierung vereinfachen kann.

Drei Klassen von Werkzeugen

Die OMG unterscheidet generell zwischen drei Werkzeugklassen:

- Die reinen Malwerkzeuge für Diagramme der Unified Modeling Language (UML). Ein Beispiel dafür wäre "Aris E-Business Workbench" von IDS Scheer oder "Visio" von Microsoft.

- Die herkömmlichen Case-Werkzeuge, die plattformspezifischen Code generieren. Beispiel wären hier "Together Controlcenter" von Borland oder "Innovator" von MID.

- Die modernen MDA-Werkzeuge, die meist auf Case-Werkzeugen aufsetzen. Typischerweise unterstützen sie beide Modelle (plattformspezifisch und plattformunabhängig) unterstützen und anschließend Code erzeugen, der für eine bestimmte Zielumgebung optimiert ist. Beispiele sind "Arcstyler" von Interactive Objects und "Tau Generation 2" von Telelogic.