Ist die Zeit reif für „Vista“ - DVZ Datenverarbeitungszentrum ...
Ist die Zeit reif für „Vista“ - DVZ Datenverarbeitungszentrum ...
Ist die Zeit reif für „Vista“ - DVZ Datenverarbeitungszentrum ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Verwendung eines Webservices mittels<br />
einer abstrakten Definition der anzusprechenden<br />
Nachrichten (messages),<br />
Datentypen (types) und Porttypen<br />
(portType). Im zweiten Teil erfolgt <strong>die</strong><br />
konkrete Definition des verwendeten<br />
Protokolls (binding) auf Basis des vorher<br />
definierten Porttyps und <strong>die</strong> Angabe des<br />
eigentlichen Netzwerk-Endpunktes (port)<br />
des Webservices.<br />
Als Austauschformat zur Übertragung<br />
der Nachrichten zwischen Webservices<br />
wird SOAP eingesetzt, welches Regeln<br />
<strong>für</strong> das Nachrichtendesign aufstellt und<br />
definiert, wie Daten in der Nachricht<br />
abzubilden sind.<br />
SOAP kann auf jedes Protokoll der<br />
Transport- und An wen dungs schicht des<br />
ISO/OSI-Referenz modells aufsetzen.<br />
Jedoch bietet sich <strong>die</strong> Kombination<br />
Http/TCP auf Grund des hohen Nutzungskreises<br />
an.<br />
Prozesse in SOA<br />
Die Spezifikationen WDSL oder SOAP<br />
ermöglichen lediglich ein zustandsloses<br />
Client-Server-Modell <strong>für</strong> synchrone oder<br />
unkorrelierte asynchrone Interaktionen<br />
zwischen Webservices. Diese rein elementare<br />
Kommunikation ist gewünscht, da<br />
einerseits <strong>die</strong>s genau das Ziel der Spezi fikationen<br />
ist und um andererseits Überlappungen<br />
in der Spezifikation bzgl. des<br />
Nachrichtenaustausches zu vermeiden.<br />
Jedoch ist <strong>für</strong> <strong>die</strong> Abbildung eines prozessorientierten<br />
eGovernments <strong>die</strong><br />
Koordination und Zustandsbehaftung<br />
von Webservices nötig, da Verwal tungsprozesse<br />
meist mehrere Fach anwen dungen<br />
und Basiskomponenten umfassen,<br />
langlebig sind und von Benutzer- bzw.<br />
Verwaltungsentscheidungen abhängen.<br />
Als Ergänzungsstandard <strong>für</strong> <strong>die</strong> Lösung<br />
<strong>die</strong>ses Problems ist <strong>die</strong> „Web Service for<br />
Business Process Execution Language“<br />
(BPEL) entstanden, welche <strong>die</strong> Ent wicklung<br />
eines komplexen, langlebigen und<br />
zustandsbehafteten Interaktionsmodells<br />
zwischen Webservices ermöglicht.<br />
BPEL definiert verschiedene Partnerbeziehungen<br />
zwischen Webservices und<br />
erzeugt so einen automatisierten BPEL-<br />
Geschäftsprozess. Die Steuerung <strong>die</strong>ser<br />
Partnerbeziehungen erfolgt durch ver -<br />
schiedene BPEL-Aktivitäten, welche <strong>die</strong><br />
20<br />
Operationen der jeweiligen Partner in<br />
den eigenen BPEL-Geschäftsprozess<br />
involvieren.<br />
Eine nachhaltige Einschränkung der<br />
BPEL-Spezifikation ist <strong>die</strong> fehlende<br />
Unterstützung der direkten Einbeziehung<br />
von Benutzerinteraktionen in einem<br />
BPEL-Geschäftsprozess. Dies kann durch<br />
Zusatzspezifikationen (z. B. BPEL4People)<br />
oder Tool-Erweiterungen der Hersteller<br />
ausgeglichen werden.<br />
SOA – Mehr als Technologie<br />
Ein oft falsch verstandener Ansatz ist <strong>die</strong><br />
rein technologische Ausrichtung von<br />
SOA. Der erste Schritt zu einer SOA ist<br />
<strong>die</strong> Definition eines geeigneten Rahmens:<br />
<strong>die</strong> SOA-Governance. Sie umfasst mit<br />
einem gezielten Management den ge -<br />
sam ten Lebenszyklus einer serviceorientierten<br />
Architekturlandschaft.<br />
Dies be in haltet SOA-spezifische Personen<br />
rollen, Zuständigkeitsvereinbarungen<br />
<strong>für</strong> Services und Geschäftsprozesse<br />
sowie auf SOA angepasste Ent wick lungsprozesse.<br />
Die Definition von Regeln und<br />
Richtlinien durch <strong>die</strong> Vereinbahrung von<br />
Service Level Agreements (SLA) bildet<br />
das Finale im SOA-Governance und<br />
garantiert so <strong>die</strong> Administrierbarkeit<br />
einer lebensfähigen SOA-Gesamt architektur.<br />
SOA-Governance schafft eine<br />
organisatorische Grundlage, mit deren<br />
Hilfe <strong>die</strong> Verwaltung in M-V in <strong>die</strong> Lage<br />
versetzt wird, sich prozessorientiert auf<br />
Veränderungen einzustellen.<br />
<strong>DVZ</strong>INFO. www.dvz-mv.de<br />
Fazit<br />
Wesentliche Vorteile von SOA sind <strong>die</strong><br />
Plattform- und Herstellerunabhängigkeit<br />
und <strong>die</strong> dementsprechend erreichte<br />
Inter operabilität durch den geforderten<br />
Einsatz von standardisierten, auf XML<br />
basierenden Technologien. SOA eröffnet<br />
auf <strong>die</strong>se Weise eine vielversprechende<br />
Lösung des altbekannten Problems der<br />
Integration von Alt-Applikationen in eine<br />
neue IT-Landschaft und ermöglicht <strong>die</strong><br />
deutliche Aufwertung vorangegangener<br />
IT-Infrastruktur-Investitionen.<br />
Darüber hinaus läutet SOA einen Paradigmen<br />
wechsel ein: Abkehr von einer reinen<br />
IT-Orientierung hin zu einer ganzheitlichen<br />
Sicht auf Verwaltungsprozesse und<br />
IT-Infrastruktur. Mit solch einem Vor gehens<br />
modell kann eine ebenenüberg<strong>reif</strong>ende<br />
eGovernment-Architektur ge schaffen<br />
werden, <strong>die</strong> sich den im Wandel begriffenen<br />
Strukturen und Prozessen der Ver -<br />
wal tung flexibel anpasst.<br />
Jana Schulze<br />
Systemlösungen<br />
Uwe Gärtitz<br />
Systemlösungen