Richtlinie: Servicerealisierung - BPEL-Services in einer SOA-Anwendung
Diese Richtlinie beschreibt eine Anwendung, die mit einer BPEL-basierten Choreographie in einem SOA-Stil erstellt wird.
Beziehungen
Hauptbeschreibung

Einführung

Diese Seite beschreibt eine Anwendung, die mit einer BPEL-basierten Choreographie in einem SOA-Stil erstellt wird. Die Erfahrungen, die während der Design- und der Entwicklungsphase dieses Projekts bereits gemacht wurden, sind für andere Benutzer, die eine BPEL-basierte Choreographie in einer serviceorientierten Architektur verwenden möchten, von Vorteil, da sie einen allgemeinen Einblick in die Materie bekommen. Der Designansatz wird - im Rahmen eines Vergleichs mit Vor- und Nachteilen - bewertet, wobei die Geschäftsanforderungen und die vorhandenen Anwendungselemente berücksichtigt werden. Diese Seite enthält Designempfehlungen und identifiziert die Merkmale, die die Verwendung eines BPEL-gesteuerten Ansatzes nahe legen.

Gemachte Erfahrungen

  1. Die richtige Segmentierung der Geschäftslogik zwischen dem Workflow und Partnerservices auszuwählen, ist immer wichtig, wenn auch zuweilen schwierig.

    Die Geschäftslogik für die Workflow-basierte Choreographie und die Partnerservices wird getrennt gehandhabt. Schließlich sollten die Partnerservices für die rechenintensive bzw. komplexe Logik zuständig sein, während die Choreographie die Logik enthält, von der man erwartet, dass sie im Falle einer Modifizierung der Geschäftsanforderungen geändert wird.

    Da diese Trennung nicht immer klar sein wird, ist es sinnvoll, die Anwendung so zu entwerfen, dass sie durch Modifizieren des Workflow und Hinzufügen neuer Partnerservices wachsen kann, anstatt vorhandende Partnerservices zu modifizieren.

    Das ist ein grundsätzlich iterativer Ansatz. Frühe Prototypen erfordern wahrscheinlich ein Refactoring der Partnerservices, um ein Design zu erzielen, das durch Hinzufügen neuer Partnerservices wachsen kann.

    In jedem Fall sollte Code, der unnötig ist oder sich nicht ändert, aus dem Ablauf herausgehalten werden.

  2. Nutzen Sie die einzigartigen Fähigkeiten von BPEL.

    Die Fähigkeit von BPEL, Partnerservices mit einer Vielzahl verschiedener Bindungen zu orchestrieren.

    Achten Sie darauf, keine Abhängigkeiten von den Merkmalen einer bestimmten Partnerimplementierung oder Partnerservicebindung herzustellen. Andernfalls komplizieren oder begrenzen Sie spätere Änderungen an der Choreographie oder der Gesamtanwendung.

    Ziehen Sie im Rahmen Ihrer Strategie zur Leistungsverbesserung in Erwägung, Zwischenergebnisse in BPEL-Variablen zu speichern.

  3. Entwerfen Sie, wo das möglich ist, Partnerservices zustandsunabhängig mit idempotenten Operationen.

    Im Kontext dieser Diskussion bedeutet Idempotenz einfach, dass ein Service mit denselben Eingabedaten mehrmals aufgerufen werden kann, mit der Erwartung, dass die Antwort für jeden Aufruf richtig ist. Dieses Merkmal bietet sowohl dem Aufrufenden als auch dem Service eine wichtige Vereinfachung hinsichtlich der Interaktion. Fehlerbehebung, Neustart nach Ausfall und Skalierung über Clustering werden vereinfacht. Für den Aufrufenden wird die Behebung von Netz-, Server- und Clientfehlern vereinfacht. Idempotenz ist ein wichtiger Indikator für eine potenziell gute Übereinstimmung mit der BPEL-Choreographie von Partnerservices.

    Wenn komplexere Interaktionen erforderlich sind, umfassen die Web-Services-Protokolle Kompensationsfunktionen, die in diesen Bereich eingesetzt werden können. Wenn Sie solche Anforderungen im allgemeinen Anwendungsdesign vermeiden können, vorausgesetzt, es kommt nichts dazwischen, wird das Ergebnis einfacher zu verwalten und zu testen sein.

