Betriebliche Informationssysteme


VL 09 – Serviceorientierte Architektur


Sören Auer, TU Chemnitz, ISST

soeren.auer@informatik.tu-chemnitz.de

Stefan Kühne, Universität Leipzig, FMI IFI BIS

kuehne@informatik.uni-leipzig.de




Lernziele

  • Serviceorientierte Architekturen
    • Prinzipien
    • Ziele
    • Bewertungen
  • Service
  • SOA-Technik
    • Web Services
    • Semantic Services
    • Android Services


Überblick

Layer 1 A2B B2B A2C B2C en ManmanpeoplepersonChris KempsonChris KempsonChris Kempsonimage/svg+xmlen PPS FSS WW IPS E-Government E-Business E-Commerce B2BI SOA EAI ERP CRM SCM Markt- plätze Geschäfts- modelle Kunde


Serviceorientierte Architektur




Serviceorientierte Architektur

Architekturparadigma



Serviceorientierte Architektur (SOA)

  • Begriff erstmals eingeführt durch Gartner (1996)
    • bisher keine einheitliche Definition
  • [OASIS 2006]
    • “paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”
      • technologieunabhängiges Konzept
      • anwendbar in unterschiedlichen Bereichen und Abstraktionsebenen


Serviceorientierte Architektur (SOA)

  • [Starke u. Tilkov 2007]
    • "Eine serviceorientierte Architektur (SOA) ist eine Unternehmensarchitektur, deren zentrales Konstruktionsprinzip Services (Dienste) sind.“
    • Unternehmenswert steht im Vordergrund


Serviceorientierte Architektur (SOA)



  • SOA := Component based Design
  • SOA := Enterprise Application Integration
  • SOA := Business Process Management


Service

  • klar gegeneinander abgegrenzte und aus betriebswirtschaftlicher Sicht sinnvolle Funktion
  • Erbringung durch eine Unternehmenseinheit oder durch externe Partner
  • Nutzung:


Beispiel



Wer nutzt Services, wer stellt diese bereit?

  • erfordert Mehrwert von Diensten für Erbringer und Nutzer
    • Provide-or-consume-Entscheidung
    • Verrechnungsmodelle
      • protokollierte Nutzung, Zuordnung zu Nutzern
      • transaktionsorientierte Verrechnung
    • Katalogisierung


Wer nutzt Services, wer stellt diese bereit? (2)

  • technische Services, wie Datensicherung, möglich, jedoch nicht im Fokus
  • Wiederverwendung durch Aufruf
    • Services werden oft remote erbracht
    • Performance
    • grobgranularer Entwurf


Serviceschnittstelle und Implementierung

  • Service besteht aus
    • öffentliche (stabile) Schnittstelle
      • Operationen
      • ausgetauschte Informationen
      • Adresse
    • Implementierung (intern)
      • Geschäftslogik
      • Daten
    • Policies
      • Sicherheitsanforderungen/Berechtigungen
      • Performanceanforderungen
      • organisatorische Zuordnungen


Entwurfsziel: lose Kopplung von Services

  • Entkopplung, soweit wie möglich, bzgl.
    • zeitliche Abhängigkeit
    • örtliche Abhängigkeit
    • Struktur- und Implementierungsabhängigkeit
    • Datenabhängigkeit


Zwischenfazit

  • SOA als unternehmensweites Architekturkonzept
    • einheitliche, durchgängige Architektur für alle Fachbereiche eines Unternehmens
  • SOA-Migration ist langfristiges Vorhaben
    • unternehmensspezifische Entscheidungen, Ausprägungen
  • Konstruktionsprinzip Service
    • Services übernehmen die Rolle von Anwendungen
    • Outsourcing auf Basis von Services
    • Verantwortlichkeiten für Services


Perspektiven auf SOA

Layer 1 Business Vorgehensweisen Methoden Governance Architektur Technik Betrieb


SOA-Technik




SOA-Technik

Web Services



Architekturstile

  • schnittstellenorientiert
    • Fokus: Serviceschnittstellen und -operationen
    • oft synchrone Kommunikation (Request/Reply)
  • nachrichtenorientiert
    • Fokus: ausgetauschte Nachrichten
    • oft in Umgebungen mit EAI- oder MOM-Hintergrund


Architekturstile (2)

  • ressourcenorientiert
    • Fokus: identifizier- und adressierbare Ressourcen
    • feste Methoden durch Applikationsprotokoll
    • auch als „Ressourcenorientierte Architektur“ bezeichnet
    • vgl. REST [Algermissen 2009]


Web-Service-Stack



