Service Engineering. IVS Arbeitsgruppe Softwaretechnik

Transkript

1 Service Engineering IVS Arbeitsgruppe Softwaretechnik Abschnitt: Part 1 Seite 1

2 Agenda Part 1 Motivation Anwendungsarchitekturvs. IT-Unternehmensarchitekturen Überblick zum SOA-Ansatz Vorgehen zur SOA-Implementierung Komposition von Serviceangeboten Seite 2

3 Motivation Seite 3

4 Motivation SOA ist ein technologieunabhängiges Architekturkonzept, das Softwarearchitekturen einfacher und flexibler machen soll und dabei die Wiederverwendung bestehender Komponenten unterstützt. SOA ist nicht an bestimmte Technologien wie etwa Web Services gebunden. Quelle: Reinheimer, S.; Lang, F.; Purucker, J.; Brügmann, H.: 10 Antworten zu SOA, in HMD 253, dpunkt.verlag, Heidelberg, Februar 2007 Seite 4

5 Begriff der IT-Architektur Architekturebenen: Geschäftsarchitektur Arbeitsabläufe und Organisationsstrukturen Anwendungsarchitektur verwendete Unternehmensanwendungen Technologische Architektur Betrieb SW-und HW-Infrastruktur Quelle: Conrad, S.; Hasselbring, W.; Koschel, A.; Tritsch, R.: Enterprise Application Integration, Spektrum Akademischer Verlag, München 2006 Seite 5

6 Begriff der IT-Architektur Seite 6

7 Anwendungsarchitektur vs. IT-Unternehmensarchitekturen Seite 7

8 Client/Server-Architektur moderner Applikationen DBS Client mit GUI DB-1 Browser JSP, XHTML HTTP SOAP via HTTP DBS Web- Server Applikation- Server DB-2 Browser z.b. CORBA Integration- Server (Wrapper) Legacy- Anwendung Seite 8

9 Produkt- und Organisations- zentrierte IT-Architekturen Seite 9

10 Aktuelle Problembereiche Silo -Applikationenfür spezielle Produkte und Dienstleistungen Unübersichtliche Anzahl benötigter Schnittstellen (Spagetti) Enge Kopplung der verwendeten Applikationen Schwerfällige Umgestaltung IT-gestützter Prozesse Fallende IT-Budgets(bis zu 40% innerhalb der letzten 7 Jahre) Hochgradige Daten-und Funktionsredundanz Performance der GP schwer nachvollziehbar Heterogenität der verwendeten Technologien bzw. Techniken Seite 10

11 Überblick zum SOA-Ansatz Ansatz Seite 11

12 Zielstellungen einer SOA Schnelle Bereitstellung neuer Lösungen (Integration vs. Entwicklung) Transparenz/Kenntnis verfügbarer fachlicher Serviceangebote Identifizierung potentieller Funktions-und Datenredundanzen Verhindern redundanter Entwicklungen - Wiederverwendung von bereits vorhandenen Services - Reduktion der Kosten für Entwicklung & Wirkbetrieb Etablierung von internen und externen Servicemarktplätzen - Evolutionäre Optimierung vorhandener Servicelandschaften - Reduktion der Kundenbindung -Flexibilisierung Einheitliche Spezifikation der vorhandenen Services Seite 12

13 Bezugsbereich einer SOA In Anlehnung an: Frisius, O.: Service Oriented Architecture Revolution oder Buzzword, sd&mag, GI / ACM Stuttgart, Dezember 2005 Seite 13

14 Bestandteile einer SOA Seite 14

15 Web Services als Implementierungsalternative Seite 15

16 Vorgehen zur SOA-Implementierung Seite 16

17 Elemente einer SOA-Stategie Stategie Berücksichtigung organisatorischer Implikationen, Etablierung einer SOA-Infrastruktur, Vorgaben zur Spezifikation von Servicekandidaten, Vorgehensweise für die Entwicklung von Serviceangeboten, Vorgehensweise zur Assemblierung von Serviceangeboten, Aspekte der Qualitätssicherung und Testaktivitäten, Empfehlungen zur Installation und Konfiguration, Rahmenbedingungen für das Service-Management. Seite 17

18 buttom up getriebenes Vorgehen Betrachtung existierender Anwendungen Identifikation aus Sicht der Anwendung sinnfälliger Services Bereitstellung von Serviceverzeichnisse (z.b. UDDI) Bereitstellung einer Enterprise Service Bus (ESB) Technische Lösungsalternativen zur Orchestrierung Management der Integrationsinfrastruktur Applikationsschnittstellen Serviceschnittstellen Seite 18

19 top down getriebenes Vorgehen Formale Modellierung der Geschäftsprozesse Etablierung einer unternehmensweit gültigen Onthologie Identifikation von Business-Services entsprechender Domainen Etablierung prozesszentrierter Softwarearchitekturen Business Process Management (Bewertung der Prozessgüte) Seite 19

20 Vorgehen zur SOA-Implementierung Entwickleranforderungen (buttom up) AG getriebene Serviceidentifikation Mapping Identifizierbare Servicetypen Kundenanforderungen (top down) GP getriebene Serviceidentifikation Mapping Altanwendungen (Wrapping) Existierende Basis-Services Orchestrierte Basis-Services Kommerzielle Serviceangebote Serviceneuentwicklung Identifikation benötigter Referenzdaten (z.b. Kunden- oder Produktdaten) Zyklisches Prüfen auf tatsächliche Nutzung ggf. Aussonderung Klassifikation der Serviceangebote und semantische Zuordnung der Funktionen & Daten Katalogisierung der im Unternehmen bzw. bei Partnern vorhandenen Services Seite 20

21 Komposition von Serviceangeboten Seite 21

22 Komposition von Serviceangeboten In the past, we've been builders of custom software, or deployersof packages. In the new, agile application development, we'll find that reuse and assembly will be the keys. Application development organizations can't code themselves into the future! Quelle: Hotle, M.; Vecchio, D.: AD Scenario TyingAgile Development, BPM and Architecture Together, GartnerSymposium ITxpo, Cannes/France 2005 Seite 22

23 Komposition von Serviceangeboten Quelle: Seite 23

24 Komposition von Serviceangeboten BPEL (Business Process Execution Language) wurde im Jahr 2003 von IBM, BEA und Microsofteingeführt. BPEL ist eine XMLbasierteSprache zur Beschreibung von Geschäftsprozessen, deren einzelne Aktivitäten durch Webservicesimplementiert sind. Weiterhin kann mit BPEL ein Webservice selbst beschrieben werden. Web Service -Choreography Definition Language(Ablösung von WSCI) ist ein W3C-Standard zur Modellierung abstrakter Prozesse (Choreografie). WS-CDL wurde entworfen als komplementäre Modellierungssprache zu anderen Sprachen, die zur Orchestrierung von ausführbaren Prozessen verwendet werden. Seite 24

25 Komposition von Serviceangeboten Seite 25

26 Komposition von Serviceangeboten WSDL-basierte Kapselung der orchestrierten Web Services WSDL WSDL WSDL Seite 26