Klassifizierung und Suche Semantischer Ressourcen in verteilten Systemen

Inhaltsverzeichnis

1. Grundlagen
1.1 Webservices
1.2 Webservice - Orchestrierung
1.3 Semantic Web
1.4 Semantic Webservices
1.5 Semantic Webservice Registry
1.6 OWL-S
1.7 Planer
1.8 Matchmaking Algorithmen
1.9 Facettenbasierte Klassifikation

2. Synthese
2.1 Problematik im Bauwesen
2.2 Konzept zur Integration von Daten, Modellen und Services
2.3 Semantische Datenbasis
2.4 Austauschen von Berechnungsmodellen
2.5 Facettenbasierte Klassifikation

3. Implementierung
3.1 Implementierung des Konzeptes
3.2 Semantische Datenbasis
3.3 Adapter Webservices
3.4 Funktionale Webservices
3.5 Evaluierungsbeispiel
3.6 OSPP Erweiterung
3.7 Standards und Entwicklungswerkzeuge

4. Zusammenfassung

5. Anhang
5.1 Abbildungen
5.2 Tabellenverzeichnis
5.3 Abbildungsverzeichnis
5.4 Literaturverzeichnis

Einleitung

Semantic Web ist eines der meistgenutzten Schlagworte im Bezug auf die Zukunft des WWW. Die Notwenigkeit des Semantic Web entsteht durch die „Überproduktion“ von Information. Dabei werden mehr Informationen produziert, als verarbeitet werden können. Dabei verlieren die produzierten Informationen ihre Nützlichkeit, denn die Information hat nur dann einen Nutzen, wenn diese verarbeitet und in der Schlussfolgerung eines Ergebnisses berücksichtigt werden kann. Die obere Aussage wird durch die folgende Statistik belegt:

Die Anzahl der im Internet verfügbaren Webseiten und die Menge der angebotenen Services wächst stetig an. Bereits im November 2006 ergaben Schätzungen, dass die Zahl der weltweit angebotenen Seiten die Marke von 100 Millionen überschritten hat (Netcraft, 2006).

Die Vision des Semantic Web stammt von Tim Berners-Lee aus dem Jahr 1998 (Berners-Lee, 1998). Semantic Web soll die Kommunikation zwischen Programmen, sogenannten Software Agenten, verbessern. Dazu müssen die Informationen so aufbereitet werden, dass sie nicht nur von verschiedenen Programmen auf verschiedenen Computer fehlerfrei gelesen werden können, wie beispielsweise XML, sondern auch verstanden. Die Software Agenten sollen die Bedeutung von im Internet veröffentlichen Informationen begreifen und daraus automatisch Schlussfolgerungen ziehen können. Die „Überproduktion“ der Daten betrifft auch das Bauwesen. So werden während der Bauwerksüberwachung viele Daten benötigt oder auch produziert.

Diese Arbeit bildet eine Brücke zwischen der Informatik und dem Bauwesen. Dabei werden die Konzepte aus dem Semantic Web durch die Integration in einer modernen Entwicklungsumgebung an die Lösung der Probleme aus dem Bauwesen angepasst. Semantic Web kann zum Einen für die Suche der benötigten Webservices, sowie dazugehörigen Berechnungsmodellen zum Einsatz kommen. Zum Anderen können die Berechnungsergebnisse, sowie die benötigten Eingabedaten ebenfalls semantisch beschrieben werden und dadurch effektiv in weiteren Projekten genutzt werden.

Gliederung

Diese Arbeit ist in drei Kapitel aufgeteilt: im ersten Kapitel werden die theoretischen Grundlagen sowie die aktuellen Technologien und Standards kurz vorgestellt. Danach folgt das Kapitel der Synthese. Dieses beschreibt die während dieser Arbeit entdeckten Problemstellungen sowie erarbeiteten Methoden zu deren Lösung. Das letzte Kapitel beschreibt die praktische Umsetzung von in der Synthese erarbeiteten Methoden, dabei werden die aktuellen Technologien und Werkzeuge für die Anwendung in einem größeren Vorhaben diskutiert. Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick.

1. Grundlagen

In diesem Kapitel werden die notwendigen Konzepte und Technologien kurz vorgestellt. Zuerst werden einige klassische Technologien für die Erstellung einer modernen verteilten Anwendung erläutert. Nachfolgend werden die darauf aufbauenden semantischen Konzepte und derzeit exisitierenden Werkzeuge und Standards vorgestellt.

1.1 Webservices

„Web Services sind aus der Software-Entwicklung praktisch nicht mehr wegzudenken – sie leisten in vielen Einsatzgebieten und unterschiedlichsten Branchen gute Dienste“

Thilo Frotscher (Frotscher, et al., 2007)

Webservices sind heute sehr verbreitet und werden in vielen Branchen eingesetzt. Der Erfolg von Webservices liegt in dem standardisierten Konzept, das durch die Web Services Interoperability Organisation (WS-I) durch die Veröffentlichung von Richtliniendokumenten festgelegt wird (Frotscher, et al., 2007). Die Standards für Webservices müssen einen Webservice aus verschiedenen Sichten beschreiben, damit die anderen Programme dieses finden, seine Schnittstelle begreifen und mit diesem kommunizieren können. Nachfolgend werden die drei derzeit am häufigsten dafür verwendeten Standards vorgestellt.