Die Fallstudie

Diese Fallstudie beschreibt ein IBM Projekt, mit dem die Informationstechnologie, die vom ServicePac®-Geschäft verwendet wird, aktualisiert werden kann. Das Ziel dieses Projekts war, spezifische Problempunkte zu mindern und das ServicePac®-Geschäft so zu positionieren, dass es in Umfang und Funktionalität erweitert werden kann.

Wie viele erfolgreiche Geschäfte erlebte das ServicePac®-Geschäft von IBM eine Reihe schrittweise ablaufender Übergänge, angefangen mit der Kombination verschiedener Gewährleistungsprogramme zu drei nach geographischen Gesichtspunkten organisierten Geschäften. Später wurden Operationen, die in den einzelnen geographischen Sektoren unterschiedlich gehandhabt wurden, zu einer einzigen weltweit organisierten Operation zusammengefasst. Im Laufe der Jahre hat das ServicePac®-Geschäft immer wieder neue Angebote hinzugefügt, wie z. B. Installationsservices und Angebote zur Unterstützung neuer IBM Hardware. Obwohl das ServicePac®-Geschäft selbst eine einzige weltweit organisierte Operation ist, werden seine Produkte, die ServicePacs®, von zahlreichen IBM Geschäftsbereichen und Geschäftspartnern verkauft. Alle Anbieter haben ihre eigenen Auftragserfassungssysteme, die an ihre eigenen Geschäftsbereiche (und nicht an ServicePacs®) angepasst sind. Diese Systeme stellen ein echtes Who-is-who verschiedener Technologien dar, die zu verschiedenen Zeiten von verschiedenen Teams entwickelt wurden.

Auftragserfassungssysteme, die ServicePacs® bearbeiten, müssen bei der Auftragserfassung Validierungen durchführen, die auf vom ServicePac®-Geschäft entwickelten Anforderungen basieren. Die ServicePac-Validierung kann komplex sein. ServicePacs® werden in mehr als 100 Ländern angeboten, oft in unterschiedlicher Form. Die ServicePac®-Angebote variieren je nach Produktmodell, nach Auslieferungsland, Vertriebskanal, Auftragserfassungssystem und kundenspezifischen Informationen, z. B. bereits vorhandenen ServicePacs®.

Traditionell wurde die ServicePac®-Auftragsvalidierung im Auftragserfassungssystem durchgeführt, wobei nur die Validierungsanforderungen, die für die vom gegebenen System unterstützten Vertriebswege erforderlich waren, implementiert wurden. Mit dem Anwachsen des ServicePac®-Geschäfts sind auch die Kosten für die Kommunikation der Validierungsanforderungen und die Koordination ihrer Entwicklung, den Test und das Deployment stark angestiegen. Außerdem hat die Entwicklung einer angemessenen Auftragsvalidierung in den Auftragssystemen die Markteinführungszeit für neue Angebote deutlich erhöht.

Die Abbildung veranschaulicht einen serviceorientierten Ansatz bei der Auftragsvalidierung.

Abbildung 1 - Serviceorientierter Ansatz bei Auftragsvalidierung mit ServicePac®. Der Ansatz besteht darin, einen einzelnen Service für alle Auftragserfassungssysteme, die ServicePacs® verarbeiten, zur Verfügung zu stellen und nicht spezifische Validierungslogik in jedes Auftragssystem zu stellen.

Ein serviceorientierter Ansatz der Validierung

Schon früh war offensichtlich, dass die Validierung dem Zuständigkeitsbereich des ServicePac®-Geschäfts und nicht den einzelnen Verkaufssystemen, über die ServicePacs® bestellt werden, zugeordnet werden musste. Es wurden zwei Optionen in Betracht gezogen: Code, der die Anforderungen der Auftragsvalidierung kapselt, an alle Auftragssysteme zu verteilen oder einen zentralen Auftragsvalidierungsservice bereitzustellen. Ein wichtiger Faktor für die Auswahl des zentralen Service waren die Steuerungsprobleme, die mit dem verteilten Code zusammenhingen.

