Online-Artikel 20060506b Seagull SOA

Beginnen Sie gerade mit der Planung einer serviceorientierten Architekturstrategie (SOA), suchen aber noch nach dem geeigneten Ansatzpunkt? Oder sind Sie schon dabei und bereuen schon einige der ersten Entscheidungen? Einige frühe Nutzer mögen behaupten, dass die Vorteile von SOA die Kosten nicht aufwiegen. Um Rückschläge und Kostenüberschreitungen zu verhindern, sollten Sie bei der Auswahl des Mainframe Integration-Anbieters schon wissen, worauf Sie achten müssen.

enn Sie diese 10 Tipps befolgen, werden Sie mit dem Mainframe Integration-Anbieter zufriedener sein:

Dieser Schritt ist bei der Auswahl eines Integrations-Anbieters besonders wichtig. Prüfen Sie Ihre speziellen Anforderungen sehr genau, bevor Sie sich festlegen. Bei der Auswahl der Architektur, die für Ihre Zwecke besonders geeignet ist, müssen Sie verschiedene Faktoren abwägen.

Es gibt drei verschiedene Grundmodelle bei der Integrationsarchitektur: dezentral (alles, was nicht auf dem Mainframe sitzt); Mainframe (keine dezentralen Laufzeitkomponenten); und gemischt (Mainframe- und dezentraler Einsatz und verschiedene Stufen):

- Anhänger des dezentralen Prinzips suchen vielleicht nach einer Architektur, bei der keine zusätzliche Software auf dem Mainframe installiert werden muss. Dies ist von Vorteil, wenn kein Zugriff auf den Mainframe vorhanden ist, zum Beispiel wenn der Mainframe ausgelagert ist oder nur eingeschränkter Kontakt zum Mainframe-Personal und den Ressourcen besteht. Die Installations- und Konfigurationsprozesse laufen schneller ab, da sie keine Mainframe-Koordination erfordern. Bei guter Leistung bietet dezentrale Serververbreitung (auch »Serverfarm« genannt) mehr Durchsatz, Lastausgleich und Ausfallsicherung.

- Anhänger von Mainframes achten auf Architekturen, die nur auf dem Mainframe residieren, und möglicherweise innerhalb verschiedener Object Transaction Monitors (OTMs) wie CICS. Diese Produkte zeigen unerreichte Leistung und Skalierbarkeit, was teilweise an der speziellen Natur des Mainframes liegt. Die Komplexität von Serverfarm und Netzwerk wird durch eine komplexere interne Architektur ersetzt, die Mainframe-Erfahrung und einen koordinierten Projekteinsatz erfordert.

- Gemischte Einsätze sind ein relativ neues Konzept. Sie verbinden die Vorteile der dezentralen und der Mainframe-Architektur. In dieser Konfigurationsoption können einige der CPU-intensiven Prozesse vom Mainframe auf dezentrale Plattformen ausgelagert werden, sodass die Arbeitslast besser verteilt wird. Für Mainframe-Werkstätten, die MIPs-bewusst und misstrauisch gegenüber Mainframe-Upgrades sind, kann dies besonders bedeutend sein, da viele Softwareprodukte eine Preis- und Wartungsstruktur auf Basis von MIPs aufweisen. Im gemischten Einsatz kann die XML-Verarbeitung dezentral ablaufen, was effizienter ist als das Mainframe Tausende von XML-Nachrichten pro Sekunde verarbeiten zu lassen. Als weiteren Vorteil ergibt sich hieraus weniger Netzwerkverkehr, da ein gemischter Einsatz einen zusätzlichen Abstraktionslayer bietet. Da der gemischte dezentrale Server das XML-Parsing übernimmt, verbleiben nur die »XML-gestrippten« rohen Anwendungsdaten, die über das Netzwerk an den Mainframeserver geleitet werden.

