DE10357831A1

DE10357831A1 - System und Verfahren zum Reengineering von Objektmodell-Komponenten zur Generierung von Web-Services

Info

Publication number: DE10357831A1
Application number: DE2003157831
Authority: DE
Inventors: Zaijun Dr.-Ing. Hu; Eckhard Dr.-Ing. Kruse; Yauheni Dipl.-Ing. Veryha; Jens Dipl.-Inf. Doppelhamer
Original assignee: ABB Research Ltd Switzerland
Current assignee: ABB Research Ltd Switzerland
Priority date: 2003-12-09
Filing date: 2003-12-09
Publication date: 2005-07-21

Abstract

System und Verfahren zum Reengineering von Objekt-Komponenten, insbesondere COM-Komponenten, zur Generierung von Web-Service-Wrappern, wobei eine Interaktionsschicht (10) und eine Verarbeitungsschicht (20) und eine Datenpersistenzschicht (30) mit mehreren funktionalen Einheiten (21, 22, 23, 24, 25, 26) und/oder Datenkomponenten (31, 32, 33, 34, 35, 36) vorgesehen sind, die derart zusammenwirken, DOLLAR A È dass eine Bestimmung beziehungsweise Selektion einer jeweilig dem Reengineering zu unterwerfenden Objektmodell-Komponente (31), insbesondere eine COM-Komponente, ermöglicht ist, DOLLAR A È das Objektmodell der jeweils vorbestimmten Objektmodell-Komponente (31), insbesondere eine COM-Komponente, analysiert und auf ein repräsentatives XML-Dokument (32) abgebildet wird, DOLLAR A È das XML-Dokument (32) anhand vorbestimmter XML-Schnittstellenschemata (33) validiert wird und DOLLAR A anhand des erzeugten XML-Dokumentes (32) und unter fakultativer Verwendung von Code-Vorlagen (34) automatisiert eine Generierung von Web-Service-Wrappern (35) durchgeführt wird.

Description

Die Erfindung betrifft ein System sowie ein entsprechendes Verfahren zum Reengineering von Objektmodell-Komponenten, insbesondere von COM-Komponenten, zur Generierung von Nachrichten-basierten Web-Services, beispielsweise für einen plattformunabhängigen Zugriff auf Daten beziehungsweise Informationen eines Automatisierungssystems über ein WAN (Wide Area Network) und/oder ein LAN (Local Area Network), insbesondere das Internet und/oder ein firmen- beziehungsweise systeminternes Intranet.
Die Entwicklung und Realisierung zeitgemäßer Automatisierungssysteme, beispielsweise im Kraftwerksbereich und/oder der Papierindustrie und/oder der chemisch/pharmazeutischen Industrie und/oder bei der Metallverarbeitung, ist durch integrierte Datenbestände mit einheitlichen Datenstrukturen und Datenbeschreibungsformaten geprägt. Eine vertikale Integration von beispielsweise Feldgeräten, Feldbus und Leitebene beziehungsweise Leitsystemebene bis hin zur MES (Manufacturing Execution System)-Ebene, sowie eine horizontale Integration von beispielsweise Einkauf, Entwurf und Engineering bis hin zum Systembetrieb und zur Wartung, die sich gegebenenfalls über den gesamten Lebenszyklus einer Anlage oder eines automatisierungssystems hinweg erstrecken, erfordern einen flexiblen Zugriff auf alle relevanten Daten beziehungsweise Informationen, das jeweilige Automatisierungssystem und/oder die jeweilige Anlage betreffend.
Demgemäß erscheint auch eine plattformunabhängige und programmiersprachenneutrale Nutzung von beispielsweise Anwendungskomponenten und/oder Daten- beziehungsweise Informationsbeständen eines Automatisierungssystems, über das Internet und/oder ein Intranet wünschenswert und vorteilhaft. Eine derartige Nutzungsmöglichkeit könnte beispielsweise einem Daten-Client erlauben, aufgrund seiner jeweiligen Entwicklungsumgebung, Werkzeuge und/oder Anwendungskomponenten auszuwählen, um selbsttätig erwünschte beziehungsweise benötigte Daten und/oder Informationen eines Automatisierungssystems von einem Datenspeicher und/oder aus einer Datenbank abzurufen.
Ein derartiges Vorgehen beziehungsweise eine derartige Funktionalität ist beispielsweise mit Nachrichten- beziehungsweise Message-basierten Web-Services realisierbar, welche sich durch ein standardisiertes Kommunikationsprotokoll, wie beispielsweise SOAP (Simple Object Access Protocol) oder HTTP (Hypertext Transfer Protocol), eine gut definierte Service-Architektur und eine standardisierte Beschreibungssprache, wie beispielsweise WSDL (Web Services Description Language), auszeichnen.
Im Automatisierungsbereich beziehungsweise Automationsbereich umfasst eine traditionelle Informationssystemarchitektur üblicherweise drei Schichten, nämlich

• eine Sicht-Schicht, mit Bedienoberfläche, durch welche beispielsweise eine Präsentation von Daten und/oder Informationen und/oder eine Interaktion mit Systemkomponenten ermöglicht ist,
• eine Datenquelle beziehungsweise Datenquell-Schicht, die auch Echtzeit-Prozessdaten enthalten kann und durch die beispielsweise eine Daten- beziehungsweise Informationsmodellierung, Informationsbeschreibung und -speicherung ermöglicht ist, sowie
• eine logische Schicht., die basierend auf dem jeweiligen Datenmodell der Datenquelle, ein entsprechendes Operationsmodell zur Verarbeitung, Benutzung und Navigation von Daten und/oder Informationen bereitstellt.

