DE69523939T2

DE69523939T2 - Verfahren zur erzeugung von objektstrukturen für den zugriff auf konventionelle, nicht objekt-orientierte geschäftsanwendungen

Info

Publication number: DE69523939T2
Application number: DE69523939T
Authority: DE
Inventors: Sascha Baumeister; Michael Beisiegel; Reinhard Duscher
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1995-06-07
Filing date: 1995-06-07
Publication date: 2002-05-29
Anticipated expiration: 2015-06-08
Also published as: US5845289A; EP0783733A1; WO1996041258A1; EP0783733B1; DE69523939D1; JPH09508742A; JP3652376B2

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren, das die Einbeziehung und das Umstellen von Geschäftsanwendungen (Business Applications, BA), die auf einem Datenverarbeitungssystem ausgeführt werden, auf moderne Umgebungen, die auf objektorientierter Technologie (OOT) basieren, gestattet und leitet. Insbesondere bezieht sich die vorliegende Erfindung auf ein Verfahren des Erzeugens eines objektorientierten (OO) Zugriffs auf BAs, die auf einem Datenverarbeitungssystem ausgeführt werden, wobei die BAs nicht dem Paradigma der Objektorientierung entsprechen und angenommen wird, dass sie konventionellen, nicht- objektorientierten Prinzipien folgen.
Sowohl Nutzer von Informationstechnologie als auch die Informationstechnologie selbst werden mit einer neuen Dimension von Flexibilitäts- und Adaptivitätsforderungen zur Softwareunterstützung und -steuerung ihrer Tätigkeit konfrontiert. Natürlich sind die Softwareentwicklungstechniken ebenfalls mit diesen Anforderungen konfrontiert. Einerseits sind Geschäftsinitiativen die Erzeuger dieser Forderungen, andererseits sind die Informationstechnologien selbst die treibenden Kräfte.
Unternehmen erfüllen neue und sich ändernde Marktanforderungen. Verbesserte Kundendienste und Markteinführungszeiten sind wichtige Unterscheidungsmerkmale. Die Globalisierung von Märkten, organisatorische Änderungen wie Dezentralisierung und neue Geschäftszusammenschlüsse erfordern neue Geschäftsstrukturen und Konzepte. Als eine Antwort auf diese Anforderungen versuchen Firmen, die zugrunde liegenden Geschäftsprozesse in einem ernsthaften Ausmaß umzugestalten. Geschäftsanwendungssoftware, die ein riesiges Spektrum verschiedener Anwendungstypen wie OLTP (Online Transaction Processing Applications), Datenbankanwendungen usw. umfasst, bildet in diesem Bereich ein wichtiges unterstützendes und aktivierendes Element und muss diesen Entwicklungen folgen. Die Situation ist sogar noch schlechter, weil Informationstechnologien durch ein Angebot neuer Technologien wie Client/Server-, Multimedia- und objektorientierter (OO) Technologien selbst drastische Veränderungen durchmachen.
Für den Versuch, bestehende BAs für diese Änderungen im Allgemeinen und, da OOT immer wichtiger wird und als das vereinigende Verfahren für den Zugriff auf andere neue Technologietypen angesehen wird, für OOT im Speziellen einzubeziehen, umzustellen oder anzupassen, sind verschiedene Verfahren bekannt.
Wenn die Ursprünge einer gegebenen Anwendung viele Jahre und manchmal sogar mehr als ein Jahrzehnt zurückliegen und wenn Technologien ein Gegenstand dramatischer Entwicklung gewesen sind, könnte ein erster Impuls vorschlagen, auf diese Typen von geerbten Anwendungen zu verzichten, da eine Anpassung in Bezug auf die neuen Technologien wie Client/Serverkonzepte usw., für die diese Anwendungen nicht vorbereitet wurden, hoffnungslos scheint. Es besteht kein Zweifel, dass diese Vorgehensweise in bestimmten Situationen vernünftig sein könnte. Die Entscheidung, eine geerbte Anwendung "wegzuwerfen", ist oft eine überstürzte Antwort. Die Suche nach Alternativen, die gestatten, die geerbten Anwendungen "wiederzuverwenden", sind lohnend, da sie wertvolles Wissen über das Geschäft enthalten, das sie unterstützen. Für ihre Neuausführung müssten viele Mannjahre aufgewendet werden. Da sich auch viele Unternehmen sehr intensiv auf ihre Geschäftsunterstützungsanwendungen verlassen, können derartige Diskontinuitäten nicht akzeptabel und evolutionärere Verfahren stattdessen vorteilhafter sein.
Die Modernisierung von geerbten Anwendungen durch Umstrukturierung könnte ein alternatives Verhalten sein. Als ein Ergebnis erfordert dieses Konzept oft große Investitionen in die alte Anwendung selbst, wohingegen die "sichtbaren" Wirkungen der modernen Technologien im Vergleich zum Gesamtaufwand sehr bescheiden sind. Manchmal führt die Umstrukturierung einer Anwendung eigentlich zu einer völlig neuen Ausführung. Wenn andererseits diese "versteckte" Neu- Ausführung vermieden werden soll, wird man typischerweise in Bezug auf die Freiheit der Gestaltung der Merkmale der neuen Anwendungsstruktur eingeschränkt.
Insbesondere wenn eine Anwendung für objektorientierte Umgebungen verfügbar gemacht werden soll, steht eine "Umhüllung" genannte Technik zur Verfügung. Umhüllen von bestehenden Anwendungen bedeutet, eine Anwendung in ein Objekt oder eine Reihe von Objekten zusammenzufassen (zu kapseln), welche die Aktivitäten der Anwendung als Objektmethoden bieten. Da diese Art von Verfähren hauptsächlich auf der gegebenen Anwendungsausführung basiert, führt dies zu irreführenden Objektstrukturen, da sie nicht hauptsächlich an Objekten bezüglich des modellierten Geschäfts ausgerichtet sind. Manchmal wird eine vollständige Anwendung in ein einziges monolithisches Objekt gehüllt.

Aufgabe der Erfindung