Es gibt keine Architektur, die für jede Anwendung ideal ist, es gibt jeweils Vor- und Nachteile. (Weitere Informationen über dieses Thema finden Sie im z/Journal-Artikel »Exploring Options for Mainframe Integration«, August/September 2005.) Leider finden viele Schlachten um die Entscheidung für eine dieser Architekturen auf der Ebene persönlicher Vorlieben statt, da sich keine dieser Gruppen im Bereich der anderen wohl fühlt. Entscheiden Sie nicht vorschnell aufgrund von Vorurteilen. Kann Ihr Anbieter alle drei Architekturen unterstützen? Falls ja, kommen Sie bei der Umsetzung zukünftiger Projekte in den Genuss größter Flexibilität.

Mainframe-Anwendungssysteme wie CICS gab es schon lange vor SOA oder anderen standardbasierten Programmiertechniken. Viele der frühen Anwendungen befolgten zwar die Standards der Programmiersprachen, konnten aber nur wenige Standards in Hinblick auf Eingabe- und Ausgabemedien befolgen, insbesondere beim Mainframe 3270-Bildschirm. Und somit verknüpften viele Anwendungen mit Bildschirmeingabe und -ausgabe die pseudokonventionelle Logik auf Basis des 3270-Bildschirms mit der Logik der Geschäftsanwendung. Diese Interaktion passt nicht zum locker verbundenen synchronen Modell, das für Web-Services erforderlich ist.

Etwa 80 Prozent aller Mainframe-Anwendungen basieren auf dem eng verknüpften Modell und können nicht an SOA teilnehmen, ohne die Anwendung neu zu strukturieren, sodass sie »lose Verknüpfung« unterstützt. Durch Microflow entfällt der Bedarf nach dieser teuren Neustrukturierung, da vorhandene Anwendungen, bei denen die Bildschirm- und Geschäftslogik miteinander vermischt ist, umhüllt werden, sodass sie nur noch lose verknüpft scheinen. Microflow isoliert den Nutzer des Service von der Zugriffsebene – in diesem Fall der Bildschirm-Interaktion und den 3270-Steuerinformationen –, indem es den Prozessablauf der Mainframe-Anwendung einkapselt.

Microflow-Einsätze werden auf verschiedene Weise umgesetzt. Jede für sich ist einzigartig und erfordert weitreichendes Verständnis zur Bestimmung der Akzeptanz innerhalb Ihrer Unternehmensarchitektur. Bei der Ausführung von Microflow gibt es zwei wesentliche Komponenten: das Microflow Script (MS) und den Microflow Prozessor (MP). Je nach der Integrationsarchitektur des Anbieters kann es sich hierbei um unabhängige oder kombinierte Komponenten handeln. Unabhängige Microflow-Skripte enthalten alle Informationen, mit denen der MP durch die Zielanwendung navigieren kann. Kombinierte Komponenten enthalten die MS-Informationen plus des ausführbaren Codes des MP. Eine genaue Beschreibung dessen, was Sie Ihren Anbieter über die Unterstützung von Microflows fragen sollen, sehen Sie in der Seitenleiste.

Benötigen Sie Zugriff auf Rohdaten des Mainframe aus unterschiedlichen Dateistrukturen, oder Zugriff auf Anwendungen, bei denen Sie Daten nutzen müssen, die bereits durch Anwendungen bearbeitet wurden? Normalerweise ist Letzteres der Fall. In den heutigen hoch regulierten Umgebungen kann es sich als vorteilhaft erweisen, die vorhandenen sicheren Anwendungsschnittstellen zu nutzen statt Mainframe-Rohdaten über neue Web-basierte Benutzeroberflächen offen zu legen.