WSDL steht für Web Service Description Language und ist eine Sprache für die Beschreibung von Webservices. Die grundlegende Idee ist, dass ein WSDL-Dokument alle nötigen Informationen enthält die notwendig sind, um den Webservice aufzurufen. Zum einen beschreibt WSDL die abstrakte Schnittstelle eines Webservices zum anderen die Kommunikation mit dem Webservice. So kann beispielsweise ein WSDL-Dokument genutzt werden um den Source-Code (Service-Stub) für einen Webservice-Client automatisch zu erzeugen. Apache Axis liefert einige Codegeneratoren standardmäßig mit (Apa08). Die Nutzung der Generatoren wird oft durch die GUI erleichtert, zum Beispiel gibt es einige Eclipse Plugins für die Generierung eines Axis2 Webservices oder Clients. Der WSDL-Standard ermöglicht verschiedene Nachrichtenaustauschmechanismen. So könnte beispielsweise ein Service von sich aus eine Nachricht senden, die nicht durch eine unmittelbar zuvor enthaltende Nachricht eines Clients, sondern durch ein internes Ereignis ausgelöst wurde. Die Nachrichtenaustauschmechanismen werden mit Hilfe von Message Exchange Pattern (MEP) realisiert. In WSDL1.1 gibt es beispielsweise vier festdefinierte MEPs. (1) One-Way: Der Service empfängt eine Nachricht. (2) Request-Response: Der Service empfängt eine Nachricht und sendet daraufhin eine Nachricht zurück. (3) Solicit-Response: Der Service sendet eine Nachricht und erhält daraufhin eine Nachricht zurück. (4) Notification: Der Service sendet eine Nachricht und erwartet keine Antwort (Frotscher, et al., 2007). WSDL 2.0 unterstützt beliebige MEP’s, die MEP’s müssen lediglich mit einer URI eindeutig referenziert sein, wobei die acht gebräuchlichsten MEP’S in WSDL 2.0 vordefiniert sind. Außerdem unterstützt WSDL 2.0 ähnlich wie IDL^[1] die Mehrfachvererbung, so kann ein Interface eines WSDL-Dokumentes von einem Interface eines anderen WSDL-Dokumentes abgeleitet werden. Im WSDL 2.0 Standard können im Vergleich zu WSDL 1.1 nicht nur XML-Schema Typen, sondern auch die funktionalen Schnittstellen wiederverwendet werden.

SOAP ist heute das wichtigste Kommunikationsprotokoll für Webservices. Ursprünglich stand der Name SOAP für Simple Object Access Protocol, der Name kam aus der Welt von IIOP^[2] und RMI^[3], deswegen war auch das Wort Objekt so wichtig. Ab Version 1.2 ist SOAP ein einfacher Name und kein Akronym mehr, dieser wird beibehalten, weil er die Technologie populär gemacht hat (Frotscher, et al., 2007). SOAP ist ein XML-basiertes Protokoll und besitzt deswegen eine große Interoperabilität. So kann beispielsweise ein C++ Programm unter Unix einen in Java entwickelten und auf dem Apache Tomcat unter Windows laufenden Webservice aufrufen. SOAP wird oft in Verbindung mit dem HTTP-Protokoll zusammen genutzt, das von meisten Firewalls durchgelassen wird. Jedoch ist die Nutzung mit anderen Transportprotokollen wie TCP^[4] oder SMTP^[5] möglich. SOAP besitzt einen eingebauten Fault Mechanismus, dadurch kann auf der Client-Seite genau festgestellt werden wo der Fehler entstanden ist. Ab SOAP 1.2 sind fehlerspezifische Informationen in der SOAP Nachricht selbst zu finden und nicht mehr wie bei SOAP 1.1 in HTTP-Header, so hat SOAP 1.1 zum Beispiel die Fehler durch HTTP-Status-Code 500 (Internal Server Error) beantwortet (SOA08). SOAP 1.2 beantwortet die Fehler mit einer SOAP-Nachricht in einem erfolgreichen HTTP-Response (HTTP-Status-Code 200), die die Fehlerbeschreibung in XML-Format enthält. Dadurch ist die Trennung zwischen der Transport- und Anwendungslogik viel deutlicher geworden.

Universal Description, Discovery and Integration (UDDI) (Bellwood, et al., 2003) bietet eine Schnittstelle, die es Businesspartnern und anderen Serviceanbietern ermöglicht, dynamisch die in der UDDI registrierten Webservices zu suchen und zu veröffentlichen. UDDI wurde ursprünglich von großen Firmen wie Microsoft, IBM, Ariba entwickelt. Die UDDI Spezifikation bietet eine API für die Suche und Veröffentlichung von Webservices. Die UDDI Business Registry ist eine vollständige Implementierung dieser Spezifikation und wurde ab Mai 2001 von Microsoft und IBM in Betrieb genommen (Cerami, 2002). Eine UDDI-Implementierung ist ein Webservice, deren Schnittstelle die UDDI-API Spezifikation implementiert (Fensel, et al., 2007). Die veröffentlichten Informationen in einer UDDI werden in drei Kategorien aufgeteilt:

White pages

Allgemeine Informationen über eine Firma, zum Beispiel Firmenname (business name), Beschreibung der Gewerbetätigkeit (business description), Postadresse.

Yellow pages

Enthält allgemeine Klassifikation entweder für das Angebot einer Firma oder eines Services. Zum Beispiel können hier standardisierte Codes aus der Industrie, ein Produkt oder geografische Standard Taxonomien enthalten sein.

Green pages

Enthält technische Informationen über einen Webservice, also eine Adresse für dessen Aufruf, sowie einen externen Link zur technischen Dokumentation.

(Cerami, 2002)

Die veröffentlichte Information über einen Webservice wird von dem Webservice-Anbieter erzeugt und erleichtert die Suche nach dem gewünschten Webservice.

Die UDDI hat vier Arten von Informations-Datenstrukturen (Web081): (1) businessEntity beschreibt den Webserviceanbieter, (2) businessService charakterisiert Webservices hinsichtlich des Service-Angebots, (3) bindingTemplate enthält detaillierte technische Informationen zur Nutzung des Webservices, (4) tModel ist ein generischer Container, der die detaillierten Service-Informationen enthält. Der Zusammenhang zwischen einzelnen UDDI-Datenstrukturen ist in der Abbildung 40 (siehe Anhang) veranschaulicht. UDDI war ein Misserfolg im Bereich von öffentlichen Webservices und URB wurde von großen Firmen eingestellt, nur die kleinen Firmen bieten die UDDI-Schnittstelle als Zugang für ihre Service Repository. Heute wird UDDI hauptsächlich im Intranet^[6] und Extranet^[7] verwendet (Fensel, et al., 2007). Das Hauptproblem einer UDDI ist ihre statische Struktur. Eine solche Struktur macht es unmöglich, eine schnelle Anpassung einer Anwendung an die neuen Anforderungen vorzunehmen. Außerdem basiert UDDI auf einer Textsuche und nutzt somit nicht die Vorteile der semantischen Beschreibung von Informationen. So existiert beispielsweise keine indirekte Suche, wo die Webservices basierend auf logischen Schlussfolgerungen aus bereits in der UDDI enthaltendem Wissen schlussgefolgert werden können (Cardoso, 2007).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Webservice Protokoll Stak

Derzeit gibt es zwei Methoden einen Webservice zu entwickeln. Jede dieser Methoden hat ihre Vorteile und Nachteile, einige davon sind in dem unten stehenden Zitat deutlich aufgeführt.