Die logische Schicht wird üblicherweise mit Komponententechniken, wie beispielsweise COM (Component Object Models), CORBA (Common Object Request Broker Architecture) oder EJB (Enterprise Java Beans), realisiert. Diese Komponententechniken sowie die ihnen zugrunde liegenden Objektmodelle bieten zahlreiche Vorteile, insbesondere hinsichtlich Wiederverwendbarkeit und Wartbarkeit beziehungsweise Pflegbarkeit. Aber sie haben auch nicht zu vernachlässigende Nachteile, beispielsweise im Hinblick auf Insel-Integration und im Hinblick auf Sicherheitsaspekte.
Web-Services beziehungsweise Nachrichten-basierte Web-Services sind individuell gestaltbare und wiederverwendbare Verarbeitungswerkzeuge, deren Funktionalität plattform- und programmiersprachenunabhängig ist und die über ein WAN und/oder ein LAN, insbesondere das Internet und/oder ein Intranet, aufrufbar und/oder ausführbar sind.
Web-Services basieren auf dem Client/Server-Prinzip. Durch die Verwendung von Web-Service-Techniken, den Einsatz der ihnen jeweilig zugrundeliegenden Kommunikationsprotokolle, wie beispielsweise HTTP und/oder SOAP, sowie ihre weitgehende Akzeptanz und Verbreitung in der Industrie, lassen sich bekannte Nachteile traditioneller Komponententechniken sowie deren Objektmodelle, wie beispielsweise CORBA, COM und EJB, bei gleichzeitigem Erhalt bekannter Vorteile, weitgehend überwinden.
Beispielsweise. setzt eine Verwendung kommerzieller Objektmodell-Komponenten, insbesondere COM-Komponenten, nachteilig voraus, dass die jeweiligen Entwickler den Umgang mit der jeweiligen Komponententechnik beziehungsweise Komponenten-Technologie fachkundig beherrschen, die durch die jeweiligen Objektmodell-Komponenten exportierten Schnittstellen kennen und eine jeweilig Objektmodellfähige Arbeitsplattform besitzen, welche auch eine Implementierung und Ausführung der jeweiligen Objektmodell-Komponenten unterstützt.
Nicht zuletzt aufgrund der ernormen Verbreitung und Popularität des Common Object Model (COM), das einen programmiersprachenunabhängigen, binären Standard für die Implementierung von Objekten zur Verfügung stellt, erscheint mit erfolgreicher Verbreitung und Durchsetzung der Internet-Technologie, insbesondere auch ein Einsatz von COM-Komponenten über das Internet und/oder ein Intranet wünschenswert. Dadurch wäre der Einsatzbereich durch COM-Komponenten implementierter Funktionalitäten, insbesondere für ein Automatisierungssystem, deutlich erweitert und der erforderliche Migrationsaufwand erheblich reduziert.
Nachrichten-basierte Web-Services erlauben hierbei vorteilhaft, die Funktionalität einer COM-Komponente über ein WAN und/oder LAN, insbesondere das Internet und/oder ein Intranet, zugänglich und nutzbar zu machen. Bei einer bestehenden COM-Komponente ist dazu jedoch herkömmlich ein weitestgehend manueller Reengineeringprozess, das heißt, ein manuell durchgeführter, struktureller Umwandlungsprozess, erforderlich, für den es keine einheitlichen Definitionen und/oder Standards gibt. Jeder Entwickler legt vielmehr selbstständig und/oder individuell, abhängig von empirischen Erfahrungswerten und/oder Arbeitsweisen, den jeweiligen Reengineeringprozess fest und führt ihn demgemäß durch. Eine Problematik besteht insbesondere darin, das jeweilige Objektmodell und/oder die in den jeweiligen Objektmodell-Komponenten implementierten Schnittstellen beziehungsweise Implementierungsklassen mit möglichst geringem Aufwand und mit möglichst hoher Flexibilität auf die Web-Service-Architektur abzubilden.
Der maßgeblich manuell durchgeführte Reegineeringrozesses von COM-Komponenten umfasst dabei üblicherweise,

1. eine Analyse des Objektmodells, das gewöhnlich in einer Typbibliothek in Form von einer IDL (Interface Definition Language) beschrieben wird,
2. ein manuelles Selektieren der Schnittstellen bzw. der Implementierungsklassen, die als Web-Services zu realisieren sind,
3. eine Entscheidungsfindung darüber, welche Methoden einer Schnittstelle bei der Realisierung berücksichtigt werden sollen,
4. eine Abbildung einer Schnittstelle beziehungsweise einer Implementierungsklasse auf einen Web-Service-Wrapper,
5. ein manuelles Erstellen des Web-Service-Wrappers mittels gebräuchlicher Programmcodemittel und
6. ein Erzeugen von ausführbaren, binären Web-Service-Komponenten, die über Internet und/oder Intranet zugänglich beziehungsweise nutzbar sind.