Der größte Einzelvorteil bei der Bereitstellung der Auftragsvalidierung als Service für die Auftragserfassung ist, dass die Auftragserfassungssysteme nicht mehr ihre eigene ServicePac®-Auftragsvalidierungslogik lokal implementieren, testen oder ausführen müssen. Die vielleicht größte Problemstellung (oder Befürchtung) kommt von den vielen Eignern von Auftragssystemen, die jetzt eine neue Laufzeitabhängigkeit von einem externen System, das von einer anderen Organisation betrieben wird, zu berücksichtigen haben. Wie Sie im Folgenden erfahren werden, überwog in diesem Fall der Vorteil, der sich im Endeffekt aus der Bereitstellung der Validierungslogik als Service ergab, die Probleme.

Es folgt eine kurze Zusammenfassung der architektonischen Ziele für das Projekt:

  1. Schnittstellendesign: Die Validierungsschnittstelle muss so konzipiert sein, dass die erwartete Weiterentwicklung des Geschäfts großzügig berücksichtigt wird (z. B. sollten neue Produktangebote nicht allgemein Schnittstellenmodifizierungen erfordern).

  2. Unabhängigkeit des Nachrichtenprotokolls: Der Validierungsservice muss unabhängig von der aufrufenden Plattform, vom Programmierungsmodell, der Transportschicht für das Netz oder Hardwareoptionen zugänglich sein.

  3. Beweglichkeit der Geschäftsabläufe: Die Validierungslogik wurde implementiert, um erwartete Geschäftsänderungen sicher, kosteneffizient und schnell durchzuführen, ohne Einbußen bei Leistung und Zuverlässigkeit hinnehmen oder Kompromisse hinsichtlich grundsätzlicher Designregeln eingehen zu müssen.

  4. Skalierbarkeit: Das Skalieren auf höhere Durchsätze sollte keine Reprogrammierung oder größere Funktionstests beinhalten.

Schnittstellendesign

Bei der Arbeit mit dem Geschäftseigner und Geschäftsarchitekten aller Parteien, die die Produktnomenklatur verwalten, wurde eine in sich konsistente und gut dokumentierte Taxonomie für die aktuellen und erwarteten Produkte entwickelt. Basierend auf der Taxonomie wurde ein in der XML-Schemasprache beschriebenes XML-Datenmodell entwickelt, das alle notwendigen Produkttypen mit deren Attributen ausdrückt. Wenn neue Produkte bereitgestellt werden, kann die Taxonomie sich zusammen mit potenziellen Schemaänderungen ändern, allerdings wird erwartet, dass das tatsächliche Nachrichtenformat ungeändert bleibt, so lange die neuen Angebote in den Bereich der definierten Taxonomie fallen.

Dieser Ansatz stellt dem Geschäft die gewünschte Flexibilität zur Verfügung, um neue Angebote schnell und preiswert einzuführen. Natürlich werden nicht alle möglichen Fälle abgedeckt. Wenn z. B. ein neues Produkt die Vorbedingung hat, die in den vorhandenen Nachrichtendefinitionen nicht vorweggenommen wurde, müssen die neuen Nachrichtendefinitionen richtig installiert werden.

Die Nutzinformationen einer einfachen Nachricht zu einer Validierungsanfrage, die einen einzelnen Auftrag für ein einzelnes ServicePac® für einen Kundencomputer, der durch seine Teilenummer und Seriennummer identifiziert wird, ist in Liste 1 zu sehen. Das Nachrichtenformat unterstützt mehrere Bestellungen von ServicePacs®, die neuer und vorhandener Hardware zugeordnet werden können. In bestimmten Fällen können Nachrichten Tausende verschachtelter Elemente haben.

Unabhängigkeit von Nachrichtenprotokollen