Wenn Anwendungsintegration erforderlich ist, fragen Sie nach, ob der Anbieter eine Architektur unterstützt, die das einzigartige Framework des Transaktionsmonitors nutzen kann, wie CICS. Datenintegrationsplattformen bestimmen eine Architektur, die vom Transaktionsmonitor unabhängig ist, und müssen näher an der Datenbank sein, wenn dies aus Sicht der Leistung sinnvoll ist. Diese Integrationsplattformen werden auf eigenem unabhängigem Mainframe-Adressraum ausgeführt, während sie Anforderungen für viele verschiedene Datenbanken bedienen.

Aus Sicht der Datenintegration ist dies vielleicht positiv, aber es ist nicht mehr so angenehm, wenn sich die Anwendung im Monitor-Adressraum der CICS-Transaktion befindet. Überlegungen zur Leistung können ins Spiel kommen, wenn Sie dieses Datenintegrationsmodell mit einem wahren Anwendungsintegrationsmodell vergleichen, das zur Koexistenz und zur Nutzung der Eigenschaften eines Untersystems bei der Unterstützung von Mainframe-Transaktionsverarbeitungsmonitoren wie CICS entworfen wurde. Maximale Leistung erhalten Sie, wenn Sie die »Servicegrenze«, an der sich der MP befindet, so nah wie möglich an der Zielanwendung platzieren. (Weitere Information hierzu finden Sie im bereits genannten z/Journal-Artikel von August/ September 2005.)

4. Machen Sie sich mit den Support- und Servicegruppen des Anbieters vertraut:

Unabhängig von der gewählten Architektur werden Sie bestimmt eine Lernkurve durchlaufen. Wählen Sie einen Anbieter, dem Sie in Hinblick auf Anweisungen und koordinierte Hilfe trauen können. Testen Sie die Support-Kanäle der potenziellen Anbieter. Wenn Sie die Nutzung professioneller Serviceleistungen in Betracht ziehen, sollten Sie das Integrationsprodukt, über das Sie nachdenken, verstehen und sich damit wohl fühlen. Irgendwann wird Ihr Unternehmen das Integrationsprojekt warten müssen.

Und das sollte nicht der Zeitpunkt sein, an dem Sie feststellen, dass die Komplexität des Projekts und der erforderliche Produktmix größer sind, als Ihr Personal es handhaben kann. Beginnen Sie mit Befähigungsnachweisen und gehen Sie dann zu kleinen Projekten über, statt gleich vollständige umfangreiche Änderungen auszuführen. Diese sollten gemeinsame Einsätze vom Softwareanbieter und Ihrem Projektteam sein, damit Sie auf dem neuesten Stand bleiben. Vergewissern Sie sich, dass messbare Ergebnisse entstehen, indem Sie Projekt-Meilensteine, Regressoptionen und Strafgebühren für nicht eingehaltene Zeitpläne festlegen. Bestimmen Sie gemeinsam mit dem Anbieter Akzeptanzkriterien, darunter Dokumentation, interne Schulungen, Leistungsrichtlinien und Fehlerbehebungs-/Ausfallszenarien.

5. Machen Sie sich mit der integrierten Entwicklungsumgebung (Integrated Development Environment, kurz IDE) vertraut:

Seien Sie gewarnt vor zusammenbrechenden Märkten, in denen einige Softwareanbieter andere Softwareanbieter aufkaufen und die dann verschiedene widersprüchliche IDEs umfassen. Finden Sie heraus, wie viele unterschiedliche IDEs unterstützt werden und erforderlich sind. Durch Übernahme unterstützen Softwareanbieter zumindest vorübergehend mehrere IDEs. Wird Ihnen garantiert, dass die von Ihnen genutzte IDE auch zukünftig unterstützt wird? Der Wechsel einer IDE ist nicht so schlimm, doch die IDE erstellt einen »Service« und jeder Anbieter hat eine eigene Integrationsinfrastruktur für die von seiner IDE erstellten Services. Wenn Sie als die bisher genutzte IDE wechseln, müssen Sie möglicherweise auch die unterstützende Infrastruktur Ihrer SOA umstellen, und das kann teuer werden. Sie sollten mit der gewünschten IDE vollständig vertraut sein. Was geschieht, wenn ein Kunde aufgrund spezieller Anforderungen der integrierten Anwendung von der Logik abweicht, die das Produkt eines Softwareanbieters ihm aufgezwungen hat? Viele IDEs erstellen verdeckten Sourcecode. Wenn die Anwendungslogik zu komplex ist, muss der Kunde zusätzlichen Sourcecode manuell schreiben, damit die von der IDE angefangene Aufgabe vervollständigt werden kann. Dies funktioniert vielleicht, wenn Sie ein Mainframe-Anwendungsentwickler sind, der sich mit COBOL oder Rexx auskennt, aber es ist Zeitverschwendung, wenn Sie ein dezentraler Entwickler mit Spezialisierung auf Java oder C sind. Da einige IDEs ihre Anziehung schon unter einfachen Anwendungsszenarien verlieren, sollten Sie sicherstellen, dass die IDE auch ihre komplexesten Anwendungen behandeln kann. Wenn COBOL- und Rexx-Sourcecode-Generatoren genutzt werden, denken Sie daran, dass eine kritische Stufe bei der Umsetzung darin besteht, den Code zu kompilieren und mit den entsprechenden Mainframe-Bibliotheken zu verknüpfen. Sind Sie darauf vorbereitet, während der Designzeit den COBOL-Code und die Speicherauszüge zu untersuchen, falls etwas fehlschlägt? Es gibt noch weitere Umsetzungsprobleme, bei denen Sie sich von CICS-Systemprogrammierern helfen lassen müssen, wenn Sie den erstellten Code in eine CICS übernehmen möchten. In diesen Fällen muss die CICS Resource Definition Online (RDO) beibehalten werden, um die neuen Services vollständig zu installieren oder vorhandene zu ändern. Wenn die Entwicklung größtenteils von dezentralem Personal ausgeführt wird, achten Sie auf einfache, intuitive, integrierte Entwicklungsumgebungen. Wenn die Entwickler mainframeausgerichtet sind, vergewissern Sie sich, dass die IDE benutzerfreundlich genug ist oder dass andere mainframespezifische Schnittstellen auf Basis von CICS oder anderen Fernverarbeitungsmonitoren vorhanden sind.

6. Schauen Sie eine Softwaredemonstration an oder probieren Sie es selbst aus:

Fragen Sie nach einer Produktdemonstration, oder noch besser, fragen Sie nach einer direkten Vorführung vor Ort. Viele Anbieter zeigen die Leistungsstärke ihres Produkts mit einem gut geschriebenen fehlerfreien Demopaket. Das kann irreführend sein, da es extra so geschrieben wurde, die täglichen kleinen Ausnahmen zu vermeiden.

Ein sachlicherer, realistischerer Test wäre eine Aufnahme einer Ihrer typischen Anwendungen. Seien Sie gründlich, denn dabei wird sich herausstellen, ob Sie sich mit der IDE wohlfühlen und ob versteckte Umsetzungsschritte erforderlich sind. Am besten bearbeiten Sie Ihren eigenen Service, statt einem Vertreter über die Schulter zu schauen. Dann wissen Sie wirklich, welche Hindernisse in Ihrem Integrationsprozess auftreten können.

Jeder verlangt eine Liste von Referenzkunden, doch die meisten Unternehmen machen sich nicht die Mühe, die Referenzen auch zu befragen. Das kann sich als Fehler erweisen. Da der Integrationsmarkt durch Übernahmen schrumpft, kann die Referenzkundenkartei eines Softwareanbieters mit Referenzen anderer Produkte durchmischt werden, die im Lauf der Zeit erworben wurden. Überprüfen Sie die Referenzen genau, um sicherzustellen, dass Sie nicht das einzige Unternehmen sind, das ein Produkt in einer bestimmten Weise nutzt. Setzen Sie nicht die Zukunft Ihres Unternehmens durch nicht geprüfte Technik aufs Spiel. Wenn die Anforderungen eine einzigartige Lösung erfordern, stellen Sie zumindest sicher, dass Sie mit dem zu erwartenden Support zufrieden sein werden.

