01.12.2012 Aufrufe

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 ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!