SOAP (urspr. Simple Object Access Protocoll)

  • SOAP v1.2 ist W3C Recommendation
  • Protokoll zum Austausch XML-basierter Nachrichten
  • regelt
    • Nachrichtendesign
    • Abbildung und Interpretation von Nachrichten
    • Konventionen für entfernte Prozeduraufrufe


SOAP (urspr. Simple Object Access Protocoll) (2)

  • unabhängig vom zugrunde liegenden Transportprotokoll
  • unabhängig von der Semantik der übertragenen Nachrichten
  • ermöglicht lose Kopplung zwischen Anwendungssystemen
  • impliziert gewissen Overhead


SOAP-Aufbau

  • Header enthält Informationen, die von Vermittlerknoten ausgewertet werden können
  • Body enthält den Inhalt, der zwischen einem Sender und einem Empfänger ausgetauscht werden soll


SOAP – Konventionen zur Nachrichtenkonstruktion

Interaktionsstile
Layer 1 soap-envelop Envelope soap-envelop Body <Bestellung> <Produkt>…</…> <Menge>…</…> </…> soap-envelop Envelope soap-envelop Body <Bestellung> <Produkt>…</…> <Menge>…</…> </…> <bestellen </…> Document Style RPC Style


  • Möglichkeiten der Codierung
    • XML Schema-konform (literal)
    • SOAP-spezifisch (encoded)


SOAP-Bindings

  • SOAP spezifiziert zustandslose Ein-Wege-Kommunikation
  • HTTP-Binding
    • Konstruktion von HTTP-Requests (GET, POST, …) und entsprechenden Response-Nachrichten
    • Adressierung über HTTP-URI
    • kein explizites Routing in SOAP (ergibt sich durch HTTP-Routing)


Web Service Description Language

  • Beschreibung von Web Services
  • vergleichbar zu konventionellen IDLs
    • jedoch mit konkreten Bestandteilen
  • Lokalisierung von Web Services
  • ursprünglich von IBM, Microsoft und Ariba entwickelt
  • plattform-, programmiersprachen- und protokollunabhängig
  • WSDL 2.0 ist W3C Recommendation


WSDL 1.1-Bestandteile

  • abstrakte
    • types
    • message
    • portType
      • operation
        • input
        • output
        • fault


WSDL 1.1-Bestandteile (2)

  • konkrete
    • binding
      • operation
    • service
      • port


WSDL 1.1-Beispiel (message, portType)

<!-- request GetLastTradePriceInput is of type TradePriceRequest -->
<wsdl:message name="GetLastTradePriceInput">
    <wsdl:part name="body" element="xsd1:TradePriceRequest"/>
</wsdl:message>
<!-- request GetLastTradePriceOutput is of type TradePrice --><wsdl:message name="GetLastTradePriceOutput">
    <wsdl:part name="body" element="xsd1:TradePrice"/>
</wsdl:message>

<!-- wsdl:portType describes messages in an operation -->

<wsdl:portType name="StockQuotePortType">

<!-- the value of wsdl:operation eludes me -->

   <wsdl:operation name="GetLastTradePrice">

       <wsdl:input message="tns:GetLastTradePriceInput"/>

       <wsdl:output message="tns:GetLastTradePriceOutput"/>

    </wsdl:operation> </wsdl:portType>



WSDL 1.1-Beispiel (binding)

<wsdl:binding name="StockQuoteSoapBinding“ 

  type="tns:StockQuotePortType">

   <soap:binding style="document"   

  transport="http://schemas.xmlsoap.org/soap/http"/>


   <wsdl:operation name="GetLastTradePrice">

  <soap:operation soapAction="http://example.com/GetLastTradePrice"/>


  <wsdl:input>

          <soap:body use="literal"/>

  </wsdl:input>

      <wsdl:output>

         <soap:body use="literal"/>

      </wsdl:output>

  </wsdl:operation>

</wsdl:binding>


WSDL 1.1-Beispiel (binding)

<wsdl:service name="StockQuoteService">

  <wsdl:documentation>My first service</documentation>


  <wsdl:port name="StockQuotePort" binding="tns:StockQuoteBinding">


  <!-- give the binding an network address-->

     <soap:address location="http://example.com/stockquote"/>

   </wsdl:port>

</wsdl:service>


WSDL 2.0-Bestandteile

  • abstrakte
    • types
    • interface
      • operation
  • konkrete
    • binding
    • service
      • endpoint


