Download pdf - NEW VERSION: Data Quality und SOA

Seite 1

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.

WHITE PAPER / Data Quality meets SOA – Datenqualität für alle Geschäftsprozesse verfügbar machen

WHITE PAPER: SOA

http://www.uniserv.com/de/solutions/SOA.php


http://www.uniserv.com/de/index.php


Seite 2© UNISERV GmbH / +49 7231 936-1000 / All rights reserved.

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.

WHITE PAPER: SOA

Ausgangspunkt Datenqualitäts-ServicesUm 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.

Ein wichtiges Ziel im Rahmen der Verbesserung von Datenqualität besteht darin, unvollständige oder fehlerhafte Daten gar nicht erst in der Datenbank zu speichern. Mögliche Probleme sollen bereits bei der Erfassung erkannt und daraufhin entwe-der automatisch oder mittels eines entsprechenden Feedbacks an den Anwender durch diesen berei-nigt werden. Spezialisierte Suchindizes sorgen dafür, dass eine Suche in Datenbeständen mit 1.000.000 bis hin zu 100.000.000 Datensätzen auch bei abweichender Schreibweise im Regelfall nur den Bruchteil einer Sekunde benötigt. Doch diese Antwortzeiten erfordern ein intelligentes Caching der Indizes. Das wiederum kann sehr effi-zient durch die Implementierung der Software als zentralen Service gewährleistet werden, der von einem eigenen Server zur Verfügung gestellt wird.

Neben der Antwortzeit spielte bereits bei Datenqualitäts-Services die Integration in unter-schiedlichste Umgebungen eine wichtige Rolle. Für das Erreichen dieses Ziels ist eine Entkopplung des Datenqualitätsservices vom Servicekonsumenten sowie die Nutzung über ein Client/Server-Protokoll wichtig. Daher wurde diese Funktionalität im Bereich Datenqualität, zumindest für anspruchsvolle-re Anwendungen, schon vor der „Erfindung“ service-orientierter Architekturen als Service bereitgestellt und genutzt. So war es möglich, sowohl die hohen Anforderungen an die Antwortzeiten zu erfüllen als auch die Bereitstellung von Funktionalitäten für unter-schiedlichste Umgebungen zu gewährleisten.

http://www.uniserv.com/de/products/data-quality-functions-features/address-validation-data-capture.php


http://www.uniserv.com/de/products/data-quality-functions-features/address-retrieval-intelligent-search.php



Vom » fat client « zur3-Schichten-ArchitekturLayered Architecture

Die typische Architektur aus den Anfangszeiten der Client/Server-Welt bestand aus einer Datenbank, die neben der Speicherung von Transaktions- und Stammdaten auch eine asynchrone Kommunikation zwischen unterschiedlichen Systemkomponenten und damit eine Entkopplung dieser Komponenten 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.

LAYERED ARCHITECTURE

Name

Street

Postcode

Customer

ROLE

Supplier

Reseller

Name

Street

Postcode

Customer

Supplier

Reseller

FAT CLIENT CLIENT

APPLICATION SERVER

ROLE

WHITE PAPER: SOA


WHITE PAPER: SOA

Diese Situation hat sich in den vergangenen Jahren grundlegend verändert. Ausgangspunkt dafür war vor allem die Etablierung von Standards im Rahmen der JEE3 (Java Enterprise Edition) und in der Folge die Bereitstellung leistungsfähiger Implementierungen dieser Standards sowohl als kommerzielle Produkte als auch als Open-Source-Lösungen.

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

LAYERED ARCHITECTURE

Name

Street

Postcode

Customer

ROLE

Supplier

Reseller

Name

Street

Postcode

Customer

Supplier

Reseller

FAT CLIENT CLIENT

APPLICATION SERVER

ROLE

DIE EINFACHE INTEGRATION IN DEN APPLIKATIONSSERVER – SEI ES AUF BASIS EINER JEE- ODER EINER .NET-ARCHITEKTUR – TRAT DAMIT JETZT IN DEN VORDERGRUND.


