SOA (Service Oriented Architecture)

 + andere TechDocs
+ SOAP Webservices
+ SOA-Bücher
+


Kaum ein anderes Thema verspricht so großes Verbesserungspotenzial für die Geschäftsprozesse und die IT-Architektur wie SOA. Aber SOA erfordert auch besonders große Anstrengungen: organisatorisch, bezogen auf die Geschäftsprozesse und in der IT.



Inhalt

  1. Begriffe im SOA-Umfeld
  2. Entscheidung für SOA
  3. Erfolgsfaktoren für eine SOA
  4. Governance
  5. SOA-Referenz-Stack
  6. ESB (Enterprise Service Bus)
  7. OSGi, SCA, JBI, WCF
  8. Serviceorientierung versus Objektorientierung
  9. Lose Kopplung versus unternehmensweites Datenmodell
  10. Enge Kopplung versus lose Kopplung
  11. Serviceentwurf: Top-down versus Bottom-up
  12. Technischer Schnittstellen- und Serviceentwurf
  13. MEP (Message Exchange Pattern)
  14. Security-Stack
  15. Webservices
  16. Java-Frameworks für Webservices
  17. Open-Source-SOA-Komponenten
  18. BPEL-Editor, SOA-Entwicklungsumgebung und SOA-System
  19. Links auf weiterführende Informationen



Begriffe im SOA-Umfeld

