• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
NEW VERSION: Data Quality und SOA
 

NEW VERSION: Data Quality und SOA

on

  • 1,562 views

Data Quality meets SOA –

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

Statistics

Views

Total Views
1,562
Views on SlideShare
1,562
Embed Views
0

Actions

Likes
1
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    NEW VERSION: Data Quality und SOA NEW VERSION: Data Quality und SOA Document Transcript

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