Die Erfindung basiert auf der Aufgabe, zusammenarbeitende Objektstrukturen zum Zugriff auf BAs zu erzeugen und auszuführen, die nicht auf den Prinzipien von OOT aufgebaut sind. Dasselbe Verfahren sollte auch für den Fall gelten, dass die BAs auf einem entfernten Datenverarbeitungssystem ausgeführt werden, d. h. nicht auf demselben System wie die neuen Objektstrukturen.
Die Aufgabe der Erfindung wird durch Anspruch 1 gelöst. Entsprechend der Erfindung wird das vorgeschlagene Verfahren auf die Definition von echten Businessobjekt-Klassen (BO) mit einer eindeutigen Bedeutung als Einheiten oder Konzepte bezüglich des zugrunde liegenden Geschäfts gerichtet, wie es durch die BA unterstützt wird. Die BOs werden durch Definieren ihrer BO-Attribute (BOA) gekennzeichnet. Da die BA zur Verarbeitung geschäftsrelevanter Daten verwendet wird, stellt das Spektrum der Eingabe- und Ausgabeparameter der BA die BOAs der einzelnen Klassen BO dar. Innerhalb der OO-Umgebung werden die BAs als Transaktionsobjekt-Klassen (Klassen TO) ausgeführt, welche die BAs kapseln. Die Klassen TO steuern die Ausführung der BAs. Da die BA-Ausführung bis zum BA-Abschluss typischerweise mehrere Interaktionen benötigt, die Eingabe- oder Ausgabeparameter senden oder empfangen, überwacht das TO auch den BA-Status. Zum Zweck der BA-Ausführung sind die Klassen TO verantwortlich, die BOA-Werte aus den BOs transparent zu entnehmen, um die Eingabeparameter der BA zusammenzufassen, die zur Verarbeitung an die BA gesendet werden.
Außer der BA-Ausführung führen die Klassen TO auch die BO- Realisierungsverarbeitung aus. BO-Realisierung bedeutet, die Ausgabeparameter zu verarbeiten, die von der BA in einem ersten Schritt zurückgesendet werden, wobei geprüft wird, ob die Ausgabeparameter Daten von BOs speichern, die noch nicht zu einer Instanz gemacht wurden. Falls erforderlich, erzeugt der Realisierungsprozess diese neuen BO-Instanzen. Im zweiten Schritt verarbeitet die Realisierung die Ausgabeparameter, wie sie von der BA zurückgesendet werden, um die entsprechenden BOAs der BO-Instanzen zu aktualisieren.
Da der BO-Definitionsprozess nicht durch das BA-Verhalten eingeschränkt wird, kann irgendeine Klasse BO so ausgeführt werden, dass sie die Freiheit für ein echtes Modell der Geschäftswelt in Form von Objektstrukturen gibt. Irreführende Objektidentitäten können somit vermieden werden.
Die BOs verbergen die BA-Struktur und sind daher die ideale Basis als Integrationsplattform mit zusätzlichen Anwendungen und neuen Typen grafischer Benutzeroberflächen.
Außerdem können die BAs auf einem entfernten Datenverarbeitungssystem verarbeitet werden, es können Client/Server-Strukturen ausgeführt werden, selbst wenn die ursprüngliche BA nicht für diesen Zweck entwickelt wurde. Die BO-Strukturen bieten ein permanentes Speicherkonzept für Daten, die transparent zugreifbar und/oder modifizierbar sind, indem sie die BAs ausnutzen.
Das Kapseln der BAs in TOs und Realisieren der Verbindung von BAs mit den Eingabe- oder Ausgabeparametern des BA machen die BOs zu einem sehr großen Teil unabhängig von Struktur und Eigenheiten der BA.
Weitere Vorteile der Erfindung werden durch den Realisierungsprozess geboten. Realisierung hat die Konsequenz, dass eine BO-Instanz, wenn sie erzeugt wird, den Teil der BOA- Werte speichert, der von der speziellen BA zu diesem Zeitpunkt geboten wird, der nur ein Teil des gesamten BOA-Spektrums des BO sein kann. So kann das teilweise Realisierungsverhalten gestatten, mit BO-Instanzen zu arbeiten, die nur den Teil der BOA-Werte speichern, der tatsächlich vom Nutzer gebraucht wird. Dies ist von besonderer Wichtigkeit für Objekte mit Bezug auf den Geschäftsbereich, da diese sehr groß werden können. Äußerst wirtschaftliche Verwendung von Speicher ist somit Hauptvorteil und Folge des Realisierungsansatzes. Andererseits wird während der Lebensdauer einer BO-Instanz ihr Attributspektrum schrittweise mit jeder weiteren BA- Ausführung, die zusätzliche BOA-Werte liefert, vervollständigt. Zusätzliche Realisierungsprozesse, die zu einer inkrementellen Vervollständigung des BOA- Attributspektrums führen, garantieren, dass die erforderlichen Daten verfügbar bleiben.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 2 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung werden die einzelnen Eingabe- oder Ausgabedatenblöcke, BA-Nachrichten genannt, welche die Eingabe- oder Ausgabeparameter umfassen, die in einer Interaktion mit der BA gesendet oder empfangen werden, in separate Objektklassen gekapselt, Transaktionsaufzeichnungs- Klassen (Transaction Record, TR) genannt. Jeder BA- Nachrichtentyp ist in einer eigenen Klasse TR gekapselt. Außer den Eingabe- oder Ausgabeparametern selbst speichert die Klasse TR auch beschreibende Informationen über die einzelnen Datenelemente, welche die gekapselte BA-Nachricht bilden. Zum Beispiel kann ein BA-Nachrichtendatenelement durch seinen Datentyp (Zeichenkette, numerisch, ...), seine Länge, seine Position innerhalb der gesamten BA-Nachricht und so weiter beschrieben werden.
Da die meisten Parameter Teil einer BA-Nachricht sind, kann erwartet werden, dass die Klassen TR zusätzlich für jedes BA- Nachrichtendatenelement Abbildungsinformationen zum Zuordnen zu einem eindeutigen BOA der bestimmten Klasse BO und umgekehrt speichern, um BOAs verschiedener BOs darzustellen.
Klassen TO kapseln die BAs und nutzen TR-Instanzen zum Erzeugen und Austauschen einzelner BA-Nachrichten. Durch Zuordnen dieser Klassen TR, die für den Datenaustausch mit der gekapselten BA zu der kapselnden Klasse TO wichtig sind, wird dem TO ermöglicht, Funktionen zu nutzen, die durch TR geboten werden.
TRs bieten den Vorteil, eine genaue Struktur eines ansonsten unstrukturierten Bytestroms einzuführen, die mit der BA ausgetauscht werden. Diese Kapselung erfolgt auf eine modulare, objektorientierte Weise.
Wegen der Abbildungsinformationen, die in den Klassen TR gespeichert sind, sind die TRs von zentraler Wichtigkeit als Beitrag zum BO-Realisierungsprozess.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 3 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung teilt das Verfahren das Spektrum von BOAs in zwei Untergruppen. Die erste Untergruppe von BOAs, BO- Schlüsselattribute (BO Key Attributes, BOKA) genannt, hat die besondere Eigenschaft, dass jede Kombination von BOKA-Werten eindeutig und genau eine BO-Instanz innerhalb der Klasse BO unabhängig von den BOA-Werten einer zweiten Untergruppe von. BOAs, BO-Allgemeinattribute (BO General Attributes, BOGA) genannt, die aus allen verbleibenden BOAs gebildet wird, kennzeichnet.
Ein Vorteil dieses Verfahrens ist die Möglichkeit, ein getrenntes Zugriffsverfahren zu einem Objekt aufzubauen. Außer dem Zugriff auf ein Objekt über herkömmliche Objektreferenzen gestattet das obengenannte Konzept Zugriff auf ein Objekt durch Kennzeichnen seiner BOKA-Werta, die durch ihre eigene Natur ein BO eindeutig kennzeichnen. Dieses getrennte Zugriffsverfahren ist für den Realisierungsprozess elementar, da es Objektstrukturen gestattet, die Realisierung eines BO auszuführen, ohne dass eine Objektreferenz des BO realisiert sein muss.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 4 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung wird ein so genannter BO-Instanzraum (BO Instance Space, BOIS) als ein gemeinsames Speichermedium für alle BO-Instanzen nach Erzeugung aufgebaut. Der BOIS unterstützt auch das Abrufen einer bestimmten BO-Instanz basierend auf den Informationen der Klasse BO und der BOKA- Werte der BO-Instanz, wodurch BOISs das BOKA-Konzept ausnutzen.
Dieses Merkmal ist wichtig, um einen partiellen, schrittweisen Realisierungsprozess zu ermöglichen. Für die wiederholte Realisierung von BOs müssen zusammenarbeitende Objektstrukturen in der Läge sein, ein bestimmtes BO zu suchen, das an einer gemeinsamen Stelle realisiert wird, das die BO-Instanz mit weiteren BO-Daten erweitert.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 5 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung können verschiedene Typen von BOISs unterschieden werden. Ein oder mehrere so genannte explizite BOISs können zum Speichern und Abrufen von BO-Instanzen einer bestimmten Klasse BO ausgenutzt werden; d. h., für jede spezielle Klasse BO ist es möglich zu definieren, in welchem der expliziten BOISs eine BO-Instanz dieser Klasse gespeichert werden wird. Außerdem wird ein sogenannter impliziter BOIS zur Verfügung stehen, der verwendet wird, um BO-Instanzen einer bestimmten Klasse BO zu speichern, wenn keiner der expliziten BOISs zum Speichern und Abrufen von BO-Instanzen dieser Klasse BO definiert wurde.
Dieses mehrfache BOIS-Konzept erhöht die Flexibilität. Weiterhin kann es für Geheimhaltungs- und Sicherheitszwecke verwendet werden. Als ein weiterer Vorteil gestattet es die Bereitstellung von BOIS von angemessenen Größen, d. h. von BOISs, die eine beachtliche Anzahl von BO-Instanzen speichern, die so die Effektivität für das Auffinden von BO-Instanzen beeinflussen.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 6 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung kann das BOIS-Konzept durch Steuer- Verarbeitung verbessert werden, indem überwacht wird, ob auf irgendwelche der innerhalb eines BOIS gespeicherten BO- Instanzen noch durch irgendein anderes Objekt im System Bezug genommen wird. Sobald ein BOIS feststellt, dass der letzte Bezug zu irgendeiner der gespeicherten BO-Instanzen entfernt wurde, d. h., kein anderes Objekt innerhalb des Systems bezieht sich weiter auf die BO-Instanz, löscht die Steuerverarbeitung eines BOIS die BO-Instanz transparent.
Ein derartiges BOIS-Verhalten vereinfacht die Handhabung von BO-Instanzen erheblich. Es ist nicht mehr notwendig, eine BO- Instanz explizit zu löschen, wenn der aktuelle Nutzer nicht mehr an der BO-Instanz interessiert ist. Es genügt, dass ein Nutzer den Objektbezug aufgibt, der BOIS wird die BO-Instanz feststellen, zu der kein Bezug besteht und die BO-Instanz transparent löschen.
Unabhängige Nutzer derselben BO-Instanz, die voneinander keine Kenntnis haben, müssen in der BO-Instanz ihr Interesse nicht synchronisieren, d. h., ob das BO entfernt werden kann oder ob ein anderer Nutzer die BO-Instanz noch benötigt.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 7 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung werden die Klassen TO durch eine Gruppe von OO-Methoden erweitert, die ein abstraktes Protokoll verkörpern, um mit den BAs zu interagieren. Das Protokoll umfasst eine OO-Methode START, um eine Übertragungsverbindung unter Verwendung irgendeines der verfügbaren Übertragungsprotokolle aufzubauen, wenn die BA auf einem entfernten Datenverarbeitungssystem ausgeführt wird, und um die Ausführung der BA zu beginnen, die der Klasse TO zugewiesen wurde. Weiterhin bietet das Protokoll eine OO- Methode STOP, um die BA auszuführen und zu beenden, und, wenn die BA auf einem entfernten Datenverarbeitungssystem ausgeführt wird, die Übertragungsverbindung zu dem entfernten System zu schließen. Schließlich ist die OO-Methode TRANSMIT Teil des Protokolls, um bestimmte BA-Nachrichten an die BA zur Verarbeitung zu übertragen, wobei der Anforderer von Wissen und Verständnis irgendwelcher Übertragungsdetails entlastet wird, um auf eine antwortende BA-Nachricht zu warten, die von der BA als ein Ergebnis der Verarbeitung der ersten BA- Nachricht zurückgesendet wird.
Diese Verringerung des Spektrums von Interaktionen mit der BA zu einem gemeinsamen Kern, d. h. zu einem gemeinsamen Verhalten, unabhängig von der konkreten Technologie, die zum Datenaustausch zwischen TO und der BA verwendet wird, führt zu einer dramatischen Vereinfachung, da typischerweise eine überwältigende Anzahl verschiedener konkreter Techniken verfügbar ist, die jetzt auf gemeinsame Weise behandelt werden können. Insbesondere wenn die BA auf einem entfernten Datenverarbeitungssystem ausgeführt wird, muss auf hochentwickelte und komplexe Netzwerk-Protokolle zugegriffen werden. Das Verfahren der Erfindung gestattet, das abstrakte Protokoll auf die verschiedenen konkreten Protokolle abzubilden. Diese Abbildung wird nur einmal ausgeführt und steht dann zur wiederholten Ausnutzung abhängig von der tatsächlich verfügbaren Technologie zu Verfügung.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 8 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung werden die Klassen TO um Wissen und Fähigkeit erweitert, ihre zugeordneten Klassen TR festzustellen. Ähnlich werden die Klassen TR um Wissen und Fähigkeit erweitert, die Klasse TO festzustellen, der sie zugeordnet sind.
Die Fähigkeit einer TO-Instanz, ihre zugeordneten TR-Klassen und TR-Instanzen festzustellen, gestattet es, die Möglichkeiten der einzelnen TRs transparent zu nutzen und befreit so die TOs vom Wissen über irgendwelche Einzelheiten der BA-Nachricht. Umgekehrt gestattet die Fähigkeit der TR- Instanzen, ihre zugeordnete TO-Instanz festzustellen, den IR- Instanzen, transparent auf Informationen zuzugreifen, die innerhalb einer TO-Instanz gespeichert sind, und gestattet den TRs, sie für ihre Verarbeitung auszunutzen. Basierend auf diesen Konzepten kann die TO-Instanz die Erzeugung einer BA- Nachricht einschließlich des Füllens von Informationen in die BA-Nachricht an die TR-Instanzen abgeben. Im allgemeinen vereinfacht das Verfahren die OO-Methoden-Schnittstellen, da Objekte mit der Möglichkeit ausgestattet sind, verknüpfte Objekte festzustellen, aus denen viele zusätzliche Informationen für die eigene Verarbeitung abgerufen werden können, die anderenfalls über die OO-Methoden-Schnittstellen weitergeleitet werden müssten.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 9 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung werden die Klassen TR um eine OO- Methode INXACTION erweitert. INXACTION stellt die BO- Instanzkennzeichen fest, die zur Erzeugung der BA-Nachricht unter Verwendung der BOKA-Werte verwendet werden sollen, auf die von ihrer zugeordneten TO-Instanz zugegriffen werden kann. INXACTION greift auf die BO-Instanzen innerhalb des BOIS mit Hilfe der BOKA-Werte zu. Unter der Steuerung der Abbildungsinformationen des TR entnimmt INXACTION die erforderlichen BOA-Werte aus den BO-Instanzen, um eine BA- Nachricht zu erzeugen und die BOA-Werte in die verknüpften Positionen der BA-Nachricht der BA-Nachrichtendatenelemente zu speichern. Danach sendet INXACTION die erzeugte BA-Nachricht durch Aufrufen der OO-Methode TRANSMIT der zugeordneten TO- Instanz zur weiteren Verarbeitung an die BA. Als Antwort auf den Empfang der BA leitet INXACTION die aktuell empfangene BA- Nachricht als BA-Ausgabe an die OO-Methode OUTXACTION dieser TR-Instanz weiter, die für die Verarbeitung der empfangenen BA-Ausgabenachricht verantwortlich ist. Weiterhin wird jede der Klassen TR mit einer OO-Methode OUTXACTION zur Verarbeitung der aktuell empfangenen BA-Nachricht erweitert. In diesem Verarbeitungsschritt werden BO-Instanzen mit BOA- Werten, die in der aktuell empfangenen BA-Nachricht gespeichert sind, in einem Prozess erweitert, der inkrementelle partielle BO-Realisierung oder kurz Realisierung genannt wird. Realisierung bedeutet, dass OUTXACTION zuerst unter der Steuerung der Abbildungsinformationen des TR alle BO-Instanzen feststellt, die von den Datenelementen der aktuell empfangenen BA-Nachricht berührt wurden. Die BOKA- Werte für die berührten BO-Instanzen werden entweder von den BOKA-Werten der aktuell empfangenen BA-Nachricht oder von der zugeordneten TO-Instanz abgerufen, die alle BOKA-Werte aller BO-Instanzen speichert, die unter ihrer Steuerung in einem Kontext realisiert wurden.
Realisierung bedeutet zweitens, dass OUTXACTION basierend auf den BOKA-Werten jede berührte BO-Instanz innerhalb des BOIS sucht. Wenn die berührte BO-Instanz in dem BOIS gefunden werden konnte, wird sie während des Realisierungsprozesses verwendet, wenn dagegen die berührte BO-Instanz innerhalb des BOIS nicht gefunden werden könnte, wird eine neue BO-Instanz innerhalb des BOIS erzeugt. Realisierung bedeutet drittens, dass OUTXACTION unter Steuerung der Abbildungsinformationen des TR jedes Datenelement der aktuell empfangenen BA-Nachricht in das entsprechende BOA der berührten BO-Instanz kopiert und somit die BOAs der BO-Instanzen inkrementell realisiert. Zum Schluss sendet OUTXACTION die Objektreferenzen aller berührter BO-Instanzen, die während der aktuellen Ausführung von OUTXACTION realisiert wurden, an ihren Aufrufer zurück.
Die Erweiterung der TR-Instanzen um die OO-Methoden INXACTION und OUTXACTION, welche die obengenannte Folge von Aktivitäten ausführen, führt vorteilhafterweise dazu, dass die TO- Instanzen befreit werden vom
Erzeugen der BA-Nachrichten, die an die BAs gesendet werden sollen,
Ausführendes Realisierungsprozesses selbst.
Stattdessen nutzen die TO-Instanzen die TR-Instanzen für diesen Teil der Verarbeitung aus. Die TO-Instanzen begrenzen ihre Aktivitäten beim Steuern der BA-Ausführung durch Austauschen von BA-Nachrichten. Das Spektrum von TO- Aktivitäten wird übersichtlicher. Andererseits sind, da für die TR-Instanzen die Abbildungsinformationen zwischen den BA- Nachrichtendatenelementen und den BOAs verfügbar sind, die TR- Instanzen die ideale Stelle für die BA-Nachrichtenerzeugung und BO-Realisierungs-Verarbeitung, was zu einer modularen Gesamtstruktur führt. Der Ansatz profitiert von dem BOIS- Konzept, da es für die Verarbeitung der Realisierung vorteilhaft ist, auf BO-Instanzen unter Verwendung der BOKA- Werte zuzugreifen.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 10 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung wird die vollständige Reihenfolge von Interaktionen der BA-Ausführung vom Anfang bis zum Abschluss aus einer oder mehreren Untereinheiten zusammengesetzt, Übertragungsschritte (Transactional Steps, TSTs) genannt. Jeder TST erzeugt selbständig eine BA-Nachricht oder mehrere BA-Nachrichten und tauscht sie mit der BA aus. Die TST-Ausführung ist abgeschlossen, sobald durch die BA eine BA-Nachricht zurückgesendet wird, die als die letzte BA- Nachricht des TST definiert wurde. Diese letzte BA-Nachricht definiert optional den Beginn eines nächsten TST. Jeder der TSTs ist als eine eindeutige OO-Methode gekapselt, Übertragungsobjektmethode (Transactional Object Method, TOM) der Klasse TO genannt.
Durch Einführung dieser TOMs ist es nun möglich, einen bestimmten Teil einer BA durch einen TOM-Aufruf auszuführen. Die TOM befreit ihren Aufrufer vom Erzeugen, Senden und Empfangen von BA-Nachrichten. Außerdem wird die Interpretation der empfangenen BA-Nachrichten im Realisierungsschritt transparent für den Aufrufer bearbeitet.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 11 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung werden die Klassen BO durch OO- Methoden erweitert, Geschäftsobjektmethoden (Business Object Methods, BOMs) genannt, die einen funktionellen, von BÄs gebotenen Teil kapseln.
Der Aufruf einer BOM führt schließlich zum Aufruf einer oder mehrerer TOMs einer oder mehrerer TO-Instanzen. Sobald eine BOM aufgerufen wird, kann ihre Ausführung zuerst zur Erzeugung einer neuen TO-Instanz führen, wenn eine TOM von einer TO- Instanz ausgeführt werden soll, die noch nicht zu einer Instanz gemacht wurde.
Die Einführung dieser BOMs gestattet nun, bestimmte T eile verschiedener BAs transparent auszuführen. So werden die Nutzer der BO-Instanzen vollständig von den TO- und TR- Strukturen abgeschirmt. Gegebenenfalls wissen sie nicht einmal, dass es diese Strukturen gibt.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 12 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung werden die BOM- und TOM-OO-Methoden erweitert, um alle Objektreferenzen der BO-Instanzen, die während ihrer Ausführungsperiode realisiert wurden, an ihre Anforderer zurückzusenden. Dies gestattet den Anforderern, die Ergebnisse der BA-Ausführung durch Prüfen der realisierten BOs auszunutzen.
Zusätzliche Vorteile der Erfindung werden durch Anspruch 13 ausgeführt. Entsprechend einer weiteren Ausführungsform der vorgeschlagenen Erfindung werden eine oder mehrere Übertragungsobjekt-Klassen (Communication Object classes, CO) eingeführt, die ein abstraktes Protokoll bieten, das aus den OO-Methoden START, STOP, TRANSMIT mit gleicher Semantik wie das abstrakte Protokoll der Klassen TO besteht. Die Klassen CO werden zum Zweck von Kapselaspekten eingeführt, die für die Details der Übertragung zu den BAs wichtig sind. Insbesondere wenn die BAs auf einem entfernten Datenverarbeitungssystem ausgeführt werden sollen, wird das abstrakte Protokoll auf ein konkretes Übertragungsprotokoll abgebildet, das verwendet wird, um Datenverarbeitungssysteme in einem Computernetz zu verbinden. Durch Zuordnen einer Klasse CO zu einer Klasse TO und Erweitern der OO-Methode START der TO-Instanz, um eine Instanz der zugeordneten Klasse CO zu erzeugen, um die entsprechende OO-Methode START der zugeordneten CO-Instanz aufzurufen, sind die TO-Instanzen in der Lage, die CO-Instanz zur Übertragung an die BA zu nutzen. Auf dieselbe Art werden die OO-Methoden STOP und TRANSMIT der TO-Instanz erweitert, um die entsprechenden Methoden der zugeordneten CO-Instanz zur Ausführung des konkreten Protokolls aufzurufen, auf dem die CO-Instanz basiert.
Die Erzeugung einer oder mehrerer getrennter Klassen CO, die das abstrakte Protokoll auf irgendeines der verfügbaren konkreten Übertragungsprotokolle abbilden, verbessert die Modularisierung der funktionellen Bestandteile. Gleichzeitig erhöhtes die Flexibilität, da das TO einfach aktiviert werden kann, um das abstrakte Protokoll über irgendeines der verfügbaren konkreten Protokolle zu verarbeiten, indem nur die entsprechende. Klasse CO der Klasse TO zugeordnet wird.
Eine weitere Aufgabe der Erfindung wird durch Anspruch 17 zusammen mit zusätzlichen Vorteilen der Erfindung gelöst, wie durch die Ansprüche 18 und 19 dargelegt. Gemäß der Erfindung ist das vorgeschlagene Verfahren auf die Ausführung und die Wechselwirkung von Objektstrukturen gerichtet, wie oben beschrieben. Diese Objektstrukturen können durch das Verfahren wie in Ansprüch 1 bis 13 entworfen oder einige andere Techniken hergeleitet werden.
Viele Vorteile dieses Ausführungsverfahrens wurden bereits besprochen. Für weitere Details wird daher auf die obigen Abschnitte verwiesen.
Fig. 1 ist ein Diagramm, das die Zuordnungen der BOAs zu den Eingabe- und Ausgabeparametern der BAs widerspiegelt
Fig. 2 ist ein Diagramm einer TR und ihrer Beziehung zu BOs und BOAs
Fig. 3 ist ein Diagramm, das die Klasse CO und ihr abstraktes Protokoll darstellt
Fig. 4 ist ein Diagramm, das einige konkrete Ausführungsmöglichkeiten für die abstrakten Protokolle darstellt
Fig. 5 ist ein Diagramm der Hierarchie der Klasse TO und der problemspezifischen Klassen TO
Fig. 6 ist ein Diagramm der Architekturmerkmale einer problemspezifischen Klasse TO
Fig. 7 stellt den Prozess der Bildung von Unterklassen problemspezifischer Klassen BO dar
Fig. 8 bietet einen Überblick über die konzeptionelle Wechselwirkung der Hauptarchitekturelemente
Die der Veranschaulichung dienende Ausführungsform der Erfindung basiert auf BAs, die unter Steuerung eines Transaktionsverwaltungssystems ausgeführt werden, im aktuellen Fall dem bekannten IMS (Information Management System) der IBM Corporation. BAs im Sinne der Erfindung werden in dieser Umgebung als echte Transaktionen dargestellt.
Wie bereits in der vorausgehenden Besprechung gezeigt, bezieht sich die Erfindung auf irgendeinen Typ von BA, nicht nur auf Transaktionen im Sinn einer Transaktionsüberwachung.
Die Erfindung wurde innerhalb einer Umgebung auf der Basis von Smalltalk erfolgreich ausgeführt und geprüft.
Herausragende Elemente und Prinzipien der Ausführungsform sind:
Das wesentliche Ziel sind die Definition und Unterstützung von echten Businessobjekten (Business Objects, BOs), d. h. von Objekten mit einer tatsächlichen Bedeutung als eine eindeutige Einheit oder ein Konzept hinsichtlich des zugrunde liegenden Geschäfts. Die Kennzeichnung des BO ist natürlich das Ergebnis einer menschlichen Analyse der geerbten Anwendung in Verbindung mit dem Geschäftsbereich. Das Verfahren wird daher annehmen, dass die BO-Identitäten als ein Ergebnis einer vorhergehenden objektorientierten Analyse verfügbar sind, die erfahrungsgemäß unkompliziert ist, wenn das Wissen der geerbten Anwendung zur Verfügung steht. Das Problem "großer" Objekte mit irreführender Identität, wie bei Umhüllungstechniken anzutreffen, wird somit vermieden.
Unterstützung dieser gekennzeichneten BOs in der Umstellungsarchitektur und -umgebung bedeutet:
o Es muss möglich sein, die BOs zu definieren und zu realisieren (auszuführen).
o BO-Methoden können schließlich zur Ausführung von zugrunde liegenden, umgestellten IMS-Transaktionen führen.
o Eingabe/Ausgabeparameter der BO-Methoden werden sich entweder auf BO-Attribute oder auf unabhängige Parameter der BO-Methoden selbst beziehen.
Modifikation der zugrunde liegenden geerbten Anwendung (in diesem Fall IMS-Transaktionen) sollte auf ein Minimum begrenzt werden, um somit ein Maximum von Wiederverwendung des vorausgegangenen Anwendungsentwicklungsaufwands zu gestatten. Es wird unten gezeigt werden, dass im Fall des Umstellens von IMS-Anwendungen überhaupt keine Modifikation der geerbten Anwendung erforderlich ist.
Diese Umstellungsarchitektur und -umgebung können daher als Vermittler zwischen dem geerbten Code und den BOs angesehen werden.
Die BOs sind andererseits die ideale Basis
o für neue Typen grafischer Benutzeroberflächen (GUIS),
o als Integrationsplattform mit zusätzlichen Anwendungen
- entweder als zusätzliche BO-Methoden
- oder als Teilnehmer eines größeren Arbeitsbereichs, in dem die BOs Teil davon sind
IMS bietet die Protokollsuite Advanced-Program-to- Program-Communication (APPC) von IBM an, ein konkretes Protokoll für Übertragungszwecke zwischen Programmen über Computersystemgrenzen. Zusätzlich ist APPC in IMS als eine sogenannte "Implicit-APPC"-Unterstützung verfügbar, die insbesondere IMS-Transaktionen gestattet, die ursprünglich nur für eine Datenstation vom Typ 3270 entwickelt wurden, um zur Ausführung transparent von fern über APPC an die Transaktion geleitet zu werden und um Daten auszutauschen, wobei eine Interaktion einer Datenstation vom Typ 3270 basierend auf der APPC- Protokollsuite simuliert wird. Die Ausführungsform der Erfindung basiert auf der Ausnutzung dieser impliziten APPC-Unterstützung.
BOs im Sinn der Umstellungsarchitektur sind Träger von permanenten Daten, die nach Benutzerbedürfnissen neu zu einer Instanz gemacht werden. Interaktion mit den BOs über die BO-Methoden wird BO-Daten basierend auf den bestehenden Schnittstellen der entfernten Transaktionen transparent abrufen oder modifizieren.
Eine Analyse bestehender Transaktionsanwendungen wird offenbaren, dass typischerweise
o Eingabe/Ausgabedaten einer Transaktion nicht nur auf ein einziges BO bezogen sind. Die Ausführung einer Transaktion könnte so zu dem transparenten Bezug/der Spezialisierung (reference/instantation) einer Vielzahl von BOs führen.
o eine einzelne Transaktion nur auf eine echte Untergruppe von BO-Attributen bezogen wird. Dies führt zu dem interessanten Effekt, dass die Spezialisierung der BOs nur teilweise erfolgen kann, d. h. nur in Bezug auf eine Untergruppe von BO- Attributen. BOs werden nur in dem tatsächlich notwendigen Ausmaß verfügbar gemacht. Wenn gewünscht, erhöht sich die Anzahl verfügbarer BO- Attribute dynamisch, was zu einer sehr leistungsfähigen und wirtschaftlichen Verwaltung der Speicherressourcen führt.
Die Umstellungsarchitektur selbst muss mit OO-Techniken ausgeführt werden.
Kurz gesagt, die Umstellungsarchitektur und -umgebung unterstützen einen OO-Zugriff auf bestehende Transaktionsanwendungen, wohingegen die Unterteilung dieses Zugriffs durch BOs definiert wird.
Das durch die Erfindung vorgeschlagene und in der Ausführungsform unten ausgeführte Verfahren wird in der folgenden Beschreibung eine Architektur genannt. Einzelne Teile des gesamten Verfahrens werden als Architekturelemente besprochen.
Entsprechend dem aktuellen Verfahren sind für das Gesamtproblem, die Gruppe bestehender Online- Transaktionsverarbeitungsanwendungen (Online Transaction Processing Applications, OLTP), die dem konkreten Geschäftsmodell, d. h. den Businessobjekten, als Grundbausteine zur Verfügung stehen und diese Transaktionen innerhalb von Methoden, d. h. Nachrichten, zu kapseln (umhüllen), die BOs verantwortlich für die Verringerung auf eine Gruppe interagierender Basisobjekttypen, d. h. Objektklassen. Diese begrenzte Gruppe von Objektklassen bildet die Architektur des Verfahrens.
Natürlich wird die gesamte Architektur selbst mit einer Gruppe von Klassen im Sinn einer objektorientierten Programmiersprache (in diesem Fall Smalltalk) ausgeführt, die ein Gerüst von Klassen mit sorgfältig angepasster Funktionalität bietet.
Das Umstellen einer bestehenden OLTP-Anwendung auf diese vorgeschlagene Architektur bedeutet, eine Gruppe von anwendungsspezifischen Klassen durch den Prozess der Aufteilung der grundlegenden Architekturbasisklassen in Unterklassen auszuführen. Zur Laufzeit werden Instanzen dieser anwendungsspezifischen Objektklassen dann die transparente Ausführung der bestehenden OLTP-Transaktionen unter Verwendung von BO-Attributen als OLTP-Parameter unterstützen. Die anwendungsspezifischen Klassen führen diesen Teil der gesamten Funktionalität aus, der innerhalb der Architekturbasisklassen nicht allgemein verfügbar ist. Dieser OO-Typ-Ansatz verringert den anwendungsspezifischen Entwicklungsaufwand bedeutend und erhöht gleichzeitig die Flexibilität der Ausführung.
So bietet das Client-System eine Gruppe permanenter BOs. Interaktionen mit den BOs können transparent zur Ausführung von OLTP-Transaktionen führen, die das zugrunde liegende Transaktionssystem, die spezielle Struktur von Transaktionen, die Datenbanken, die durch die Transaktionen manipuliert werden, und natürlich die Übertragungsdetails des Client- und des Server-Computer-Systems, das die OLTP Anwendung ausführt, vollständig verdecken.
Die vorgeschlagene Architektur kehrt die Sicht einer Transaktion um, die in der Vergangenheit auf dem funktionellen Ansatz basierte. Herkömmlicherweise würden Transaktionen als ein Prozess angesehen, der eine zweckmäßig definierte Gruppe von Attributen der BOs kombiniert.
Die aktuelle Architektur kehrt diese Sicht um, da die wesentlichen Einheiten die permanenten BOs sind, die durch Senden von Nachrichten manipuliert werden können, von denen einige zur Ausführung herkömmlicher Transaktionen führen. Die Hauptarchitekturelemente, die einzeln besprochen werden, sind:
1. Businessobjekte (Business Objects, BOs)
2. BO-Instanzraum (BO Instance Space, BOIS)
3. Übertragungsaufzeichnung (Transaktion Records, TRs)
4. Übertragungsobjekte (Communication Objects, COs)
5. Transaktionsobjekte (Transactional Objects, TOs)
BOs sind die Schlüsselelemente der Gesamtarchitektur, da
auf alle anderen Architekturelemente auf eine indirekte Art nur durch Interaktion mit den BOs zugegriffen werden kann,
die Gruppe der BO-Klassen und BO-Instanzen eine Schicht bildet, die einen BO-Nutzer vom Rest der umgestellten OLTP-Anwendung und von der geerbten Anwendung selbst abschirmt.
Wie schon durch den Namen gekennzeichnet, sind BOs die Objekte, die in einem direkten Sinn die Einheiten sind, die in der Geschäftswelt eine Rolle spielen. In Bezug auf Beschaffenheit und Unterteilung stellen die BOs das Modell des Unternehmensbereichs dar. Offensichtlich sind Beispiele für BOs Kunden, Verträge, Bestellungen, Konten und so weiter. Ausschließlich zu diesem. Zeitpunkt umfasst der Verhaltensaspekt des Definitionsprozesses der BOs zwei Schritte:
1. Feststellen der BO-Identität
2. Feststellen der BO-Attribute
Hinsichtlich der BO-Identität kann eines oder eine Kombination der folgenden Verfahren angewendet werden:
Entsprechend der Erfahrung ergeben sich sehr oft BO- Identitäten ziemlich offensichtlich aus dem Geschäftsbereich, indem nur nach den Einheiten gefragt wird, mit denen das spezielle Geschäft arbeitet.
Für bestimmte Wirtschaftszweige wurden spezielle Datenmodelle unabhängig von einer speziellen Firma entwickelt. Zum Beispiel wurden die Finanz- und Versicherungsgeschäfte sehr genau durch bestimmte Datenmodelle (Finanzanwendungsarchitektur, FAA, und Versicherungsanwendungsarchitektur, IAA) modelliert. Falls verfügbar, können diese Datenmodelle direkt verwendet werden, um auf die BO-Identitäten zu schließen.
Natürlich könnte in schwierigeren Fällen eine objektorientierte Analyse (object oriented analysis, OOA) unter Verwendung einer der verfügbaren Methoden zum Identifizieren der relevanten BOs erforderlich sein.
Da BOs Träger von permanenten Daten sind, die abgerufen und durch die Verwendung bestehender Transaktionen manipuliert werden sollen, muss das Datenspektrum des BO als die Gruppe der BO-Attribute definiert werden.
Als eine herausragende Eigenschaft wird das aktuelle Verfahren des Feststellens und Definierens der BO-Attribute durch die Eigenheit gekennzeichnet, dass es auf dem Eingabe- und Ausgabe-Datenspektrum der bestehenden Transaktionsanwendung basiert, oder anders gesagt, es basiert auf den Spezifikationen der Benutzeroberfläche (user interface, UI) der bestehenden Transaktion. Um Hintergrund und Vorteil dieses Verfahrens zu verstehen, muss erkannt werden,
dass die UI-Spezifikationen direkt die geschäftsbezogenen Daten widerspiegeln, d. h. die Datenelemente, mit denen sich ein Geschäftsbenutzer der Transaktionsanwendungen beschäftigt. Entsprechend der Erfahrung mit diesem Typ von Verfahren basierend auf diesem geschäftlichen Standpunkt können die Datenelemente, die für den Geschäftsbereich wesentlich sind, festgestellt und mit den verschiedenen Typen von BOs als BO-Attribute einfach und sehr wirksam verknüpft werden.
dass die bestehenden Transaktionen in einem späteren Schritt zur Abfrage und Manipulation der BO-Daten verwendet werden. Die Daten, die Teil der UI- Spezifikation sind, begrenzen daher genau das Datenspektrum, das als BO-Attribute zur Verfügung steht.
dass dies das Analysieren komplizierter Datenbankstrukturen vermeidet, die historisch in einem evolutionären Prozess gewachsen sind. Außerdem enthalten die Datenbanken selbst nicht direkt die für das Geschäft relevanten Daten, wie bestimmte Typen von Abbildungen, die oft zwischen den Datenbanken und durch Benutzerschnittstellen widergespiegelten Daten vorkommen.
Da die Anzahl von Transaktionen einer speziellen Anwendung zunimmt, die auf die aktuelle Architektur umgestellt wurde, muss das BO-Attributspektrum erweitert werden. Somit ist der Prozess des Definierens der BO-Attribute iterativ. Die Daten, auf die durch die Transaktionen zugegriffen werden kann, befinden sich typischerweise in (manchmal einer Vielzahl von) Datenbanken. Die Klassen BO modellieren daher verschiedene Typen von permanenten BOs. Um die verschiedenen Instanzen eines BO einer einzelnen Klasse eindeutig identifizieren zu können, muss die Gruppe von BO-Attributen folgendes unterscheiden:
BO-Schlüsselattribute
Typischerweise werden sie dargestellt durch eine (sehr kleine) Untergruppe von BO-Attributen, die mit Bezug auf die zugrunde liegenden Datenbanken zusammen mit der Klasse BO eine bestimmte BO-Instanz eindeutig identifizieren. Natürlich ergeben sich die BO- Schlüsselattribute direkt aus den Schlüsselattributen der entsprechenden Datenbanken.
BO-Allgemeinattribute
Der gesamte Rest der BO-Attribute, der nicht gestattet, die verschiedenen BO-Instanzen innerhalb der Datenbanken eindeutig zu unterscheiden, werden als Allgemeinattribute bezeichnet.
Wenn die BO-Attribute mit der UI-Spezifikation einer Vielzahl bestehender Transaktionen verknüpft werden, sind folgende wesentliche Beobachtungen wichtig:
Die Eingabe/Ausgabe-Datenelemente in der UI- Spezifikation einer bestehenden Transaktion können sich auf eine Untergruppe von BO-Attributen beziehen. Das heißt, mit Bezug auf eine bestimmte Klasse BO kann nur ein Teil ihres Attributspektrums mit den Eingabe/Ausgabe-Datenelementen einer einzelnen Transaktion verknüpft werden. Umgekehrt gibt es weitere BO-Attribute, die nicht innerhalb der Eingabe/Ausgabe- Datenelemente einer bestimmten Transaktion auftreten.
Die Eingabe/Ausgabe-Datenelemente in den UI- Spezifikationen einer bestehenden Transaktion können sich auf Untergruppen von Attributen der verschiedenen BOs beziehen.
Verschiedene Attribute eines bestimmten BO können sich auf Eingabe/Ausgabe-Datenelemente von verschiedenen Transaktionen beziehen.
Der Prozess des Verknüpfens der Eingabe/Ausgabe-Datenelemente von bestehenden Transaktionen mit den BO-Attributen wird zusammen mit den obigen Beobachtungen in Fig. 1 dargestellt. Fig. 1 zeigt zwei verschiedene BAs, eine BA (110) und eine BA (120). Weiterhin werden zwei verschiedene Klassen BO (130) und (140) zusammen mit ihren Attributen (131) und (141) dargestellt.
Bestimmte Eingabe- und Ausgabeparameter sind wichtig für die leitende BA (110). Diese Parameter sind Teil der zwei Tabellen (111) und (112) auf einem Computerbildschirm 3270. Im Beispiel von Fig. 1 sind die Eingabe- und Ausgabeparameter der BA (120) in Tabelle (121) zu finden. Die Verbindungslinien in Fig. 1 spiegeln zum Beispiel wider, dass
- Eingabe/Ausgabeparameter (113) von BA (110) mit BOA (132) der Klasse BO (130) verknüpft sind und umgekehrt,
- Eingabe/Ausgabeparameter (122) von BA (120) mit BOA (132) der Klasse BO (130) verknüpft sind und umgekehrt,
- Eingabe/Ausgabeparameter (114) von BA (120) mit BOA (142) der Klasse BO (140) verknüpft sind,
- usw.
Jedes zu einer Instanz gemachte BO wird zusammen mit den anderen BOs innerhalb einer speziellen Sammlung gespeichert, BO Instanzraum (BO Instance Space, BOIS) genannt. Da jedes BO eindeutig durch die Klasse des BO zusammen mit den speziellen Werten der BO-Schlüsselattribute gekennzeichnet wird, ist diese Gruppe von Informationen auch ausreichend zur eindeutigen Kennzeichnung von BO-Instanzen innerhalb des BOIS.
Die Notwendigkeit, das Konzept eines BOIS einzuführen, ist eine direkte Folge der Beobachtungen, die in den Ausführungen zu dem Architekturelement Business Objects (BOs) besprochen wurden: wenn eine einzelne Transaktion typischerweise nur Teile des Spektrums der Attributwerte einer BO-Instanz liefert und wenn so die Ausführung von mehreren Transaktionen erforderlich ist, um die BO-Attributwerte schrittweise zu vervollständigen, dann muss es möglich sein
das mögliche Vorkommen einer bestimmten BO-Instanz an einer eindeutigen Stelle zu suchen,
die Attributwerte einer bestimmten BO-Instanz schrittweise zu vervollständigen/aktualisieren
und gleichzeitig die aktualisierte BO-Instanz allen Nutzern des BO verfügbar zu machen.
Dieses teilweise Erzeugen einer BO-Instanz, erweitert um den Prozess der schrittweisen Vervollständigung der BO-Attribute, wird im folgenden Realisierung genannt, um es von einem vollständigen Erzeugen einer Instanz zu unterscheiden. Dieses Konzept der Realisierung bietet einige sehr attraktive Vorteile:
Es gestattet die Arbeit mit unvollständigen Daten.
Im Gegensatz zu anderen permanenten Modellen bietet es eine sehr wirtschaftliche Verwendung des Speichers. BO-Instanzen werden nicht mit Bezug auf ihr gesamtes Attributspektrum zu einer Instanz gemacht. Dies ist von besonderer Wichtigkeit, da auf der geschäftsrelevanten Ebene Objekte sehr groß werden können. BO-Instanzen werden nur in dem Maß realisiert, wie es tatsächlich vom Nutzer gefordert wird.
Während der Lebensdauer einer BO-Instanz kann ihr Attributspektrum schrittweise vervollständigt werden.
In direktem Zusammenhang mit dem BOIS steht die Frage der Lebensdauer einer bestimmten BO-Instanz. Da im allgemeinen Fall eine Vielzahl von Transaktionsausführungen für eine BO- Realisierung erforderlich sein könnte, muss eine BO-Instanz eine größere Lebensdauer haben, als eine zugrunde liegende Realisierungstransaktion. In der aktuellen Lösung "lebt" eine BO-Instanz, wenn sie nicht explizit durch einen Nutzer gelöscht wird, so lange, bis mindestens ein Nutzer auf diese BO-Instanz Bezug nimmt.
Die aktuelle BOIS-Ausführung bietet zwei BOIS-Alternativen, aus denen ein Nutzer der Architektur wählen kann. Für ein einzelnes BO kann ein Nutzer entscheiden, wo sich die BO- Instanz befinden soll:
in einem impliziten BOIS.
Der implizite BOIS wird die Standardauswahl eines Nutzers sein, da seine Handhabung keinen weiteren Aktivitäten des Nutzers erfordert. Wenn im Fall eines impliziten BOIS der BOIS feststellt, dass es keinen Nutzer dieser speziellen BO-Instanz gibt, entfernt er dieses BO transparent und automatisch.
Die aktuelle implizite BOIS-Ausführung basiert auf dem Garbage-Collector von Smalltalk.
in einem expliziten BOIS.
Ein expliziter BOIS kann als eine Art von privatem BOIS angesehen werden, dessen Verwendung wahrscheinlich eine Ausnahme sein wird. Im Fall eines expliziten BOIS muss ein Nutzer mit dem BOIS interagieren, um den BOIS zu informieren, ein bestimmtes BO vom BOIS zu löschen. So wird das Löschen des BO nicht länger transparent ausgeführt.
Wenn eine bestimmte Transaktion aufgerufen wird, erwartet sie im Allgemeinen eine bestimmte Menge von Daten als einen Eingabe-Datenblock. Als Folge der Ausführung wird ein Ausgabe- Datenblock zurückgesendet. Mit Bezug auf TMS werden diese Datenblöcke IOAREAs (input/output areas, Eingabe/Ausgabe- Bereiche) genannt.
Von ihrer eigenen Bedeutung her können die Eingabe/Ausgabe- Datenblöcke als eine Nachricht angesehen werden, die der Transaktion bekannt ist, die für Aufruf und Rückgabe der Transaktion ausgetauscht wird.
Die verschiedenen Typen von Nachrichten werden als spezielle Objektklassen modelliert, die Transaktionsaufzeichnungen (Transaction Records, TRs) genannt werden. Der wichtige Punkt bei TRs ist, dass sie keinen unstrukturierten Strom von Bytes darstellen. TRs sind mit beschreibenden Informationen ausgestattet, welche
für jeden Parameter, der Teil der Nachricht ist, die genaue Position, seine Länge, seinen Typ, ... definieren,
für jeden Parameter folgendes definieren
o die spezielle Klasse BO,
o das spezielle BO-Attribut,
das er darstellt,
die Parameter definieren, die nicht mit einer bestimmten Klasse BO verknüpft sind, aber trotzdem Eingabe/Ausgabe- Daten der Transaktion darstellen.
Somit sind die TR-Architekturen die zentrale Verbindung zwischen den Klassen BO und entsprechenden BO-Attributen einerseits und den einzelnen Eingabe/Ausgabe-Parametern einer Transaktion. TRs speichern daher die Abbildungsinformationen von einem Datenelement innerhalb einer Eingabe/Ausgabe- Nachricht auf ein Datenelement innerhalb einer Klasse BO, einem BO-Attribut und umgekehrt.
Wie schon im Zusammenhang mit dem Architekturelement eines BO besprochen, können verschiedene Parameter einer Nachricht, d. h. verschiedene Parameter eines TR, mit BO-Attributen von verschiedenen Klassen BO verknüpft sein.
Diese Abbildungsinformationen sind von wesentlicher Bedeutung,
um die BO-Realisierung zu unterstützen.
Unter Verwendung der Abbildungsinformationen ist es möglich, jeden Parameter einer Ausgabe-Nachricht einer Transaktion in das richtige BO-Attribut zu speichern und somit den Realisierungsprozess zu führen.
um die Erzeugung einer Eingabe-Nachricht zu unterstützen, welche die Ausführung der Transaktion auslöst.
Basierend auf den Abbildungsinformationen ist es möglich, eine Eingabe-Nachricht zu erzeugen, die durch eine bestimmte Transaktion ausführbar ist, und sie zu füllen
o mit Daten, die sich aus genau definierten BO- Attributen ergeben,
o mit Daten von zusätzlichen Eingabeparametern, die nicht mit einer bestimmten Klasse BO verknüpft sind.
Das Verhältnis zwischen den einzelnen Datenelementen in einem TR und den entsprechenden BO-Attributen wird in Fig. 2 dargestellt. Fig. 2 zeigt die Abbildung zwischen dem Eingabe- oder Ausgabe-Datenblock (IOAREA), d. h. die BA-Nachricht, die einzelnen Eingabe- oder Ausgabeparameter innerhalb dieses Blocks und die BOAs der einzelnen Klassen BO, die durch die Klasse TR angeordnet werden. (200) zeigt eine Klasse TR, die einen. Eingabe- oder Ausgabe-Datenblock (201) kapselt, der aus den einzelnen Eingabe- oder Ausgabeparametern (202) bis (207) zusammengesetzt wird. Weiterhin werden eine Klasse BO (220) zusammen mit ihren BOAs (221) und ein BO (230) zusammen mit seinen BOAs (231) und ein BO (240) zusammen mit seinen BOAs (241) gezeigt. Die durch die TRs verwaltete Abbildung wird durch die Verbindungen dargestellt, die zwischen einzelnen Eingabe- oder Ausgabeparametern der BA-Nachricht und einzelnen BOAs bestimmter Klassen BO gezeichnet sind. Zum Beispiel
- Eingabe- oder Ausgabeparameter (202), die BOA Parm1 (222) von BO (220) zugeordnet sind
- und so weiter bis zur letzten Zuordnung, wo
- Eingabe- oder Ausgabeparameter (207) BOA (242) von BO (240) zugeordnet sind.
Die Übertragung besteht im Wesentlichen aus dem Austausch von Informationen. Die grundlegende und architektonische Informationseinheit im aktuellen Verfahren ist eine Nachricht, die aus zwei Teilen gebildet wird:
Nachrichtentext
Der Nachrichtentext ist der tatsächliche Strom von Bytes, der die kleinsten Einheiten von Eingabe/Ausgabe-Daten einer Transaktion verkörpert. Daher ist der Nachrichtentext der Block von Daten, an denen ein TR arbeitet, um Unterelemente auf BO-Attribute abzubilden und umgekehrt (wie in den Ausführungen zu dem Architekturelement Transaction Records, TRs besprochen).
Transaktionssuffix (TS)
Um die Natur eines TS zu verstehen, sei daran erinnert, dass beim Empfang eines Ausgabe-Nachrichtentextes von einer Transaktion im Allgemeinen kein Kennzeichen verfügbar ist, das den Typ und somit die Anordnung der konkreten Nachricht kennzeichnet. Dieses Verhalten ist die Folge mehrerer Ursachen:
o Mit Kenntnis der speziellen Transaktion, die ausgeführt werden soll, und des zu verarbeitenden Eingabe-Nachrichtentextes kann nicht im Vorhinein der Typ des zu erwartenden Ausgabe-Nachrichtentextes geschlussfolgert werden. Abhängig von den Daten des Eingabe-Nachrichtentextes und abhängig von zusätzlichen Daten, die in der Datenbankumgebung gespeichert sind, in der die Transaktion ausgeführt wird, können verschiedene Ausgabe-Nachrichtentexte durch die Transaktion erzeugt werden.
o Abhängig vom Eingabe-Nachrichtentext und zusätzlichen Informationen in den Datenbanken kann eine ausführende Transaktion entscheiden, eine andere Transaktion aufzurufen, die den Ausgabe- Nachrichtentext erzeugt. So ist sogar die Identität der antwortenden Transaktion im Allgemeinen Fall im Voraus unbekannt.
Als eine Architekturlösung zu obengenannten Problemen schlägt das aktuelle Verfahren vor, jeden Nachrichtentext mit einem zusätzlichen Informationselement zu markieren, das Transaktionssuffix (TS) genannt wird. Ein TS, natürlich selbst durch ein Objekt dargestellt, speichert zwei Typen von Informationen:
a. den Namen der speziellen Transaktion, auf die sich die Nachricht bezieht,
b. den speziellen Nachrichtentyp, d. h. sein Layout.
Der TS wird als eine Art von Suffix an eine Nachricht angehängt. Die ideale Stelle zum Erzeugen und Anfügen des TS an die Ausgabenachricht ist ein Postprozessor, der in der Transaktionsumgebung arbeitet, nachdem die eigentliche Transaktion ihre Verarbeitung beendet hat.
Im Fall der IMS-Transaktionsüberwachung sind diese Informationselemente
a. TRANCODE
Ein 8-Bytecode, der eine Transaktion kennzeichnet.
B. MODNAME
Ein 8-Bytecode, der die spezielle Tabellenmaske kennzeichnet, auf die sich die Nachricht bezieht.
Wie es im Fall von IMS die implizite APPC-Unterstützung bewirkt, welche die PC-Protokoll-Suite verwendet, um die Nachrichten zu/von bestehenden IMS-Transaktionen zu übertragen, kann ein einfacher APPC-Ausgang in das IMS- System als ein Postprozessor zum Erzeugen der speziellen. TSs eingeführt werden.
Da das Verfahren der Übertragung und des Austauschs von Nachrichten (im oben erwähnten Sinn) mit einer Transaktion immer einem einzelnen Protokolltyp folgt, wurde es innerhalb einer speziellen Objektklasse ausgeführt, die Übertragungsobjekte (Communication Objects, COs) genannt wird.
Das Protokoll umfasst immer die folgenden Schritte, die entsprechend als Instanzmethoden eines CO der Klasse BplCommunication ausgeführt werden:
start: aConnectionSpecification
o das Verfahren start: fordert als einen Parameter ein Objekt, das alle Daten enthält, die erforderlich sind, um eine Übertragungsverbindung aufzubauen; zum Beispiel
- die Adresse des (entfernten) Computersystems,
- die spezielle zu startende Transaktion,
- berechtigungsbezogene Daten wie Benutzeridentifikation und Passwort,
- usw.
o basierend auf der Verbindungsspezifikation im Objekt aConnectionSpecification wird eine Übertragungsverbindung aufgebaut (wenn sie nicht schon aktiv ist), und die Transaktion wird für den Empfang der ersten zu verarbeitenden Nachricht vorbereitet.
transmit: aMessage
o Das Verfahren transmit: erfordert als Eingabe ein Objekt aMessage, das die Eingabe-Nachricht darstellt, die zur Verarbeitung an die Transaktion gesendet werden soll.
o Das Verfahren transmit: wird dann auf die Ausgabe- Nachricht warten, die von der Transaktion erzeugt wird, die danach an den Anrufer des Verfahrens transmit: geliefert wird; d. h., bei Rückgabe liefert transmit: die Ausgabe-Nachricht, bestehend aus dem Nachrichtentext und dem TS.
o Die Ausführung des Verfahrens transmit: kann mehrere Male angefordert werden.
stop
o Das Verfahren stop bedeutet, die Ausführung der Transaktion zu stoppen und die Übertragungsverbindung zu verlassen.
Fig. 3 spiegelt eine Instanz eines CO der Klasse BplCommunication mit den oben diskutierten Verfahren wider, die das Protokoll für den Nachrichtenaustausch mit der Transaktion darstellen.
Das obige Protokoll ist nur ein abstraktes Protokoll, das praktisch gesehen ein konkretes Protokoll bearbeitet werden muss, wie
ein Dialogmodell, das zum Beispiel durch APPC ausgeführt wird,
ein allgemeines nachrichtenbasiertes Modell, das zum Beispiel durch MQI (Message Queuing Interface) ausgeführt wird,
ein entferntes Prozeduraufrufmodell, das zum Beispiel durch TCP/IP RPC (Transmission Control Protokoll/Internet Protocol Remote Procedure Call) ausgeführt wird,
ein 3270-Emulationsmodell, das zum Beispiel durch EHLLAPI (Emulator High Level Languague Application Programming Interface) ausgeführt wird,
usw.
Zum Zeitpunkt der Umstellung muss mindestens eine konkrete Protokollausführung wie BplAPPC ausgewählt sein, die zur aktuellen Ausführung verwendet wurde, die mit IMS- Transaktionen arbeitet.
Es können Unterklassen eingeführt werden, die das besprochene abstrakte Protokoll durch Abbilden desselben auf eine konkrete Protokollausführung ausführen.
Dieser Unterklassenprozess wird in Fig. 4 dargestellt. Die Klasse CO (401) erkennt die allgemeinen Merkmale des abstrakten Protokolls. Das abstrakte Protokoll wird auf verschiedene konkrete Protokolle innerhalb der CO-Unterklassen (402) bis (405) abgebildet.
Transaktionsobjekte (TOs) sind die Klassen, die ein Modell mindestens einer Transaktion darstellen. Wenn eine bestimmte Gruppe von Transaktionen immer nur als Gruppe in einer vordefinierten Folge ausgeführt wird, kann es vernünftig sein, eine solche Gruppe von Transaktionen als ein einzelnes TO zu modellieren.
Ohne Einschränkung der Allgemeingültig sei für die weitere Beschreibung angenommen, dass nur eine einzige bestehende Transaktion durch ein TO gekapselt ist.
Um einer TO-Instanz zu gestatten, eine Übertragungsverbindung zu der möglicherweise entfernten Transaktion aufzubauen, werden definierende Informationen, wie zum Beispiel
die Adresse des entfernten Computersystems,
die spezielle zu startende Transaktion,
genehmigungsbezogene Daten wie Benutzerkennung und Passwort,
die konkrete Klasse CO, die zur Übertragung zu verwenden ist (wie in den CO-Einzelheiten in den Ausführungen zu dem Architekturelement Communication Objects (COs) besprochen),
usw.
in einem Objekt gespeichert, auf das durch die TO- Klassenvariable localConnectionSpecification Bezug genommen wird.
Die Verwaltung der Nachrichten ist eine kooperative Aufgabe, die von dem TO selbst und seinen eindeutig verknüpften TR- Instanzen ausgeführt wird. Zu dem Zeitpunkt, wenn ein TO gerade zu einer Instanz gemacht wird, werden auch alle verknüpften TRs parallel zu einer Instanz gemacht, was der Kombination von TO- und TR-Instanzen ermöglicht, alle Nachrichtenaustauschvorgänge mit der Transaktion zu behandeln. Die TO-Instanzvariable localTransactionRecords speichert in einem Wörterbuch alle TR-Instanzen, die für die Verwaltung des Nachrichtenflusses dieses speziellen TO gebraucht werden; d. h. das TO kennt alle Nachrichten, die zur Kommunikation mit dieser speziellen Transaktion wichtig sind.
Eine TO-Instanz speichert die aktuelle zu verarbeitende Nachricht, die entweder an die Transaktion zu senden oder von der Transaktion zu empfangen ist, innerhalb der Instanzvariable currentMessage. Dieser gemeinsame Speicherplatz vereinfacht die Zusammenarbeit der TO-Instanz und ihrer verknüpften TR-Instanzen beträchtlich.
Bereits zu diesem Zeitpunkt, wenn eine TO-Instanz aufgebaut wird, wird eine Architektur-TO-Instanzmethode start ausgeführt,
um eine CO-Instanz zu erzeugen,
um eine Übertragungsverbindung aufzubauen,
um die entfernte Transaktion zu beginnen
mit Hilfe der entsprechenden Methode start: der CO-Instanz und der Informationen in localConnectionSpecification.
Die Instanzmethode start hat eine Gegenmethode stop, um die Transaktion zu beenden und die Übertragungsverbindung zu verlassen.
Da jedes zu einer Instanz gemachte TO seine eigene Übertragungsverbindung umfasst, kann eine beliebige Anzahl von TO-Instanzen, sogar von derselben Klasse, parallel arbeiten.
Nur in seltenen Fällen ist die Ausführung einer Transaktion das Ergebnis eines einzigen Nachrichtenaustauschs einer anfordernden und einer antwortenden Nachricht, wobei die Transaktion danach abgeschlossen ist. In den meisten Fällen findet eine möglicherweise längere Folge von Nachrichtenaustauschvorgängen, d. h. Austausch von Bildschirmen, vom Start bis zum Abschluss einer Transaktion statt. Gewöhnlich werden solche Typen von Transaktionen aus offensichtlichem Grund Dialogtransaktionen genannt.
Typischerweise kann eine Folge von Nachrichtenaustauschvorgängen, die eine einzelne Transaktion darstellt, in eine Folge von Transaktionsschritten zerlegt werden. Jeder Transaktionsschritt beginnt mit einer Nachricht, die Informationen enthält, die durch einen Benutzer angegeben werden, gefolgt vom Empfangen und Senden weiterer Nachrichten, die automatisch verarbeitet werden können, und endet mit (einschließlich) einer Nachricht, die an die Transaktion gesendet wird, die wiederum Informationen durch einen Benutzer anfordert. So sind Transaktionsschritte eine Zerlegung der Dialogtransaktionsausführung in Einheiten von Nachrichtenfolgen, die automatisch ohne menschlichen Eingriff ausgeführt werden können.
Jeder dieser Transaktionsschritte muss als eine eigene Instanzmethode des TO modelliert werden, Transaktionsobjektmethode (Transaction Object Method, TOM) genannt.
Es können zwei Parametertypen Teil eines TOM-Aufrufs sein
Schlüsselattribute, die eindeutig BO-Instanzen kennzeichnen. Wenn zum Aufbauen der an die Transaktion zu sendenden Nachricht Daten erforderlich sind, die zu BOs gehören, müssen nur die Schlüsselattribute, welche die BOs kennzeichnen, angegeben werden. Wie unten beschrieben, ist die ist die allgemeingültige TO-Logik in der Lage, die erforderlichen BO-Attributdaten abzurufen, um die Eingabe-Nachricht für die Transaktion aufzubauen.
zusätzliche TOM-Methoden-Parameter.
Dieser Parametertyp wird nur benötigt, wenn der Parameter kein Attribut irgendeines BO darstellt.
Beim Aufruf löst eine TOM das Senden einer Nachricht an die (entfernte) Transaktion aus. Da die TOM einen bestimmten Transaktionsschritt ausführt, kennt sie die Identität der Nachrichten, d. h. der TRs (siehe Ausführungen zu dem Architekturelement Transaction Records, TRs für weitere Informationen), die vorbereitet und an die Transaktion gesendet werden müssen. Die TOM setzt diese Verarbeitung durch Aufrufen einer Architektur-Instanzmethode inXaction dieser TR- Instanz in Gang, die für das Aufbauen der speziellen Nachricht verantwortlich ist.
Die Architekturmethode transmit sendet die Nachricht, die aktuell innerhalb der Instanzvariable currentMessage gespeichert ist, an die Transaktion. transmit der aktuellen TO-Instanz verwendet eigentlich das Verfahren, das genauso genannt wird und zu der CO-Instanz gehört (die während des Erzeugens einer TO-Instanz aufgebaut wurde), um diese Nachricht zu senden und gleichzeitig auf die antwortende Nachricht der Transaktion zu warten. Diese Antwort wird an den Aufrufer weitergeleitet.
Das Verfahren transmit wird durch eine der verknüpften TR- Instanzen aus ihrer Methode inXaction aufgerufen (siehe unten).
Neben den eher statischen und beschreibenden Aspekten, wie in den Ausführungen zu dem Architekturelement Transaction Records beschrieben, umfassen TRs auch bestimmte dynamische Merkmale, die innerhalb der Architekturmethoden ausgeführt werden. Diese Aktivitäten werden gemeinsam mit der speziellen TO-Instanz ausgeführt, die mit der TR-Instanz verknüpft ist. Zusätzlich zu der Beschreibung des Architekturelements eines TO (wie in den Ausführungen zu dem Architekturelement Transaction Objects (TOs) besprochen) muss betont werden, dass
jeder TR zusammen mit seiner verknüpften TO-Instanz zu einer Instanz gemacht wird, mit der er eine Eins-zu-eins- Entsprechung bildet,
jede TR-Instanz ihre verknüpfte TO-Instanz kennt.
Die dynamischen Merkmale sind zweifach und werden innerhalb der folgenden beiden Architekturmethoden ausgeführt.
Die TR-Instanz-Methode inXaction ist verantwortlich für
das Erzeugen der korrekten Nachrichtenschablone, die an die Transaktion gesendet werden soll.
Welches Nachrichtenobjekt erzeugt werden soll, ergibt sich aus der Natur der aktuellen TO-Instanz, da jede TR für die Verarbeitung einer speziellen Nachricht verantwortlich ist.
das Kopieren aller erforderlichen Informationen in die TR; d. h. in die Nachricht.
Wie in der Erörterung von TRs in den Ausführungen zu dem Architekturelement Transactional Objects (TOs) besprochen, speichert eine TR beschreibende Informationen für die einzelnen Datenelemente der TR.
Jene TR-Elemente, die BO-Attribute darstellen, können unter Verwendung der BO-Schlüsselattribute ausgefüllt werden, die Teil des TOM-Aufrufs sind. Die BO- Schlüsselattribute gestatten der Methode inXaction, die BO-Instanz innerhalb des BOIS zu finden und die erforderlichen BO-Attributwerte abzurufen.
Von den TR-Elementen, die nicht mit BO-Attributen verknüpft sind, wird erwartet, dass sie Parameter sind, die als Teil des TOM-Aufrufs angegeben sind, so dass dem Verfahren inXaction gestattet wird, diese Daten ebenfalls zu sammeln.
Senden der Nachricht an die entfernte Transaktion durch Aufrufen der Architekturinstanzmethode transmit der verknüpften TO-Instanz.
Bevor dies geschieht, muss die aktuell zu sendende Nachricht in der Instanzvariablen currentMessage der verknüpften TO-Instanz verfügbar gemacht werden, da transmit im Namen von currentMessage arbeitet (siehe oben).
Weiterleiten der Verarbeitung der Ausgabe-Nachricht der Transaktion zu der Architekturinstanzmethode outXaction der verantwortlichen TR-Instanz zur weiteren Verarbeitung.
Die verantwortliche TR-Instanz kann durch Analysieren des TS festgestellt werden, der von der Übertragungsausführung (wie in den Ausführungen zu dem Architekturelement Communication Objects (COs) besprochen), zusammen mit den Informationen zurückgesandt wird, die in der Instanzvariable localTransactionRecords verschlüsselt sind.
outXaction ist verantwortlich für das Analysieren und Verarbeiten der Ausgabenachricht, die innerhalb der Instanzvariablen currentMessage der verknüpften TO-Instanz verfügbar ist, durch
Realisieren aller BOs, die durch den TR-Inhalt beeinflusst sind.
Wie in der Erläuterung von TRs im Abschnitt zu dem Architekturelement Transactional Objects (TOs) besprochen, speichert die TR die beschreibenden Informationen für die einzelnen Datenelemente der TR. Somit kann outXaction
o die TR-Elemente feststellen, die BO-Attribute darstellen,
o die beeinflussten BOs im BO-Instanzraum BOIS auffinden oder die BO-Instanz erzeugen, wenn sie noch nicht vorhanden,
o die BO-Attribute von der TR zum BO selbst kopieren
die Liste der realisierten BOs zu ihrem Aufrufer zurücksenden
inXaction sendet dem Aufrufer die Liste von realisierten BOs zurück, die nach der Rücksendung von outXaction empfangen wurden.
Nach Rückkehr vom Aufruf von inXaction empfängt die TOM die Liste realisierter BOs.
Die TOM muss basierend auf der Ausgabenachricht, d. h. der von der Transaktion empfangenen TR, entscheiden, wie weiter vorgegangen wird. Wenn der Transaktionsschritt abgeschlossen ist, wird einfach die Liste realisierter BOs an ihren Aufrufer weitergeleitet. Die TOM löst das Senden der nächsten Nachricht an die entfernte Transaktion durch nochmaliges Absetzen von inXaction mit Bezug auf die TR-Instanz aus, die für das Verarbeiten der nächsten Nachricht und das Wiederholen der Folge von Aktivitäten inXaction-transmit-outXaction verantwortlich ist.
Um die Menge des Ausführungsaufwandes für jede Klasse TO zu verringern, wird das Modellieren einer bestehenden Transaktion aller allgemeiner, d. h. Architektur-TO-Merkmale, innerhalb der TO-Super-Klasse BplTransactionObject ausgeführt. Da abhängig vom Typ der Transaktionsüberwachung, die eine bestimmte Transaktion ausführt, die Verwaltung des Nachrichtenflusses zwischen dem TO und der entfernten Transaktion etwas anders sein könnte, können Unterklassen für die einzeln unterstützten Transaktionsüberwachungen eingeführt werden, wie IMS, CICS, ... Die Unterklassen BplIMSTransactionObject, BplCICSTronsactionObject, ... führen die mit der Transaktionsüberwachung verknüpften Abweichungen aus. (Obwohl sich der Prototyp nur auf IMS konzentriert!) Wenn es keine derartigen Abweichungen gibt, können diese dazwischenliegenden Klassen gelöscht werden. Die Klassenstruktur liefert das Spektrum von Architektur-TO-Merkmalen wie
Übertragungsverwaltung
Transaktionsaufruf und Nachrichtenaustausch
BO-Realisierung
für die problemspezifischen Klassen TO, die Unterklassen davon sind.
Der übrige Ausführungsaufwand innerhalb der problemspezifischen Klassen TO, welche die umgestellten Transaktionen darstellen, ist begrenzt auf
Wählen des konkreten Übertragungsmodells und Definieren der Übertragungsspezifikationen,
Modellieren der TRs und TSs, für welche die Klasse TO verantwortlich ist,
Ausführen der konkreten TOMs, welche die entsprechenden Transaktionsschritte ausführen.
Die TOM-Ausführung könnte bedeuten, einen Status einer TO- Instanz zuzuordnen, welche die Folge von TOM-Ausführungen prüft, wenn die entfernte Transaktion, unabhängig vom TOM- Vorgänger, die TOM-Ausführung nicht erlaubt.
Die oben besprochene Hierarchie der Klassen TO und einige Beispiele problemspezifischer Klassen TO werden in Fig. 5 gezeigt. Die Klasse, die alle allgemeinen Merkmale eines TO ausführt, ist (501). Wenn Gruppen von BAs gekapselt werden sollen, die bestimmte gemeinsame Verhaltensmerkmale zeigen, zum Beispiel, wenn sie in einer bestimmten Umgebung ausgeführt werden sollen, die eine spezielle Art der Verwaltung erfordert, können diese Allgemeinheiten in die TO-Unterklassen wie (502), (503) ... aufgenommen werden. Dann sind schließlich die problemspezifischen TO-Aufrufe Unterklassen hiervon, wie (504), (505) und (506).
Fig. 6 fasst die wichtigsten (Architektur-) Merkmale eines TO zusammen.
(601), (602) und (603) stellen die OO-Methoden dar, die das abstrakte Übertragungsprotokoll bilden. Weiterhin werden 2 problemspezifische TOMs (604) und (605) widergespiegelt.
Jene Methoden eines BO, die zur Ausführung einer (oder eines Teils einer) Transaktion führen, werden Businessobjektmethoden (Business Object Methods, BOMs) genannt. Die problemspezifischen BOMs sind die einzige Schnittstelle zu Nutzern der Gesamtarchitektur zur transparenten Ausführung entfernter Transaktionen ohne Kenntnis der zugrunde liegenden Architektur.
Zwei Parametertypen können Teil eines BOM-Aufrufs sein
Schlüsselattribute, die andere BO-Instanzen (abgesehen von dem BO, zu dem die BOM gehört) eindeutig kennzeichnen,
zusätzliche Parameter der BOM-Methode.
Dieser Parametertyp wird nur gebraucht, wenn ein Parameter kein Attribut irgendeines BO darstellt.
Ausführer von BOMs müssen das folgende Verhalten innerhalb einer BOM realisieren:
abhängig davon, ob die BOM den ersten Transaktionsschritt einer Folge von Schritten ausführt, muss eine TO-Instanz zu einer Instanz gemacht werden, die in der Lage ist, die verknüpfte Transaktion auszuführen,
eine oder mehrere TOMs der zu einer Instanz gemachten TO(s) müssen zur Ausführung der entsprechenden Transaktion aufgerufen werden,
abhängig davon, ob die BOM den letzten Transaktionsschritt einer Folge von Schritten ausführt, welcher die gesamte Transaktionsausführung abschließt, muss die TO-Instanz wieder entfernt werden. Indirekt verlässt die Entfernung einer TO-Instanz auch die zugeordnete Übertragungsverbindung.
schließlich sendet die BOM ihrem Aufrufer die Liste realisierter BOs zurück, wie sie von den ausgeführten TOMs empfangen wurden.
Um die Menge des Ausführungsaufwandes für jede Klasse BO zu verringern, werden alle allgemeinen, d. h. Architektur-Merkmale innerhalb der BO-Super-Klasse BplBusinessObject ausgeführt. Als ein Beispiel liefert diese Klasse die Funktionalität, automatisch Abruf- und Setz-Verfahren für alle BO-Attribute aus der Liste von BO Attributen zu erzeugen.
Problemspezifische Klassen BO werden als Unterklassen der Klasse BplBusinessObject ausgeführt. Der übrige Ausführungsaufwand innerhalb einer problemspezifischen Klasse BO ist begrenzt auf
die Definition von BO-Schlüssel- und Allgemeinattributen,
die BOM-Ausführung.
Der BO-Unterklassenprozess wird in Fig. 7 dargestellt. Er zeigt die BO-Superklasse (701), die verwendet wird, um die problemspezifischen Klassen BO (702) bis (706) abzuleiten.
Fig. 8 stellt die Wechselwirkung eines Teils der Architekturelemente dar, die auf einem abstrakten Beispiel basieren. Die numerischen Markierungen beziehen sich auf die einzelnen Verarbeitungsschritte, die unten beschrieben werden:
1.
a. Irgendeine Art der Anwendung (801), die eine Transaktionsanwendung ausnutzt, die auf die aktuelle Architektur umgestellt wurde (zum Beispiel eine objektorientierte grafische Benutzeroberfläche), ruft eine BOM BOM_1 (802) einer bestimmten BO-Instanz BO_1 (803), die zusätzliche BOM-Parameter BOMParms weiterleitet.
2.
a. BOM_1 macht ein TO (804) zu einer Instanz und baut somit transparent eine Übertragungsverbindung zum entfernten Transaktionssystem auf und beginnt die entfernte Transaktion, die als das aktuelle TO modelliert ist.
b. BOM_1 ruft weiterhin eine bestimmte TOM TOM_1 (805) auf, welche die BO-Schlüsselattribute BOKey und BOM- Methoden-Parameter TOMParms weiterleitet.
3.
a. Die problemspezifische TOM TOM_1 (805) weiß, welche Nachricht an die Transaktion gesendet werden soll. Sie beginnt dann die Architekturmethode inXaction (806) von dieser TR-Instanz TR_1 (807), die für die Verarbeitung der speziellen Nachricht verantwortlich ist.
4.
a. inXaction (806) der verantwortlichen TR-Instanz TR_1 (807) verwendet die beschreibende Information des TR, um alle Parameter auszufüllen, die auf den BO-Attributen basieren, auf die über BOKey und TOM-Methoden-Parameter TOMParms zugegriffen werden kann, die von ihrer verknüpften TO-Instanz TO_a (804) an TOM_1 (805) weitergeleitet werden.
b. Sobald die Nachricht erzeugt wurde, wird sie an die entfernte Transaktion zur Ausführung gesendet (808).
5.
a. Die entfernte Transaktion sendet der TO-Instanz eine Antwort-Nachricht (808).
6.
a. inXaction (806) analysiert den TS der empfangenen Nachricht, um die konkrete Nachricht festzustellen, d. h. die TR-Instanz, die für die Verarbeitung der Nachricht verantwortlich ist.
7.
a. Beschreibende Informationen über die Natur der TR- Elemente zusammen mit den TOM-Parametern BOKey und TOMParms ihrer verknüpften TO-Instanz TO_a (804) gestatten outXaction (809) der TR-Instanz TR_1 (807), die Realisierung auszuführen. In diesem Beispiel führt die Realisierung zum Aktualisieren des BO BO_1 (803) und Erzeugen einer Instanz von 2 neuen BOs BO_2 (810) und BO_3 (811).
8.
a. Die Steuerung wird von outXaction (809) zu inXaction (806), zu TOM_1 (805), zu BOM_1 (802) und schließlich zur aufrufenden Anwendung zur weiteren Nutzung zurückgegeben, welche die Liste der realisierten BOs damit weiterleitet (in diesem Beispiel BO_1 (803), BO_2 (810), BO_3 (811)).
Die vorgeschlagene Umstellungsarchitektur erlaubt es, die bestehenden geerbten Transaktionsanwendungen "wiederzubenutzen", ohne dass ihre Neu-Ausführung erforderlich sind.
Da es möglich war, die bestehenden Transaktionsanwendungen ohne die Notwendigkeit ihrer Modifikation zu integrieren, kann die Anwendung sowohl in der herkömmlichen Umgebung als auch innerhalb der neuen Architektur parallel verwendet werden.
Client/Server-Strukturen werden implizit für bestehende Anwendungen realisiert, die ursprünglich nicht für einen verteilten Arbeitsmodus vorgesehen sind.
Auf der Client-Seite wurde eine OO-Sicht erzeugt, die nur aus Businessobjekten besteht, die einen BO-Benutzer von allen Transaktionsdetails transparent abschirmt. Die sich ergebende BO-Struktur ist die ideale Plattform für die nahtlose Integration mit anderen Anwendungstypen und Anwendungserweiterungen auf dem Client-System.
Basierend auf der BO-Plattform können neue und produktivere Software-Entwicklungskonzepte und Werkzeuge basierend auf dem OO-Paradigma ausgenutzt werden.
Das Konzept der Realisierung gestattet ein dynamisches und schrittweises Erzeugen von Instanzen des BO-Attribut- Spektrums. Dies vermindert die Verarbeitungszeit für das Erzeugen von BO-Instanzen und den Speicherverbrauch beträchtlich, da ein BO nur im tatsächlich erforderlichen Ausmaß zu einer Instanz gemacht wird.
Die vorgeschlagene Architektur führt eine vorteilhafte Verteilung von Verarbeitungsaufgaben ein.
o Das Serversystem liefert Transaktionsmöglichkeiten.
o Da das Serversystem nicht als ein einfacher Datenserver zum Speichern und Abrufen von Daten verwendet wird, sondern auch mit Bezug auf seine Verarbeitungsmöglichkeiten für Transaktionen ausgenutzt wird, wurde ein bestimmter Grad von Parallelität eingeführt.
o Da das Serversystem im Gegensatz zu einem Datenserver als ein echter Verarbeitungsserver verwendet wird, wird die Datenmenge, die über das Netzwerk übertragen wird, verringert, da die entfernte Transaktion als eine Datenvorverarbeitung angesehen werden kann. Zusätzlich verringert dies auch das Sicherheitsrisiko, weil eine verringerte Menge von Daten das entfernte System verlassen muss.
Die vorgeschlagene Architektur gestattet auch eine evolutionäre Umstrukturierung der Transaktionsanwendung, zum Beispiel mit Bezug auf die zugrunde liegenden Datenbankstrukturen, ohne den Client-Teil zu beeinflussen.
Außerdem ist wichtig, dass dieselbe Gesamtarchitektur nicht nur für Umgestaltungszwecke verwendet werden kann. Ohne irgendwelche Veränderungen der obigen Beschreibung kann die vorgeschlagene Architektur zur Unterstützung neuer Typen von (entfernten) Transaktionen ausgenutzt werden, die speziell entwickelt wurden, um innerhalb des aktuellen Schemas genutzt zu werden, die dann keine separate Terminaltyp-Benutzer-Schnittstelle anbieten würden.
Zusammenfassend gestattet der Architektur-Vorschlag eine wirtschaftliche und äußerst leistungsfähige Umstellung von einer bestehenden Transaktionsanwendung zu verteilten Objektstrukturen und bietet gleichzeitig eine ideale Plattform für die Weiterentwicklung neuer Anwendungsbestandteile.