SOA
Service Oriented Architecture (Dienstorientierte Architektur).
SOA ist eher ein Paradigma (Denkmuster) als ein exakt definierbarer Begriff. Es gibt keine harten Kriterien, anhand derer exakt beurteilt werden kann, ob eine Architektur oder ein System dem SOA-Architekturstil entspricht. Als wichtige Aspekte werden meistens genannt:
- Auf Services basierendes Unternehmens- und IT-Architekturkonzept
- Agil änderbare Geschäftsprozesse durch einfach und flexibel verknüpfbare Services
- An fachlichen Geschäftsprozessen orientierte IT-Services (Business-IT-Alignment)
- Autarke, lose koppelbare und austauschbare Services
- SOA vereint oder unterstützt wichtige Ziele von CBD (Component Based Development), EAI (Enterprise Application Integration) und BPM (Business Process Management).
Eine SOA besteht im Groben meistens aus folgenden Teilen (siehe auch SOA-Referenz-Stack):
- Anwendungs-Frontend (Application Level, Development Tools, BPEL-Engine, BPM)
- Service Registry (bzw. Repository)
- Service-Bus (z.B. ESB)
- Services
Service
Im SOA-Umfeld sind mit Services Software-Komponenten gemeint, die zu Geschäftsprozessen kombiniert werden können. Die Service-Komponenten (Funktionsbausteine, Module, Anwendungen) werden über öffentliche Schnittstellen (Interfaces) aufgerufen, oft über ein Netzwerk, eventuell sogar über das Internet.
Anders als Bibliotheken oder andere Komponenten werden Services von den Nutzern lediglich aufgerufen, aber nicht in das aufrufende System eingebettet.
SOA-Services sind bevorzugt zustandslos und kommunizieren oft über SOAP-Webservices oder Messaging-Systeme, aber es werden auch andere Kommunikationsarten verwendet (z.B. REST).
Bei für SOA verwendeten Services kann nicht von fest definierten Konsumenten ausgegangen werden. Deshalb müssen SOA-Services robuster und genauer spezifiziert und dokumentiert sein und es wird ein Versionierungskonzept benötigt.
Zum Serviceentwurf siehe: Top-down versus Bottom-up und Technischer Schnittstellen- und Serviceentwurf.
Registry und Repository
Verzeichnisdienst und Speicherung von Metainformationen zu den Services, beispielsweise: Schnittstelle, Anbieter, IP-Adresse, Port, fachliche Klassifikation und Dokumentation, Regeln, Einschränkungen, Transaktionsverhalten, Versionierung, Bezahlung, Zugriffsrechte, Sicherheit, SLA (Service Level Agreement).
Die Abgrenzung zwischen Registry und Repository ist nicht einheitlich, aber meistens gilt:
- Das Repository repräsentiert eher die fachliche Sicht und die Registry eher die technische Sicht.
- Das Repository enthält weiter gehende Informationen und Daten als die Registry.
- Die Registry wird vor allem zur Verwaltung der Services zur Laufzeit verwendet (z.B. Adressen, Policies).
- Das Repository enthält auch Information, die etwa zur Entwicklungszeit oder für das Management benötigt werden (z.B. Dokumentation, Versionierung, Auditing, Logging).
ESB
Enterprise Service Bus.
Ein ESB stellt eine Middleware-Integrationsinfrastruktur dar und wird oft als Grundlage für SOA verwendet. Vorrangige Aufgabe ist, die verschiedenen Services möglichst flexibel zu verknüpfen ("Service-Mediation"). Die Services werden meistens per SOAP-Webservice-Schnittstellen oder über Messaging-Systeme (MOM, Message-Oriented Middleware) gekoppelt und Legacy-Systeme werden über Konnektoren eingebunden. Dabei erfolgt intelligentes Routing und es werden Datentransformationen und Funktionen für Transaktionen, Sicherheit und Verwaltung ausgeführt. Das ESB-System kann von einer BPEL-Engine gesteuert werden, die mit BPEL-XML-Dokumenten beschriebene Geschäftsprozesse ausführt.
BAM
Business Activity Monitoring.
Betriebswirtschaftliche Überwachung der Geschäftsprozesse auf Basis von Kennzahlen (KPI, Key Performance Indicators).
BPM
a) Business Process Management
Geschäftsprozesse-Management. Dazu gehören vor allem die Verwaltung von Geschäftsprozessen, aber auch die technische Ausführung von Prozessen (wie in einem Workflow Management System) sowie Analyse, Design, Dokumentation, Planung, Implementierung, Monitoring von Prozessen und Geschäftsprozessmodellierung.
Während BPEL zumindest bis zur Version 2.0 keine Möglichkeit bietet, Interaktionen mit dem Anwender in Prozesse einzubinden, so ist dies mit Workflow- und BPM-Systemen möglich.
b) Business Process Modeling
Geschäftsprozessmodellierung: Ablaufgestaltung, Darstellung und Beschreibung der Geschäftsprozesse.
BPMN
Business Process Modeling Notation.
OMG-Standard einer grafischen Beschreibungssprache für Geschäftsprozesse.
BPMN kann (mit Hilfe von Zusatzinformationen) in eine Ausführungssprache wie BPEL überführt werden.
Alternativen zu BPMN können sein: UML-Aktivitätendiagramm, Aris EPK (Ereignisorientierte Prozesskette), VKD (Vorgangskettendiagramm), PAP (Programmablaufplan), IDEF0 (Integration Definition Language), Petri-Netz.
BPEL
Business Process Execution Language.
OASIS-Standard einer auf XML basierenden Sprache zur Beschreibung und Orchestrierung von Geschäftsprozessen, deren Aktivitäten durch Webservices implementiert sind. Das BPEL-XML-Dokument kann von einer BPEL-Engine ausgeführt werden.
Genaueres finden Sie unter Web Services Business Process Execution Language Version 2.0.
XPDL
XML Process Definition Language.
WfMC-Standard für eine Workflow-Beschreibungssprache. Ist nicht auf Webservices beschränkt. Konkurriert mit BPEL.
WS-*
Auf Webservices basierende Standards, zum Beispiel:
WS-Addressing, WS-Policy, WS-Security, WS Reliable Messaging, WS Transactions Framework.
Mittlerweile ist die Menge der über 100 WS-*-Standards kaum noch zu überblicken. Erschwerend kommt hinzu, dass sich viele Standards noch ändern, zu anderen Standards konkurrieren oder sogar nicht verträglich sind. Einige wichtige Webservices finden Sie weiter unten erläutert.
SOAP
(Buchstaben haben keine Bedeutung mehr, früher: Simple Object Access Protocol).
W3C-Standard für XML-basiertes Nachrichtenformat für Webservices.
Eine Einführung finden Sie unter SOAP und Programmierbeispiele unter SOAP Web Services mit JAX-WS.
WSDL
Web Service Description Language.
W3C-Standard zur XML-basierten Schnittstellenbeschreibung von SOAP-Webservices.
Weiteres zu WSDL finden Sie unter soap.htm und jee-jax-ws.htm.
XML
Extensible Markup Language.
W3C-Standard zur Textdarstellung strukturierter Daten.
Weiteres zu XML finden Sie unter java-xml.htm.
XSD
XML Schema Definition.
W3C-Standard zur Definition der Art und Struktur von XML-Dokumenten und den enthaltenen Elementen.
EDA, CEP
Event-driven Architecture beziehungsweise Complex Event Processing.
Auch als "SOA 2.0" bezeichnete Weiterentwicklungsidee einer konsequent ereignisgesteuerten Kommunikation zur größtmöglichen Entkopplung.
Während bei SOA die Services eher in bestimmten Reihenfolgen durchlaufen werden, werden bei EDA / CEP mehrfache asynchrone Ereignisse in nicht festgelegter Reihenfolge parallel bearbeitet.


Entscheidung für SOA

Zur Motivation für die Einführung einer SOA werden häufig folgende Vorteile genannt:

Natürlich gibt es auch Nachteile und Risiken:

Ob SOA die Komplexität erhöht, wird unterschiedlich beurteilt:

Mögliche Gründe für langfristige Kosteneinsparungen:

Die Einsparpotenziale werden sehr unterschiedlich eingeschätzt. Während [Wolfgang Keller] die Einsparungen im IT-Bereich mit maximal 5 bis 10 % des IT-Budgets ansetzt, zitiert [Jan vom Brocke] Studien, die (zumindest in Einzelfällen) Kosteneinsparungen von über 30 % und ROIs von über 400 % nennen.



Erfolgsfaktoren für eine SOA

Als Treiber für eine erfolgreiche SOA-Einführung werden häufig folgende Faktoren genannt:

[Dirk Krafzig, Karl Banke und Dirk Slama] betonen als die "Vier Säulen für den Erfolg" besonders die Wichtigkeit von:



Governance

Eine Unternehmens-Governance stellt ein System dar, nach dem ein Unternehmen gesteuert und kontrolliert wird. Dies umfasst Managementaktivitäten und Organisationsstrukturen.

Eine IT-Governance beschäftigt sich mit den Fragen:

Weiteres zu IT-Governance finden Sie zum Beispiel unter: http://www.itgi.org.

Eine SOA-Governance ist ein Teil der IT-Governance und dient dazu, die SOA-Architektur zu steuern und zu vereinheitlichen. Dabei können drei Schichten unterschieden werden:

  1. Strategische Schicht (Macro Governance):
    Einbindung in die Geschäftsführung, Treffen von grundsätzlichen strategischen Entscheidungen (z.B. Business Process Outsourcing).
  2. Operationale Schicht:
    Koordination der Aktivitäten, um Geschäftsprozesse und Abläufe zu optimieren.
  3. Technische Schicht (Micro Governance):
    Verwaltung von Services und Assets, eventuell Tool-unterstützt, zum Beispiel Versionierung, Repository, Deployment, Betrieb, Lebenszyklus.

[Joachim Schelp und Matthias Stutz] untergliedern die SOA-Managementaktivitäten in drei Bereiche:

  1. Implement SOA:
    SOA Enablement (Voraussetzungen für eine SOA-Einführung), SOA Portfolio Management, Richtlinien für das SOA Service Design, SOA Service Build
  2. Manage SOA:
    SOA Repository, SOA Maintenance, Versionierung, Abhängigkeiten, SOA Funding (Verrechnung)
  3. Control SOA:
    SOA Controlling, SOA Service Level Management, Kennzahlen, SOA Quality Management, SOA Risk & Security Management

[Nicolai Josuttis] beschreibt die Aufgaben und Aspekte der SOA-Governance folgendermaßen:

Für [Mohamad Afshar] von Oracle sind die acht wichtigsten "Key Leverage Points" im Oracle-Governance-Modell:

SOA-Governance-Oracle



SOA-Referenz-Stack

[Dirk Krafzig, Karl Banke und Dirk Slama] schlagen folgende grobe Untergliederung einer SOA vor:

Eine Strukturierung der SOA in hierarchische Schichten und einen möglichen SOA-Referenz-Stack beschreiben [Jürgen Dunkel und Arne Koschel] folgendermaßen (die grau hinterlegten Komponenten sind in der Regel in einer ESB-Middleware enthalten):


          Application Level (Development Tools)           
                                                          
                    Service Discovery                     
                                                          
             Service          Orchestration &     Service 
Security     Container        Process Engine      Mana-   
                                                  gement  
          Service Connectors and Transformation           
                                                          
              QoS        Routing      Naming              
                                                          
               Communication                              
               (Transport + Network Level)

Die Strukturen der kommerziellen SOA-Systeme von IBM, SAP, Oracle und Microsoft sind bei [Daniel Liebhart] beschrieben. Im gleichen Buch werden auch die beiden wichtigsten SOA-Referenzmodelle OASIS Reference Model for Service Oriented Architecture und W3C Web Services Architecture erläutert.



ESB (Enterprise Service Bus)

Oft basiert SOA auf einem ESB. Der ESB stellt eine technische Middleware-Integrationsinfrastruktur zur Vernetzung der Services und weiterer technischer Beteiligter dar.

Der ESB kann als Fortsetzung von EAI (Enterprise Application Integration) gesehen werden. Während bei EAI der Fokus eher auf der technischen Anbindung von Systemen und Applikationen liegt, unterstützt der ESB darüberhinaus als Grundlage für SOA eine agile Gestaltung der fachlichen Geschäftsprozesse ("Bei EAI integriere ich hinterher, bei SOA mache ich mir vorher Gedanken").

Ein ESB-System kann folgende Funktionen beinhalten:

