Model-Driven & Service-Oriented Architectures (MDA + SOA)

Model-Driven & Service-Oriented Architectures (MDA + SOA)

Posts 1-3 of 3
  • Wolfgang Neuhaus
    Wolfgang Neuhaus    Premium Member   Group moderator
    The company name is only visible to registered members.
    Service Oriented Architecture - eine Kurzvorstellung
    Hallo!

    Wer sich bereits einmal mit dem Thema SOA beschäftigt hat, dem ist sicherlich aufgefallen, dass Service orientierte Architekturen dazu neigen, schematische Implementierungsmuster hervor zu rufen.

    Da diese dazu neigen, sich besonders gut und effizient generieren zu lassen, halten wir eine Diskussion über SOA im Kontext von MDA für notwendig und sinnvoll.

    Eine kurze Definition für SOA findet man unter http://de.wikipedia.org/wiki/Service_Oriented_Architecture

    Ausführlicher wird's unter http://www.looselycoupled.com/stories/2003/tactics-soa-infr0...

    Und unter http://www.soai.org findet man eine in Deutschland im Aufbau befindliche Community zum Thema.

    In diesem Forum würden wir gerne praktische Erfahrungen diskutieren, die mit MDA und SOA in Kombination gemacht worden sind. Darüber hinaus wollen wir aber auch Trends diskutieren, wohin die Reise gehen könnte.

    Also, Feuer frei!

    Wolfgang Neuhaus
    • 06 Dec 2004, 4:33 pm
  • Post visible to registered members
  • Mohammed Unewisse
    Mohammed Unewisse    Premium Member
    The company name is only visible to registered members.
    Re^2: Service Oriented Architecture - und unter der Motorhaube?
    Hallo Herr Ostrowski,
    Ihr Beitrag hat mir sehr gut gefallen, da er auf einen Bereich verweist, der bisher in den praktischen MDA und SOA Ansätzen eher Stiefmütterlich behandelt wird. Dem Bereich, dass eine Komponente (sei es nun ein Service oder eine herkömmliche Applikation) nicht nur fachliche Geschäftsprozesse abdecken, sondern auch mit dem eigenen Lebenszyklus in IT-Service-Managementprozesse integriert werden muss.
    Es gibt ein Leben nach der Auslieferung. Innerhalb des gesamten Lebenszyklus von IT-Systemen erfordern der Betrieb und notwendige Anpassungen und Wartungen 70-80% des Kosten- und des Zeitaufwands.
    Mittels MDAD (ModelDriven Analyse und Design) und MDSD (ModelDriven SoftwareDevelopment) haben wir Softwareentwickler mittlerweile Werkzeuge und Ansätze in der Hand, die uns auf den Weg zur industriellen Softwarefertigung ein ganzes Stück voran gebracht haben, bzw. bei stärkerer Akzeptanz, bringen werden.
    Mittels MDxx generieren wir EARs, Webservices usw. und evtentuell auch noch ein paar JMX-Beans und das ganze lassen wir dann auf den IT-Betrieb los. Innerhalb des IT-Betriebs muss dann leider oft wieder auf die alte handwerkliche Arbeitsweise (vi läßt grüßen) zurückgegriffen werden, um die Komponente durch ihren Lebenszyklus zu führen.
    Um einen hohen Reifegrad einer Service orientierten Architektur erreichen zu können müssen diese IT-SoftwareLifecycleManagement-Prozesse (z.B.: Monitoring, Upgrade, Installation – Deinstallation, Konfiguration Fehleridentifikation und -behebung) vereinheitlicht und schon bei der Softwareentwicklung berücksichtigt werden, da Ansonsten der Betrieb eines auf Services orientierten Systems zum Flaschenhals wird.
    Das spricht aber nicht gegen Ansätze wie MDA, sondern führt vielmehr dazu, dass der ModelDriven Gedanke sich von reinen (fachlichen) Design-Time einer Komponente auch auf die (technische)Runtime ausdehnen muss.
    Modelle haben ihren Vorteil darin, dass sie, von für ihren Stakeholder unwichtigen Details, abstrahieren und somit die Komplexität eines Systems verbergen können. Standardisierte (sei es nun Firmenintern oder auch größer) Modellsprachen führen darüber hinaus noch zu einer Vereinheitlichung von Abläufen und zu einer Produktivitätsteigerung.
    Der wichtigste Stakeholder ist sicherlich der Anforderungsteller auf der Fachseite, diesen berücksichtigen heutige MDA-Tools schon recht gut. MDA-Tools unterstützen dabei die fachlichen Aspekte zu modellieren und von den technischen Details zu abstrahieren. Die technischen Details werden dann zu 95% generiert.
    Was dabei evtl. übersehen wird ist, dass für den IT-Betrieb, der zumindestens in größeren Unternehmen ebenfalls ein wichtiger Stakeholder ist, genau diese technischen Details die Details sind mit denen er arbeitet. Was also MDA langfristig bieten sollte, sind verschiedene Modelle auf ein System(service), die dann zu einem ganzen Zusammengeführt werden können.
    Die Modelle, die den fachlichen Aspekt abdecken, werden zum großen Teil in Code aufgehen und stellen daher Modelle zur Design-Time dar. Modelle für den IT-Betrieb haben dahingehend einen anderen Charackter, dass sie auch nach der Auslieferung immer wieder angepasst werden müssen. So müssen die einzelnen Service-Modelle in übergeordnete Systemlandschaftsmodelle integriert werden, deren Informationen zu Designzeit noch nicht vorhanden sind. Sie stellen Modelle zur Runtime dar.
    Ideal wäre es, und da komme ich wieder auf Ihren Beitrag zurück, wenn solche Modelle von den Integrationsplattformen und –frameworks gelesen und „verstanden“ werden könnten und zum Beispiel Konfigurationänderungen an einem Service modell basiert vorgenommen werden könnten.
    Es wird ein Unterscheidungsmerkmal von den Integrationsplattformen (und ihren Entwicklungsumgebungen) sein, wie weit sie dieses Modelbasiertes IT-ServiceManagement unterstützen werden. Mit einer schnellen Standardisierung in diesem Bereich rechne ich persönlich aber eher nicht.
    Auch wenn er nicht von uns (SAP AG) ist, finde ich Microsofts Ansatz, wie er unter http://www.microsoft.com/windowsserversystem/dsi/dsiwp.mspx
    beschrieben wird, was den Bereich eines MetaModells für den Systembetrieb und die kontinuierliche Integration des Modells vom VisualStudio bis in die Management-Produkte angeht recht interessant und auch lesenswert, auch wenn vieles darin wohl noch Visionen sind.

    Mit freundlichen Grüßen aus Walldorf und ein schönes Wochenende

    Mohammed Unewisse

    P.S.: An die Schweden and friends : Bis nächsten Samstag auf dem Weihnachtsmarkt;-)
    • 10 Dec 2004, 07:59 am