Einer der großen Vorteile der Verwendung von BPEL ist, dass die Messaging-Beziehungen zwischen den Services abstrakt in WSDL beschrieben werden, was eine gewisse Unabhängigkeit für die Nachrichtenprotokolle ermöglicht. Um den maximalen Vorteil dieser Funktion nutzen zu können, müssen Sie sorgfältig vermeiden, Implementierungen zu erstellen, die von bestimmten Merkmalen des während der Entwicklung verwendeten Nachrichtenprotokolls abhängig sind. Wenn EJB-Bindungen während der Entwicklung verwendet werden, kann der Programmierstil einen kurzen, regen Nachrichtenaustausch (d. h. einen häufigen Austausch kleiner Nachrichten) zur Folge haben. Wenn die Bindung zu einem späteren Zeitpunkt in JMS oder in SOAP over HTTP geändert wird, entsteht wahrscheinlich ein ernsthafter Leistungsengpass, der auf einen größeren Systemaufwand für diese Protokolle zurückzuführen ist. In diesem Fall können die Auswirkungen der Verschiebevorgänge, die zwischen den Bindungen stattfinden, verringert werden, indem man einen Programmierstil mit allgemein definiertem Nachrichtenaustausch praktiziert (d. h. relativ seltener Austausch größerer Nachrichtentexte). Somit macht sich der Systemaufwand, der mit der Erstellung und dem Empfang von Nachrichten verbunden ist, für größere Datenmengen bezahlt.


<?xml version="1.0" encoding="UTF-8"?>
 <spkOrderDataList>
  <header>
   <orderReference>1040-5124-001</orderReference>
   <orderDate>2004-08-15</orderDate>
   <orderingSystem>WEB</orderingSystem>
   <country>US</country>
   <distributionChannel>A</distributionChannel>
   <headerReturnCode/>
  </header>
 <spkSegmentList>
   <orderItemReference>102</orderItemReference>
   <spkPartNumber>69P9921</spkPartNumber>
   <spkType>WMAINTOPT</spkType>
   <spkQuantity>1</spkQuantity>
   <hardwareQuantity>1</hardwareQuantity>
   <spkReturnCode/>
   <hardwareSegment>
    <serialNumber>77X9182</serialNumber>
    <hardwareIdentifier>8676M2X</hardwareIdentifier>
    <hardwareReturnCode/>
   </hardwareSegment>
 </spkSegmentList>
 </spkOrderDataList>
</ServicePacData:validationRequest>

Liste 1 - Beispiel für eine einfache Nachricht, die von dem Validierungsservice, der sich aus einer einzigen Bestellung eines durch Teilenummer und Seriennummer identifizierten ServicePac® zusammensetzt, empfangen wird. Der Validierungsservice gibt die empfangene Nachricht zurück, die mit den Validierungscodes oder Fehlercodes versehen ist. Die aufrufende Komponente kann ihre eigenen Referenznummern bereitstellen, um sie zur Anfrage und Antwort in eine Beziehung zu setzen.

Eine weitere Überlegung zur Unabhängigkeit von Protokollen ist der Nachrichtenstil. In diesem Projekt wurde einem zukünftigen Bedarf an asynchronen Nachrichten durch die Erstellung von Definitionen von Validierungsnachrichten Rechnung getragen, die ein (gegenwärtig ungenutztes) Feld für die Korrelation von Anfrage- und Antwortnachrichten enthielten, obwohl die gesamte aktuelle Verwendung synchron ist und daher keine Korrelation benötigt. Die Bearbeitung solcher Problemstellungen deckt normalerweise das Nachrichten- und das Anwendungsdesign ab.

Beweglichkeit der Geschäftsabläufe

Grundsätzlich akzeptiert der ServicePac®-Validierungsservice einen Auftrag und gibt die Informationen zurück, indem er angibt, ob der Auftrag gültig ist, und, falls nicht, warum er nicht gültig ist. Wichtig ist jedoch, den Umfang für die Überarbeitung, das erneute Testen und den Leistungseinfluss zu minimieren, wenn Modifizierungen als Reaktion auf neue Geschäftsanforderungen vorgenommen werden müssen. Ganz sicher ist es von Vorteil, wenn man eine Vorstellung davon hat, wie die neuen Anforderungen beim Design der Erstimplementierung wahrscheinlich aussehen werden.

Details der Erstimplementierung:

Der Validierungsservice extrahiert die Details des ServicePac®-Auftrags, die sich aus den folgenden Bestandteilen zusammensetzen: den ServicePac®-Typen, der Hardware, auf die sie angewendet werden soll, des Zielorts der ServicePac®-Lieferung (Land), des Vertriebskanals und der Kundendaten. Die Geschäftslogik testet dann die Auftragsinformationen gegen eine Sammlung deklarativer, vom ServicePac®-Geschäft bereitgestellter Anweisungen. Die Testgruppe, die auf jede Bestellung angewendet werden muss, ist von den Bestellungsdetails abhängig. Einige der Tests erfordern den Zugriff auf zusätzliche Daten, die nur über ferne Systeme zugänglich sind.

Es gibt drei Datentypen, die für die Validierung einer Bestellung erforderlich sind: Referenzdaten dieser Anwendung, zwischengespeicherte Referenzdaten anderer Systeme und reale Daten, die bei jeder Validierung einer Bestellung von anderen Systemen abgerufen werden müssen.

Der Zugriff auf Referenzdaten dieser Anwendung erfolgt über einen Partnerservice, der als Bestandteil dieser Anwendung erstellt wurde. Dieser Service ist auch für andere Anwendungen verfügbar, die den Zugriff auf Referenzdaten dieser Anwendung benötigen.

Referenzdaten anderer Anwendungen werden durch den Zugriff auf einen Partnerservice, der als Bestandteil dieser Anwendung erstellt wurde, bereitgestellt. Wo das möglich ist, stellt der Partnerservice die von anderen Anwendungen abgerufenen Daten in den Cache, um die Anzahl der Netzzugriffe zu reduzieren. Durch Lokalisierung der Caching-Strategie im Partnerservice kann die Strategie im Laufe der Zeit nach Bedarf geändert werden, ohne dass in der übrigen Anwendung Änderungen durchgeführt werden müssen.

Daten und Zwischenergebnisse, die nur während der Lebenszeit einer Validierungsanfrage gespeichert werden müssen, werden in BPEL-Variablen gespeichert. Bei Verwendung von BPEL-Variablen ist kein Systemaufwand für vermeidbare Zugriffe auf Partnerservices mehr erforderlich, daher können BPEL-Variablen die Gesamtleistung verbessern.

Die Abbildung veranschaulicht eine topologische Sicht der Workflow-gesteuerten Implementierung der Geschäftslogik.

Abbildung 2 - Topologische Sicht der Workflow-gesteuerten Implementierung der Geschäftslogik, die festlegt, welche der rechenintensiven bzw. datenintensiven Tests zur Validierung eines bestimmtes Auftrags durchgeführt werden müssen. Dieselbe Serviceschnittstelle wird von allen Auftragserfassungssystemen verwendet, die Aufträge validieren müssen.

Im Folgenden wird die Spezifik dieser neuen Anforderungen untersucht, die anhand der mit dem Geschäft geführten Gespräche und der Untersuchung der Langzeittrends vorweggenommen werden können.

Während der Erweiterung des ServicePac®-Geschäfts werden neue Geschäftstests für die ServicePac®-Validierung erstellt. Vorhandene Tests müssen jedoch nicht geändert werden. Die Validierung neuer Produkte erfordert eine neue Gruppierung vorhandener und möglicherweise neuer Tests.

Diese Gruppe von Anforderungen passt gut zu einem Workflow-gesteuerten System, in dem der Workflow verwendet wird, um Testgruppen, die von jedem Produkttyp benötigt werden, zusammenzufügen. Die Aspekte der Tests, die rechen- bzw. datenintensiv sind, können dann in einer weniger flexiblen aber effizienteren Technologie entwickelt und als Partnerservices für die zentrale Workflow-Steuerkomponente übergeben werden (siehe Abbildung 2).

Wenn neue Geschäftsangebote zum Validierungssystem hinzugefügt werden, wird der Workflow selbst modifiziert, um den Zugriff auf die vorhandenen Partnerservices (und möglicherweise neue Partnerservices zur Unterstützung des neuen Angebots) zu ermöglichen. Vorausgesetzt, dass die Partnerservices zu Beginn richtig segmentiert wurden, bietet diese Architektur einen sehr attraktiven Modus, in dem neue Anforderungen keine erneuten Tests bzw. keine erneute Codierungen zuvor implementierter Funktionen in großem Umfang erfordern.