„Wenn man bei der Entwicklung mit XML Schema-Datentypen startet, so ist es leicht, diese auf plattformspezifische Datentypen abzubilden, da entsprechende Abbildungsregeln bereits existieren. Startet man dagegen mit plattform- oder sprachspezifischen Datentypen, so kann es passieren, dass keine standardisierte Abbildung nach XML besteht und somit andere Kommunikationspartner Schwierigkeiten haben werden, mit diesen umzugehen.“

(Frotscher, et al., 2007)(Seite 57)

Beim Code-First-Ansatz^[8] wird zuerst der Programcode implementiert und erst dann mit Hilfe eines Generierungswerkzeugs ein WSDL-Dokument dafür erstellt (Abbildung 2). So generiert beispielsweise Axis2-JavaToWSDL-Generator automatisch eine WSDL Datei für eine Java-Klasse. So ein Generator spart viel Entwicklungszeit, da er nicht nur die Operationsbeschreibung generiert, sondern auch die komplexen Java-Klassen in XML-Schema Typen abbildet. Der JavaToWSDL-Generator funktioniert leider nicht immer wie erwartet, und manchmal muss die WSDL Beschreibung per Hand angepasst oder sogar erstellt werden (Frotscher, et al., 2007) (Seite 55). Das schöne am Code-First-Ansatz ist, dass man sich um die komplexen Standards eines Webservices gar nicht kümmern muss, wie zum Beispiel die Generierung eines WSDL-Dokumentes oder Abbildung eines Java Typs in einen XML-Schema Typ. Dieser Ansatz bringt auch Vorteile, wenn die Schnittstelle von der Java-Klasse, die die Anwendungslogik für den Webservice enthält, verändert wurde. Dann kann ganz schnell ein neues WSDL-Dokument generiert und veröffentlicht werden. Das Problem dieses Ansatzes liegt in der schlechten Interoperabilität mit fremden Technologien, da jeder Webservice Generator seine eigene Methode zur Abbildung der Klassen einer Programmiersprache in die XSD-Datentypen verfolgt. Die Schärfe dieses Problems nahm etwas ab, nachdem das WS-I (Web Services Interoperability Forum) den Basic Profile, ein Richtliniendokument für die Verwendung von Webservice-Technologien, veröffentlicht hat. In der Praxis existieren bereits XML-Schemata die möglichst große Interoperabilität zwischen verschiedenen Vertragspartnern gewährleisten. Die Geschäftspartner können ihre Software gegen diesen gemeinsamen Vertrag validieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Ablaufschema beim Code-First-Ansatz (Frotscher, et al., 2007)

„Leider ist jedoch festzustellen, dass keines der vorhandenen Werkzeuge zur Erstellung von WSDL-Dokumenten frei von Fehlern ist. Dies liegt sicherlich wiederum an der Komplexität der Spezifikation und den vielen darin versteckten Stolperfallen.“

(Frotscher, et al., 2007) (Seite 60)

Eine andere Methode zum Entwicklen eines Webservices ist der Contract-First-Ansatz^[9] . Beim Contract-First-Ansatz wird zuerst die Spezifikation eines Webservices in Form eines WSDL-Dokumentes erstellt, dabei werden in das WSDL-Dokument die gemeinsam genutzten XML-Schema Typen importiert und eventuell neue definiert (Abbildung 3). Die die Operationen von Schnittstellen werden mit Hilfe dieser Typen definiert (Input, Output). Ein auf solche Weise erstelltes WSDL-Dokument sollte mit dem Analyse-Tool des WS-I auf seine Konformität mit dem Basic Profile überprüft werden, bevor aus dem WSDL-Dokument der Programmcode(Skeleton) generiert wird. Wenn die Analyse erfolgreich ist, kann mit der Implementierung des erstellten WSDL-Dokumentes fortgefahren und der Skeleton generiert werden. Die Contract-First Methode erfordert ein tieferes Verständnis von XML-Schema und WSDL-Standard sowie ein Verständnis von WS-I Basic Profiles. Leider ist die Toolunterstützung für Contract-First noch recht schlecht. Ein Entwickler steht damit der Komplexität von XML-Schema und WSDL Spezifikationen ohne ausreichende Werkzeugunterstützung gegenüber (Frotscher, et al., 2007).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Auflaufschema beim Contract-First-Ansatz (Frotscher, et al., 2007)

1.2 Webservice - Orchestrierung

„Seien es internationale Hotelreservierungssysteme mit einer Vielzahl angebundener Hotelketten und Vertriebspartner, Systeme im Finanzdienstleistungsbereich, in der Logistikbranche oder verschiedenste Stellen im öffentlichen Sektor (Behörden, Ministerien usw.) – die Einsatzgebiete sind ausgesprochen vielfältig“

(Frotscher, et al., 2007)