Fragen Sie, ob der Anbieter Nutzergruppen oder Kundenforen fördert. Die Teilnahme daran kann viel ans Licht bringen, da hier offene und direkte Diskussionen die Regel sind.

Statt über eine Liste, die Sie vom möglichen Anbieter erhalten, können Sie auch unvoreingenommenes direktes Kundenfeedback auf Konferenzen finden. Hier können Sie viel erfahren, wenn Sie sich in der Nähe der Anbieterstände aufhalten und Vorträge über Erfahrungen der Benutzer anhören. Lassen Sie sich vom Vortragenden Kontaktinformationen geben, und auch von anderen Teilnehmern, besonders wenn diese sich an der Diskussion beteiligt haben. Diese Teilnehmer sind vermutlich auch zum Einkaufen da, genau wie Sie, und haben möglicherweise schon wichtige Informationen gesammelt.

Anbieter versuchen manchmal, über Einzelhändlerabkommen respektabler zu wirken. Oft sind solche Abkommen legitim, aber Sie sollten nach Kundenreferenzen fragen, insbesondere in Bezug auf das Einzelhändlerabkommen. Oft existieren diese Einzelhändlerabkommen nur auf dem Papier, aufgrund von Vertragsbeziehungen wenn Softwareanbieter andere Softwareanbieter aufkaufen. Und manchmal sind Einzelhändlerabkommen nur Einzelszenarien, um mit einem bestimmten Kunden ins Geschäft zu kommen. In diesen Fällen schließt ein größerer Softwareanbieter eine Partnerschaft mit einem kleineren Softwareanbieter ab und bietet dessen Produkt an. Diese Art eines Einzelhändlerabkommens scheint dem Kunden oft besonders verlockend, da es den Eindruck von langen, strategischen Beziehungen zwischen zwei Anbietern vermittelt. Erforschen Sie diese Beziehungen und prüfen Sie die Anzahl und die Qualität der Referenzen.

Überprüfen Sie die Finanzen des Unternehmens. Ist es solvent? Ist das Unternehmen in Privatbesitz oder eine Aktiengesellschaft? Stammt sein Ertrag aus dem Verkauf von Produkten und Dienstleistungen, aus Übernahmen oder rechtlichen Auseinandersetzungen? Unternehmen haben manchmal ein schlechtes Quartal oder einen schlingernden Kurs – aber seien Sie gewarnt vor stagnierenden Bilanzen, selbst wenn die Firma aktiv andere Firmen übernimmt. Das kann ein Zeichen für schlechte Unternehmensplanung und Betriebsführung sein. Solche Firmen sind auch die ersten Kandidaten für eine Übernahme. Sie sollten die Finanzen des Unternehmens erforschen, um sicherzustellen, dass Sie Ihre SOA-Strategie nicht wieder umstellen müssen, wenn sich der Staub einer Übernahme gelegt hat.

Wenn Ihr Unternehmen viel Geld in ein Integrationsprojekt steckt, sollten Sie einen Besuch in der Firmenzentrale einplanen. Dadurch können Sie den Zustand eines Unternehmens vielleicht deutlich besser einschätzen. Wenn Sie die Niederlassung eines größeren Unternehmens besuchen, versuchen Sie, die Abteilungen Demo, Support und Forschung und Entwicklung für das jeweilige Produkt zu besuchen, damit Sie sehen können, ob die Größe und Qualität Ihren Vorstellungen entspricht. Das Letzte, was Sie hören möchten, ist dass der Anbieter aufgekauft wurde und Sie einen Migrationsprozess von 12 bis 18 Monaten durchlaufen müssen, sobald der Migrationsvorgang bestimmt wurde.