Mittels entsprechender Verarbeitungswerkzeuge wird dabei eine Visualisierung der jeweiligen Schnittstellen beziehungsweise der Implementierungsklassen der jeweiligen COM-Komponente durchgeführt und durch Verstandestätigkeit eine Entscheidung darüber herbeigeführt, welche Schnittstellen beziehungsweise Klassen durch Anwendung welcher Methoden auf Web-Services abzubilden sind.
Dementsprechend sind die jeweiligen Web-Service-Wrapper zu programmieren, welche die Logik beziehungsweise logischen Elemente der abzubildenden Objektmodell-Komponente einkapseln und ausführbare Web-Service-Komponenten generieren. Der manuell durchgeführte Reengineeringprozess bedingt nachteilig einen fachkundigen Einsatz verschiedenartiger Werkzeuge und/oder Anwendungskomponenten, insbesondere zur Visualisierung und/oder Verarbeitung und/oder Generierung von Web-Services, und ist bei vergleichsweise großer Komplexität des jeweiligen Objektmodells besonders aufwendig und schwierig, da eine komplexe Modellstruktur mit zahlreichen Beziehungen und Kopplungen zwischen Schnittstellen und/oder Klassen nachteilig zu der Notwendigkeit führt, die gesamte Beziehungshierarchie des jeweiligen Objektmodells auf die Web-Service-Architektur abzubilden, was aufgrund des damit verbundenen vergleichsweise hohen Aufwandes und der daraus resultierenden hohen Fehleranfälligkeit kaum noch manuell durchführbar ist. Der Reengineeringprozess ist darüber hinaus mit zeitintensiver Programmiertätigkeit behaftet, die zu einem wesentlichen Teil aus Routinenarbeiten besteht.
Eine Verbesserung des Reengineeringprozesses derart, dass nur noch minimale manuelle Eingriffe erforderlich sind, erscheint somit überaus wünschenswert und vorteilhaft.
Der Erfindung liegt die Aufgabe zugrunde, ein vereinfachtes und verbessertes Reengineering von COM-Komponenten zur Generierung von Web-Services zu ermöglichen.
Diese Aufgabe wird durch ein System und ein Verfahren zum Reengineering von Objektmodell-Komponenten, insbesondere COM-Komponenten zur Generierung von Web-Services sowie deren binäre Komponenten mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in weiteren Ansprüchen und der nachfolgenden Beschreibung angegeben.
Das erfindungsgemäße System zum Reengineering von Objektmodell-Komponenten, insbesondere COM-Komponenten, zur Generierung von Web-Services umfasst eine Interaktionsschicht und eine Verarbeitungsschicht und eine Datenpersistenzschicht, wobei die Schichten mehrere funktionale Einheiten und/oder Datenkomponenten aufweisen, die derart zusammenwirken,

• dass eine Bestimmung beziehungsweise Selektion einer jeweilig dem Reengineering zu unterwerfenden Objektmodell-Komponente, insbesondere eine COM-Komponente, ermöglicht ist,
• das Objektmodell der jeweils vorbestimmten Objektmodell-Komponente analysiert und auf ein repäsentatives XML-Dokument abgebildet wird,
• das XML-Dokument anhand vorbestimmter XML-Schnittstellenschemata validiert wird und
• anhand des erzeugten XML-Dokumentes und unter fakultativer Verwendung von Code-Vorlagen automatisiert eine Generierung von Web-Service-Wrappern und/oder von darauf basierenden Web-Services durchgeführt wird.

