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