Nachforschungen über Anbieter sind langwierig und zeitaufwendig und können frustrierend sein, da die notwendigen Details oft schwierig zu ermitteln sind. Außerdem sind die heutigen Entscheidungen morgen vielleicht schon nicht mehr angemessen. Normale Vertreter des Anbieters können einige Fragen vielleicht gar nicht beantworten, sodass Sie nach weiteren Personen suchen müssen, von denen Sie die erforderlichen Detailinformationen erhalten. Die Suche nach den richtigen Antworten verhindert Überraschungen während Ihres Integrationsvorgangs. Bleiben Sie am Ball, Ihre Sorgfalt wird sich letztendlich auszahlen.

Microflows

Wenn ein Anbieter Microflows unterstützt, stellen Sie ihm folgende Fragen:

- In welchem Format oder in welcher Sprache sind die MSs geschrieben? Dies ist wichtig für die Phase vor der Umsetzung und für die Berücksichtigung der Entwicklungszeit. Wie im Artikel beschrieben werden kombinierte MS/MP-Einheiten als Programmiersprache wie COBOL, Rexx oder Java ausgedrückt. Stellen Sie sicher, dass Sie mit der Sprache vertraut sind, falls Sie den Microflow manuell bearbeiten müssen. Wenn Sie diese kombinierten Microflows in Betracht ziehen, die in einer Programmiersprache erstellt wurden, dann denken Sie auch an die Übertragbarkeit der Sprache. COBOL/LE oder Rexx lassen sich möglicherweise nicht einfach an eine dezentrale Plattform in der vorhandenen Form übertragen. Bei Java besteht die Gefahr, dass es nicht im nativen Format an die Mainframe-Plattform übertragen werden kann. Es gibt noch weitere Umsetzungseigenschaften, auf die Sie achten müssen. Sie wurden in diesem Artikel beschrieben.

Unabhängige MSs können in verschiedenen Formaten auftreten, von firmeneigenen bis zu standardbasierten wie XML. Als weiterer Vorteil kann XML einfach an jede ordnungsgemäß entwickelte Umgebung angeschlossen werden.

- In welcher Sprache ist der MP geschrieben? Dies gilt insbesondere für Umgebungsüberlegungen zur Ausführungszeit. Bei kombinierten Angeboten aus MS/MP als Teil des Umsetzungsvorgangs wird die Microflow-Anwendung kompiliert und an ihren endgültigen Zustand geknüpft, sei es COBOL, kompiliertes Rexx oder Java. Beachten Sie dabei, dass solche Systeme sehr gute Leistungscharakteristika aufweisen, wenn sie ordnungsgemäß entwickelt wurden. Der Nachteil hierbei liegt in großer Redundanz im Vergleich zum unabhängigen Microflow, da vor jeder einzelnen serviceaktivierten Anwendung ein unabhängiges Microflow-Prozessorsystem sitzt, seien es fünf, 500 oder noch mehr Anwendungen.

- Bei unabhängigen Microflows, bei denen MS von MP getrennt sind, stellen Sie sicher, dass der MP in einer schnellen und effizienten Sprache geschrieben ist. Besonders auf dem Mainframe ist Assembler (BAL) die beste Wahl. Dies stellt die bestmögliche Leistung sicher. Unabhängige Microflows weisen nur einen einzelnen MP pro Architekturplattform auf. Es gibt keine Redundanz wie in den vorher beschriebenen kombinierten MS/MP-Angeboten. Der Nachteil liegt darin, dass Leistungsprobleme auftreten können, wenn der MP das MS in der Ausführungszeit übersetzen muss. Forschen Sie in diesem Fall nach, ob der Microflow auf Byte-Code kompiliert werden kann.

Kompilierte Microflows sind effizienter und viel schneller in der Verarbeitung. XML-basiertes MS, dessen endgültiger Zustand durch Byte-Code kompiliert wird, weist sowohl die Anschließbarkeit als auch die Leistungsvorteile auf.