Akronyme

BA Geschäftsanwendung
BOA Businessobjektattribut
BOGA Businessobjekt-Allgemeinattribut
BOIS Businessobjekt-Instanzraum
BOKA Businessobjekt-Schlüsselattribut
BOM Businessobjektmethode
CO Übertragungsobjekt
IMS Informationsverwaltungssystem
OLTP Online-Transaktionsverarbeitung
OO Objektorientierung
OOT Objektorientierte Technologie
TO Transaktionsobjekt
TOM Transaktionsobjektmethode
TR Transaktionsaufzeichnung
TRO Transaktionsaufzeichnungsobjekt
TS Transaktionssuffix
TST Transaktionsschritt

Claims

1. Verfahren des Erzeugens eines objektorientierten (object oriented) /OO/ Zugriffs auf mindestens eine Geschäftsanwendung (Business Application) /BA/, die auf einem Datenverarbeitungssystem ausgeführt wird, wobei die BA nicht dem Paradigma der Objektorientierung entspricht, das die folgenden Schritte umfasst:

Definieren mindestens einer Businessobjekt-Klasse /BO/ im Sinne einer eindeutigen. Einheit oder eines Konzepts bezüglich der zugrundeliegenden Aufgabe, die durch die BA unterstützt wird;

Definieren von BO-Attributen /BOA/ der Klasse BO, die Eingabe- und Ausgabeparameter der BA einschließen;