In einer vorteilhaften Ausführungsform des Systems weist die Verarbeitungsschicht als funktionale Einheit eine Vorverarbeitungseinrichtung auf, welche das Objektmodell der vorbestimmten Objektmodell-Komponente, insbesondere der COM-Komponente, automatisiert analysiert und/oder die jeweilig ermittelten Schnittstellen der COM-Komponente derart angibt, dass eine Abbildungstrategie für die Abbildung der jeweiligen Objektmodell-Komponente, insbesondere ihrer Schnittstellen beziehungsweise Implementierungsklassen, auf das repräsentative XML-Dokument definierbar beziehungsweise festlegbar ist. Dazu gehören auch Namenabbildung und Abbildungskardinalität.
In einer weiteren vorteilhaften Ausgestaltung des Systems weist die Verarbeitungsschicht als funktionale Einheit einen Mapper beziehungsweise Abbilder auf, der mittels einer festgelegten Abbildungsstrategie und unter Verwendung von wenigstens einem XML-Schnittstellenschema ein für das jeweilige Objektmodell und das angestrebte Abbildungsergebnis repräsentatives XML-Dokument mit regelbasiertem XML-Schema erstellt.
In einer weiteren vorteilhaften Ausführungsform des Systems weist die Verarbeitungsschicht als funktionale Einheit eine Validierungseinheit auf, welche anhand im jeweiligen XML-Schnittstellenschemata festgelegten Regeln und/oder Beziehungen und/oder Strukturen eine Überprüfung und/oder Validierung des repäsentativen XML-Dokumentes vornimmt.
Vorteilhaft ist als weitere funktionale Einheit der Verarbeitungsschicht ein Generator vorsehbar, der anhand des repräsentativen XML-Dokumentes und unter Verwendung von bereitgestellten Code-Vorlagen Web-Service-Wrapper generiert.
Vorteilhaft ist als weitere funktionale Einheit der Verarbeitungsschicht auch ein Kompilierer beziehungsweise Kompiler vorsehbar, der die generierten Web-Service-Wrapper in ausführbare, binäre Web-Service-Wrapper beziehungsweise Web- Service-Komponenten derart umwandelt, dass diese programmiersprachen- und/oder plattformunabhängig sind.
In einer weiteren vorteilhaften Ausführungsform des Systems weist die Datenpersistenzschicht als funktionale Einheit einen Komponentenspeicher auf, in welchem beziehungsweise auf welchem dem Reengineeringprozess zugrunde legbare Objektmodell-Komponenten, insbesondere COM-Komponenten, auf- und/oder abrufbar gespeichert sind.
Vorteilhaft ist als funktionale Einheit der Interaktionsschicht eine Interaktionseinrichtung, die beispielsweise einen Touchscreen oder eine kombinierte Anzeige/Eingabevorrichtung umfasst, vorsehbar, über welche auf wenigstens eine Objektmodell-Komponente, insbesondere eine COM-Komponente, Zugriff besteht und/oder welche mit funktionalen Einheiten der Verarbeitungsschicht in Kommunikations- und/oder Wirkverbindung steht. Vorteilhaft stellt die jeweilige Interaktionseinheit eine dafür eingerichtete Benutzeroberfläche beziehungsweise Benutzerumgebung bereit, mittels welcher im Zusammenwirken mit den funktionalen Einheiten der Verarbeitungsschicht auch mit vergleichsweise geringen Programmierkenntnissen eine entsprechende Abbildungsstrategie definierbar und/oder Code-Vorlagen erstellbar und/oder ausführbare Web-Services erzeugbar sind.
In einer besonders vorteilhaften Ausgestaltung des Systems weist die Verarbeitungsschicht einen Vorlage-Editor, beispielsweise ein gebräuchlicher Texteditor, zum Erstellen von Code-Vorlagen, mit gebräuchlichen Programmcodemitteln, auf.
Vorteilhaft sind als weitere funktionale Einheiten der Datenpersistenzschicht ein Vorlage-Speicher zur Speicherung von erstellten Code-Vorlagen und/oder ein XML-Schnittstellenschemaspeicher zur Speicherung von vorbestimmten XML-Schnittstellenschemata und/oder ein Zwischenproduktspeicher zur Speicherung des repräsentativen XML-Dokumentes vorsehbar.
Vorteilhaft ist der Generator der Verarbeitungsschicht derart ausführbar, dass er generierte Web-Service-Wrapper mit den jeweiligen Code-Vorlagen gebunden dem Vorlage-Speicher der Datenpersistenzschicht zuführt.
In einer weiteren vorteilhaften Ausführungsform des Systems ist darüber hinaus wenigstens eine funktionale Einheit zur bedarfsgerechten Verfeinerung und/oder Anpassung der generierten Web-Service-Wrapper vorgesehen.
In einer bevorzugten Ausführungsform des Systems sind die funktionalen Einheiten der Verarbeitungsschicht, die eine Vorverarbeitungseinrichtung und/oder einen Mapper und/oder eine Validierungseinrichtung und/oder einen Generator und/oder einen Kompilierer umfassen, in wenigstens einer Datenverarbeitungseinrichtung implementiert beziehungsweise integriert.
Vorteilhaft ermöglicht das angegebene System eine wesentliche Vereinfachung für das Reengineering von Objektmodell-Komponenten, insbesondere von COM-Komponenten, und die Generierung von Web-Services, da eine automatisierte Abbildung der jeweiligen Objektmodell-Komponente auf die entsprechenden Web-Services durchgeführt wird und damit der erforderliche Aufwand erheblich reduziert und die Fehleranfälligkeit minimiert wird.
Die vorgenannten Ausgestaltungen sind hierbei sowohl jeweils für sich als auch in Kombination vorteilhaft vorsehbar.
Die weitere Darlegung der Erfindung sowie vorteilhafter Ausgestaltungen erfolgt anhand von einigen Figuren und Ausführungsbeispielen.
Es zeigen:
1 ein beispielhaftes System zum Reengineering von COM-Komponenten zur Generierung von Web-Services,
2 ein beispielhaftes Verfahren zum Reengineering von COM-Komponenten zur Generierung von Web-Services zur Ausführung auf dem System gemäß 1,
3 ein Dokument mit beispielhaftem XML-Schnittstellenschema zur Beschreibung von Abbildungsregeln, Struktur, Beziehungen und Basiselementen, die den endgültigen Web-Services zugrunde zu legen sind,
4 ein beispielhaftes regelbasiertes XML-Dokument mit zugrunde gelegtem XML-Schema und
5 eine beispielhafte Code-Vorlage
In 1 ist ein beispielhaftes System zur automatisierten Generierung von Web-Services aus einer COM-Komponente gezeigt, wobei die COM-Komponente bestimmungsgemäß für einen Datenzugriff auf Informationsserver entwickelt worden ist. Das System weist im wesentlichen drei Schichten auf, nämlich eine Interaktionsschicht 10 mit wenigstens einer Interaktionseinrichtung 11, eine Verarbeitungsschicht 20 mit mehreren funktionalen Verarbeitungswerkzeugen 21, 22, 23, 24, 25, 26 und eine Daten- beziehungsweise Informationspersistenzschicht 30 in der die verschiedenen Ein- und Ausgangsinformationen beziehungsweise Dokumente verwaltet und gepflegt werden. Jede Schicht umfasst somit weitere Funktionseinheiten und/oder Datenkomponenten, welche die Funktionalität der jeweiligen Schicht bestimmen.
Im Zusammenwirken mit der Verarbeitungsschicht ermöglicht die Interaktionsschicht eine Daten- und/oder Informationserfassung, eine Bedienung und/oder Überwachung des Systems durch Benutzer beziehungsweise Anwender und/oder eine Visualisierung von Daten und/oder von Informationen, beispielsweise auch von Nachrichten, und/oder von Ergebnissen.
Die Verarbeitungsschicht umfasst mehrere funktionale Einheiten, wie beispielsweise eine Vorverarbeitungseinrichtung 21, einen Mapper 22, das heiß, ein Maskengene rierungswerkzeug, einen Validator 23, einen Vorlage-Editor 24, einen Generator 25 und einen Compiler 26.
Die Vorverarbeitungseinrichtung 21 hat die Aufgabe, eine vorgegebene COM-Komponente zu analysieren und die jeweiligen Schnittstellen der COM-Komponente derart anzugeben, dass dem jeweiligen Anwender beziehungsweise Benutzer die Möglichkeit gegeben ist mittels Mapper 22 eine Abbildungstrategie zu definieren beziehungsweise festzulegen.
Der Mapper 22 ist hierbei maßgeblich für die Definition der Abbildungsstrategie verantwortlich. Mit ihm ist bestimmbar, welche Schnittstellen auf Web-Services abgebildet werden und welche nur auf einfache Datenstrukturen abgebildet werden sollen. Dabei sind auch Namenabbildung und Kardinalität festlegbar. Die Abbildung einer Funktion einer Komponente auf eine Web-Service-Funktion wird ebenfalls durch den Mapper 22 verwirklicht.
Mittels Validator 23 wird im Zusammenwirken mit XML-Schnittstellenschema 33 und Mapper 22 die Gültigkeit des Abbildungsergebnisses, beispielsweise hinsichtlich Eindeutigkeit, Reihenfolge, Beziehungen und/oder Struktur überprüft und/oder validiert. Nach der erfolgreichen beziehungsweise gelungenenen Abbildung wird als Vorstufe ein XML-Dokument 32 erzeugt und als Datei abgelegt.
Der Vorlage-Editor 24 wird zur Erstellung parametrierbarer Code-Vorlagen verwendet, die in der Abbildung einer COM-Komponente auf Web-Services mehrmals anwendbar sind. Der Inhalt und Umfang einer Code-Vorlage wird durch die jeweils abzubildende Schnittstelle und/oder jeweils abzubildende Funktion bestimmt.
Der Generator 25 generiert basierend auf dem vorstufig erzeugten XML-Dokument (32) Web-Services in einer vorbestimmten Zielprogrammiersprache. Dabei setzt er entsprechende Code-Vorlagen 34 ein und bindet sie mit generiertem Code.
Der Compiler 26 bewirkt eine Umwandlung des durch den Generator 25 produzierten Code in eine binäre und damit in eine programmiersprachen- und plattformunabhängige Codeform, damit die jeweiligen Web-Services auch über Internet und/oder Intranet aufrufbar sind.
Die Datenpersistenzschicht 30 umfasst diverse Persistenzformen – COM DLL 31, XML Dokumente 32, XML-Schema 33, Code-Vorlagen 34, Web-Service-Klassen (35) und binäre Web-Service-Komponenten. Die Datenpersistenzschicht spielt auch bei Flexibilität und Wiederverwertbarkeit eine große Rolle. Die Code-Vorlagen 34 sind bei der Code-Wiederverwendung einsetzbar, wodurch der Programmieraufwand erheblich reduziert wird, und das vorstufige XML-Dokument 32 ermöglicht es den Mapper 22 und/oder den Validator 23 und/oder den Generator 25 auch bei Komponenten und/oder Funktionseinheiten einzusetzen, die nicht COM-basiert sind.
In 2 ist ein Verfahren zum Reengineering von COM-Komponenten und automatisierten Generieren von Web-Services sowie ihrer binären Komponenten gezeigt.
Das Verfahren zum Reengineering von COM-Komponenten für Web Services umfasst hierbei mehrere Verfahrensabschnitte, in denen jeweils eine Visualisierung 210 der jeweiligen COM-Komponente, insbesondere ihrer Schnittstellen, eine Abbildung 220 der jeweiligen COM-Komponente auf ein XML-Dokument, eine Validierung 230 des jeweilig erstellten XML-Dokumentes auch anhand vorbestimmter XML-Schnittstellenschemata, eine Erstellung von Code-Vorlagen 240, eine Erzeugung 250 von Web-Service Wrapper Klassen auch unter Verwendung der erstellten Code-Vorlagen, eine bedarfsgerechte Feineinstellung 260 und/oder Kompilierung 270 der erzeugten Web-Service Wrapper Klassen zur Generierung binärer und damit ausführbarer Web-Service Wrapper durchgeführt wird.
Jeder durchlaufene Verfahrenabschnitt liefert im Ergebnis ein Produkt oder Zwischenprodukt.
Nach verfahrensvorbereitender Erfassung der jeweiligen COM-Komponente wird in einem ersten Verfahrensabschnitt 210 mittels der Vorverarbeitungseinrichtung 21 eine Visualisierung des Objektmodells der jeweilig erfassten COM-Komponente durchgeführt. Der Visualisierungsprozess umfasst hierbei einen Ladevorgang, bei welchem das Objektmodell der jeweiligen COM-Komponente in den Speicher der Datenverarbeitungseinrichtung geladen wird und/oder einen Kennzeichnungsvorgang, bei welchem bestimmt wird wie ein Datenobjekt im jeweiligen Automatisierungssystem identifiziert wird.
In einem zweiten Verfahrensabschnitt 220 wird mittels einer vom Mapper angegebenen Konfiguration die Abbildungsstrategie für die Abbildung der Schnittstellen und/oder Implementierungsklassen der jeweiligen COM-Komponente bestimmt und als Zwischenergebnis in Form eines XML-Dokumentes 32, insbesondere einer XML-Datei, abrufbar gespeichert. Der jeweilige Abbildungsprozeß setzt hierbei voraus, dass das Objektmodell der COM-Komponente in einen Datenspeicher der jeweilig verfahrensausführenden Datenverarbeitungseinrichtung geladen ist, wofür der Visualisierungsprozeß sorgt. Die jeweilige Abbildungsstrategie legt hierbei fest, welche Schnittstellen beziehungsweise Implementierungsklassen auf welche Art und Weise auf die entsprechenden Web-Services abgebildet werden sollen. Dazu gehören unter anderem auch die Namenabbildung und die Kardinalität. Das als Zwischenergebnis generierte XML-Dokument 32, das die Vorstufe für den Abbildungsprozess bildet, welcher durch die Abbildungsstrategie bestimmt wird, entspricht hierbei einem regelbasierten XML-Schema 33. Das regelbasierte XML-Schema definiert Strukturen, Beziehungen und grundlegende Elemente die bei der Abbildung auf Web-Services zu verwenden und zu berücksichtigen sind.
In einem dritten Verfahrensabschnitt 230 wird mittels des Validators 23 eine Validierung des als Zwischenergebnis generierten XML Dokumentes 32 durchgeführt, das heißt das XML-Dokument 32 wird, basierend auf den in dem XML-Schema 32, beziehungsweise im XML-Schnittstellenschema, festgelegten Regeln und/oder Beziehungen und/oder Strukturen, geprüft beziehungsweise überprüft.
In einem weiteren, vierten Verfahrensabschnitt 240, der weitestgehend unabhängig von den anderen Abschnitten ausgeführt wird, werden mittels eines Vorlage-Editors 24, insbesondere eines gebräuchlichen Texteditors, Code-Vorlagen 34 mit wiederverwendbaren Programmcodemitteln erstellt.
In einem fünften Verfahrensabschnitt 250 werden mittels des Generators 26, unter Verwendung der erstellten Code-Vorlagen 34, entsprechende Web-Service-Wrapper 35 generiert, wobei fakultativ in einem weiteren, sechsten Verfahrenabschnitt 260 eine Feinabstimmung zur bedarfsgerechten Anpassung der jeweiligen Web-Service Wrapper sowie der späteren jeweiligen Web-Service-Komponenten an individuelle Bedürfnisse durchführbar ist.
In einem siebten Verfahrenabschnitt 270 wird der jeweilige Web-Service-Wrapper mittels des Compilers beziehungsweise Kompilierers 26 entsprechend übersetzt und in eine ausführbare binäre Web-Service-Komponente umgewandelt, wobei die umgewandelte binäre Web-Service-Komponente dann plattform- und/oder programmiersprachenunabhängig und somit universell einsetzbar ist.
In 3 sind die Programmcodemittel eines in einer Datei abgelegten, beispielhaften XML-Schnittstellenschemas 33 gezeigt. Durch das XML-Schnittstellenschema werden Struktur und/oder Regeln und/oder Beziehungen und/oder Grundelemente festgelegt, die im vorstufigen XML-Dokument 32 anwendbar beziehungsweise verwendbar sind. Einem Klassen- beziehungsweise class-Element muss beispielsweise ein Namen zugewiesen sein und es muss die Elemente „referenceld", „field", „property" und „method" aufweisen. Das jeweilige XML-Schema 22 bestimmt dabei auch die Reihenfolge verschiedener Elemente, deren Zusammenschau wiederum ein anderes Element bildet. Diese Reihenfolge bestimmt auch die Reihenfolge der Programmcodemittelgenerierung und damit das Layout der generierten Programmcodemittel, was im Hinblick auf eine leichtere Pfleg- und/oder Wartbarkeit und/oder eine erleichterte, bedarfsgerecht vorzunehmende Feineinstellung, von immanenter Bedeutung sein kann.
In 4 ist ein beispielhaft vorstufiges XML-Dokument 32 gezeigt. Anhand dieses XML-Dokumentes 32 werden, mittels des Generators 26, die verschiedenen Web-Service-Wrapper-Klassen 35 erzeugt und, mittels des Compilers 27, in binäre Web-Service-Wrapper Komponenten 36 umgewandelt. Aus dem beispielhaft in 4 gezeigten Dokument ist ersichtlich, dass eine Klasse „ABBSystem", die in der entsprechenden COM-Kompenente definiert ist, auf zwei XML-class- beziehungsweise XML-Klassen-Elemente abgebildet wird, nämlich auf „ABBSystem" und „ABBSystemBuddy". Das „ABBSystem"-Element wird auf einen Web-Service abgebildet, wohingegen das „ABBSystemBuddy"-Element als normale Datenstruktur umgesetzt wird. Es ist in aller Regel nicht notwendig, alle Klassen einer COM-Komponente auf Web-Services abzubilden. Das „ABBObjectType"-Element in dem XML Dokument 32 ist ein Beispiel dafür.
In 5 ist eine beispielhafte Code-Vorlage 34 gezeigt, die innerhalb eines Web-Services die Handhabung von übergebenen Aufrufparametern und ihre Zuordnung zu serverseitig bereitgestellten Daten durchführt. Um aus der Code-Vorlage 34 den kompilierbaren Code für einen Web-Service-Wrapper zu erzeugen, werden generische Parameter, wie beispielsweise „%Parameter1%", „%Parameter2%", „%Parameter3%", „%Parameter4%", „%Parameter5%" und/oder „%Parameter6%" durch Bindung aufgelöst und entsprechend ersetzt.