[Christoph Mathas] stellt den ESB als ein "Service-Mediation-System" dar, dessen allgemeinen Schichtenaufbau er folgendermaßen beschreibt:

                                                                        ..................
                           Prozessumsetzung                            
                                                                       
                                                                         Interoperabilität
                           Nachrichten-Mediation/Transformation        
                                                                       
                                                                        ..................
                                Nachrichten-Metainformationen          
                                (Systemerweiterungen)                  
                                                                         Integration
                                Nachrichten-Binding                    
Admin.    Service                                                      
und       Reposit.                                                      ..................
Verwalt.                        Service-Adressierung                   
                    Service                                            
                    Registry
                                Besondere Systemmerkmale               
                                (Policies, Transaktionen, Sicherheit)  
                                                                         Kommunikation
                              Direkter   Nachrichtenübermittlung       
                              Schnitt-   (Transport-Encoding)          
                              stellen-
                              aufruf     Dienstkonnektivität           
                                         (Transportprotokoll-Binding)  
                                                                        ..................

Während bei EAI die beiden unterschiedlichen Topologien "Hub & Spoke" (dedizierter zentraler Server als Hub) und "Bus" (auf die verschiedenen Systeme verteilte Software-Bibliothek, Kommunikation über so genannten "Software Bus") zum Einsatz kommen, ist beim ESB fast immer die letztere Variante gemeint.

Beachtet werden muss, dass der ESB oft nicht aus nur einer einzigen Technologie besteht, sondern viele verschiedene Produkte und Konzepte beinhalten kann.



OSGi, SCA, JBI, WCF

Verschiedene Komponentenarchitekturen und Service-Bus-Konzepte sollen die Entwicklung von Services vereinheitlichen. Einige dieser Standards ergänzen sich, andere konkurrieren miteinander:

Weiteres hierzu finden Sie im JavaSPEKTRUM 05/2007 und bei [Christoph Mathas].



Serviceorientierung versus Objektorientierung

Serviceorientierung im Sinne von SOA steht in gewisser Weise im Widerspruch zu den Paradigmen der objektorientierten Programmierung (OOP):

Trotzdem widersprechen sich Serviceorientierung und Objektorientierung nicht: Beim Zusammenspiel der SOA-Komponenten bietet die Serviceorientierung die größeren Vorteile, aber innerhalb der SOA-Komponenten kann die objektorientierte Programmierung ihre Stärken ausspielen.



Lose Kopplung versus unternehmensweites Datenmodell

In den 80er und 90er Jahren wurde vielfach ein globales Datenmodell für alle Daten des Unternehmens angestrebt, häufig EDM (Enterprise Data Model) genannt.

Viele Autoren bezeichnen heutzutage diese Versuche als gescheitert (z.B. [Dirk Krafzig, Karl Banke, Dirk Slama], [Jens Coldewey], [Thomas Müller]).

[Markus Völter] und [Nicolai Josuttis] zweifeln nicht nur die Erreichbarkeit des unternehmensweiten Datenmodells an. Sie postulieren sogar, dass dies auch gar nicht sinnvoll wäre, da solche Datenmodelle groß, komplex, unüberschaubar und schwer wartbar werden, und jede Änderung großen Aufwand bedeutet oder durch Workarounds umgangen werden muss. Unternehmensweite Datenmodelle können das wichtige SOA-Ziel Agilität einschränken. Völter schlägt deshalb eine Domänen-Struktur vor.

[Roman Roth] empfiehlt eine gezielte verwaltbare Datenredundanz, wenn dadurch SOA-Services besser entkoppelt und Abhängigkeiten vermieden werden können, auch wenn dadurch die vollständige referenzielle Datenintegrität eventuell nicht mehr konsequent gewährleistet werden kann.



Enge Kopplung versus lose Kopplung

Lose Kopplung ist ein wesentliches Merkmal einer SOA (und allen großen verteilten Systemen). [Nicolai Josuttis] listet folgende typische Unterschiede zwischen enger und loser Kopplung auf (es müssen nicht alle Eigenschaften genau so implementiert sein):


 Enge KopplungLose Kopplung
Physikalische VerbindungPunkt-zu-Punktüber Vermittler
Kommunikationsstilsynchronasynchron
Datenmodellkomplexe gemeinsame Typennur einfache gemeinsame Typen
Typsystemstrengschwach
Bindingstatischdynamisch
Plattformspezifikastark / vielschwach / wenig
Interaktionsmusterüber komplexe Objektbäume navigierendatenzentrierte autonome Nachrichten
Transaktionssicherheit2PC (Two-Phase-Commit)Kompensation
Kontrolle fachlicher Logikzentrale Kontrolleverteilte Kontrolle
Deploymentgleichzeitigzu verschiedenen Zeitpunkten
Versionierungexplizite Upgradesimplizite Upgrades
Abhängigkeitenviele engewenige explizite
Performanceschlechterbesser
Ausfallsicherheitschlechterbesser
Komplexitätgeringerhöher