Koordination von Web Services

  • Realisierung einer Geschäftsfunktion beinhaltet oft mehrere Services
  • Koordinationskonzepte
    • Choreographie
    • Komposition
  • Komposition enthält [Bussler 2001]
    • Art und Beschaffenheit der zu aggregierenden Services
    • Prozessbeschreibungsschema (Orchestrierungsschema)
    • Datenbeschreibungsschema
    • Service-Selektierungsschema
    • Transaktionsschema
    • Ausnahmebehandlungsschema


Business Process Execution Language

  • Prozessbeschreibungssprache zur Komposition von Web Services
  • Unterstützung langlebiger Prozesse („Programming in the Large“)
  • BPEL-Prozesse sind selbst wieder Services (beschrieben durch WSDL)
  • BPEL4WS 1.1 u.a. von BEA, Microsoft, IBM entwickelt
    • Microsoft: blockstrukturiertes XLang
    • IBM: graphstrukturiertes WSFL
  • Standardisierung durch OASIS
    • Organization for the Advancement of Structured Information Standards
  • aktuelle Version BPEL 2.0: WS-BPEL


BPEL-Metamodell



BPEL-Beispiel



Frage

  • Wie kommt man vom Geschäftsprozessmodell (z.B. modelliert in ARIS) zur lauffähigen Orchestrierung (z.B. in BPEL-Designer bzw. ActiveBPEL)
    • [Kühne 2009]


Erweiterungen von WS-BPEL

  • BPEL4People
    • Erweiterung um nutzerinteraktive Aspekte
  • BPEL-SPE, BPELlight
    • Modularisierung von Orchestrationen
    • wiederverwendbare Teilprozesse
  • BPELJ
    • Einbettung von Java-Anweisungen (Java-Snippets)
  • Microsoft BizTalk Server
    • call-Konstrukt
  • Oracle BPEL-Manager
    • flowN-Konstrukt


Beschreibung nicht-funktionaler Eigenschaften

  • WS-Policy
  • WS-Addressing
  • WS-Reliable Messaging
  • WS-Security
  • WS-SecurityPolicy
  • Security Assertion Markup Language (SAML)
  • WSFederation,
  • WS-Trust
  • WS-SecureConversationeme


WS-Interoperability (WS-I)

  • Gruppe von Unternehmen, die Best Practices zur Interoperabilität von Web-Services-Techniken herausgibt
  • Veröffentlichung von
    • Profilen
    • Referenzimplementierungen
    • Werkzeugen
  • Beispiele
    • Basic Profile (Serialisierung von Nachrichten, Nutzung von SOAP, Beschreibung von Services)
    • Basic Security Profile
    • Reliable Secure Profile


Enterprise Service Bus

  • Integrationsplattform
  • regelt Kommunikation zwischen Service-Provider und -Consumer
  • Infrastrukturdienste, wie
    • intelligentes Routing
    • Logging
    • Authorisierung
    • Transaktionsmanagement
    • Nachrichtentransformation
  • regelt technische Konnektivität (inkl. Netzwerk- und Protokolldetails)
  • Kapselung heterogener Technologien
  • Kapselung verschiedener Kommunikationskonzepte


Serviceorientierte Architektur




Serviceorientierte Architektur

Semantic Services



Semantic Services

  • etwa zeitgleiche Entwicklung von
    • Semantic Web
    • XML, SOAP, Web Services
  • Beziehungen im Kontext dynamischer Choreographie und Orchestrierung
  • Semantic Web Services
    • Einsatz von Agenten-Technologien für Discovery, Execution, Composition, Interoperation
    • Ontology Web Language for Services (OWL-S)
    • Web Service Modeling Ontology (WSMO)
    • Semantic Web Services Framework (SWSF)
    • Web Service Semantics (WSDL-S)


Prinzipien von Semantic Services

  • Anwendungsfälle
    • Publishing/Discovery
    • Matching/Composition
  • benötigen
    • Verweise auf Taxonomien
    • Annotationen in WSDL-Dokumenten
    • Adaption zur Laufzeit
    • Einsatz von Mapping-Services
  • Implikationen
    • Unternehmensontologie


Serviceorientierte Architektur




Serviceorientierte Architektur

auf Basis von Android



Android

  • Apps bestehen aus vier Komponententypen
    • Activity: benutzerorientierte Funktionalitäten mit grafischer Repräsentation
    • Service: benutzerorientierte Funktionalitäten im Hintergrund
    • BroadcastReceiver: Listener-Funktionalität, die auf verschiedene Ereignisse reagiert
    • ContentProvider: tabellenorientierte Datenspeicherung
  • Servicebeschreibung durch
    • ACTION
    • CATEGORY
    • DATA
  • Intents und Intentfilter


Android