Claims

System zum Reengineering von Objektmodell-Komponenten (31), insbesondere COM-Komponenten, zur Generierung von Web-Service-Wrappern (35), wobei eine Interaktionsschicht (10) und eine Verarbeitungsschicht (20) und eine Datenpersistenzschicht (30) mit mehreren funktionalen Einheiten und/oder Datenkomponenten vorgesehen sind, die derart zusammenwirken, • dass eine Bestimmung beziehungsweise Selektion einer jeweilig dem Reengineering zu unterwerfenden Objektmodell-Komponente (31), insbesondere eine COM-Komponente, ermöglicht ist, • das Objektmodell der jeweils vorbestimmten Objektmodell-Komponente (31), insbesondere eine COM-Komponente, analysiert und auf ein repäsentatives XML-Dokument (32) abgebildet wird, • das XML-Dokument (32) anhand vorbestimmter XML-Schnittstellenschemata (33) validiert wird und • anhand des erzeugten XML-Dokumentes (32) und unter fakultativer Verwendung von Code-Vorlagen (34) automatisiert eine Generierung von Web-Service-Wrappern (35) durchgeführt wird.
System nach Anspruch 1, dadurch gekennzeichnet, dass die Verarbeitungsschicht (20) eine Vorverarbeitungseinrichtung (21) aufweist, welche das Objektmodell der vorbestimmten Objektmodell-Komponente (31), insbesondere eine COM-Komponente, analysiert und/oder die jeweilig ermittelten Schnittstellen der Objektmodell-Komponente (31) derart angibt, dass eine Abbildungstrategie für die Abbildung der jeweiligen Objektmodell-Komponente (31), insbesondere ihrer Schnittstellen, auf das repräsentative XML-Dokument (32) definierbar beziehungsweise festlegbar ist.
System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Verarbeitungsschicht (20) einen Mapper (22) aufweist, die mittels einer festgelegten Abbildungsstrategie und unter Verwendung von wenigstens einem XML- Schnittstellenschema (33) ein für das Objektmodell sowie das Abbildungsergebnis repräsentatives XML-Dokument (32) mit regelbasiertem XML-Schema erstellt.
System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Verarbeitungsschicht (20) einen Validator (23) aufweist, der basierend auf in vorbestimmten XML-Schnittstellenschemata (33) festgelegten Regeln und/oder Beziehungen und/oder Strukturen eine Überprüfung und Validierung des repäsentativen XML-Dokumentes (32) durchführt.
System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Verarbeitungsschicht (20) einen Generator (25) aufweist, der anhand des repräsentativen XML-Dokumentes (32) und unter Verwendung von Code-Vorlagen (34) Web-Service-Wrapper (35) generiert.
System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Verarbeitungsschicht (20) einen Kompilierer (26) aufweist, der die generierten Web-Service-Wrapper (35) in binäre Web-Service-Komponenten (36) derart umwandelt, dass diese programmiersprachen- und/oder plattformunabhängig sind.
System nach einem der vorherigen Ansprüche dadurch gekennzeichnet, dass die Datenpersistenzschicht (30) einen Komponentenspeicher aufweist, in welchem dem Reengineeringprozess zugrunde legbare Objektmodell-Komponenten (31), insbesondere COM-Komponenten, zugreif- beziehungsweise aufrufbar abgelegt sind.
System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Interaktionseinrichtung (11) der Interaktionsschicht (10) Zugriff auf wenigstens eine Objektmodell-Komponente (31), insbesondere eine COM-Komponente, hat und mit den funktionalen Einheiten (21, 22, 23, 24, 25, 26) der Verarbeitungsschicht (10) in Kommunikations- und/oder Wirkverbindung steht.
System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Verarbeitungsschicht (20) einen Vorlage-Editor (24) zum Erstellen von Code-Vorlagen (34) aufweist.
System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Datenpersistenzschicht (30) einen Vorlage-Speicher zur Speicherung von Code-Vorlagen (34) und/oder einen XML-Schnittstellenschemaspeicher zur Speicherung von XML-Schnittstellenschemata (33) und/oder einen Zwischenproduktspeicher zur Speicherung des repräsentativen XML-Dokumentes (32) aufweist.
System nach einem der Anspruch 8, dadurch gekennzeichnet, dass die Verarbeitungsschicht (20) einen Generator (25) aufweist, der generierte Web-Service-Wrapper (35) mit den jeweiligen Code-Vorlagen (34) gebunden dem Vorlage-Speicher der Datenpersistenzschicht (30) zuführt.
System nach einem der Ansprüche 8 oder 9, dadurch gekennzeichnet, dass auf dem XML-Schnittstellenschemaspeicher XML-Schnittstellenschemata (33) aufruf- beziehungsweise abrufbar gespeichert sind.
System nach einem der Ansprüche 8 bis 10, dadurch gekennzeichnet, dass auf dem Vorlagen-Speicher Code-Vorlagen (34) aufruf- beziehungsweise abrufbar gespeichert sind.
System nach einem der Ansprüche 8 bis 11, dadurch gekennzeichnet dass auf dem Zwischenproduktspeicher jeweils das repräsentative XML-Dokument (32) aufruf- beziehungsweise abrufbar gespeichert ist.
System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die funktionalen Einheiten der Verarbeitungsschicht (20) in wenigstens einer Datenverarbeitungseinrichtung implementiert und eine Vorverarbeitungseinrichtung (21) und/oder einen Mapper (22) und/oder einen Validator (23) und/oder einen Generator (25) und/oder einen Kompilierer (26) umfassen.
Verfahren zum Reengineering von Objektmodell-Komponenten (31), insbesondere COM-Komponenten, zur Generierung von Web-Service-Wrappern (35), wobei abschnittsweise mittels einer Interaktionsschicht (10) und einer Verarbeitungs schicht (20) und einer Datenpersitstenzschicht (30) mit mehreren funktionalen Einheiten und/oder Datenkomponenten • eine Bestimmung beziehungsweise Selektion einer jeweilig dem Reengineering zu unterwerfenden Objektmodell-Komponente (31), insbesondere einer COM-Komponente, durchgeführt wird, • das Objektmodell der jeweils vorbestimmten Objektmodell-Komponente (31), insbesondere einer COM-Komponente, analysiert und auf ein repäsentatives XML-Dokument (32) abgebildet wird, • das XML-Dokument (32) anhand vorbestimmter XML-Schnittstellenschemata (33) validiert wird und • anhand des erzeugten XML-Dokumentes (32) und unter Verwendung von Code-Vorlagen automatisiert eine Generierung von Web-Service-Wrappern (35) durchgeführt wird.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass mittels einer Vorverarbeitungseinrichtung (21) das Objektmodell der vorbestimmten Objektmodell-Komponente (31), insbesondere einer COM-Komponente, analysiert und/oder die jeweilig ermittelten Schnittstellen der jeweiligen Obkjektmodell-Komponente (31) derart angegeben werden, dass eine Abbildungstrategie für die Abbildung der jeweiligen Objektmodell-Komponente (31), insbesondere ihrer Schnittstellen, auf das repräsentative XML-Dokument (32) definierbar beziehungsweise festlegbar ist.
Verfahren nach einem der Ansprüche 16 oder 17, dadurch gekennzeichnet, dass mittels eines Mappers (22) eine Abbildungsstrategie für die Abbildung der Schnittstellen und/oder Implementierungsklassen der jeweiligen Objektmodell-Komponente (31), insbesondere einer COM-Komponente, bestimmt wird und unter Verwendung von wenigstens einem XML-Schnittstellenschema (33) ein für das Objektmodell sowie die Abbildungsstrategie repräsentatives XML-Dokument (32) mit regelbasiertem XML-Schema erstellt wird.
Verfahren nach einem der Ansprüche 16 bis 18, dadurch gekennzeichnet, dass mittels eines Validators (23), basierend auf festgelegten Regeln und/oder Beziehungen und/oder Strukturen vorbestimmter XML-Schnittstellenschemata (33) eine Überprüfung und Validierung des repäsentativen XML-Dokumentes (32) durchgeführt wird.
Verfahren nach einem der Ansprüche 16 bis 19, dadurch gekennzeichnet, mittels eines Generators (25), anhand des repräsentativen XML-Dokumentes (32) und unter Verwendung von Code-Vorlagen (34) Web-Service-Wrapper (35) generiert werden.
Verfahren nach einem der Ansprüche 16 bis 20, dadurch gekennzeichnet, dass mittels eines Kompilierers (26) die generierten Web-Service-Wrapper (35) in binäre Web-Service-Komponenten (36) derart umgewandelt werden, dass diese programmiersprachen- und/oder plattformunabhängig sind.
Verfahren nach einem der Ansprüche 16 bis 21, dadurch gekennzeichnet, dass dem Reengineeringprozess zugrunde legbare Objektmodell-Komponenten (31), insbesondere COM-Komponenten, zugreif- beziehungsweise aufrufbar auf einem Komponentenspeicher abgelegt sind.
Verfahren nach einem der Ansprüche 16 bis 22, dadurch gekennzeichnet, dass mittels der wenigstens einen Interaktionseinrichtung (11) der Interaktionsschicht (10) auf wenigstens eine Objektmodell-Komponente (31), insbesondere eine COM-Komponente, selektiv zugegriffen wird und/oder die die wenigstens eine Interaktionseinrichtung (11) mit den funktionalen Einheiten (21, 22, 23, 24, 25, 26) der Verarbeitungsschicht (20) in Kommunikations- und/oder Wirkverbindung steht.
Verfahren nach einem der Ansprüche 16 bis 23, dadurch gekennzeichnet, dass mittels eines Vorlage-Editors (24) Code-Vorlagen (34) zum Generieren von Web-Service-Wrappern (35) erstellbar sind.
Verfahren nach einem der Ansprüche 16 bis 24, dadurch gekennzeichnet, dass mittels eines Generators (25) generierte Web-Service-Wrapper (35) mit den jeweiligen Code-Vorlagen (34) gebunden einem Vorlage-Speicher zugeführt werden.
Verfahren nach einem der Ansprüche 16 bis 25 dadurch gekennzeichnet, dass XML-Schnittstellenschemata (33) auf einem XML-Schnittstellenschemaspeicher aufruf- beziehungsweise abrufbar gespeichert werden.
Verfahren nach einem der Ansprüche 16 bis 26, dadurch gekennzeichnet, dass Code-Vorlagen (34) auf einem Vorlagen-Speicher aufruf- beziehungsweise abrufbar gespeichert werden.
Verfahren nach einem der Ansprüche 16 bis 27, dadurch gekennzeichnet dass das jeweilige repräsentative XML-Dokument (32) auf einem Zwischenproduktspeicher aufruf- beziehungsweise abrufbar gespeichert wird.
Verfahren nach einem der Ansprüche 16 bis 28, dadurch gekennzeichnet, dass eine bedarfsgerechte Feineinstellung der unter Verwendung von Code-Vorlagen (34) generierten Web-Service-Wrapper (35) und damit auch der späteren, ausführbaren Web-Service-Komponenten (36) durchgeführt wird.