Weitere ähnliche Inhalte Ähnlich wie NEW VERSION: Data Quality und SOA (20) NEW VERSION: Data Quality und SOA1. WHITE PAPER: SOA
WHITE PAPER /
Data Quality meets SOA –
Datenqualität für alle Geschäftsprozesse
verfügbar machen
Datenqualitätsfunktionen wurden im Be-
reich Unix, Windows und Linux schon als
Services bereitgestellt, als die Analysten
von Gartner den Begriff SOA noch nicht
erfunden hatten. Für diese Architektur
waren überwiegend technische Gründe
ausschlaggebend. Darüber hinaus stel-
len sich mit der Implementierung von ser-
vice-orientierten Architekturen neue und
andere Anforderungen an Datenquali-
tätsservices, gleichzeitig wachsen auch
die Möglichkeiten und der Nutzen, den
sie bewirken können.
__________________________
Alle in diesem Dokument verwendeten Firmen-, Produktnamen und Logos sind Han-
delsnamen und/oder eingetragene Warenzeichen der jeweiligen Unternehmen.
Seite 1
2. WHITE PAPER: SOA
Ausgangspunkt
Datenqualitäts-Services
Um die Bedeutung von service-orientierten Architekturen für die Bereitstellung
und Nutzung von Datenqualitätsfunktionen zu betrachten, ist es zunächst nütz-
lich, einen Blick auf die typischen Datenqualitäts-Funktionen selbst zu werfen.
ANWENDUNG A: Eine klassische Anwendung ist die Adressprüfung aufgrund von Referenzdaten, in
denen Straßen- und Ortsnamen sowie die Abhängigkeiten der Postleitzahlen von Orten, Straßen und
Hausnummer hinterlegt sind. Im Gegensatz zu einem einfachen Datenbankzugriff soll hier die rich-
tige Adresse auch dann gefunden werden, wenn die Eingabe unvollständig ist, Schreibfehler oder
Hörfehler enthält. Ziel ist eine große Treffergenauigkeit, um einen möglichst hohen Anteil fehlerhafter
Adressen automatisch korrigieren zu können.
ANWENDUNG B: Eine weitere Anwendung ist die Dublettensuche im eigenen Bestand. Auch hier ist das
Ziel trotz unvollständiger, abweichender oder fehlerhafter Eingabe - sei es ein Geschäftsobjekt, ein
Geschäftspartner, ein Produkt oder auch eine Sales Opportunity - schnell und sicher zu identifizieren.
Einerseits um die Suche zu vereinfachen und damit die Produktivität der Anwender zu erhöhen, ande-
rerseits um die Anlage von Dubletten, das bedeutet doppelt vorhandene Einträge, die sich auf dasselbe
Objekt in der realen Welt beziehen, zu vermeiden. Damit soll eine konsistente, vollständige und eindeu-
tige Abbildung der real existierenden Objekte in der Datenbank erreicht werden.
Ein wichtiges Ziel im Rahmen der Verbesserung von Neben der Antwortzeit spielte bereits bei
Datenqualität besteht darin, unvollständige oder Datenqualitäts-Services die Integration in unter-
fehlerhafte Daten gar nicht erst in der Datenbank schiedlichste Umgebungen eine wichtige Rolle. Für
zu speichern. Mögliche Probleme sollen bereits das Erreichen dieses Ziels ist eine Entkopplung
bei der Erfassung erkannt und daraufhin entwe- des Datenqualitätsservices vom Servicekonsumenten
der automatisch oder mittels eines entsprechenden sowie die Nutzung über ein Client/Server-Protokoll
Feedbacks an den Anwender durch diesen berei- wichtig. Daher wurde diese Funktionalität im
nigt werden. Spezialisierte Suchindizes sorgen Bereich Datenqualität, zumindest für anspruchsvolle-
dafür, dass eine Suche in Datenbeständen mit re Anwendungen, schon vor der „Erfindung“ service-
1.000.000 bis hin zu 100.000.000 Datensätzen orientierter Architekturen als Service bereitgestellt
auch bei abweichender Schreibweise im Regelfall und genutzt. So war es möglich, sowohl die hohen
nur den Bruchteil einer Sekunde benötigt. Doch Anforderungen an die Antwortzeiten zu erfüllen als
diese Antwortzeiten erfordern ein intelligentes auch die Bereitstellung von Funktionalitäten für unter-
Caching der Indizes. Das wiederum kann sehr effi- schiedlichste Umgebungen zu gewährleisten.
zient durch die Implementierung der Software als
zentralen Service gewährleistet werden, der von
einem eigenen Server zur Verfügung gestellt wird.
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 2
3. WHITE PAPER: SOA
Vom » fat client « zur
3-Schichten-Architektur
Layered Architecture LAYERED ARCHITECTURE
Die typische Architektur aus den Anfangszeiten der FAT CLIENT
Client/Server-Welt bestand aus einer Datenbank,
die neben der Speicherung von Transaktions- und ROLE
Stammdaten auch eine asynchrone Kommunikation Name Customer
zwischen unterschiedlichen Systemkomponenten Street Supplier
und damit eine Entkopplung dieser Komponenten Postcode Reseller
ermöglichte. Botschaften (Messages) wurden vom
Sender in die Datenbank geschrieben und vom
Empfänger dort ausgelesen. Dazu war allerdings
ein regelmäßiges „Pollen“ der entsprechenden
Tabelle erforderlich, um festzustellen, ob neue, noch
unbearbeitete Messages zur Verfügung standen.
Die Geschäftslogik war überwiegend in sogenann-
ten „fetten“ Clients implementiert. Aufgaben, für
die Batch-Verfahren Anwendung fanden, wurden
durch Hintergrundprozesse, die auf die Datenbank
zugriffen, implementiert.
Interaktive Funktionen zur Prüfung von Adressen oder
zur Erkennung von Dubletten direkt bei der Erfassung
waren in aller Regel in die graphische Oberfläche
integriert. Der Aufruf erfolgte üblicherweise über
proprietäre Schnittstellen. Spezifikationen wie DCE1
oder CORBA2, deren Ziel die Standardisierung
von Schnittstellen für die Kommunikation verteilter
Komponenten war, kamen über ein Nischen-Dasein
nicht hinaus.
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 3
4. LAYERED ARCHITECTURE WHITE PAPER: SOA
FATDiese Situation hat sich in den vergangenen Jahren
CLIENT CLIENT
grundlegend verändert. Ausgangspunkt dafür war
vor allem die Etablierung von Standards im Rahmen
ROLE ROLE
Name Customer Name Customer
der JEE3 (Java Enterprise Edition) und in der Folge die
Bereitstellung leistungsfähiger Implementierungen
Street Supplier Street Supplier
dieser Standards sowohl als kommerzielle Produkte
Postcode Reseller Postcode Reseller
als auch als Open-Source-Lösungen.
DIE EINFACHE INTEGRATION IN DEN APPLICATION SERVER
APPLIKATIONSSERVER –
SEI ES AUF BASIS EINER JEE- ODER EINER
.NET-ARCHITEKTUR – TRAT DAMIT JETZT
IN DEN VORDERGRUND.
Für die Windows-Welt zog Microsoft mit der
Entwicklung von .NET4 als sprachunabhängi-
ge Plattform und den .NET Enterprise-Services
nach. Damit stand unabhängig von der gewähl-
ten Plattform (JEE, .NET) eine leistungsfähige
Infrastruktursoftware bereit, um die Geschäftslogik
weitgehend aus der Präsentationsschicht zu lösen
und auf dem Server in einer eigenen Schicht zu
implementieren. Damit veränderten sich auch die
Anforderungen an Datenqualitäts-Services, die jetzt
überwiegend aus dem Bereich der Geschäftslogik
auf der Serverseite angesprochen wurden.
1 http://en.wikipedia.org/wiki/Distributed_Computing_Environment
2 http://en.wikipedia.org/wiki/CORBA
3 http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
4 http://en.wikipedia.org/wiki/.NET_Framework
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 4
5. WHITE PAPER: SOA
SOAP als Enabler für SOA
Richtig effektiv wird SOA erst durch die Etablierung Proprietary Protocol
eines Standardprotokolls für die Bereitstellung und
Nutzung von Services. Mit dem Web Service
Protokoll SOAP5 wurde diese Lücke geschlossen.
Es wird von praktisch allen Middleware- und
Infrastrukturkomponenten unterstützt und ermöglicht
damit erst die Interoperabilität zwischen Service-
Providern, Middleware und Service-Consumern.
Damit entfällt die Bereitstellung von Konnektoren
für die Nutzung proprietärer Protokolle in pro-
pietärer Middleware. Damit ist die Grundlage
für die Etablierung mächtiger Middleware-
Komponenten gelegt. Dazu gehört das Konzept
des Enterprise Service Bus (ESB)6, der die lose
Kopplung unterschiedlicher Komponenten mit
einem besonderen Gewicht auf dem Routen von
Messages ermöglicht, genauso wie Engines,
die in einer Geschäftsprozesssprache definier-
te Workflows (BPEL)7 direkt ausführen können.
5 http://en.wikipedia.org/wiki/SOAP
6 http://en.wikipedia.org/wiki/Enterprise_service_bus
7 http://en.wikipedia.org/wiki/BPEL
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 5
6. WHITE PAPER: SOA
Damit haben sich SOAP-basierte Web Services SOAP Protocol
auch zum zentralen Instrument entwickelt, um
interaktive Datenqualitätsservices in modernen
Enterprise Architekturen bereitzustellen. Es handelt
sich dabei überwiegend um Services, die nach
dem Request/Response Pattern ablaufen, in dem
der Service-Consumer einen Request initiiert, zum
Beispiel „validiere die angegebene Adresse“ und
der Service direkt mit einer Bestätigung, einem
Korrekturvorschlag oder einer Auswahl von
möglichen korrekten Adressen antwortet. Diese
Vorgehensweise entspricht dem interaktiven
Charakter der Validierung, die dem Anwender
direkt bei der Erfassung eines Geschäftsobjektes
zu unterstützen und im Falle von Problemen
Eingriffsmöglichkeiten eröffnen soll.
DER ZUSAMMENHANG ZWISCHEN DER
IMPLEMENTIERUNG VON GESCHÄFTS-
PROZESSEN UND DATEN-
QUALITÄTSFUNKTIONEN WIRD UNMITTEL-
BAR SICHTBAR UND DAMIT AUCH
DER BEITRAG, DEN SIE ZUM ERFOLG
DES ENTSPRECHENDEN GESCHÄFTS-
PROZESSES LEISTEN.
Allerdings ist diese Funktionalität nicht mehr isoliert
in der Präsentationsschicht implementiert, sondern
findet in aller Regel im Kontext eines übergeord-
neten Geschäftsprozesses statt, wie zum Beispiel
der Implementierung des Bestellprozesses in einer
E-Business Anwendung, der Implementierung eines
Prozesses zur Leadkonvertierung und –qualifizie-
rung in einer CRM-Anwendung oder einem ver-
gleichbaren Prozess.
5 http://en.wikipedia.org/wiki/SOAP
6 http://en.wikipedia.org/wiki/Enterprise_service_bus
7 http://en.wikipedia.org/wiki/BPEL
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 6
7. WHITE PAPER: SOA
Customer Cases
Orange
Die Kunden des Telekommunkationsunternehmens die zur Implementierung der Geschäftsprozesse von
Orange in Frankreich können über unterschied- Orange benötigt werden. In dieser Umgebung
liche Kanäle Kontakt mit dem wird auch der Uniserv Datenqualitätsservice für die
Unternehmen aufnehmen. Sie Validierung, Restrukturierung und Normierung von
können das Web-Portal von Kundenadressen bereitgestellt. Dieser service-orien-
Orange im Internet besuchen, tierte Ansatz macht es möglich, dass in unterschied-
das Call-Center von Orange lichen Prozessen und in unterschiedlichen Kanälen
anrufen und sie können dieselben Services eingesetzt werden. Egal, ob es
das Handy-Geschäft eines Vertragspartners von sich um die Anlage eines neuen Orange-Kunden
Orange besuchen. Doch unabhängig davon, wel- oder um die Änderung der Adresse eines beste-
chen Kontaktkanal der Kunde wählt, muss sicher- henden Kunden handelt und egal über welchen
gestellt sein, dass die entsprechenden Prozesse Kontaktkanal ein Prozess ausgelöst wird - die zugrun-
in derselben Qualität ablaufen. Ein wichtiger deliegende service-orientierte Architektur sorgt in
Bestandteil dieser Prozessqualität besteht in der jedem Fall dafür, dass die ablaufenden Prozesse
Sicherstellung korrekter Kundenadressen. konsistent gestaltet sind und auf dieselben Services
Technische Basis ist der Open-Source Java zurückgreifen können. Damit ist es möglich, unter-
Applikationsserver JONAS. Dieser JEE Server ist der nehmensweit einen einheitlich hohen Standard der
zentrale Drehpunkt für die Bereitstellung von Services, Qualität der Adressdaten zu gewährleisten.
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 7
8. WHITE PAPER: SOA
Customer Cases
WinGroup AG
Die deutsche WinGroup AG, ein
Dienstleistungsverbund im Bereich Sales und
Marketing, bietet seinen
Kunden ein umfangreiches
Angebot an Services in
den Bereichen Call-Center,
Lettershop, Dialogmarketing sowie IT-Services an.
Um über alle Servicebereiche und kundenspezi-
fischen Applikationen hinweg ein konstant hohes
Qualitätsniveau der zugrundeliegenden Prozesse
zu gewährleisten, hat die Tochtergesellschaft
WinLogic eine service-orientierte Architektur, basie-
rend auf einem Enterprise Service Bus, entwickelt.
Dieser stellt die zentrale Middleware dar, um alle
Applikationen im Unternehmen an die zentralen
Services anzudocken. Im Bereich Datenqualität
sind hier die Adressprüfung und der Dublettencheck
von Uniserv angebunden.
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 8
9. WHITE PAPER: SOA
Leichtgewicht REST –
wenn SOAP zu schwerfällig ist
Auch wenn das SOAP-basierte Protokoll für die Grund des Overheads, den das SOAP-Protokoll
Einbindung in typische Enterprise-Middleware die mit sich bringt, für dieses Anwendungsszenario
ideale Lösung zu sein scheint, gibt es abweichende nicht immer geeignet. RESTful Web Services8 sind
Anwendungen, für die Alternativen wie zum Beispiel im Vergleich zu SOAP-basierten Web Services
RESTful Services vorteilhaft sind. Das ist insbeson- ausgesprochen schlank. Der Aufruf erfolgt mit
dere dann der Fall, wenn Datenqualitätsservices Mitteln des http-Protokolls, in der Folge werden die
direkt in der Präsentationsschicht angesprochen Aufrufargumente in der URL kodiert. Das Ergebnis
werden sollen, die wiederum HTML/AJAX-basiert wird im Falle eines Aufrufs aus JavaScript im
ist. Ein für diesen Fall typisches Szenario sind Idealfall im JSON9- Format zurückgeliefert. Daraus
Eingabehilfen, die nach einer partiellen Eingabe
des Anwenders diese Eingabe automatisch SO GESTALTETE SERVICES LASSEN
vervollständigen oder basierend auf der parti- SICH IDEAL IN TYPISCHEN
ellen Eingabe Vorschläge zur Vervollständigung WEB 2.0 ANWENDUNGEN NUTZEN
anbieten. Eingabehilfen sind naturgemäß in
der Präsentationsschicht angesiedelt. Sie stellen
allerdings deutlich höhere Anforderungen an die resultiert ein JavaScript-Code, der vom JavaScript-
Antwortzeit, da sie im Rahmen der Eingabe häufi- Interpreter des Browsers direkt interpretiert werden
ger – der Regel entsprechend nach jedem einge- kann, um so das Ergebnis des Aufrufs direkt als
gebenen Zeichen – aufgerufen werden. JavaScript-Objekte bereitzustellen. So gestaltete
Services lassen sich ideal in typischen Web 2.0
Zwar bieten sich im Bereich der Adresseingabe Anwendungen nutzen.
für diese Realisierung dieselben Services an, die
auch für die Adressvalidierung genutzt werden.
Allerdings sind SOAP-basierte Web Services auf
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 9
10. WHITE PAPER: SOA
SOAP –
die feinen Unterschiede
Auch bei der Adaption von proprietären Darüber hinaus bietet die SOAP-Spezifikation zwei
Schnittstellen an eine auf SOAP-basierende grundsätzliche Möglichkeiten, die Verknüpfung
Kommunikation ist eine Lernkurve zu bewältigen. zwischen dem Paketaufbau in XML und den
Die Pakete, die im Rahmen einer SOAP- basier- Konstrukten der Programmiersprache, die das
ten Kommunikation ausgetauscht werden, werden Paket bereitstellt oder interpretiert, in der WSDL zu
in einem Metaformat, der sogenannten WSDL10 definieren. Der sogenannte „rpc-style“ entspricht
(Web Service Description Language), beschrieben. – wie das Akronym andeutet – eher dem klassi-
Zunächst muss bei der Entwicklung der WSDL schen Remote Procedure Call (RPC) und model-
sorgfältig darauf geachtet werden, dass die ver- liert Operationen als Methodenaufrufe, die sich
wendeten Datentypen von allen Zielsprachen und von lokalen Aufrufen nicht unterscheiden. Sie sind
ideal, wenn der Web-Service aus einer objektori-
ZUNÄCHST MUSS BEI DER ENTWICK- entierten Programmiersprache wie Java oder C#
LUNG […] SORGFÄLTIG DARAUF aufgerufen werden soll. Der sogenannte „docu-
GEACHTET WERDEN, DASS DIE VER- ment-style“ ist eher geeignet, komplexe Inhalte als
WENDETEN DATENTYPEN VON ALLEN Ergebnis zu modellieren, die als XML-Dokument mit
ZIELSPRACHEN UND –SYSTEMEN, […] eigenem XML-Schema dargestellt werden. Damit
TATSÄCHLICH UNTERSTÜTZT WERDEN. ist zum Einen eine Validierung mit Standard-XML-
Mitteln gegen das XML-Schema möglich, zum
–systemen, in denen der Service konsumiert wer- anderen kann mit Standard-XML-Mitteln oder ent-
den soll, auch tatsächlich unterstützt werden. Bei sprechenden Frameworks das Ergebnisdokument
einer rein unternehmensinternen Entwicklung mit leicht weiterverarbeitet, transformiert oder für die
homogener Softwareinfrastruktur – zum Beispiel Präsentationsschicht aufgearbeitet werden. Beide
JEE oder .NET – ist dieser Aspekt relativ unkritisch. Varianten haben ihre Vorteile und Nachteile.
Bei einem Datenqualitätsservice, der in den unter- Services, die den Anspruch haben, aus beliebigen
schiedlichsten Umgebungen einsetzbar sein soll, Kontexten aufrufbar zu sein, müssen möglicherwei-
die vorher möglicherweise gar nicht alle bekannt se sogar beide Varianten zur Verfügung stellen.
sind, ist dieses Kriterium aber essentiell.
8 http://en.wikipedia.org/wiki/REST
9 http://en.wikipedia.org/wiki/JSON
10 http://en.wikipedia.org/wiki/Web_Services_Description_Language
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 10
11. WHITE PAPER: SOA
Web Services sind ihrer Natur nach zustands- sie die meisten Applikationsserver bieten oder wie
los. Das bedeutet, dass im Idealfall keine sie auch als Open Source-Erweiterung existieren,
Teilergebnisse, sondern das Gesamtergebnis als eingesetzt werden. Somit wird ein effektives und
Resultat des Aufrufs zurückgeliefert wird und zwei konfigurierbares Pooling ermöglicht.
aufeinanderfolgende Aufrufe völlig unabhängig
voneinander sind. Gerade die letzten beiden Punkte erfordern in der
Regel ein, zumindest partielles, Redesign, wenn die
bestehende Funktionalität als Web Service bereitge-
WEB SERVICES SIND IHRER NATUR
stellt werden soll.
NACH ZUSTANDSLOS. […] WEB
SERVICES MÜSSEN SKALIERBAR SEIN.
Web Services müssen skalierbar sein. Eine
Voraussetzung dafür ist die beschriebene
Zustandslosigkeit. Darüber hinaus sollte der Web
Service möglichst wenig bis gar nicht auf globale
Ressourcen zugreifen. Sollten diese dennoch benötigt
werden, sollte die Verwaltung und Synchronisation
des Zugriffs auf diese Ressourcen keineswegs ad-
hoc für den jeweiligen Web-Service implementiert
werden. Stattdessen sollten Ressourcen-Pools, wie
8 http://en.wikipedia.org/wiki/REST
9 http://en.wikipedia.org/wiki/JSON
10 http://en.wikipedia.org/wiki/Web_Services_Description_Language
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 11
12. WHITE PAPER: SOA
SOA verwischt die Unter-
scheidung zwischen » on Premise «
und » on Demand «
Die Bereitstellung von Software Services und Bei landesspezifischen Postleitzahlverzeichnissen
Applikationen über das Internet, wie sie unter den fallen diese Aufwände und Ausgaben für jedes
Schlagworten „Software on Demand“, „Software Land an, für das Adressen geprüft werden. Das
as a Service11“ oder „Cloud Computing“ ange- macht den Einsatz solcher Lösungen nur für größere
sprochen wird, ist ein Thema mit wachsender
Bedeutung. Vielfach wird ein grundsätzlicher DENN IM RAHMEN EINER SERVICE-
und tiefgehender Widerspruch zwischen lokal ORIENTIERTEN ARCHITEKTUR IST ES NICHT
installierter Software („on Premise“) und über ENTSCHEIDEND, WIE DER JEWEILIGE
das Internet genutzte Software („on Demand“) SERVICE BEREITGESTELLT WIRD.
dargestellt. Aus der SOA-Perspektive ist das nicht
der Fall. Denn im Rahmen einer service-orientierten Datenmengen interessant. Diese Einschränkung ent-
Architektur ist es nicht entscheidend, wie der jewei- fällt mit einer Bereitstellung des Services als SaaS-
lige Service bereitgestellt wird. Gerade im Bereich Angebot, bei dem ausschließlich auf Basis der
der Datenqualitätsservices, die Validierungen und durchgeführten Transaktionen abgerechnet wird.
Korrekturen durch Abgleiche gegen Referenzdaten Durch die Nutzung in einer service-orientierten
durchführen, bietet die Bereitstellung eines Architektur lassen sich auch lokal installierte und
Service über das Internet - als Alternative zu über das Internet genutzte Services beliebig kom-
einem lokal installierten Server - interessante neue binieren oder gegeneinander austauschen. Somit
Anwendungsmöglichkeiten. kann die für den jeweiligen Anwender optimale
Lösung gefunden werden, die auch im Nachhinein
Die für den Service benötigten Referenzdaten flexibel an veränderte Rahmenbedingungen ange-
müssen regelmäßig aktualisiert werden. Das passt werden kann.
bedeutet sowohl regelmäßig wiederkehren-
den manuellen Aufwand als auch regelmäßige
Abonnementgebühren, die an den Datenlieferanten
zu zahlen sind.
11 http://en.wikipedia.org/wiki/Software_as_a_Service
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 12
13. WHITE PAPER: SOA
Schlussfolgerungen
Aus den im Vorfeld beschriebenen Erfahrungen ergeben sich
folgende Konsequenzen unter Berücksichtigung zweier Aspekte:
Welche Anforderungen stellen sich
ASPEKT EINS:
an Datenqualitätsfunktionen, die in einer SOA-
Umgebung eingesetzt werden sollen?
– Die Funktionen müssen über SOAP als Services – Es sollte geprüft werden, ob ein alternatives
ansprechbar sein. So ist eine Integration in Nutzungsszenario, in dem der Service über
praktisch alle Infrastrukturen zur service-orientier- das Internet bereitgestellt wird, wirtschaftliche
ten Implementierung von Geschäftsprozessen oder technische Vorteile bringt, und ob der
gewährleistet. Allerdings ist im Detail darauf Serviceprovider ein solches Szenario unter-
zu achten, dass ein Mapping zwischen den stützt.
XML-Elementen der Service-Beschreibung und
den entsprechenden Konstrukten der jeweiligen
Serverumgebung abbildbar ist.
– Falls der Einsatz in der Präsentationsschicht
absehbar ist, ist zu prüfen, ob eine RESTful
Service-Implementierung erforderlich ist.
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 13
14. WHITE PAPER: SOA
ASPEKT ZWEI: Welche Aspekte sind zu berück-
sichtigen, wenn Funktionen zur Validierung,
Anreicherung, Aufbereitung von Daten SOA-
tauglich gemacht werden sollen?
– Die Einsatzszenarien müssen klar definiert wer- – Die Skalierbarkeit des Service muss sichergestellt
den. Besonders wichtig ist die Fragestellung, sein: Falls der Web-Service globale Ressourcen
ob der Einsatzbereich der Services im Rahmen benötigt, z.B. eine Datenbankverbindung,
der Geschäftslogik oder der Präsentationslogik dann sollten diese durch einen entsprechen-
erfolgt. Im ersten Fall erfolgt die Integration im den Ressourcenpool im Servercontainer ver-
Applikationsserver, im Enterprise Services Bus waltet werden. Andernfalls werden diese
oder einer BPEL-Engine, im zweiten Fall in einer Ressourcen schnell zum Nadelöhr, das eine
graphischen Oberfläche, die wiederum eigene echte Skalierbarkeit des Service verhindert.
Anforderungen stellen kann. Abhängig davon
erfolgt die Entscheidung, ob SOAP-basierte – Der Service sollte internetfähig sein, d.h. es soll-
und/oder RESTful Services angemessener sind. te für die Funktionsfähigkeit des Services keine
Rolle spielen, ob er im lokalen Netz oder über
– Die Zielsysteme und –sprachen, in welchen der das Internet bereitgestellt wird. Damit erweitern
Service genutzt werden soll, müssen festgelegt sich die Einsatzmöglichkeiten enorm.
werden. Davon abhängig ist die Entscheidung,
wie komplex die Modellierung - bezogen auf
die verwendeten XML-Strukturen und XML- Für mehr Informationen
Datentypen der Aufrufergebnisse - sein kann. über SOA besuchen Sie uns im Internet unter
www.uniserv.com/SOA. Oder nehmen Sie
– Der Service muss zustandslos entworfen wer- direkt mit uns Kontakt auf:
den, d.h. er muss ohne Speicherung eines inter-
nen Zustandes zwischen zwei Aufrufen funktio-
nieren. Falls ein Zustand zwischen den Aufrufen
erforderlich ist, dann muss der Zustand beim
Folgeaufruf wieder übergeben oder in geeigne- Wir freuen uns auf Sie und beraten und
ter Weise persistent gemacht werden. begleiten Sie gerne bei und in Ihrem Projekt.
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 14
15. WHITE PAPER: SOA
Über Uniserv
Uniserv ist der größte, spezialisierte Anbieter von Data Quality Solutions in
Europa mit international einsetzbarem Softwareportfolio sowie Services zur
Qualitätssicherung von Daten in Business Intelligence, bei CRM-Anwendungen,
Data Warehousing, eBusiness sowie Direct- und Database-Marketing.
Mit mehreren Tausend Installationen weltweit unterstützt
Uniserv Hunderte von Kunden in ihrem Bemühen, den
Single View of Customer in ihrer Kundendatenbank ab- DATEN-
MIGRATIONS-
zubilden. Uniserv beschäftigt am Stammsitz in Pforzheim PROJEKTE
sowie in der Niederlassung in Paris, Frankreich, über eBUSINESS
110 Mitarbeiter und zählt branchenübergreifend und
international zahlreiche renommierte Unternehmen wie ERP
beispielsweise ADAC, Allianz, BMW, Commerzbank,
DBV Winterthur, Deutsche Bank, Deutsche Börse Group, COMPLIANCE/
France Telecom, Greenpeace, GEZ, Heineken, Johnson SPERRLISTEN
CRM
& Johnson, Nestlé, Payback, PSA Peugeot Citroën so-
wie Time Life und Union Investment zu seinen Kunden.
Weitere Informationen sind unter
www.uniserv.com erhältlich SOA
DIALOG-
UND
DIREKT- MDM/CDI
MARKETING
ON PREMISE/
ON DEMAND
BI/BDW
CPM
Erfahrung: Marktstellung: Mitarbeiter:
ÜBER 40 JAHRE MARKTFÜHRER EUROPA ÜBER 110
UNISERV GmbH Kontakt:
Rastatter Straße 13 • 75179 Pforzheim • T +49 7231 936-0 • 07231/936-1000
F +49 7231 936-3002 • E info@uniserv.com • www.uniserv.com
© Copyright Uniserv • Pforzheim • All rights reserved.
© UNISERV GmbH / +49 7231 936-1000 / All rights reserved. Seite 15