WHITE PAPER: SOA

SOAP als Enabler für SOA

Richtig effektiv wird SOA erst durch die Etablierung 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

Proprietary Protocol



WHITE PAPER: SOA

Damit haben sich SOAP-basierte Web Services 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.

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

SOAP Protocol

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.

http://www.uniserv.com/de/solutions/CRM.php


WHITE PAPER: SOA

Customer CasesOrangeDie Kunden des Telekommunkationsunternehmens Orange in Frankreich können über unterschied-

liche Kanäle Kontakt mit dem Unternehmen aufnehmen. Sie können das Web-Portal von Orange im Internet besuchen, das Call-Center von Orange anrufen und sie können

das Handy-Geschäft eines Vertragspartners von Orange besuchen. Doch unabhängig davon, wel-chen Kontaktkanal der Kunde wählt, muss sicher-gestellt sein, dass die entsprechenden Prozesse in derselben Qualität ablaufen. Ein wichtiger Bestandteil dieser Prozessqualität besteht in der Sicherstellung korrekter Kundenadressen.Technische Basis ist der Open-Source Java Applikationsserver JONAS. Dieser JEE Server ist der zentrale Drehpunkt für die Bereitstellung von Services,

die zur Implementierung der Geschäftsprozesse von Orange benötigt werden. In dieser Umgebung wird auch der Uniserv Datenqualitätsservice für die Validierung, Restrukturierung und Normierung von Kundenadressen bereitgestellt. Dieser service-orien-tierte Ansatz macht es möglich, dass in unterschied-lichen Prozessen und in unterschiedlichen Kanälen dieselben Services eingesetzt werden. Egal, ob es sich um die Anlage eines neuen Orange-Kunden oder um die Änderung der Adresse eines beste-henden Kunden handelt und egal über welchen Kontaktkanal ein Prozess ausgelöst wird - die zugrun-deliegende service-orientierte Architektur sorgt in jedem Fall dafür, dass die ablaufenden Prozesse konsistent gestaltet sind und auf dieselben Services zurückgreifen können. Damit ist es möglich, unter-nehmensweit einen einheitlich hohen Standard der Qualität der Adressdaten zu gewährleisten.



WHITE PAPER: SOA

Customer CasesWinGroup AGDie 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.


http://www.uniserv.com/de/products/data-quality-functions-features/address-retrieval-intelligent-search.php


WHITE PAPER: SOA

Leichtgewicht REST – wenn SOAP zu schwerfällig ist

SO GESTALTETE SERVICES LASSEN SICH IDEAL IN TYPISCHEN WEB 2.0 ANWENDUNGEN NUTZEN

Auch wenn das SOAP-basierte Protokoll für die Einbindung in typische Enterprise-Middleware die ideale Lösung zu sein scheint, gibt es abweichende Anwendungen, für die Alternativen wie zum Beispiel RESTful Services vorteilhaft sind. Das ist insbeson-dere dann der Fall, wenn Datenqualitätsservices direkt in der Präsentationsschicht angesprochen werden sollen, die wiederum HTML/AJAX-basiert ist. Ein für diesen Fall typisches Szenario sind Eingabehilfen, die nach einer partiellen Eingabe des Anwenders diese Eingabe automatisch vervollständigen oder basierend auf der parti-ellen Eingabe Vorschläge zur Vervollständigung anbieten. Eingabehilfen sind naturgemäß in der Präsentationsschicht angesiedelt. Sie stellen allerdings deutlich höhere Anforderungen an die Antwortzeit, da sie im Rahmen der Eingabe häufi-ger – der Regel entsprechend nach jedem einge-gebenen Zeichen – aufgerufen werden.

Zwar bieten sich im Bereich der Adresseingabe für diese Realisierung dieselben Services an, die auch für die Adressvalidierung genutzt werden. Allerdings sind SOAP-basierte Web Services auf