Skalierbarkeit

Da die BPEL-Anwendung über einem ausgereiften Middleware-Stack, der Clustering als Konfigurationsoption bereitstellt, implementiert wird, war das Verschieben des ServicePac®-Validierungsprojekts in die Fußzeile, die durch bei Bedarf durch Hinzufügen neuer Hardware einfach skaliert werden kann, unkompliziert. Die Gesamtarchitektur, bei der Partnerservices über eine Workflow-Steuerkomponente aufgerufen werden, passt gut zum Clustering-Modell.

Als Designpunkt ist dieser Service idempotent, da an diesen Service gerichtete Aufrufe keine Nebenwirkungen haben, die von Aufrufenden ermittelt werden können. Daher muss ein Servicekonsument keine Fehlerbehebungsmaßnahmen durchführen, wenn ein Serviceaufruf einen Fehler zurückgibt oder nicht ausgeführt werden kann. Tatsächlich kann der Servicekonsument jederzeit einen Aufruf wiederholen. Die Tatsache, dass die Partnerservices ebenfalls idempotent sind, vereinfacht die der Prozessskalierung zugeordneten Faktoren mit Clustering erheblich, da die Fehlerbehebung relativ einfach ist und der Wiederanlauf und der Neustart nach einem Fehler unkompliziert sind. Darüber hinaus gibt es keine Notwendigkeit einer "Affinität für Aufrufende", da jede Interaktion unteilbar ist und kein spezifisches Caching für Aufrufende der Verarbeitung einer Anfrage zugeordnet ist.

Anwendung von Workflow und BPEL

BPEL4WS (Business Process Execution Language for Web Services) ist eine Sprache und ein Programmiermodell, das speziell für die Ausführung Workflow-basierter Geschäftslogik, die die Choreographie von Web-Services einschließt, entwickelt wurde. BPEL ist ein offener Standard für viele Herstellerimplementierungen von Authoring-Tools und Laufzeiten.

Die Fähigkeit, den ServicePac®-Geschäftsprozess über ein schematisches Prozessdiagramm zu beschreiben und dann die Implementierungslogik mit den auf Standards basierenden BPEL4WS-Konstrukten zu repräsentieren, bot genau die richtige Kombination aus Flexibilität und Isolation, um die flexible ServicePac®-Geschäftslogik zu implementieren.

Für dieses Projekt wurde IBM WebSphere Application Developer Integration Edition (WSADIE) als Authoring-Umgebung ausgewählt. Entwickelte Codeartefakte wurden für die Ausführung in der Laufzeit von IBM WebSphere® Business Integration Server Foundation 5.1.1 eingeplant, die eine Steuerkomponente für die Ausführung von Geschäftsprozessen bereitstellt, um den Workflow später auszuführen. Die Daten werden auf einem DB2-Server (Version 8.1) bereitgestellt.

Es wurden für die ServicePac®-Validierung individuelle Tests als Enterprise Java Beans, insbesondere Stateless-Session-Beans, die im EJB-Container von WebSphere® Application Server ausgeführt werden, implementiert. Die Tools von WSADIE haben die Integration dieser EJBs als Web-Services über die automatisierte Generierung von WSDL-Dateien vereinfacht. Infolgedessen können individuelle Tests entweder in demselben Container wie der BPEL-Prozess oder in dedizierten Containern in anderen Serverinstanzen implementiert werden.

Die Abbildung veranschaulicht den Workflow, wie er von einem BPEL-Grafikeditor dargestellt wird.

Abbildung 3 zeigt eine grafische des BPEL-Editors für den Validierungs-Workflow. Das Tool unterstützt das Ausblenden von Teilprozessen und bildet eine Schleife, um die Details der einzelnen Teile des gesamten Workflow zu vereinfachen.

Abbildung 3 zeigt den vollständig erweiterten BPEL-Prozess, mit dem die Validierungsservices von ServicePac® gesteuert werden, so wie sie im BPEL-Erstellungs- und Editiertool von WSADIE erscheinen.