- Bietet der Anbieter anschließbare Microflows an? Dieser Artikel enthält mehrere Hinweise zur Anschließbarkeit. Die Bedeutung dieses Konzepts kann gar nicht genug betont werden. Die Anschließbarkeit von Microflows stellt Kostenersparnis durch Mobilität bei sich ändernden Unternehmensanforderungen sicher, da der Entwicklungsvorgang nur einmal ausgeführt werden muss. Danach handelt es sich nur noch um eine Neuumsetzung. Diese Funktion ist nur über unabhängige Microflow-Skripte möglich, bei denen ein plattformabhängiger MP ein allgemeines Skript über den Umsetzungsvorgang aufnehmen kann.

- Unterstützt der MP Anwendungsverdichtung? Dies ist wichtig, wenn Sie mehrere Anwendungen kombinieren möchten und dabei Daten aus allen entnehmen, oder wenn eine Anwendung von einer anderen abhängig ist, da sie wesentliche Informationen in einem Prozess daraus bezieht. Bei vielen Anbietern ist die Microflow-Verarbeitung nur einzeln möglich, d. h. jeder Microflow unterstützt nur eine einzige Transaktion oder Anwendung. In diesen Fällen bleibt es dem Entwickler überlassen, mehrere Microflows zu erstellen, die alle gültigen Kundenanforderungen unterstützen, und es liegt am Service Client/Anforderer, mit mehreren Serviceanrufen alle benötigten Informationen zu sammeln. MPs, die Verdichtung unterstützen, neigen dazu, den Prozess zu vereinfachen, da Informationen nur einmal gesendet werden müssen.

- Kann der MP Anwendungen der Bildschirm- und Geschäftslogik (COMMAREA) unterstützen, sowohl einzeln als auch kombiniert? Viele Anbieter unterstützen nur einen Teil der Verarbeitungsfähigkeiten von Microflow. Microflows sind flexibel genug, um bildschirmbasierte und logikbasierte Anwendungen kombiniert unterstützen zu können, sodass sie Erfolg bei der Entwicklung neuer servicebasierter Anwendungen bieten. Dies ist besonders wichtig, wenn zukünftige Mainframeprojekte vorhandene bildschirmbasierte Anwendungen aktualisieren und in Module wie serviceähnliche, logikbasierte Anwendungen umwandeln. Der Microflow kann nicht mehr ordnungsgemäß funktionieren, wenn er nicht sowohl bildschirm- als auch geschäftslogikbasierte Anwendungen unterstützen kann. Ein Microflow, der beides unterstützen kann, fährt unterbrechungsfrei fort.

- Kann der MP Microflow-Zustandsverarbeitung unterstützen? Zustandsbehaftete Microflows zeigen bessere Leistungs- und Durchsatzeigenschaften, da Komponenten in einem einzigen Microflow parallel verarbeitet werden können. (Im Gegensatz dazu stehen die zustandsfreien Microflows, bei denen jeder Microflow von Anfang bis Ende verarbeitet wird, bevor Daten an den Serviceanforderer gesendet werden.) Zustandsbehaftete Microflows sind gekennzeichnet durch die Fähigkeit des Entwicklers, die Funktionen des Microflow in Klassen zu unterteilen, wie Start, Ausführung, Rückgabe und Ende. Die wahre Leistungskraft des zustandsbehafteten Microflows zeigt sich, wenn die Unterprozesse Start und Ende nur einmal ausgeführt werden müssen, während der Unterprozess Ausführung parallel mit dem Unterprozess Rückgabe verarbeitet wird. Große Leistungsgewinne entstehen aufgrund der Abwesenheit zusätzlicher Anmeldeprozesse und vieler verschachtelter Ebenen von Anwendungsbildschirmen und ‑logik.

Copyright © 2003-2012 ap Verlag GmbH