Grund des Overheads, den das SOAP-Protokoll mit sich bringt, für dieses Anwendungsszenario nicht immer geeignet. RESTful Web Services8 sind im Vergleich zu SOAP-basierten Web Services ausgesprochen schlank. Der Aufruf erfolgt mit Mitteln des http-Protokolls, in der Folge werden die Aufrufargumente in der URL kodiert. Das Ergebnis wird im Falle eines Aufrufs aus JavaScript im Idealfall im JSON9- Format zurückgeliefert. Daraus

resultiert ein JavaScript-Code, der vom JavaScript-Interpreter des Browsers direkt interpretiert werden kann, um so das Ergebnis des Aufrufs direkt als JavaScript-Objekte bereitzustellen. So gestaltete Services lassen sich ideal in typischen Web 2.0 Anwendungen nutzen.


WHITE PAPER: SOA

SOAP – die feinen Unterschiede

8 http://en.wikipedia.org/wiki/REST

9 http://en.wikipedia.org/wiki/JSON

10 http://en.wikipedia.org/wiki/Web_Services_Description_Language

ZUNÄCHST MUSS BEI DER ENTWICK-LUNG […] SORGFÄLTIG DARAUF GEACHTET WERDEN, DASS DIE VER-WENDETEN DATENTYPEN VON ALLEN ZIELSPRACHEN UND –SYSTEMEN, […] TATSÄCHLICH UNTERSTÜTZT WERDEN.

Auch bei der Adaption von proprietären Schnittstellen an eine auf SOAP-basierende Kommunikation ist eine Lernkurve zu bewältigen. Die Pakete, die im Rahmen einer SOAP- basier-ten Kommunikation ausgetauscht werden, werden in einem Metaformat, der sogenannten WSDL10 (Web Service Description Language), beschrieben. Zunächst muss bei der Entwicklung der WSDL sorgfältig darauf geachtet werden, dass die ver-wendeten Datentypen von allen Zielsprachen und

–systemen, in denen der Service konsumiert wer-den soll, auch tatsächlich unterstützt werden. Bei einer rein unternehmensinternen Entwicklung mit homogener Softwareinfrastruktur – zum Beispiel JEE oder .NET – ist dieser Aspekt relativ unkritisch. Bei einem Datenqualitätsservice, der in den unter-schiedlichsten Umgebungen einsetzbar sein soll, die vorher möglicherweise gar nicht alle bekannt sind, ist dieses Kriterium aber essentiell.

Darüber hinaus bietet die SOAP-Spezifikation zwei grundsätzliche Möglichkeiten, die Verknüpfung zwischen dem Paketaufbau in XML und den Konstrukten der Programmiersprache, die das Paket bereitstellt oder interpretiert, in der WSDL zu definieren. Der sogenannte „rpc-style“ entspricht – wie das Akronym andeutet – eher dem klassi-schen Remote Procedure Call (RPC) und model-liert Operationen als Methodenaufrufe, die sich von lokalen Aufrufen nicht unterscheiden. Sie sind ideal, wenn der Web-Service aus einer objektori-entierten Programmiersprache wie Java oder C# aufgerufen werden soll. Der sogenannte „docu-ment-style“ ist eher geeignet, komplexe Inhalte als Ergebnis zu modellieren, die als XML-Dokument mit eigenem XML-Schema dargestellt werden. Damit ist zum Einen eine Validierung mit Standard-XML-Mitteln gegen das XML-Schema möglich, zum anderen kann mit Standard-XML-Mitteln oder ent-sprechenden Frameworks das Ergebnisdokument leicht weiterverarbeitet, transformiert oder für die Präsentationsschicht aufgearbeitet werden. Beide Varianten haben ihre Vorteile und Nachteile. Services, die den Anspruch haben, aus beliebigen Kontexten aufrufbar zu sein, müssen möglicherwei-se sogar beide Varianten zur Verfügung stellen.


WHITE PAPER: SOA