Serviceentwurf: Top-down versus Bottom-up

Damit sich die Services an fachlichen Geschäftsprozessen orientieren (Business-IT-Alignment), wird zur Serviceidentifikation häufig eine Top-down-Vorgehensweise empfohlen. [Roman Roth] empfiehlt hierfür den wertschöpfungsorientierten Serviceentwurf, auch AOS (Added value Oriented Service) genannt, der verkürzt in etwa so abläuft:

  1. Das Geschäftsprozessmodell (Abläufe, Arbeitsschritte) und das Geschäftsdomänenmodell (fachliche thematische Zuständigkeiten, statische Zusammenhänge) werden erstellt bzw. aktualisiert.
  2. Anhand des Geschäftsprozessmodells werden Geschäftsprozessabschnitte ermittelt, die innerhalb der Grenzen einer Geschäftsdomäne ablaufen.
  3. Innerhalb dieser Geschäftsprozessabschnitte werden Sequenzen von zusammenhängenden Aktivitäten ermittelt, die genügend Wertschöpfung und Geschäftsnutzen aufweisen und als Prozessservice in Frage kommen.
  4. Zu diesen potenziellen Prozessservices werden die fachlichen, organisatorischen und technischen Beziehungen und Abhängigkeiten bestimmt.
  5. Eventuell stellt sich heraus, dass die bestehenden Prozessabläufe nicht optimal sind und ein Reengineering erfolgen sollte.
  6. Die Prozessservices werden mit dem Ziel von klar definierten Zuständigkeiten, starker Kohäsion und geringer Kopplung zu anderen Services konzipiert.
  7. Die für die ermittelten fachlich orientierten Prozessservices benötigte IT-Unterstützung wird untersucht.
  8. Die zur IT-Unterstützung benötigten oft eher technisch orientierten Softwareservices werden konzipiert.

Allerdings gibt es in der Praxis Widerstände, die eine Mischung aus Top-down und Bottom-up erzwingen können ("Meet-in-the-Middle"):


[Dirk Krafzig, Karl Banke und Dirk Slama] bevorzugen eher den Top-down-Ansatz, aber zeigen in mehreren Praxisbeispielen, dass der Bottom-up-Ansatz ebenso zu erfolgreichen SOA-Projekten führen kann.

[Nicolai Josuttis] stellt klar dar, warum weder Top-down noch Bottom-up in der reinen Form sinnvoll sind, sondern dass beide Vorgehensweisen kombiniert werden müssen. Der Ausgangspunkt sind die fachlichen Anforderungen, aber bei der Umsetzung muss die technische IT-Realität berücksichtigt werden.

Zu den Vor- und Nachteilen alternativer Serviceentwurfsvorgehensweisen siehe auch [Thomas Müller] und OASIS SOA Adoption Blueprint.



Technischer Schnittstellen- und Serviceentwurf

Architekturstile

Oft wird zwischen folgenden Architekturstilen unterschieden, obwohl die Grenzen fließend sind:

Metainformationen

Zu Services gehören Metainformationen (Vertrag).
Beispiele für funktionale Metainformationen (Schnittstelle):

Beispiele für nichtfunktionale Metainformationen (Policy):

Services

Angestrebte technische Effekte von Services:

Anzustrebende technische Eigenschaften von Services:

Transaktionen

Eventuell müssen besondere Vorkehrungen zur Transaktionsunterstützung und für Fehlersituationen vorgesehen werden:



MEP (Message Exchange Pattern)

Die Kommunikation zu den Services findet über verschiedene Nachrichtenaustauschmuster statt. Für Webservices definiert WSDL 1.1 vier und WSDL 2.0 acht verschiedene Standard-MEPs (siehe http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803). WSDL 2.0 erlaubt darüber hinaus die Definition beliebiger weiterer MEPs.


MEP nach
WSDL 1.1		 MEP nach
WSDL 2.0		 Fehlernachricht-Regel Anzahl Nachrichten Beschreibung
hin zurück
One-Way In-Only No Faults 1 0   Fire-and-Forget
-- Robust In-Only Message Triggers Fault 1 0...1   Möglicherweise mit Fehlerantwort
Request-Response
(Request-Reply)		 In-Out Fault Replaces Message 1 1   Genau eine Anfrage und eine Antwort
(entweder gewünschte Antwort oder Fehlerantwort)
-- In-Optional-Out Message Triggers Fault 1...2 0...1   Antwort ist optional; Anfrage oder Antwort können Fehlernachricht auslösen
Output-Only
(Notification)		 Out-Only No Faults Wie die obigen vier, aber in umgekehrter Richtung
(z.B. vom Server zum Client)
-- Robust Out-Only Message Triggers Fault
Solicit-Response Out-in Fault Replaces Message
-- Out-Optional-In Message Triggers Fault