Definieren mindestens einer Transaktionsobjekt-Klasse (Transactional Object) /TO/ zum Kapseln der BA;

wobei die Klasse TO bereitgestellt wird, um die Ausführung der BA entsprechend den Besonderheiten der BA zu steuern;

wobei die Klasse TO bereitgestellt wird, um den Status der BA zu verfolgen, wenn die BA-Ausführung eine Vielzahl von Interaktionen erfordert, die Eingabe- oder Ausgabeparameter senden oder empfangen;

wobei die Klasse TO bereitgestellt wird, um die Eingabeparameter für den BA-Aufruf aus den BOAs zu entnehmen;

und wobei die Klasse TO bereitgestellt wird, um den sogenannten Realisierungsprozess (materialization process) auszuführen, der aus Folgendem besteht:

Erzeugen mindestens einer BO-Instanz der Klasse BO, wenn die BO-Instanz der Klasse BO noch nicht zu einer Instanz gemacht wurde, und

Extrahieren und Speichern der Ausgabedatenparameter, die durch die BA in die entsprechenden BOAs zurückgegeben werden.

2. Verfahren nach Anspruch 1,

das weiterhin den Schritt des Definierens mindestens einer Transaktionsaufzeichnungs-Klasse (Transaction Record) /TR/umfasst, wobei

