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

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

Posts 1-4 of 4
  • Marcel Donges
    Marcel Donges    Premium Member
    The company name is only visible to registered members.
    Ist es nicht zu ruhig um SOA und MDA?
    Analysten haben das Jahr 2006 zum Jahr der SOA gemacht.
    MDA ist der reifste Standard, um SOAs (Same Old Architectures ;-) zu entwickeln.

    Ich würde mich über Meinungen von NICHT-Herstellern freuen...

    Was hindert an SOA und / oder MDA?
    Was fehlt?
    Welche elementaren Bedürftnisse bleiben ungestillt?
    • 23 Nov 2006, 11:08 am
  • Post visible to registered members
  • Marcel Donges
    Marcel Donges    Premium Member
    The company name is only visible to registered members.
    Re^2: Ist es nicht zu ruhig um SOA und MDA?
    Hallo Herr Armbruster,

    schön, dass Sie so schnell reagiert haben. Est ist also doch nicht so ruhig? Aber es gibt wohl viel Verunsicherung...

    Vielleicht sollte ich meine Definition von SOA lieber hier ablegen:

    Definition SOA (06.12.2004, 21:02) 564 Abrufe heute
    https://www.xing.com/app/forum?op=showarticles&id=195096

    SOA und MDA - was denn jetzt? (01.09.2005, 09:12) 295
    https://www.xing.com/app/forum?op=showarticles&id=699765


    Ich möchte ihren Artikel mal unkommentiert stehen lassen und erfahren, welche weitern Meinung zu diesem Thema existieren, um mal eine Art Stimmungs-Sammlung zu starten.

    Definitiv sind für mich alle Ihre Anregungen sehr gut nachvollziehbar und ich bin mir sicher, dass es weiteren Teilnehmern so oder ähnlich geht...
    • 23 Nov 2006, 12:02 pm
  • Michael Kunz
    Michael Kunz    Premium Member
    The company name is only visible to registered members.
    Re^3: Ist es nicht zu ruhig um SOA und MDA?
    Hallo,
    interessante Diskussion, vielleicht kann folgendes weiterhelfen:

    >1. es gibt keine einheitliche und griffige definition von SOA. jeder kann hierunter vestehen was er möchte.
    >aus vertrieblicher sicht ist dies optimal. kann man doch mit diesem thema werbung betreiben ohne
    >viel an den eigenen strukturen zu ändern. man muss nur eine passende definition (er)finden.
    Das kann man nun aber wirklich nicht SOA vorwerfen: Natürlich kann man für jedes Thema (fast) beliebig unsinnige Definitionen erfinden (und wenn genug Geld im Spiel ist - und das ist sowohl für Werkzeughersteller, als auch für Consulting-Unternehmen als auch für IT-Bereiche bei diesem Thema definitiv so - wird auch einiges investiert, dieses zum eigenen Vorteil zu tun) - dagegen schützt nur, daß sich langfristig hoffentlich eher der Gebrauch "sinnvoller" Definitionen durchsetzt. Zu den sinnvollen (weil erkenntnisbringenden) Definitionen ist eindeutig nachfolgende aus einem bereits 2004 erschienen Buch zu zählen: "A Service-Oriented Architecture (SOA) is a software architecture that is based on the key concepts of an application frontend, service, service repository, and a service bus. A service consists of a contract, one or more interfaces, and an implementation." Weitere Inhalte nachzulesen in Krafzig/Banke/Slama: Enterprise SOA

    >2. aufgrund der o.g. fehlenden standards, gibt es natürlich auch keine standards bezüglich der schnittstellen.
    >derzeitige "SOA" lösungen sind mehr oder weniger proprietär und somit nicht "offen".
    Ich gebe zu, daß das Thema Standards im Umfeld SOA hinlänglich komplex und auf den ersten Blick verwirrend ist, aber ich kann diese Aussage ü b e r h a u p t nicht nachvollziehen. Insbesondere wenn man bedenkt, wie reale Best-Practices im Bereich SOA und MDA aussehen (sollten). Das kann man aber leider jetzt hier nicht auf die schnelle ausdiskutieren...

    >3. je weiter der abstraktionsprozess in der IT voranschreitet, desto größer werden die probleme auf der
    >grundlegenden und technischen ebene (z.b. performance bei massenverarbeitung).
    >bei dem SOA ansatz ist der abstand zwischen technik und business-prozess schon so groß daß auf dem
    >weg durch die verschiedenen schichten sehr viel power für redundanzen, protokolle, infrastruktur,
    >administration, ... verloren geht.
    >aus rein theoretischer sicht ist SOA sicher sehr reizvoll. jeder der halbwegs vernünftige software entwickelt,
    >wird versuchen modular vorzugehen. dieses vorgehen erhöhte auch schon vor 30 jahren (ohne SOA) die
    >wiederverwendbarkeit von softwaremodulen.
    Seit Erfindung des MDSD kann glücklicherweise bei praktisch allen Problemen zwischen den Paaren Generalisierung+Interpretation zur Laufzeit auf der einen Seite und Generierung/Compilierung gewählt werden. Gute generative Ansätze haben unter realistischen Bedingungen in der Regel k e i n e relevanten Laufzeitauswirkungen. Nur zur Erinnerung an dunkle Vorzeiten: Diese Diskussionen wurden auch schon eine bis zwei Abstraktionsebenen "niedriger" geführt (1. Sind Frameworks "performant"? 2. Sind Compiler performant?). In den mir bekannten realen Projekten wird diese Diskussion heute dort nicht mehr geführt - und um MDA/MDSD und die mit SOA u. ä. eingeführten Abstraktionen hoffentlich bald auch nicht mehr. In der Realität ist das Problem doch viel eher, daß Konzepte nicht richtig eingesetzt werden (und da kann man zugegebenermaßen vieles falsch machen, und ja: Softwareentwicklung in größeren Projekten ist heutzutage eine ernstzunehmend komplexe Angelegenheit).

    >4. granularität der services: ich verkünde bei unserer nächsten konferenz, daß unsere ERP anwendung auf einer
    >SOA architektur basiert. wir haben die services "Auftragsabwicklung", "Materialwirtschaft", "Finance", "Personal".
    >alle diese services sind über schnittstellen quasi lose gekoppelt. das klingt stark nach SOA!
    >allerdings hat man bei dieser granularität das problem, daß die abhängigkeiten zwischen den einzelnen
    >services nicht vollständig über schnittstellen gelöst werden können. die auftragsabwicklung hat bestimmte
    >anforderungen an die finanzwirtschaft (und umgekehrt), die über schnittstellen nicht mehr zu lösen sind.
    >beispiel: bei der auftragsabwicklung können sie mehrere rechnungsempfänger zuordnen, die im in- und
    >ausland liegen können. die finanzwirtschaft kann aber aufträge die rechnungsempfänger in
    >unterschiedlichen ländern haben, nicht verarbeiten.
    >somit müssen funktionale einschränkungen des services "finanzbuchhaltung" in die auftragsabwicklung
    >integiert werden. das widerspricht dem SOA ansatz!
    Bei "sinnvoller" Definition (s. 1.) ist das dann k e i n e SOA (nicht ein "bißchen" keine, sondern gar keine SOA) - egal zu welcher Notlüge ihr jeweiliger Softwareanbieter auch immer greifen mag...

    Gruß
    Michael Kunz
    This post was modified on 28 Nov 2006 at 11:14 pm.
    • 28 Nov 2006, 10:22 pm