WS-BPEL (Web service Business Process Execution Language) (Alves, et al., 2007) existierte anfangs unter dem Namen BPEL4WS, erst später wurde es in WS-BPEL umbenannt. Diese Spezifikation ist allgemein besser als BPEL bekannt (By Sanjiva Weerawarana, 2005). BPEL ist eine Architektursprache für Webservices. Sie ermöglicht eine Orchestrierung von Webservices und somit die Erstellung von Business-Prozessen. BPEL basiert auf mehreren Standarten wie SOAP, WSDL und XML(Vasiliev, 2007). Ein BPEL Prozess enthält oft mehrere Webservices, die nacheinander oder parallel aufgerufen werden. BPEL kommuniziert mit Webservices ausschließlich über SOAP-Nachrichten. So wird ein Webservice mit Hilfe eines in dem BPEL-Prozess generierten SOAP-Request aufgerufen. Die Antwort von dem Webservice ist ein SOAP-Response. Dieser wird in der Geschäftsprozesslogik eines BPEL-Prozesses weiterverarbeitet. Ein BPEL-Prozess kann aus einem anderen BPEL-Prozess aufgerufen (Komposition, Dekomposition) oder selbst als ein Webservice veröffentlicht werden. Die Daten in einem BPEL Prozess werden in sogenannten Assign^[10] Activities manipuliert. Die meisten BPEL Variablen entstehen aus WSDL Message Typen oder importierten XML-Schema Typen. Die Verarbeitung von SOAP-Nachrichten geschieht standardmäßig mit Hilfe von XPath (Weerawarana, et al., 2005), jedoch können auch andere Technologien eingesetzt werden, wie beispielsweise XSLT-Transformation. So können beispielsweise die Daten aus einem SOAP-Request an einen BPEL-Prozess für die Generierung eines SOAP-Requests eines orchestrierten Webservices verwendet werden. Die ActiveBPEL Engine nutzt die XSLT Transformation, wodurch viele Probleme auf eine elegantere und effizientere Art und Weise gelöst werden können. So kann beispielsweise durch XSLT-Transformation die Performance gewaltig gesteigert werden. Ebenso kann die Transformationslogik geringere Komplexität als bei Verwendung von XPath haben. BPEL unterstützt die Verwendung von abstrakten und ausführbaren Prozessen, so kann eine Firma einen abstrakten Prozess, der einen ausführbaren Prozess beschreibt an seine Business Partner ausliefern. Dadurch bleibt die interne Logik eines ausführbaren Prozesses vor den Business Partnern versteckt und trotzdem können diese die Funktionsweise eines ausführbaren Prozesses nachvollziehen. Die Deklaration von zu verwendenden Webservices oder BPEL-Unterprozessen erfolgt über sogenannte Partnerlinks. Die Partnerlink Typen repräsentieren die Connectoren zu existierenden Webservices oder anderen BPEL Prozessen, über die die gesamte Kommunikation eines BPEL-Prozesses mit der Außenwelt erfolgt. Die Bindings und Ports eines Partnerlinks können zur Deployment-Zeit festgelegt werden, was einen BPEL-Prozess mehr anpassbar und portabel macht (Weerawarana, et al., 2005). Falls ein in dem BPEL-Prozess verwendeter Webservice auf einem anderen Server deployed wird, kann der BPEL-Prozess durch das Verändern des Deployment Descriptors wieder funktionstüchtig gemacht werden, da in einem statischen Deployment Descriptor die Bindings und Ports eines Partnerlink festgelegt sind. Es gibt vier Bindungsarten:

Static design time binding

Die Bindung ist ein Teil der Geschäftslogik. Diese Bindungsart ist nicht besonders flexibel.

Static deployment time binding

Die Endpoints werden zu Deployment Zeit festgelegt.

Dynamic binding using lookups

Ein Partnerlink enthält die Anforderungen, die ein Endpoint haben soll. Danach werden zur Laufzeit oder Deploymentzeit die Webservices gesucht, die diese Anforderungen erfüllen. Die Anforderungen sind zum Beispiel: Quality-of-service, transactional capabilities, enthaltene Funktionalität.

Dynamic binding using passed-in endpoints

Der Endpoint wird dem auszuführenden Prozess als eine Variable übergeben. Der Prozess nutzt diese Variable um den Endpoint zu setzen und erst dann ruft er über dieses den Webservice auf. Diese Bindungsart wird auch als Lazy Bindung bezeichnet.

Open Service Process Platform 2.0 (OSPP)(Habich, et al., 2008) ist eine neuartige Workflow Entwicklungsumgebung, die auch eine eigene Webservice Orchestrierungssprache besitzt. Im Gegensatz zu WS-BPEL hat OSPP viele technologische Vorteile. So beispielsweise bietet die OSPP das Konzept der Data-Gray-Box für Webservices, wodurch der Datentransfer zwischen Webservices viel effizienter gehandhabt wird. Ebenso ermöglicht OSPP die Prozesse zur Laufzeit zu vervollständigen. Das ist manchmal notwendig, wenn beispielsweise eine Exception des unbekannten Datentyps zur Laufzeit geworfen wird. In diesem Fall muss der Prozess um neue Logik erweitert werden damit diese Exception vermieden oder behandelt werden kann (Habich, et al., 2008). OSPP ermöglicht im Gegensatz zu einer gewöhnlichen BPEL Entwicklungsumgebung nicht nur die Erstellung der Workflow Prozesse sondern auch ihre Ausführung. Dazu kommt, dass die OSPP eine Webanwendung ist und somit von überall und jederzeit verfügbar ist. So können mehrere Nutzer die Prozesse gemeinsam erstellen oder nutzen, was wiederum eine engere Zusammenarbeit ermöglicht. OSPP kann relativ einfach mit neuen Plugins erweitert und somit an die speziellen Bedürfnisse einer Institution angepasst werden. Außerdem bietet OSPP die Repositorien für Webservices und Prozesse, sowie die Rechteverwaltung und kann als eine universelle Entwicklungsumgebung für die Erstellung von Prozessen in einer Firma genutzt werden.

1.3 Semantic Web

„ The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation.”

(Berners-Lee, 1998)

Das World Wide Web (auch kurz Web genannt) ist heute nicht mehr wegzudenken. Das Web enthält eine unvorstellbare Menge an Information, die ständig weiter wächst. Wegen der dezentralen Web Struktur ist diese Information überall in der realen Welt verteilt. Das Web ermöglicht den Zugriff auf diese Informationen aus jedem Ort und zu jeder Zeit. Die meisten Informationen liegen in nur für Menschen lesbarem Format vor und können von einer Maschine nicht automatisch analysiert werden. Das Problem von Web liegt darin, dass es mehr Informationen enthält als die Menschen verarbeiten können. Die Informationen sind jedoch erst dann nützlich, wenn diese in einer Entscheidung berücksichtig werden können. Der Einsatz von Suchmaschinen wie Google oder Yahoo leistet in der Verarbeitung solcher Informationen erstaunliche Ergebnisse. Jedoch basieren die statischen Techniken solcher Suchmaschinen auf dem Durchsuchen des Textes, dabei wird die Bedeutung des Textes nicht berücksichtigt. So beispielsweise liefert die Suche nach dem Schlüsselwort „Kohl“ die Ergebnisse nach dem Gemüse aber auch nach dem Altbundeskanzler (Hitzler, et al., 2007). Das Semantic Web wird das bestehende Web erweitern und dem Benutzer neue Suchdienste in vielen Bereichen anbieten. Die dafür nötigen Standards wie RDF(S), OWL wurden vom W3C Konsortium bereits definiert und werden ständig weiter entwickelt. Semantic Web soll die Informationen so repräsentieren, dass die Maschinen mit diesen Informationen auf eine Art und Weise umgehen können, die aus menschlicher Sicht nützlich und sinnvoll erscheint (Berners-Lee, 1998). Es ist nicht das Ziel von Semantic Web die Informationen mit Hilfe von künstlicher Intelligenz zu verarbeiten, obwohl die neuen Informationen durchaus aus existierenden mit Hilfe einer Inferenzmaschine abgeleitet werden können. Trotz starker Motivation und Versprechen die das Semantic Web macht ist es noch eine Vision und existiert nicht wirklich, weil die dafür nötigen Werkzeuge fehlen:

“Generally considered a subset of the next-generation Web technologies referred to as Web 3.0, the semantic Web doesn't really exist yet, largely because the available tools aren't up to the task.”(Claburn, 2007)

Viele Technologien, die das Semantic Web ermöglichen existieren bereits und sind reif für die Praxis, jedoch sind diese kompliziert und erfordern Fachwissen. Die meisten Informationen werden jedoch von Computernutzer erzeugt, die keine Ahnung von Prädikatenlogik und von der Softwareentwicklung haben. Diese Informationen werden oft nicht ausreichend semantisch beschrieben und können von Maschinen nicht interpretiert werden. Damit Semantic Web möglich ist, müssen die Informationen semantisch beschrieben werden.

„Um durch automatisiertes Schlussfolgern möglichst viel Information zu gewinnen, sind ausdrucksstarke Beschreibungslogiken nötig. Ist die Ausdrucksmächtigkeit jedoch zu groß gewählt, so ist die Logik nicht mehr entscheidbar. Ohne terminierende und effiziente Inferenz-Algorithmen ist eine Logik nicht für das Semantic Web geeignet. Daher müssen Logikstufen verwendet werden, die einen guten Kompromiss zwischen Ausdrucksmächtigkeit und Entscheidbarkeit darstellen“

Carsten Angeli (Bauer, 2008)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Schichtenmodel (Quelle: http://www.w3.org/2007/03/layerCake.png)

Die semantische Beschreibung wird durch das Zusammenspiel von vielen Standards ermöglicht. In der Abbildung 4 ist das vom W3C definierte Technologie Schichtenmodel abgebildet. Insgesamt gibt es sieben Schichten, die aufeinander aufbauen. Nachfolgend werden die einzelnen Schichten aus der Abbildung 4 kurz vorgestellt: URIs^[11] sind wichtig für die Kommunikation zwischen Maschinen, so können beispielsweise die Ressourcen eindeutig identifiziert werden. Zwei syntaktisch gleiche Begriffe, mit unterschiedlicher Semantik, können durch verschiedene URIs eindeutig referenziert werden. XML ermöglicht eine einheitliche Darstellung von verschiedenen Daten und verbessert somit die Interoperabilität zwischen verschiedenen Tools. Außerdem kann eine XML-Dokumentenstruktur für beliebige Anwendung leicht angepasst und erweitert werden. Das Resource Description Framework (RDF) ist eine Formale Sprache für die Beschreibung von Informationen. Mit Hilfe von RDF können Informationen im Web ausgetauscht werden, ohne dass ihre Bedeutung dabei verloren geht. Heute wird RDF in vielen Anwendungen verwendet, zum Beispiel das Format RSS 1.0 (RDF Site Summary) basiert auf RDF und ermöglicht ein Abonnement von Nachrichten (Hitzler, et al., 2007). RDF enthält Informationen in Form eines RDF-Graphen. Der Graph kann mit Hilfe von sogenannten Tripels oder Turtles beschrieben werden. Damit diese Daten auf jedem System eingelesen werden können, kann RDF auch mit Hilfe von XML ausgedrückt werden. Dabei beschreibt XML nur die Struktur von RDF, die Semantik ist in RDF-Termen enthalten. XML kann von einem beliebigen XML-Parser eingelesen werden und bietet somit eine gute Interoperabilität. In RDF gibt es nur einen einfachen Datentyp Literal, dieser repräsentiert eine Zeichenkette. In Anwendungen werden jedoch oft allgemein bekannte Datentypen benötigt. Deswegen wurde RDFS definiert, das die Verwendung von XML-Schema Typen ermöglicht, sowie die Definition und Vererbung eigener RDF-Datentypen(Klassen). RDF(S) ist zur Modellierung einfacher Ontologien geeignet und ist für die Darstellung komplexer Zusammenhänge nicht ausreichend. So lassen sich beispielsweise natürlichsprachliche Sätze nicht hinreichend genau in RDF(S) modellieren (Hitzler, et al., 2007). Die Web Ontology Language (OWL) wurde vom W3C als Ontologiesprache veröffentlicht. In der Entwicklung von OWL wurde ein Kompromiss zwischen dem effizienten Schlussfolgern und der Ausdrucksstärke einer Sprache erlangt. Normalerweise besitzen die Sprachen mit hoher Ausdruckstärke hohe Schlussfolgerungskomplexität. Es gibt drei verschiedene Teilsprachen OWL Lite, OWL DL, OWL Full (siehe Abbildung 5):

OWL Full enthält OWL DL, OWL Lite und RDFS. OWL Full ist sehr ausdrucksstark, deswegen erfordert das Schlussfolgern oft sehr viel Zeit. Manche Aspekte der Semantik sind jedoch aus logischem Blickwinkel problematisch (Hitzler, et al., 2007). OWL Full ist nicht entscheidbar und wird durch aktuelle Softwarewerkzeuge nur begrenzt unterstützt.

OWL DL (Description Logic) ist eine Teilsprache von OWL Full, sie stellt einen Kompromiss zwischen komplexen Ausdruckskonstrukten und dem effizienten Schlussfolgern dar. OWL DL ist entscheidbar und wird von den aktuellen Werkzeugen fast vollständig unterstützt. So unterstützt beispielsweise die Inferenzmaschine Pellet(pel08) vollständig die OWL DL. OWL DL hat eine Komplexität NExpTime(worst-case) was das Schlussfolgern reif für die Praxis macht.

OWL Lite ist eine Teilsprache von OWL DL und OWL Full. OWL Lite ist entscheidbar und hat eine Komplexität ExpTime(worst-case) (Hitzler, et al., 2007). OWL Lite ist besonders gut für die Erschaffung von einfachen Taxonomien geeignet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 OWL Teilsprachen

SPARQL Protocol und RDF Query Language (SPARQL) (Prud'hommeaux, et al., 2008) ist nun nach vielen Jahren endlich am 15. Januar 2008 zur endgültigen Recommendation avanciert. SPARQL hat sich in den letzten Jahren als eine geeignete Anfragesprache für RDF herauskristallisiert. Sie ermöglicht es, Anfragen durch benutzerdefinierte Kriterien zu filtern, und dadurch die Ergebnismenge einzuschränken. Eine SPARQL-Anfrage basiert auf der Idee des Pattern Matchings, so wird in einer Anfrage ein Muster beschrieben, mit dem ein RDF-Teilgraph übereinstimmen muss. Die Ergebnismenge wird aus gefundenen Teilgraphen generiert. Die SPARQL kann in die relationale Algebra^[12] übersetzt werden, wodurch viele Vorteile entstehen: (1) Die Anfragen lassen sich besser planen und optimieren, (2) Die in der relationalen Algebra entwickelten und erprobten Algorithmen können auch in der SPARQL eingesetzt werden (Hitzler, et al., 2007).

Eine Inferenzmaschine (engl. reasoner) ist ein Programm, das Inferenzregeln zum Ableiten neuen Wissens verwendet. Diese Regeln sind Bestandteil eines Kalküls, welches die Semantik für das Schlussfolgern genau beschreibt. Mit Hilfe dieser Semantik kann eine Inferenzmaschine die logischen Formeln lösen. Ob diese Formeln von einer Inferenzmaschine gelöst werden können, hängt von zwei Aspekten ab: zum Einen ob die Formel gültig ist und zum anderen ob diese erfüllt werden kann. Das Schlussfolgern (engl. reasoning) ist wichtiger Bestandteil des Semantic Web. Es gibt viele Algorithmen für das Schlussfolgern aus existierenden Fakten. Der wohl bekannteste ist der Rete-Algorithmus, der in abgewandelter Form die Grundlage für viele bekannte und sich im Einsatz befindende Expertensysteme bildet (Bauer, 2008). Eine Inferenzmaschine sollte folgende Anforderungen erfüllen:

1. Korrektheit: Eine Inferenzmaschine sollte nur gültige Aussagen ableiten
2. Vollständigkeit: Alle möglichen gültigen Aussagen ableiten
3. Entscheidbarkeit: Entscheidung über die Gültigkeit einer Aussage in endlicher Zeit
4. Effizienz: Eine effiziente Bearbeitung einer Anfrage
5. Skalierbarkeit: Inferenzmaschinen sollten mit stetig größer werdender Wissensbasis umgehen können
6. Adaptive Performance: Semantic Web ist sehr dynamisch, das neue Wissen kommt hinzu, das alte verschwindet
7. Robustheit: Inkonsistenzen wie widersprüchliche Aussagen oder nicht funktionierende Links kommen im Web oft vor. Solche Ausnahmen sollten die Funktionsfähigkeit einer Inferenzmaschine nicht beeinflussen.

(Endres, et al., 2006)

1.4 Semantic Webservices

Klassische Webservice Standards wie WSDL ermöglichen nur eine syntaktische Beschreibung eines Services. So ist es möglich zu beschreiben wie ein Service aufgerufen werden kann. Leider ist es nicht möglich mit herkömmlichen Standards zu beschreiben, was der Service macht oder in welcher Reihenfolge die Operationen aufgerufen werden sollen. Solche Beschreibungen können zwar in Textform in der UDDI gespeichert werden, jedoch sind diese nicht maschinenlesbar (Fensel, et al., 2007). Semantisch beschriebenen Webservices können nicht nur schneller gefunden werden sondern bieten viele neue Möglichkeiten an. Abbildung 7 veranschaulicht den Lifecycle eines Semantic Webservices. Er enthält fünf Schritte:

1. Advertisement:

Advertisement ist der Prozess der Veröffentlichung der semantischen Beschreibung eines Webservices in der Service Registry. Es gibt zwei Arten der Veröffentlichung eines Webservices: zum einen kann die semantische Beschreibung eines Webservices im Web veröffentlicht werden und eine Suchmaschine findet diese und trägt sie in ihre Registry ein, zum anderen registriert der Service-Anbieter selbst die veröffentlichte semantische Beschreibung in der gewünschten Service Registry.

2. Discovery:

Hier werden Webservices gesucht die den Forderungen der Suchanfrage entsprechen. Wobei hier nicht wie in einer klassischen Registry nur atomare Bausteine gesucht werden, sondern auch Prozessketten. Jeder Prozess (Composite Service) kann mehrere Semantic Services orchestrieren. Zum Beispiel Prozess-1 (Abbildung 6) orchestriert folgende Semantic Services: A, B, C. Die orchestrierten Services können wiederum Composite oder Atomic Services sein. Ein Atomic Service orchestriert im Gegensatz zum Composite Service keine weiteren Services, sonder beschreibt normalerweise eine implementierte Operation eines klassischen Webservices. Da die Workflow Prozesse (Composite Service) semantisch beschrieben sind, können diese zur Suche noch nicht explizit existierender Funktionalität herangezogen werden. So können Teile von mehreren Prozessen zu einem neuen Prozess zusammengefügt werden. Zum Beispiel sind in Abbildung 6 drei Prozesse abgebildet. Prozess-1 und Prozess-2 sind Composite Services . Nun stellt ein Nutzer eine Anfrage an die Registry, dass er einen Webservice braucht, der beispielsweise die Input-Variablen eines Atomic-Service A und die Output-Variablen des Atomic-Service D braucht. Der Such-Algorithmus durchsucht die registrierten Services und findet mehrere Möglichkeiten so einen Prozess aus bereits existierenden Prozessen durch Komposition zu erstellen. Eine Möglichkeit wäre beispielsweise durch die Ausnutzung der Verknüpfung von A nach B in dem Prozess-1 und von B nach D aus dem Prozess-2 einen neuen Prozess (Prozess-3) zu erstellen, bei dem die Prozessketten aus Prozess-1 und -2 verknüpft sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 Semantische Prozess-Suche

3. Selection:

Selection ist der Prozess der Auswahl von Webservices aus zuvor in Discovery gefundenen Webservices nach programmspezifischen Kriterien. Zum Beispiel kann der Suchalgorithmus mehrere mögliche Services finden, die den gestellten Anforderungen entsprechen. Nun wird in der Selection ausgewählt, welcher Service am besten für die Beantwortung einer Anfrage geeignet ist. Zum Beispiel, wenn der Suchalgorithmus mehrere mögliche Prozesse findet, die aus Prozessketten anderer Prozesse bestehen, könnte der Dijkstra Algorithmus verwendet werden, um den Prozess mit dem kürzesten Pfad aus allen möglichen zusammengestellten Prozessen auszuwählen.

4. Composition:

In diesem Schritt wird aus der semantischen Beschreibung eines Webservices ein ausführbarer Prozess erstellt. Zum Beispiel OWL-S Editor (The082) (ist ein Plugin für Protege) kann aktuell die Atomic Prozesse ausführen. Die Entwickler versprechen jedoch auch die Ausführung von Composite Prozessen zu implementieren: “but we aim to support composite as well as atomic processes, and users will be able to take the results returned from services and add them into the Protégé knowledge base.” (Elenius, et al.).

5. Invocation:

Der während der Composition erstellte Prozess wird ausführt.

(Cardoso, 2007)

Nach der Invocation kann nun wieder zum Advertisment übergegangen werden, denn der während der Selection gefundene Prozess könnte im Semantic Web als neue Information veröffentlicht und für weitere Suchen verwendet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 Semantic Webservice Lifecycle(Cardoso, 2007)

In (Fensel, et al., 2007) wird unter einem Semantic Webservice eine Kombination der semantischen Beschreibung von Daten und der semantischen Beschreibung von Logik verstanden. So können beispielsweise die semantisch beschriebenen Daten als Input für einen semantisch beschriebenen Webservice dienen. In dieser Arbeit wird dieses Konzept verfolgt und mit Konzepten aus der Bauinformatik zu einem akademischen Prototyp ausgebaut. In der Zukunft ist zu erwarten, dass die Semantic Webservices das Web in eine globale Infrastruktur für verteilte Systeme umwandeln und eine Grundlage für automatische Erstellung von Business Prozessen bilden werden. Semantic Web wird nicht nur ein Ort sein, wo die semantisch beschriebenen Informationen leicht gefunden werden können, sondern ein Ort wo alles global berechnet werden kann (Fensel, et al., 2007).

1.5 Semantic Webservice Registry

“The real problem with exact matching methods is that they cannot fully capture the intentional semantics of services or service requests.”

(Cardoso, 2007) (Seite 246)

Die Verbreitung von Webservices entwickelt eine eigene Dynamik. Genauso wie die Serviceanbieter auf den Markt kommen und gehen, entstehen und verschwinden die Webservices im WWW. Das hat zur Entwicklung von Technologien geführt, die auf solche Ereignisse reagieren können und sich an die neue Situation dynamisch anpassen können. Eine solche Methode stammt aus Semantic Web. Sie verwendet semantische Beschreibung von Webservices mittels Ontologien und einem darauf aufbauenden System zur Interpretation und Weiterverarbeitung von diesen (Bauer, 2008). Semantic Web bietet neue Möglichkeiten Webservices zu suchen. Viele Technologien wie RDF/OWL wurden in letzter Zeit stark weiterentwickelt und bieten zum Teil eine ausgereifte Basis für den Einsatz in der Praxis. Eine semantische Service Registry (wird im Weiteren als Service Registry bezeichnet) ist eine Implementierung des Verzeichnisdienstes aus der UDDI und entspricht den Gelben Seiten (Abbildung 8). Im Gegensatz zu Gelben Seiten aus der UDDI, die die Beschreibung eines Webservices intern abspeichert, verweist die semantische Service Registry auf die im WWW veröffentlichte semantische Beschreibung eines Webservices. Eine der Schwächen von UDDI ist die Verwendung von XML als statisches Datenmodell. XML garantiert zwar syntaktische Interoperabilität, ermöglich aber nicht die semantische Beschreibung eines Webservices. Außerdem können die Maschinen XML nicht verstehen (Srinivasan, et al., 2005). Laut (Cardoso, 2007) ist das größte Problem von UDDI, dass die Matching Algorithmen nicht vollständig die Semantik von beschriebenen Webservices verstehen können. Die Suche in einer klassischen UDDI ist syntaxbasiert und führt bei einer großen Anzahl der registrierten Webservices selten zu sinnvollen Ergebnissen. Eine semantische Suche von Webservices stützt sich auf die Verwendung von Ontologien. So werden beispielsweise Service Advertisments mit Hilfe von Ontologien erstellt. Das Service Advertisment enthält die semantische Beschreibung des Webservices, also was der Service macht, wie der Webservice aufgerufen werden kann, und wie er arbeitet (Cardoso, 2007). Die Semantische Service Registry nutzt für die Suche einen sogenannten Matchmaking Algorithmus (Suchalgorithmus, siehe Kapitel 1.8), der normalerweise mit der Service Registry fest gekoppelt ist. Der Matchmaking Algorithmus ist für die Verarbeitung von Suchanfragen (Service Request) verantwortlich. Diese semantischen Suchalgorithmen sind normalerweise viel intelligenter als ihre syntaxbasierten Vorgänger aus der UDDI. Die Suchanfragen werden von einem Service Requester gestellt, der ein beliebiges Programm sein kann. Ein Request kann in einer beliebigen Sprache formuliert werden, er soll lediglich die Anforderungen einer Anfrage enthalten. Im Idealfall ist ein Request in einer semantischen Beschreibungssprache wie OWL-DL formuliert. In der Realität wird jedoch ein Request in einer syntaxbasierten Sprache wie XML formuliert und es wird eine Abbildungsschicht benötigt, damit dieser in das für den Matchmaking Algorithmus verständliche Format überführt werden kann.

Die Qualität von Suchergebnissen ist von drei Faktoren abhängig (1) Wie gut die Serviceanbieter ihre Services beschreiben (2) Wie gut ein Such-Request formuliert ist (3) Intelligenz des Service Matchmaking Algorithmus.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 Aufbau einer semantische Service Registry (Cardoso, 2007)

In der Praxis gibt es Versuche, die klassische UDDI um semantische Suche zu erweitern. Eine mögliche Erweiterung ist zum Beispiel die Abbildung von semantisch beschriebenen Informationen in die festen UDDI-Datenstrukturen. Ein Beispiel für eine solche Architektur ist in (Srinivasan, et al., 2005) beschrieben. UDDI muss jedoch um einen zusätzlichen Port erweitert werden, damit ein externes semantisches Suchprogramm die Registry durchsuchen kann. Die Suchanfragen werden an dieses Programm gestellt und nicht an die Registry selbst. An die UDDI-Registry können weiterhin gewöhnliche klassische Suchanfragen gestellt werden. Eine UDDI-Registry verfolgt einen zentralen Ansatz, wo die Beschreibungen von registrierten Webservices in einer gemeinsamen Datenbasis (UDDI-Registry) gespeichert sind. Dem Semantic Web liegt jedoch ein dezentrales Konzept zugrunde, so werden die Informationen in einer gewaltigen über das gesamte WWW verteilten semantischen Datenbasis^[13] gespeichert. Die semantische Beschreibung eines Webservices ist auch eine Information und kann beispielsweise mit Hilfe von OWL-S erstellt sein. Das OWL-Dokument mit der semantischen Beschreibung eines Webservices kann auf einem Server veröffentlicht werden und somit das Gesamtwissen der semantischen Datenbasis um das in dem Dokument enthaltende Wissen erweitern. So kann ein Webservice-Anbieter seine Webservices semantisch in OWL-S beschreiben und diese OWL-Dokumente auf dem gleichen Server veröffentlichen, wo die Webservices installiert sind. Nun gibt es zwei Möglichkeiten diese Dokumente in der WS-Discovery einzubeziehen: (1) OWL-Dokumente werden in die Registry manuell eingetragen (2) Eine Suchmaschine durchsucht das Internet und findet OWL-Dokumente, dann trägt sie diese in die Registry ein (Jaeger, et al., 2005). Bei einem dezentralen Ansatz einer semantischen Service Registry bleibt die semantische Beschreibung eines Webservices immer aktuell

1.6 OWL-S

„Die Herausforderung im Umfeld der Service-orientierten Architekturen besteht darin, Semantik so eindeutig formulieren zu können, dass menschliche Interpretationsvorgänge verzichtbar werden, ohne Semantik zu verlieren.“

(Dostal, et al., 2004)

Web Ontology Language for Services (OWL-S) ist eine Empfehlung von W3C und wurde für die semantische Beschreibung von Webservices entwickelt (Martin, et al., 2004). OWL-S ermöglicht eine semantische Beschreibung von Webservices und bildet somit die Grundlage für die automatische Webservice Discovery, Ausführung und Komposition (Martin, et al., 2004). Ein Service wird in OWL-S mit Hilfe von ServiceProfile, ServiceModel und ServiceGrounding beschrieben(Abbildung 9):

ServiceProfile

ServiceProfile beschreibt, was ein Webservice macht. Es ist beispielsweise möglich einen Webservice anhand seiner Tätigkeit zu klassifizieren. So wurden in dieser Arbeit im ServiceProfile dem Service Kategorien hinzugefügt. Dadurch wurde der Service klassifiziert und kann später mit Hilfe von Facetten semantisch gefunden werden (siehe Anhang Abbildung 38).

ServiceModel

ServiceModel beschreibt die Funktionsweise eines Webservices. Zum Beispiel die Input-, Output Variablen, Vorbedingungen (Precondition) und Auswirkungen (Effects). Bei komplexen Prozessen werden die Prozesse selbst semantisch beschrieben und können später in automatischen Schlussfolgerungen eines Agent-Programms berücksichtigt werden (siehe Anhang Abbildung 39). Zum Beispiel kann während des Discovery-Prozesses der Abbildung 7 (Seite 19) aus zwei semantisch beschriebenen Prozessen(Prozess-1,-2) ein neues schlussgefolgert werden (Prozess-3).

ServiceGrounding

ServiceGrounding beschreibt die Informationen, die für die Kommunikation mit dem Webservice nötig sind, wie zum Beispiel die Adresse eines Webservices, welches Protokoll genutzt wird (SOAP, REST), wie die Input und Output Variablen in und aus den Nachrichten abgebildet werden. Solche Informationen sind normalerweise in einem WSDL-Dokument enthalten, deswegen ist es relativ einfach, ein Grounding für einen Atomic Prozess aus einem WSDL-Dokument zu generieren (Martin, et al., 2004). So gibt es beispielsweise in dem OWL-S Editor (Plugin für Protegé) (The082) einen WSDL-Importer, der ein Grounding automatisch aus einem WSDL-Dokument generieren kann. Für eine vollständige Definition eines Groundings sind beide Sprachen nötig OWL-S und WSDL. Die Abbildung 41 (siehe Anhang) zeigt, dass OWL-S und WSDL nicht das gleiche Konzept abdecken und nur zum Teil überlappen. WSDL nutzt XML-Schema für die Beschreibung von Input und Output Variablen, wobei OWL-S die Nutzung von OWL-Klassen ermöglicht. WSDL kann das Konzept von OWL-S nicht abdecken weil es nicht möglich ist, die Semantik von OWL-Klassen mit XML-Schema auszudrücken. Genauso kann OWL-S die Binding Informationen nicht semantisch beschreiben und verwendet dafür abstrakte Klassen, die die abstrakte Typen von in WSDL deklarierten message parts enthalten. So verlässt sich OWL-S auf das WSDL-Binding Konstrukt, die Message für eine Webservice Implementierung korrekt zu formulieren (Martin, et al., 2004). Der Prozess in OWL-S ist nicht mit einem ausführbaren Programm zu verwechseln, vielmehr ist der Prozess eine semantische Beschreibung eines ausführbaren Programms, wobei Composite Processes durchaus die Geschäftslogik eines Workflow Prozesses enthalten können (Martin, et al., 2004). OWL-S unterscheidet drei Arten von Prozessen, die in dem ServiceModel enthalten sein können: (1) Atomic Processes: Enthalten keine weiteren Unterprozesse und beschreiben normalerweise eine Operation eines implementierten Webservices. (2) Simple Prozesse: Abstrakte Prozesse, die einen bestimmten Sachverhalt beschreiben. (3) Composite Processes: Können weiteren Atomic oder Composite Prozesse enthalten. Enthalten die Geschäftslogik eines Workflow Prozesses.

[...]

^[1] IDL - Interface Definition Language

^[2] IIOP - Internet Inter-ORB Protocol

^[3] RMI - Remote Method Invocation

^[4] TCP – Transmission Control Protocol

^[5] Simple Mail Transfer Protocol

^[6] Intranet ist ein unternehmensinternes Rechnernetzwerk

^[7] Extranet ist eine Erweiterung von Intranets, es ermöglicht die Verwendung von Ressourcen von einer Gruppe externer Benutzer

^[8] Code-First-Ansatz wird auch als Top-Down-Methode bezeichnet

^[9] Contract-First-Ansatz wird auch als Buttom-Up-Methode bezeichnet

^[10] Assign (dt. zuordnen)

^[11] URI – Unified Ressource Identifier

^[12] Relationale Algebra ist eine formale abstrakte Sprache um Anfragen besser analysieren zu können

^[13] Semantische Datenbasis ist in Abschnitt 2.3 beschrieben