Neben diesen einfachen Standard-MEPs gibt es natürlich auch abweichende und kompliziertere. Wie sich die fachliche Sicht von der technischen Sicht unterscheiden kann und was bei unsicheren Übertragungsprotokollen passieren kann, diskutiert [Nicolai Josuttis] in seinem Buch, was verkürzt anhand des folgenden Sequenzdiagramms angedeutet wird:


Nutzer              Nutzer         Service-Mediation     Serviceanbieter   
fachliche Ebene   Protokollebene     (z.B. ESB)         Thread A   Thread B
   |                 |                  |                  |          |
    Service aufrufen |                  |                  |          |
    ————————————————>   1. Versuch      |                  |          |
                       ————————————————>  geht verloren    |          |
                                          ———————>...      |          |
                        1. Retry        |                  |          |
                       ————————————————>                   |          |
                                          ————————————————>  __ Anfrage
                                        |                    __|verarbeiten
                           geht verloren  <————————————————           |
                             ...<———————                   |          |
                                        |                  |          |
                        2. Retry        |                  |          |
                       ————————————————>                   |          |
                                          ————————————————>  __ Anfrage
                                        |                    __|verarbeiten
                        3. Retry        |                             |
                       ————————————————>                              |
                                          ———————————————————————————>  __ Anfrage
                                        |                               __|verarbeiten
                        späte Antwort     <————————————————             
    Ergebnis liefern   <————————————————                                
    <————————————————                   |                               
                        weitere Antwort   <———————————————————————————  
                       <————————————————

Der Im Diagramm gezeigte Ablauf ist folgendermaßen:

  1. Der Nutzer ruft einen Request-Response-Service auf.
  2. Die Protokollebene verschickt die Nachricht, die aber beim ersten Versuch verloren geht.
  3. Nach einem Time-out startet die Protokollebene den ersten Retry. Diese Nachricht gelangt zum Ziel und wird erfolgreich verarbeitet. Aber leider geht die Antwortnachricht auf dem Rückweg verloren.
  4. Nach einem weiteren Time-out startet die Protokollebene den zweiten Retry. Diese Nachricht gelangt auch zum Ziel und wird erfolgreich verarbeitet. Allerdings ist das System (oder Netzwerk) sehr ausgelastet, und die Antwortnachricht kommt zu spät an, um einen weiteren Retry zu verhindern.
  5. Inzwischen hat die Protokollebene nach einem weiteren Time-out den dritten Retry gestartet. Dessen Antwortnachricht kommt ebenfalls erfolgreich zurück (wird aber nicht mehr benötigt).
  6. Nicht diese letzte Antwort, sondern die vorher erhaltene, returniert die Protokollebene an den Nutzer.
  7. Im Ergebnis wurde die Anfrage dreimal bearbeitet, was natürlich nur für idempotente Nachrichten erlaubt ist (es darf z.B. nicht dreimal ein Geldbetrag abgehoben werden).

Beachten Sie folgende Besonderheiten:



Security-Stack

[Nicolai Josuttis] beschreibt einen beispielhaften Security-Stack für XML und Webservices folgendermaßen:


        Webservices-Sicherheitsstandards        
    (WS-Security, WS-Policy, WS-Trust, ...)     

  Allgemeine XML-basierte Sicherheitsstandards  
               (SAML, XACML, ...)               

            XML-Sicherheitsstandards            
      (XML Encryption, XML Signature, ...)      

        Allgemeine Sicherheitsstandards         
        (Kerberos, PKI, X.509, SSL, ...)        

            Sicherheits-Algorithmen             
              (AES, DES, RSA, ...)

Weiter weist [Nicolai Josuttis] auf folgende Punkte hin:



Webservices

Es gibt über 100 verschiedene Standards zu Webservices. Es ist schwierig, den Überblick zu behalten, weil sich viele Standards noch ändern, zu anderen Standards konkurrieren oder sogar nicht verträglich sind.