die Klasse TR bereitgestellt wird, um einen einzelnen Eingabe- oder Ausgabedatenblock zu modellieren, BA- Nachricht genannt, der die Eingabe- oder Ausgabeparameter beinhaltet, die in einer Interaktion mit der BA gesendet oder empfangen werden;

die Klasse TR bereitgestellt wird, um beschreibende Informationen über die einzelnen Datenelemente, welche die BA-Nachricht bilden, bezüglich Typ, Länge und Position innerhalb der BA-Nachricht zu speichern;

die Klasse TR bereitgestellt wird, um Abbildungsinformationen zu speichern, um ein eindeutiges Datenelement der BA-Nachricht einem eindeutigen der BOAs der Klasse BO und umgekehrt zuzuordnen;

und das weiterhin den Schritt des Zuordnens der Klasse TR zu der Klasse TO umfasst, der die Möglichkeit des Austauschs der BA-Nachricht mit der BA realisiert.

3. Verfahren nach einem der Ansprüche 1 bis 2, das weiterhin den folgenden Schritt umfasst:

Trennen der Gruppe von BOAs der Klasse BO in zwei Untergruppen, eine erste Untergruppe von BOAs, BO- Schlüsselattribute (BO Key Attributes) /BOKA/ genannt, mit der besonderen Eigenschaft, dass jede Kombination von BOKA-Werten eindeutig und genau eine BO-Instanz innerhalb der Klasse BO kennzeichnet, unabhängig von den BOA-Werten einer zweiten Untergruppe von BOAs, BO-Allgemeinattribute (BO General Attribute) /BOGA/ genannt, die aus den verbleibenden BOAs gebildet wird.