SOA-Konzepte [Dienst 2011]

  • Serviceaufruf
    • Aufruf von Services durch Intents-Struktur
    • Explizit: genaue Angabe der Implementierungsklasse
    • Implizit: Action, optional mind. eine Category, URI
  • Servicerepository
    • Abgleich Intent mit Intentfilter (aller Apps)
    • Disambiguierung durch Benutzer
  • Lose Kopplung
    • dynamische Bindung
    • synchroner oder asynchroner Aufruf


Beispiel

  • Szenario
    • Im Rahmen einer Instandhaltungsdienstleistung sind Aufträge für Wartungs-, Entstörungs- und Vorsorgemaßnahmen zur Gewährleistung der Verfügbarkeit einer technischen Anlage zu koordinieren. Hierbei werden Ersatzteil-, Werkzeug-, Hilfs- und Betriebsstofflieferanten sowie Servicetechniker einbezogen.
    • Ein konkreter fachlicher Service in diesem Szenario ist bspw. die Abfrage von Verfügbarkeiten und Angeboten für bestimmte Leistungen zu bestimmten Terminen, wie z. B. die Lieferung eines Ersatzteils, die Bereitstellung eines Krans oder die Durchführung eines Ölwechsels, bei alternativen Anbietern.
  • Intent
    • ACTION org.eumonis.maintenance.wea
    • CATEGORY offshore, KW27, WEA Gen 2, 500kW
    • DATA eumonis://.../weagen2/...


Serviceorientierte Architektur




Serviceorientierte Architektur

Anforderungen an Services



Granularität von Services

  • Wie viele SOA-Services hat ein Finanzdienstleister?
    • technische Betrachtung vs.
    • fachliche Funktionen
  • Methodiken
    • Top-down-Herleitung aus Geschäftsarchitektur
    • Bottum-up-Betrachtung vorhandener Systeme


Ableitung aus Geschäftsfunktionen [von Henning 2007]

  • Geschäftsprozesse ungeeignet
  • Geschäftsfunktionen bilden Grundlage, da kontextfrei
  • einheitliches Informationsmodell benötigt


Anforderungen an Schnittstellen [Keller 2007]

  • Regeln/Heuristiken für OO sind prinzipiell übertragbar
  • Einhaltung von Namenskonventionen
  • Trennung von Fachlichkeit und Technik
  • konsistente Zustandsübergänge
  • Redundanz- und Überschneidungsfreiheit
  • einprägsame Abstraktionen, verständliche Namen
  • Verwendung fachlicher Datentypen
  • Vermeidung unnötiger Abhängigkeiten durch „fette“ Schnittstellen
  • kontextfreie Operationen


Serviceorientierte Architektur




Serviceorientierte Architektur

Zusammenfassung und Bewertung



SOA-Zusammenfassung

  • Business-IT-Alignment durch gemeinsames Strukturierungsprinzip (Service)
  • geschäftliche Fokussierung und notwendige technische Unterstützung
  • IT-Architekturansatz
    • präzise Schnittstellen
    • Lose Kopplung zur Flexibilisierung
    • Einsatz von Standards (XML, HTTP, SOAP, WSDL, …)
    • Einsatz von Metadaten zur Beschreibung nicht-funktionaler Eigenschaften


Risiken

  • keine Alternativen zu SOA?
  • klare Struktur durch ESB?
  • Transaktionssicherheit?
  • Services sind einfach zu handhaben?
  • Wiederverwendung durch SOA?
  • Abstraktion von zugrunde liegender Technik?
  • Allheilmittel Lose Kopplung?
  • SOA vereinheitlicht technische Architekturen?
  • SOA vereinheitlicht die fachliche Seite?
  • SOA als Management-Hype?


Bewertung

  • SOA-Initiativen sind langfristige Vorhaben
    • mit entsprechenden Potenzialen
    • mit entsprechenden Risiken
  • SOA kann auf grüner Wiese gut funktionieren
  • SOA impliziert in gewachsenen Umgebungen neuartige Probleme
  • SOA ist keine Universallösung


Zusammenfassung

  • Serviceorientierte Architekturen
    • Prinzipien
    • Ziele
    • Bewertung
  • Services
  • SOA-Technik
    • Web Services


SOA – weitere Aspekte

  • Einführung einer SOA
  • SOA-Governance
  • Betrieb einer SOA-Applikationslandschaft (Bezug zu ITIL)
Gernot Starke, Stefan Tilkov (Hrsg.): SOA-Expertenwissen – Methoden, Konzepte und Praxis serviceorientierter Architekturen.




Creator: darya (VUA)

Contributors:
-


Licensed under the Creative Commons
Attribution ShareAlike CC-BY-SA license


This deck was created using SlideWiki.