Eine frühe Implementierung des Workflow für die ServicePac®-Validierung wurde dahingehend modifiziert, BPEL-Variablen zum Speichern von temporären Ergebnissen zu nutzen, anstatt zusätzliche Aufrufe an den Partnerservices abzusetzen, wurden wichtige Leistungsverbesserungen erzielt. Ein Beispiel für diesen Ansatz finden Sie in Abbildung 3, in der die Liste der Tests, die für die einzelnen Elemente eines Auftrags ausgeführt werden sollen, in einer BPEL-Variable gespeichert ist.

Übersicht über Vorteile und Nachteile des Designs

Vorteile
Nachteile
1. Das Hinzufügen neuer Angebote erfolgt schneller und weniger aufwändig.

2. Das Hinzufügen neuer Auftragssysteme ist weniger aufwändig.

3. Konsistente und umfassende Validierung.

4. Die Verwendung des Validierungsservice kann bei Aktualisierung der Auftragssysteme synchronisiert werden.

5. Neue Validierungslogik muss nur an einer Stelle implementiert und getestet werden.

6. Eigner der Validierungslogik ist ServicePac®, die Validierungslogik muss nicht über mehrere Fremdsysteme verteilt werden.
1. Zusätzliche organisationsübergreifende Laufzeitabhängigkeiten.

2. Leistungseinbußen in Form zusätzlicher Netzlatenzzeit.

3. Umstrukturierung vorhandener Systeme erforderlich.

4. Neue zentralisierte Komponente, die als einzelner Single Point of Failure für mehrere Anwendungen fungieren kann.

Im Falle der ServicePac®-Anwendung wurde festgestellt, dass die oben genannten Vorteile großen Nutzen bringen und die Nachteile alle handhabbar sind. Da die einzelnen aufrufenden Programme alle die Möglichkeit haben, die private Validierung fortzusetzen, bis sie eine geplante Aktualisierung durchführen, die viele Probleme abdeckt, ist die zusätzliche Programmierarbeit zum Packen der Daten für einen Validierungsaufruf ein kleines Inkrement, das in den Gesamtprojektumfang der aufrufenden Anwendung aufgenommen werden kann. Für die Onlineservices, die bezüglich der Antwortzeiten Anforderungen haben, die vom Validierungsservice nicht erfüllt werden können, kann vom aufrufenden Programm eine integrierte vorläufige Validierung durchgeführt werden, mit einem einzigen finalen Validierungszugriff auf den Validierungsservice. Diese Strategie bewahrt die menschlichen Faktoren der aufrufenden Anwendung und gleichzeitig auch die Integrität des gesamten ServicePac®-Auftragsprozesses. Für einige traditionelle Systeme, die keine internen Web-Services-Protokolle verwenden, wurde ein Umsetzer erstellt, der ein privates Protokoll akzeptiert und in einen Web-Services-Aufruf umsetzt (ein herstellerspezifisches Dokument für Web-Services-Adapter wurde für eines der aufrufenden Programme in diesem Projekt erstellt). Mit dem Test und der Demonstration der Zuverlässigkeit von Services wurden die Befürchtungen, es könnten durch den Validierungsservice eingeführte Leistungsengpässe auftreten, gemindert. Durch die Verwendung der Clustering-Technologie kann der Durchsatz des Validierungsservice bei Bedarf sehr schnell erhöht werden. Schließlich bedeutet die Konzentration der Validierungslogik auf eine einzige Implementierung, vorausgesetzt, es kommt nichts dazwischen, dass die Finanzmittel, die für das Deployment und den Test verschiedener unabhängiger Implementierungen erforderlich gewesen wären, für den Test und das Deployment einer einzigen Implementierung verwendet werden können, was die Probleme, die durch einen zusätzlichen Single Point of Failure für viele unterschiedlichen Auftragserfassungssysteme entstehen, mehr als ausgleicht.

Schließlich hat die Fähigkeit des Geschäfts, das Eigentumsrecht an den Validierungsanforderungen und deren Implementierung zu übernehmen, neue Angebote schnell zu realisieren und eine angemessene und konsistente Auftragsvalidierung zu Beginn des Auftragsprozesses zu gewährleisten, das Geschäft in die Lage versetzt, neue Chancen, die zuvor aus technischer Sicht unrealisierbar bzw. zu kostenintensiv waren, ins Auge zu fassen.