4. Verfahren nach Anspruch 2 und 3, das weiterhin den folgenden Schritt umfasst:

Aufbauen eines BO-Instanzraums (BO Instance Space) /BOIS/,

der bereitgestellt wird, um alle BO-Instanzen nach der Erzeugung zu speichern,

und der bereitgestellt wird, um das Abrufen einer bestimmten BO-Instanz basierend auf den Informationen der Klasse BO und der BOKA-Werte der BO-Instanz zu gestatten.

5. Verfahren nach Anspruch 4, das weiterhin den folgenden Schritt umfasst:

Definieren verschiedener Typen des BOIS,

mindestens eines sogenannten expliziten BOIS zum Speichern und Abrufen der BO-Instanzen von mindestens einer typischen Klasse BO,

und eines sogenannten impliziten BOIS, der verwendet wird, 1 wenn keiner der expliziten BOISs zum Speichern und Abrufen der BO-Instanzen einer speziellen Klasse BO definiert wurde.

6. Verfahren nach Anspruch 4 oder 5, das weiterhin den folgenden Schritt umfasst:

Verbessern des BOIS durch Steuermittel zum Überwachen, ob auf irgendwelche der BO-Instanzen, die innerhalb des BOIS gespeichert sind, von irgendeinem anderen Objekt in dem System Bezug genommen wird, und wobei der Steuer-BOIS die BO-Instanz transparent löscht, sobald der letzte Bezug zu irgendeiner der BO-Instanzen entfernt wird.