Web Services sind ihrer Natur nach zustands-los. Das bedeutet, dass im Idealfall keine Teilergebnisse, sondern das Gesamtergebnis als Resultat des Aufrufs zurückgeliefert wird und zwei aufeinanderfolgende Aufrufe völlig unabhängig voneinander sind.

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

WEB SERVICES SIND IHRER NATUR NACH ZUSTANDSLOS. […] WEB SERVICES MÜSSEN SKALIERBAR SEIN.

8 http://en.wikipedia.org/wiki/REST

9 http://en.wikipedia.org/wiki/JSON

10 http://en.wikipedia.org/wiki/Web_Services_Description_Language

sie die meisten Applikationsserver bieten oder wie sie auch als Open Source-Erweiterung existieren, eingesetzt werden. Somit wird ein effektives und konfigurierbares Pooling ermöglicht.

Gerade die letzten beiden Punkte erfordern in der Regel ein, zumindest partielles, Redesign, wenn die bestehende Funktionalität als Web Service bereitge-stellt werden soll.


WHITE PAPER: SOA

SOA verwischt die Unter-scheidung zwischen » on Premise « und » on Demand «

11 http://en.wikipedia.org/wiki/Software_as_a_Service

DENN IM RAHMEN EINER SERVICE-ORIENTIERTEN ARCHITEKTUR IST ES NICHT ENTSCHEIDEND, WIE DER JEWEILIGE SERVICE BEREITGESTELLT WIRD.

Die Bereitstellung von Software Services und Applikationen über das Internet, wie sie unter den Schlagworten „Software on Demand“, „Software as a Service11“ oder „Cloud Computing“ ange-sprochen wird, ist ein Thema mit wachsender Bedeutung. Vielfach wird ein grundsätzlicher und tiefgehender Widerspruch zwischen lokal installierter Software („on Premise“) und über das Internet genutzte Software („on Demand“) dargestellt. Aus der SOA-Perspektive ist das nicht der Fall. Denn im Rahmen einer service-orientierten Architektur ist es nicht entscheidend, wie der jewei-lige Service bereitgestellt wird. Gerade im Bereich der Datenqualitätsservices, die Validierungen und Korrekturen durch Abgleiche gegen Referenzdaten durchführen, bietet die Bereitstellung eines Service über das Internet - als Alternative zu einem lokal installierten Server - interessante neue Anwendungsmöglichkeiten.

Die für den Service benötigten Referenzdaten müssen regelmäßig aktualisiert werden. Das bedeutet sowohl regelmäßig wiederkehren-den manuellen Aufwand als auch regelmäßige Abonnementgebühren, die an den Datenlieferanten zu zahlen sind.

Bei landesspezifischen Postleitzahlverzeichnissen fallen diese Aufwände und Ausgaben für jedes Land an, für das Adressen geprüft werden. Das macht den Einsatz solcher Lösungen nur für größere

Datenmengen interessant. Diese Einschränkung ent-fällt mit einer Bereitstellung des Services als SaaS-Angebot, bei dem ausschließlich auf Basis der durchgeführten Transaktionen abgerechnet wird. Durch die Nutzung in einer service-orientierten Architektur lassen sich auch lokal installierte und über das Internet genutzte Services beliebig kom-binieren oder gegeneinander austauschen. Somit kann die für den jeweiligen Anwender optimale Lösung gefunden werden, die auch im Nachhinein flexibel an veränderte Rahmenbedingungen ange-passt werden kann.

http://www.data-quality-on-demand.com

http://www.data-quality-on-demand.com/


ASPEKT EINS: Welche Anforderungen stellen sich an Datenqualitätsfunktionen, die in einer SOA-Umgebung eingesetzt werden sollen?

WHITE PAPER: SOA

SchlussfolgerungenAus den im Vorfeld beschriebenen Erfahrungen ergeben sich folgende Konsequenzen unter Berücksichtigung zweier Aspekte:

– Die Funktionen müssen über SOAP als Services ansprechbar sein. So ist eine Integration in praktisch alle Infrastrukturen zur service-orientier-ten Implementierung von Geschäftsprozessen gewährleistet. Allerdings ist im Detail darauf zu achten, dass ein Mapping zwischen den 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.

– Es sollte geprüft werden, ob ein alternatives Nutzungsszenario, in dem der Service über das Internet bereitgestellt wird, wirtschaftliche oder technische Vorteile bringt, und ob der Serviceprovider ein solches Szenario unter-stützt.


WHITE PAPER: SOA

Für mehr Informationenüber SOA besuchen Sie uns im Internet unter www.uniserv.com/SOA. Oder nehmen Sie direkt mit uns Kontakt auf:

Wir freuen uns auf Sie und beraten und begleiten Sie gerne bei und in Ihrem Projekt.

– Die Einsatzszenarien müssen klar definiert wer-den. Besonders wichtig ist die Fragestellung, ob der Einsatzbereich der Services im Rahmen der Geschäftslogik oder der Präsentationslogik erfolgt. Im ersten Fall erfolgt die Integration im Applikationsserver, im Enterprise Services Bus oder einer BPEL-Engine, im zweiten Fall in einer graphischen Oberfläche, die wiederum eigene Anforderungen stellen kann. Abhängig davon erfolgt die Entscheidung, ob SOAP-basierte und/oder RESTful Services angemessener sind.

– Die Zielsysteme und –sprachen, in welchen der Service genutzt werden soll, müssen festgelegt werden. Davon abhängig ist die Entscheidung, wie komplex die Modellierung - bezogen auf die verwendeten XML-Strukturen und XML-Datentypen der Aufrufergebnisse - sein kann.

– Der Service muss zustandslos entworfen wer-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-ter Weise persistent gemacht werden.

ASPEKT ZWEI: Welche Aspekte sind zu berück-sichtigen, wenn Funktionen zur Validierung, Anreicherung, Aufbereitung von Daten SOA-tauglich gemacht werden sollen?

– Die Skalierbarkeit des Service muss sichergestellt sein: Falls der Web-Service globale Ressourcen benötigt, z.B. eine Datenbankverbindung, dann sollten diese durch einen entsprechen-den Ressourcenpool im Servercontainer ver-waltet werden. Andernfalls werden diese Ressourcen schnell zum Nadelöhr, das eine echte Skalierbarkeit des Service verhindert.

– Der Service sollte internetfähig sein, d.h. es soll-te für die Funktionsfähigkeit des Services keine Rolle spielen, ob er im lokalen Netz oder über das Internet bereitgestellt wird. Damit erweitern sich die Einsatzmöglichkeiten enorm.

www.uniserv.com/SOA

http://www.uniserv.com/de/contact/contact.php


Über UniservUniserv 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-zubilden. Uniserv beschäftigt am Stammsitz in Pforzheim sowie in der Niederlassung in Paris, Frankreich, über 110 Mitarbeiter und zählt branchenübergreifend und international zahlreiche renommierte Unternehmen wie beispielsweise ADAC, Allianz, BMW, Commerzbank, DBV Winterthur, Deutsche Bank, Deutsche Börse Group, France Telecom, Greenpeace, GEZ, Heineken, Johnson & 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

Erfahrung: ÜBER 40 JAHRE

Marktstellung:MARKTFÜHRER EUROPA

Mitarbeiter: ÜBER 110

DIALOG-UND DIREKT-

MARKETING

BI/BDW

CPM

CRM

ERP

eBUSINESS

DATEN-MIGRATIONS-

PROJEKTE

SOA

ON PREMISE/ON DEMAND

MDM/CDI

COMPLIANCE/SPERRLISTEN

UNISERV GmbH Rastatter Straße 13 • 75179 Pforzheim • T +49 7231 936-0 • F +49 7231 936-3002 • E [email protected] • www.uniserv.com© Copyright Uniserv • Pforzheim • All rights reserved.

WHITE PAPER: SOA

Kontakt:07231/936-1000