[Ingo Melzer] beschreibt einen beispielhaften Webservice-Stack folgendermaßen:


    Enterprise (Transactions, Grid, WSRF, Eventing, Notification, ...      

          Integration and Coordination (BPEL, WSFL, ...)                
                                                                        
          Federation, Routing (WS-Federation, WS-Routing, ...)          
Meta-                                                                   
Data      Security (WS-Security, WS-Policy, WS-Trust, SAML)      Quality
(WSDL,                                                           of     
 UDDI,    Protocol (SOAP)                                        Service
 WS-TX)                                                                 
          XML-Specifications (XML, XSD, Namespaces, ...)                
                                                                        
          Transport (HTTP, SMTP, JMS, ...)

Zu den wichtigsten und/oder aussichtsreichsten Webservices gehören:

WS-Addressing
WS-Addressing erleichtert flexibles Routing, asynchrones Messaging und die Übertragung von SOAP-Nachrichten über mehrere Zwischenknoten ("Intermediaries").
Die Definition von Service-Endpunkten kann als XML-Dokument in SOAP erfolgen und es können zusätzliche Informationen definiert werden, zum Beispiel "MessageID" und "RelatesTo" (Relationship-Kontextelement).
WS-Notification (WSN)
WSN definiert Kommunikationsmuster für ereignisorientierte asynchrone Kommunikation, zum Beispiel über Message-Queuing-Systeme.
WS Reliable Messaging (WSRM)
Ausfallsichere Nachrichtenübertragung: Transportunabhängiges Protokoll für die gesicherte Nachrichtenzustellung basierend auf WS-Addressing.
Web Services Transactions Framework (WSTF)
WSTF ist eine Spezifikationsfamilie bestehend aus drei Unterspezifikationen (und Erweiterungsmöglichkeiten).
WS-Coordination:
WS-Coordination ist die Basis für WS-AtomicTransaction und WS-BusinessActivity und bietet einen Mechanismus zum Erstellen einer neuen und zum Beitreten zu einer bereits laufenden Transaktion ("Activation" und "Registration"). Dabei wird ein "CoordinationContext" angelegt (vergleichbar mit einer MessageID).
WS-AtomicTransaction:
WS-AtomicTransaction ist ein möglicher "Coordination Type" für WS-Coordination. WS-AtomicTransaction unterstützt verschiedene "Coordinate Protocols" und definiert vor allem Zustände und Zustandsübergänge, vergleichbar mit dem XA-Two-Phase-Commit-Protokoll (2PC). Anders als der Name es vermuten lassen könnte, werden nicht nur atomare Transaktionen unterstützt. Die Transaktionen können so definiert werden, dass sie alle vier ACID-Kriterien erfüllen, oder nur einige, oder sogar kein einziges. WS-AtomicTransaction ist für eher kürzer laufende (synchrone) Transaktionen vorgesehen. Im Fehlerfall erfolgt normalerweise ein Rollback.
WS-BusinessActivity:
WS-BusinessActivity ist ebenfalls ein möglicher "Coordination Type" für WS-Coordination, aber eher für länger laufende (asynchrone) Transaktionen vorgesehen. Oft wird WS-BusinessActivity eingesetzt, um mehrere kleinere AtomicTransactions zu einer größeren Business-Aktivität zusammenzufassen. Anders als bei der AtomicTransaction erfolgt im Fehlerfall kein Rollback. Stattdessen muss ein "Compensate Handler" implementiert werden, der die vorherigen Transaktion "kompensiert".
WS-Security (WSS)
WS-Security definiert weniger eigene Verfahren, sondern bietet vor allem eine Basis, wie andere Standards verwendet und kombiniert werden können, um Authentifizierung, Autorisierung, Zugriffsschutz, Vertraulichkeit, Integrität und Verbindlichkeit sowie SSO (Single Sign-on) zu erreichen. Eingesetzt werden zum Beispiel:
WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, XML-Signatur und SAML.
WS-Interoperability (WS-I)
WS-I ist kein Webservices, sondern eine Organisation, die sich (z.B. mit "Basic Profiles") um Webservice-Kompatibilität bemüht.

Weitere WS-*-Standards finden Sie unter:
- Die WS-* Spezfikationen von Orientation in Objects, WS-Specifications von Thomas Bayer,
- Web Services Standards Overview von innoQ
- W3C Web Services
- Web Services bei OASIS
- Web Services bei IBM.



Java-Frameworks für Webservices

Zu den bekannteren Java-Frameworks für SOAP-Webservices zählen Sun Metro (RI für JAX-WS), Apache Axis2, Apache CXF und Spring Web Services. Im Javamagazin 2.2008 vergleicht Thilo Frotscher diese vier Frameworks. Einige stark verkürzte Ergebnisse zeigt folgende Tabelle:


  Sun Metro Apache Axis2 Apache CXF Spring Web Services
Basiert auf JAX-WS 2 (JSR 224, JSR 181),
JAXB 2		 AXIOM, StAX (Celtix / XFire) Z.B. AXIOM, z.B. StAX, z.B. JAXB,
kein JAX-WS
Unterstützt WSIT (WS-Security, WS Reliable Messaging, WS-Policy u.a.) WSDL 2, WS-Security, WS-SecureConversation, WS-Trust, WS Reliable Messaging, WS-Policy u.a. (JAX-WS geplant) JAX-WS, weitere ähnlich Axis2,
außerdem JAX-RS		 Weniger Zusatzspezifikationen
Enthalten in GlassFish,
Oracle WebLogic		 IBM WebSphere - (Spring)
Code-First / Contract-First Beides Beides Beides Nur Contract-First
IDE-Unterstützung Sehr gute Unterstützung in NetBeans Plug-in für Eclipse Plug-in für Eclipse Kaum IDE-Unterstützung
Besonderheiten Beste Dokumentation,
beste Kompatibilität mit .NET 3,
kaum erweiterbar,
in Java EE 5 enthalten		 Am offensten und am besten erweiterbar Beste Unterstützung für REST,
Unterstützung für JavaScript		 Optimiert für Spring,
kein JAX-WS,
nur Contract-First

Für die genannten Frameworks gilt:
- Alle lassen sich in Java EE Application Servern betreiben.
- Alle lassen sich auch ohne Java EE Application Server betreiben, zum Beispiel im Tomcat oder Jetty.
- Alle lassen sich in Spring integrieren.
- Alle bieten Unterstützung für Interzeptoren-Handler.
- Alle unterstützen sowohl synchrone Kommunikation über HTTP als auch asynchrone über JMS.

Einen weiteren Vergleich zu Metro, Axis2 und CXF finden Sie bei Thomas Bayer, predic8.

Programmierbeispiele finden Sie unter SOAP Web Services mit JAX-WS.

Alternativ zu SOAP-Webservices gibt es zum Beispiel die RESTful Web Services (einen Vergleich finden Sie hier).



Open-Source-SOA-Komponenten

Bei kommerziellen Produkten passen alle Systembestandteile optimal zusammen und es stehen viele Konnektoren fertig zur Verfügung.

Open-Source-SOA-Komponenten sind mittlerweile auch ausgereift und decken auch die meisten SOA-Bereiche ab, aber das Zusammenspiel kann komplizierter sein und es gibt weniger fertige Konnektoren.

Eine Fachstudie "Vergleich von Open Source ESBs" finden Sie bei [Buchholz/Hohloch/Rathgeber].

Beschreibungen und Bewertungen zu Workflow Engines, ESB und EAI-Konnektoren finden Sie bei [Bauler/Feltz/Biri/Pinheiro].

Einen Vergleich der beiden ESB-Systeme OpenESB und ServiceMix finden Sie bei [Thomas Bayer, predic8].

Einen Vergleich der beiden ESB-Systeme Celtix und Mule finden Sie bei [Jürgen Dunkel und Arne Koschel].

Erste Schritte zu Eclipse-Equinox-OSGi-Services, Webservices mit Eclipse WTP und Service-Mediation mit Apache Synapse sind erläutert bei [Christoph Mathas].



BPEL-Editor, SOA-Entwicklungsumgebung und SOA-System

NetBeans 6

Einen der schnellsten und einfachsten Wege zu einer SOA-Entwicklungsumgebung inklusive BPEL-Editor und BPEL-Debugger sowie zu einem komplett lauffähigen SOA-System inklusive ESB-Bus bietet NetBeans 6:

  1. Voraussetzung ist ein installiertes aktuelles Java JDK, zum Beispiel Java SE JDK 6.
  2. Downloaden Sie das Sun NetBeans IDE 6.0 Download Bundle "All" (inklusive "Web & Java EE", "SOA" und "GlassFish V2").
  3. Achten Sie bei der Installation darauf, dass die Optionen "Web & Java EE", "SOA", "GlassFish V2" und "OpenESB V2" aktiviert sind.
  4. Lesen Sie folgende Dokumentationen und führen Sie folgende Tutorials aus:
  5. Wenn Sie Fragen haben oder auf Probleme stoßen, wenden Sie sich an die NetBeans Community oder an das deutschsprachige NetBeans-Forum.
 NetBeans




GlassFish




OpenESB




Metro, JAX-WS

NetBeans BPEL


Eclipse 3.4

Für Eclipse 3.4 gibt es mit STP (SOA Tools Platform) Unterstützung für SOA. STP wird u.a. von Iona gefördert.

STP kann in Eclipse nachinstalliert werden über: 'Help' | 'Software Updates...' | 'Available Software' | 'Ganymede' | 'SOA Development'.

Wichtige STP-Komponenten sind:

STP unterstützt das SCA-Komponentenmodell, JBI, Sun Metro (JAX-WS RI), Apache CXF und Apache Tuscany.

Eine Einführung in STP bietet Christoph Mathas im Javamagazin 9.2008.



Links auf weiterführende Informationen



Weitere Themen: andere TechDocs | SOAP Webservices
© 2002-2008 Torsten Horn, Aachen