7. Verfahren nach einem der Ansprüche 1 bis 6, das weiterhin den folgenden Schritt umfasst:

Erweitern der Klasse TO um eine Gruppe von OO-Methoden, die ein abstraktes Protokoll zur Interaktion mit der BA verkörpern und folgendes beinhalten:

eine OO-Methode START, die bereitgestellt wird, um eine Übertragungsverbindung unter Verwendung irgendeines der verfügbaren Übertragungsprotokolle aufzubauen, wenn die BA auf einem entfernten Datenverarbeitungssystem ausgeführt wird, und um die Ausführung der BA zu beginnen, die der Klasse TO zugewiesen wurde;

eine OO-Methode STOP, die bereitgestellt wird, um die Ausführung der BA abzuwickeln und zu beenden, und, wenn die BA auf einem entfernten Datenverarbeitungssystem ausgeführt wird, die Übertragungsverbindung zu dem entfernten System zu schließen;

eine OO-Methode TRANSMIT, die bereitgestellt wird, um

eine erste BA-Nachricht an die BA zur Verarbeitung zu übertragen, die den Anforderer von Wissen und Verständnis irgendwelcher Übertragungsdetails befreit,

auf eine zweite BA-Nachricht zu warten, die von der BA als ein Ergebnis der Verarbeitung der ersten BA-Nachricht zurückgesendet wird.

8. Verfahren nach einem der Ansprüche 2 bis 7, das weiterhin die folgenden Schritte umfasst:

Erweitern der Klasse TO um Wissen und Fähigkeit des Feststellens ihrer zugeordneten Klassen TR,

und umgekehrt Erweitern jeder der Klassen TR um Wissen und Fähigkeit des Feststellens der Klasse TO, der sie zugeordnet ist.

9. Verfahren nach Anspruch 8, das weiterhin die folgenden Schritte umfasst:

Erweitern jeder der Klassen TR um eine OO-Methode INXACTION,

wobei die INXACTION bereitgestellt wird, um die BO- Instanz-Kennzeichen festzustellen, die zur Erzeugung der BA-Nachricht unter Verwendung der BOKA-Werte verwendet werden sollen, auf die von ihrer zugeordneten TO-Instanz zugegriffen werden kann;

wobei die INXACTION bereitgestellt wird, um auf die BO- Instanzen innerhalb des BOIS durch die BOKA-Werte zuzugreifen;

wobei die INXACTION bereitgestellt wird, um unter Steuerung der Abbildungsinformationen der TR BOA-Werte zu entnehmen, um eine BA-Nachricht zu erzeugen und die BOA- Werte in die zugeordneten Positionen der BA-Nachricht als die BA-Nachrichtendatenelemente zu speichern;

wobei die INXACTION bereitgestellt wird, um die erzeugte BA-Nachricht durch Aufrufen der OO-Methode TRANSMIT der zugeordneten TO-Instanz an die BA zur weiteren Verarbeitung zu senden;

wobei die INXACTION bereitgestellt wird, um eine aktuell empfangene BA-Nachricht als BA-Ausgabe über die OO-Methode OUTXACTION von der TR-Instanz weiterzuleiten, die für das Verarbeiten der empfangenen BA-Ausgabenachricht verantwortlich ist;

das weiterhin jede der Klassen TR mit einer OO-Methode OUTXACTION zur Verarbeitung der aktuell empfangenen BA- Nachricht durch Zuführen von BOA-Werten zu den von BO- Instanzen erweitert, die in der BA-Nachricht in einem Prozess gespeichert sind, der Incremental Partial BO Materialization oder kurz Realisierung genannt wird,

wobei die OUTXACTION bereitgestellt wird, um unter der Steuerung der Abbildungsinformationen der TR alle BO- Instanzen festzustellen, die von den Datenelementen der aktuell empfangenen BA-Nachricht berührt wurden, und zwar entweder durch Abrufen von BOKA-Werten von der aktuell empfangenen BA-Nachricht für die berührten BO-Instanzen oder durch Abrufen der BOKA-Werte von der zugeordneten TO- Instanz, die alle BOKA-Werte aller BO-Instanzen speichert, die unter ihrer Steuerung in einem Kontext realisiert wurden;

wobei die OUTXACTION basierend auf den BOKA-Werten zuerst jede berührte BO-Instanz innerhalb des BOIS sucht, wenn die berührte BO-Instanz in dem BOIS gefunden werden konnte, wird sie während des Realisierungsprozesses verwendet, wenn dagegen die berührte BO-Instanz innerhalb des BOIS nicht gefunden werden konnte, wird eine neue BO- Instanz innerhalb des BOIS erzeugt;

wobei die OUTXACTION unter Steuerung der Abbildungsinformationen der TR jedes Datenelement der aktuell empfangenen BA-Nachricht in das entsprechende BOA der berührten BO-Instanz kopiert, und somit die BOAs der BO-Instanz inkrementell realisiert;

wobei die OUTXACTION die Objektbezüge aller berührter BO- Instanzen, die während der aktuellen Ausführung von OUTXACTION realisiert wurden, an ihren Aufrufer zurücksendet.

10. Verfahren nach einem der Ansprüche 1 bis 9, das weiterhin die folgenden Schritte umfasst:

Aufbauen der vollständigen Folge von Interaktionen der BA- Ausführung von Anfang an bis zum Abschluss in mindestens einer Untereinheit, Übertragungsschritt (Transactional Step) /TST/ genannt, der zum autonomen Erzeugen und Austauschen mindestens einer ersten BA-Nachricht mit der BA und dem Abschluss der Ausführung bereitgestellt wird, sobald eine BA-Nachricht durch die BA zurückgesendet wird, die als die letzte BA-Nachricht des TST definiert ist, wobei die letzte BA-Nachricht optional den Beginn eines nächsten IST definiert und

Kapseln des TST als eine eindeutige OO-Methode, Übertragungsobjektmethode (Transactional Object Method) /TOM/ der Klasse TO genannt.

11. Verfahren nach Anspruch 10, das weiterhin die folgenden Schritte umfasst:

Erweitern der Klasse BO um mindestens eine OO-Methode, Aufgabenobjektmethode (Business Object Method) /BOM/ genannt, die einen funktionellen Teil zusammenfasst, der von BAs geboten wird;

wobei die BOM bereitgestellt wird, um erstens mindestens eine neue TO-Instanz zu erzeugen, wenn eine TOM einer TO- Instanz ausgeführt werden soll, die bis dahin noch nicht zu einer Instanz gemacht wurde, oder um anderenfalls mindestens eine bereits verfügbare TO-Instanz zu verwenden;

wobei die BOM zum Aufrufen von mindestens einer TOM bereitgestellt wird, die von der TO-Instanz geboten wird.

12. Verfahren nach Anspruch 9 und Anspruch 11, das weiterhin die folgenden Schritte umfasst:

Erweiternder Klasse TO, die zum Aufsuchen mindestens einer TR-Instanz bereitgestellt wird, und zum Aufrufen der OO-Methode INXACTION der TR-Instanz, die der TO-Instanz zugeordnet ist, die in der Lage ist, mindestens eine BA- Nachricht zu erzeugen und mit der BA auszutauschen;

Erweitern der TOM der Klasse TO, die zum Zurücksenden von Objektbezügen von BO-Instanzen bereitgestellt wird, die während der Ausführung der TOM an ihren Anforderer realisiert werden;

Erweitern der BOM der Klasse BO, die zum Zurücksenden von Objektbezügen von BO-Instanzen bereitgestellt wird, die während der Ausführung der BOM an ihren Anforderer realisiert werden.

13. Verfahren nach Anspruch 7 und irgendeinem der vorhergehenden Ansprüche, das weiterhin die folgenden Schritte umfasst:

Erzeugen mindestens einer Kommunikationsobjekt-Klasse (Communication Object) /CO/, die ein abstraktes Protokoll bietet, das aus den OO-Methoden START, STOP, TRANSMIT mit gleicher Semantik wie das abstrakte Protokoll der Klasse TO besteht;

Kapseln übertragungsrelevanter Aspekte innerhalb der Klasse CO und, wenn die BA auf einem entfernten Datenverarbeitungssystem ausgeführt werden soll, Abbilden des abstrakten Protokolls auf ein konkretes Protokoll, das verwendet wird, um die Datenverarbeitungssysteme in einem Computernetzwerk zu verbinden;

Zuordnen der Klasse CO zu der Klasse TO;

Erweitern der OO-Methode START der TO-Instanz, um eine Instanz der zugeordneten Klasse CO zu erzeugen, um die entsprechende OO-Methode START der zugeordneten CO-Instanz aufzurufen;

Erweitern der OO-Methoden STOP und TRANSMIT der TO- Instanz, um die entsprechenden Methoden der zugeordneten CO-Instanz zur Ausführung des konkreten Protokolls, auf dem die CO-Instanz basiert, aufzurufen.

14. Verfahren nach Anspruch 9, wobei die OO-Methoden INXACTION und OUTXACTION als ein alternatives Verfahren in die Klasse TO und nicht in die Klasse TR integriert werden.

15. Datenverarbeitungssystem mit einer Speichereinheit, in der Objektstrukturen gespeichert werden, die von Verfahren irgendeiner Kombination der Ansprüche 1 bis 14 abgeleitet sind.

16. Datenverarbeitungssystem nach Anspruch 15, wobei die Objektstrukturen unter Verwendung objektorientierter Technologie ausgeführt sind,

Realisieren der allgemeinen Funktionalität, die nicht für eine bestimmte Klasse BO in einer OO-Superklasse BplBusinessObject zur Ausführung durch die anwendungsspezifischen Klassen BO über das OO- Vererbungskonzept spezifisch ist;

und/oder das Realisieren der allgemeinen Funktionalität, die nicht für eine bestimmte Klasse TR in einer OO- Superklasse BplTransactionRecord zur Ausführung durch die anwendungsspezifischen Klassen TR über das OO-. Vererbungskonzept spezifisch ist;

und/oder das Realisieren der allgemeinen Funktionalität, die nicht für eine bestimmte Klasse TO in einer OO- Superklasse BplTransactionObject zur Ausführung durch die anwendungsspezifischen Klassen TO über das OO- Vererbungskonzept spezifisch ist;

und/oder Realisieren der allgemeinen Funktionalität der CO-Klasse in einer Klasse BplCommunicationObject und weiter Realisieren aller Aspekte, die von den verschiedenen konkreten Übertragungsprotokollen in Unterklassen von BplCommunicationObject abhängen, selektiv zur Ausführung durch Klassen TO, wobei ein abstraktes Übertragungsprotokoll, das zwischen BplCommunicationObjects verwendet wird, dem konkreten Übertragungsprotokoll zugeordnet wird, das durch die entsprechende Unterklasse ausgeführt wird.

17. Verfähren des Ausführens mindestens einer Geschäftsanwendung /BA/ in einem Datenverarbeitungssystem, wobei die BA nicht dem Paradigma der Objektorientierung entspricht,

das einen Schritt umfasst, in dem ein Aufgabenobjekt (Business Object) /BO/, das eine Instanz einer Klasse BO im Sinne einer eindeutigen Einheit oder eines Konzept hinsichtlich des zugrundeliegenden Aufgabe ist, die durch die BA unterstützt wird und wobei das BO BO-Attribute /BOA/ der Klasse BO enthält, die Eingabe- und Ausgabeparameter der BA enthalten, eine Methode von mindestens einem Objekt TransactionalObject /TO/ aufruft, das eine Instanz einer Klasse TO zum Kapseln der BA ist;

das einen Schritt umfasst, in dem das TO die Ausführung der BA entsprechend der Besonderheiten der BA steuert;

das einen Schritt umfasst, in dem das TO den Status der BA verfolgt, wenn die BA-Ausführung eine Vielzahl von Interaktionen erfordert, welche Eingabe- oder Ausgabeparameter senden oder empfangen;

das einen Schritt umfasst, in dem das TO die Eingabeparameter für den BA-Aufruf von den BOAs entnimmt;

das einen Schritt umfasst, in dem das TO den sogenannten Realisierungsprozess ausführt, der aus Folgendem besteht:

Erzeugen eines oder mehrerer BOs einer oder mehrerer zusätzlicher Klassen BO, wenn die BO-Instanzen der zusätzlichen Klassen BO noch nicht zu Instanzen gemacht wurden, und

Entnehmen und Speichern der Ausgabedatenparameter, die von der BA in die entsprechenden BOAs der BOs zurückgesendet werden.

18. Verfahren nach Anspruch 17

wobei die Schritte des

Entnehmens der Eingabeparameter für den BA-Aufruf von den BOAs und des

Ausführens des sogenannten Realisierungsprozesses

durch mindestens ein Transaktionsaufzeichnungs-Objekt (Transaction Record Object)/TRO/ ausgeführt werden, das eine Instanz einer Klasse TR ist, die der Klasse TO zugeordnet ist, wobei

die Klasse TR bereitgestellt wird, um einen einzelnen Eingabe- oder Ausgabedatenblock zu modellieren, BA- Nachricht genannt, der die Ein- oder Ausgabeparameter enthält, die in einer Interaktion mit der BA gesendet oder empfangen wurden;

die Klasse TR bereitgestellt wird, um beschreibende Informationen über die einzelnen Datenelemente, welche die BA-Nachricht bilden, in Bezug auf Typ, Länge und Position innerhalb der BA-Nachricht zu speichern;

die Klasse TR bereitgestellt wird, um Abbildungsinformationen zu speichern, um ein eindeutiges Datenelement der BA-Nachricht einem eindeutigen der BOAs der Klasse BO und umgekehrt zuzuordnen,

und wobei der Schritt des Sendens oder Empfangens von Eingabe- oder Ausgabeparametern durch das TRO durch Austauschen der BA-Nachricht mit der BA ausgeführt wird.

19. Verfahren nach Anspruch 18

wobei der Schritt des Sendens einer BA-Nachricht an die BA, wie in Anspruch 18 gezeigt, durch eine OO-Methode INXACTION des TRO der Klasse TR ausgeführt wird,

wobei die INXACTION die Kennzeichen der Bos feststellt, die für die Erzeugung der BA-Nachricht verwendet werden sollen, wobei die Untergruppe von BOAs verwendet wird, BO- Schlüsselattribute (BO Key Attributes) /BOKA/ genannt, welche die besondere Eigenschaft besitzt, dass jede Kombination von BOKA-Werten eindeutig und genau ein BO innerhalb der Klasse BO kennzeichnet, unabhängig von den BOA-Werten der restlichen BOAs, wobei auf die BOKA-Werte von ihrem zugeordneten TO zugegriffen werden kann;

wobei die INXACTION auf die BOs innerhalb eines BO- Instanzraums (BO Instance Space) /BOIS/ zugreift, der zum Speichern und Abrufen der BOs basierend auf den Informationen der Klasse BO und der BOKA-Werte des BOs bereitgestellt weiden;

wobei die INXACTION unter Steuerung der Abbildungsinformationen des TROs BOA-Werte entnimmt, um eine BA-Nachricht zu erzeugen und die BOA-Werte an den entsprechenden Positionen der BA-Nachricht als die BA- Nachrichtendatenelemente zu speichern;

wobei die INXACTION die erzeugte BA-Nachricht zur weiteren Verarbeitung an die BA sendet;

wobei die INXACTION eine aktuell empfangene BA-Nachricht als BA-Ausgabe über die OO-Methode OUTXACTION des TRO weiterleitet, das für die Bearbeitung der empfangenen BA- Ausgabenachricht verantwortlich ist;

wobei der Schritt des Empfangens einer BA-Nachricht der BA, wie in Anspruch 18 gezeigt, durch eine OO-Methode OUTXACTION des TRO der Klasse TR zur Verarbeitung der aktuell empfangenen BA-Nachricht ausgeführt wird, in dem den BOs weitere BOA-Werte, die in der BA-Nachricht gespeichert sind, in einem Prozess ausgeführt wird, der Incremental Partial BO Materialization oder kurz Realisierung genannt wird,

wobei die OUTXACTION unter der Steuerung der Abbildungsinformationen des TROs alle BOs feststellt, die von den aktuell empfangenen BA-Nachrichtendatenelementen entweder durch Abrufen von BOKA-Werten von der aktuell empfangenen BA-Nachricht für die berührten BOs oder durch Abrufen der BOKA-Werte von dem zugeordneten TO, das alle BOKA-Werte aller BOs speichert, die unter seiner Steuerung in einem Kontext realisiert wurden;

wobei die OUTXACTION, basierend auf den BOKA-Werten, zuerst jedes berührte BO innerhalb des BOIS sucht, wenn das berührte BO in dem BOIS gefunden werden konnte, wird es während des Realisierungsprozesses verwendet, wenn dagegen das berührte BO innerhalb des BOIS nicht gefunden werden konnte, wird ein neues BO innerhalb des BOIS erzeugt;

wobei die OUTXACTION unter Steuerung der Abbildungsinformationen der TR jedes Datenelement der aktuell empfangenen BA-Nachricht in das entsprechende BOA des berührten BO kopiert, und somit die BOAs des BO inkrementell realisiert;

wobei die OUTXACTION ihrem Aufrufer die Objektbezüge aller berührter BOs zurücksendet, die während der aktuellen Ausführung von OUTXACTION realisiert wurden.