\chapter{Tycoon Business Conversations}



\label{feinent}



Nachdem in Kapitel \ref{tbc} das Modell der Business Conversations und

der Ablauf von Konversationen erl"autert wurde, wird in diesem Kapitel die

Implementierung der Basissysteme f"ur die Abwicklung von Konversationen

mit dem persistenten Objektsystem Tycoon vorgestellt. Das implementierte Modell

der {\em Business Conversations} wird so zu den {\em Tycoon Business

Conversations}.



\section{Ein System"uberblick}



Um das Modell der Business Conversations aus Kapitel \ref{tbc} zu

implementieren, wurden mehrere Module erstellt. Damit

zwei Systeme "uber ein Netzwerk Konversationen durchf"uhren k"onnen, brauchen

sie eine Infrastruktur, mit der sie Dialoge verschicken k"onnen, um

Informationen auszutauschen. 



Es m"ussen M"oglichkeiten geschaffen werden, um Spezifikationen von

Konversationen zu erstellen. Desweiteren m"ussen diese Spezifikationen zur

Laufzeit in Objekte umgesetzt werden.



Au"serdem m"ussen die Kommunikationspartner Konversationen starten und Regeln 

zur Behandlung von Dialogen anlegen und ausf"uhren k"onnen.



Die erstellten Module werden in der Abbildung \ref{tbcueber} im

"Ubersichtsdiagramm dargestellt. Die Module {\sl ITC\/} und {\sl ITCMessage\/} 

werden zur

Kommunikation benutzt. {\sl TBConv\/}, {\sl TBCSpec\/} und {\sl TBCContent\/}

sind die Module, mit denen

Konversationen spezifiziert und instanziiert werden k"onnen. Die Module

{\sl TBCPerformer\/} und {\sl TBCCustomer\/} werden von den

Kooperationspartnern benutzt, um

Konversationen durchzuf"uhren. Das Modul {\sl TBCMediator\/} arbeitet mit 

"ubertragenen

Dialogen und dient als Anbindung f"ur weitere Systemdienste wie zum Beispiel 

Sicherheit

oder Protokollierung.



\begin{figure}[bt]

\centerline{\epsfbox{bilder/tbcueber.eps}}

\caption{Die Modulstruktur der Tycoon Business Conversations}

\label{tbcueber}

\end{figure}



Alle Pfeile im Diagramm spiegeln die Benutzung der Module sowohl auf

Schnitt\-stel\-len\-ebene als auch auf der Ebene des Programmtextes wieder. Durch 

enge

Schnittstellen ist aber zum Beispiel die Nutzung des ITC-Moduls durch das

TBCPerformer-Modul f"ur den Nutzer der TBCPerformer-Schnittstellen transparent.



\subsection{Die Kommunikationsmodule}



Damit Anwendungen mit Hilfe der Tycoon Business Conversations kooperieren

k"onnen, mu"s in jedem Tycoon-System ein Kommunikationsmodul vorhanden und

gestartet sein.



Das System f"ur die Tycoon Business Conversations unterst"utzt 

Nebenl"aufigkeit. So soll ein Dienstleister mehrere Konversationen mit

verschiedenen

Kunden gleichzeitig f"uhren k"onnen. Au"serdem soll die Kommunikation asynchron

stattfinden. Dazu bekommt ein Kommunikationsmodul mehrere Threads, die miteinander

kooperieren m"ussen. Um dieses Ziel zu erreichen, wurde ein Basismodul zur

Kommunikation von Threads geschaffen. Die Kommunikation benutzt eine feste

Menge von Nachrichten.



Das Modul {\sl Inter Thread Communication (ITC)\/} spaltet in der {\sl

start}-Funktion zwei Threads ab. 

Der eine Thread, der an die Variable {\sl remoteReader\/} gebunden ist,

wartet auf eine Nachricht, die "uber den Unix-Socket von einem anderen Rechner

zugestellt wird. Nachdem eine Nachricht empfangen wurde, wird sie mit der Funktion

{\sl deliver(\dots)\/} an den entsprechenden Thread im Objektspeicher des

Kommunikationsmoduls zugestellt. 

Der zweite Thread, der an den Namen {\sl localITCService\/} gebunden ist, 

wartet auf eintreffende Nachrichten von anderen Threads des

Objektspeichers. Wenn eine Nachricht eintrifft, wird sie entweder dem

Mediator zugestellt, oder, falls die Nachricht schon vom Mediator behandelt

wurde, an den Empf"anger weitergeleitet. Dabei wird unterschieden, ob der

Empf"anger ein Thread im gleichen Objektspeicher oder ein Kommunikationsmodul

auf einem anderen Rechner im Netzwerk ist.



Mit {\em Ports} werden die Kommunikationspartner identifiziert. Dabei umfa"st

ein Port die Adresse des Rechners, auf dem sich der Thread befindet, einen

Namen, der jeden Thread in einem Objektspeicher eindeutig kennzeichnet und

einen Kanal zur Kommunikation mit Threads des gleichen Objektspeichers. Diese

Kan"ale wurden von der Threadsynchronisation aus einer fr"uheren Diplomarbeit

\cite{piel96} "ubernommen.



Die "Ubertragung von Nachrichten zwischen verschiedenen Rechnern st"utzt

sich auf Socket-Verbindungen und entsprechende

Tycoon-Bibliotheken, die die Kommunikation in das System integrieren 

\cite{mathi96}. 



In den folgenden Abschnitten werden Module vorgestellt, die weitere Threads 

abspalten, um ihre Funktion nebenl"aufig zu erf"ullen. Diese Threads benutzen 

das ITC-Modul, um miteinander

zu kommunizieren. Dazu befinden sie sich alle Threads in einer Schleife, die 

mit der Funktion {\sl rcv(\dots)\/} des ITC-Moduls

auf eine eintreffende Nachricht wartet, um sie nach Erhalt zu analysieren und

entsprechende Aktionen auszuf"uhren. So k"onnen Threads mit Hilfe der Funktion

{\sl send(\dots)\/} des ITC-Moduls wiederum Informationen an ihre Partner

verschicken.



Alle Nachrichten werden vor der "Ubermittlung an den Kommunikationspartner 

einem sogenannten {\em Mediator}

zugestellt. In dieser Komponente k"onnen die Nachrichten ver"andert oder

umgeleitet werden. Damit k"onnen zum Beispiel Sicherheits- oder Protokolldienste in das

System integriert werden.  



Im Mediatormodul existieren Funktionen zur An-- und Abmeldung von Diensten. 

Alle Dienste

werden in einer Liste verzeichnet. Die Dienste bekommen Priorit"aten, um eine

Reihenfolge bei der Abarbeitung festzulegen. Jeder Dienst

mu"s am Ende die Nachricht an den n"achsten Dienst delegieren. Wenn kein

weiterer Dienst mehr registriert ist, kann die Nachricht dem Empf"anger

zugestellt werden. Nachrichten k"onnen somit auch vom System

unterdr"uckt werden.



\subsection{Module f"ur Konversationen}



Konversationen bestehen nach Abschnitt \ref{Conversations} aus zwei Teilen, den

Spezifikationen und den Instanzen. Diese Unterteilung spiegelt sich auch in den

Modulen wieder. Die Implementierung der Spezifikation ist nach dem 

Objektstrukturdiagramm aus Abbildung \ref{tbcspec} vorgenommen worden.



Um eine Konversationsspezifikation zu erstellen, werden zum Beispiel

Dialogspezifikationen mit Hilfe der Funktion {\sl dialogSpec(\dots)\/} erzeugt.

Die Parameterliste der Funktion enth"alt den Dialognamen, ein Array mit

m"oglichen Anfragen und ein Array mit benannten Inhaltsspezifikationen. Die

Spezifikationen f"ur den Inhalt bestehen aus einem Tupel mit dem Namen und dem

Konstruktor f"ur einen Inhaltstyp. Neue Konversationsspezifikationen werden mit

der {\sl new(\dots)\/}-Funktion erstellt. Ihre Parameter umfassen den Namen der

Konversation, die Spezifikation des initialen Dialogs und ein Array mit allen

Dia\-log\-spe\-zi\-fikationen dieser Konversation. Die Grammatik aus Abbildung

\ref{Spec-Grammar} kann leicht auf diese Funktionen abgebildet werden.



Die Dialoginhalte werden in einem eigenen Modul behandelt. Dort sind sowohl

Funktionen zur Spezifikation von Inhalten als auch Funktionen zur Behandlung der

Instanzen vorhanden. Es existieren die Zugriffsfunktionen auf Dialoginhalte,

die im Modell in Abschnitt  \ref{conv-inst} festgelegt wurden. 

Diese Funktionen werden innerhalb der Regeln der Kunden und

Dienstleistern ben"otigt, um mit den Dialoginhalten arbeiten zu k"onnen.



Beim Zugriff auf den Inhaltstyp {\sl Sequence\/} bekommt man lediglich eine

Referenz auf die Folge. Damit sind Folgen als

Massendatentyp nicht an die Dialoge, die zwischen Kunden und Dienstleistern

"ubertragen werden, gebunden. Die Massendaten k"onnen so

ausschnittsweise Inhalt von Dialogen werden.



Die Konversationsinstanzen werden im Modul {\sl TBConv\/} verwaltet. Dort kann

mit der

Funktion {\sl new(\dots)\/} eine neue Konversation aus einer Spezifikation

erstellt werden. Dazu wird eine Tabelle mit Dialogspezifikationen angelegt.

Damit sind alle Dialogspezifikation "uber ihren Namen erreichbar. Es wird eine

leere

Historie f"ur Dialoge angelegt.



Eine Konversationsinstanz enth"alt au"serdem Funktionen, die

alte oder neue Dialogobjekte oder das aktuelle Dialogobjekt zur"uckgeben. Wenn

ein neuer Dialog

erzeugt wird, wird sein Dialoginhalt mit der Funktion {\sl create(\dots)\/}

angelegt. Er kann aus  diesen

Dialoginstanzen benutzt werden. Au"serdem ist aus 

den Dialog- und Konversationsinstanzen der Zugriff auf die Spezifikationen

der Dialoge oder Konversationen m"oglich.



Konversationen, Dialoge und Inhalte sind keine aktiven Objekte, die eigene

Threads besitzen. Sie sind an den Kunden oder Dienstleister gebunden, der sie

erzeugt hat.



\subsection{Module f"ur die Akteure}



Die beiden Akteure in einer Konversation, der Kunde und der Dienstleister,

wurden in den zwei Modulen {\sl TBCCustomer\/} und {\sl TBCPerformer\/}

implementiert. In beiden Modulen sind zwei Tupel realisiert, die die beiden

Akteure darstellen. Die Tupel werden jeweils mit der Funktion {\sl new(\dots)\/}

erzeugt und enthalten Funktionen zum Setzen der Konversationspezifikation und zur

Behandlung von Dialogen. Der Kunde hat zus"atzlich eine Funktion, um eine

Konversation zu starten.



Beide Partner m"ussen die Dialoge einer Konversation behandeln, um Informationen

auszutauschen. Der Kunde braucht f"ur jeden Dialog eine Funktion, die den

Dialoginhalt nach seinen W"unschen ver"andert und ihn mit einer Anfrage an den

Dienstleister zur"uckschickt. Diese Funktionen werden als Regeln mit der

Funktion {\sl handleDialog(\dots)\/} registriert, so da"s sie abgearbeitet

werden k"onnen, wenn der zugeh"orige Dialog eintrifft. Der Dienstleister mu"s

innerhalb einer bestimmten Konversation auf die Anfragen des Kunden reagieren

und ihm einen neuen Dialog liefern. Die Aktionen, die er beim Erzeugen eines

neuen Dialogs ausf"uhrt, registiert er mit der Funktion {\sl

transition(\dots)\/}. Dabei hat der Dienstleister sowohl Zugriff auf den Dialog,

der vom Kunden zur"uckgeschickt wurde, als auch Zugriff auf den Dialog, den er an

den Kunden ausgeliefert hatte. Innerhalb der Funktionen, die als Aktionen oder

Regeln registiert wurden, k"onnen die Akteure andere Systeme aufrufen und

benutzen.



In den Modulen ist die Technik zum Ausliefern der Dialoge und zum Aufruf

der Regeln realisiert. Beide Akteure spalten bei der Konstruktion eigene Threads

ab und sind somit nebenl"aufig zu anderen Vorg"angen. So k"onnen sich mehrere

Akteure in einem Tycoon-System befinden.



Nachdem die Threads abgespalten wurden, befinden sie sich in einer Schleife und

warten 

auf Nachrichten, die an die Akteure gerichtet sind. Die Kommunikation

zwischen den Kunden- oder Dienstleisterobjekten, die mit der Funktion {\sl

new(\dots)\/} erzeugt wurden und den Threads im Objektspeicher geht "uber die

Kommunikationsfunktionen des ITC-Moduls. Das bedeutet, da"s die Funktionen wie

zum Beispiel {\sl addSpec(\dots)\/} einen Aufruf der {\sl

send(\dots)\/}-Funktion des ITC-Moduls ausl"ost, um dem Thread eine Nachricht 

mit der neuen Konversationsspezifikation zu senden.



Das gesamte Szenario der nebenl"aufigen Threads im Objektspeicher und ihrer

Beziehungen untereinander ist in der

Abbildung \ref{tbcszene} noch einmal skizziert. Zwischen dem Kunden und dem

Dienstleister besteht eine virtuelle Verbindung zum Austausch von Dialogen.

Beide Akteure besitzen Referenzen auf die Spezifikation der Konversation und

jeder Akteur referenziert eine eigene Instanz der Konversation. Das

Kommunikationssystem h"alt "uber den Socket eine Verbindungsm"oglichkeit zu

anderen Tycoon-Systemen mit einem Kommunikationssystem. Es koordiniert die

Zustellung der Nachrichten an die entsprechenden Threads unter Ber"ucksichtigung

des Mediators.



\begin{figure}[bt]

\centerline{\epsfbox{bilder/tbcszene.eps}}

\caption{Die Threads im Objektspeicher}

\label{tbcszene}

\end{figure}



\section{Die Einbettung des WebSiteProfiler}



Der WebSiteProfiler aus Abschnitt \ref{WSP} wurde in die oben beschriebene

Implementierung der Tycoon Business Conversations integriert. Bisher bestand

das System aus einer Sammlung von Funktionen, die entsprechende Werte

zur"uckgegeben haben. Diese Funktionen m"ussen in die Dialogbehandlung

integriert werden. 



Der erste Schritt zur Integration des WebSiteProfilers in die Tycoon Business

Conversations besteht darin, eine Spezifikation der Konversation zu erstellen. 

Sie wurde bereits

im Abschnitt \ref{wsp-beispiel} vorgestellt. Die Spezifikation mu"s als Objekt

im Objektspeicher vorliegen. Im zweiten Schritt wird der WebSiteProfiler als

Dienstleister gestartet. Wenn der Thread gestartet ist und auf Nachrichten

wartet, mu"s er 

seine Konversationsspezifikation bekommen. Dazu wird die Funktion {\sl

addSpec(\dots)\/} mit der Spezifikation als Argument aufgerufen. Danach mu"s er,

auf seiner Konversationsspezifikation aufbauend, Regeln f"ur die Behandlung der

Anfragen und Dialoge bekommen.

In den

Regeln, die als {\sc Tl}-Funktionen an den Dienstleister gebunden werden,

werden jetzt an den passenden Stellen die Funktionen des WebSiteProfilers

aufgerufen.



In der Abbildung \ref{regel-beispiel} ist eine Beispiel f"ur die Regel zur

Auswertung der Anfrage {\em anmelden} des ersten Dialogs dargestellt.



\begin{figure}[bt]

\begin{sl}

\begin{tabbing}

\hspace*{1cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}

\=\hspace{0.5cm}\=\kill

\>{\k ON} anmelden Anmeldung WSP-Conversation {\k WITH} d conv {\k DO}\\

\>\>{\k let} name = d.content(''Name'')!string.get()\\

\>\>{\k let} password = d.content(''Pa"swort'')!string.get()\\

\>\>{\k let} dia = \\

\>\>\>{\k if} wsp.login(name password) {\k then}\\

\>\>\>\>conv.newDialog(''T"atigkeitswahl'')\\

\>\>\>{\k else}\\

\>\>\>\>d.content(''Nachricht'')!string.set(''Pa"swort war falsch'')\\

\>\>\>\>d\\

\>\>\>{\k end}\\

\>\>dia\\

\>{\k END}\\

\end{tabbing}



\end{sl}

\caption{Beispiel f"ur die Dienstleister-Regel zur Auswertung der Anmeldung}

\label{regel-beispiel}

\end{figure}





Nach diesen Schritten ist der WebSiteProfiler als Dienstleister im System

bereit, Anfragen von Kunden nach dem Beginn der Konversation zu behandeln.



\section{Die Nutzung durch den MultiSiteAnalyzer}



Der MultiSiteAnalyzer tritt sowohl als Dienstleister als auch als Kunde auf. Als

Dienstleister erstellt er Ranglisten "uber die Nutzung von WWW-Servern, als

Kunde erfragt er die notwendigen Daten f"ur die Ranglisten von den

WebSiteProfilern. Dieser Rollenwechsel findet innerhalb der Regeln f"ur den

Dienstleister statt. Wenn der MultiSiteAnalyzer mit der entsprechenden Anfrage

aufgefordert wird, eine Rangliste zu erstellen, erzeugt er einen neuen Kunden,

der mit der Konversationspezifikation f"ur den WebSiteProfiler versehen wird und

die entsprechenden Regeln zur Behandlung der Dialoge bekommt. Dabei wird der

Dialoginhalt gem"a"s den Vorgaben des MultiSiteAnalyzer-Kunden eingetragen.

Die Konversationen mit den WebSiteProfilern sind nebenl"aufig. Erst wenn alle als

Thread abgespaltenen Konversationen mit dem finalen Dialog beendet wurden, 

wird die Rangliste erstellt.



Abbildung \ref{msa-wsp-konv} zeigt die Integration der Konversation mit dem

WebSiteProfiler in die Konversation mit dem MultiSiteAnalyzer. Wenn sich die

Konversation des Benutzers mit dem MultiSiteAnalyzer in der Phase befindet,

in der Ranglisten erstellt werden m"ussen, tritt er in

Konversationen mit den WebSiteProfilern ein. Wenn diese Konversationen beendet

sind, k"onnen die Ergebnisse der einzelnen Konversationen in der Rangliste des

MultiSiteAnalyzers aggregiert werden. Der Benutzer des MultiSiteAnalyzers kann

sich mit der Rangliste

einen Eindruck von der Nutzungsh"aufigkeit der verglichenen WWW-Server

verschaffen.



\begin{figure}[bt]

\centerline{\epsfbox{bilder/msawspin.eps}}

\caption{Integration von MultiSiteAnalyzer und WebSiteProfilern}

\label{msa-wsp-konv}

\end{figure}



\section{Vergleich der Tycoon Business Conversations mit anderen Systemen}



In Kapitel \ref{kom-verteilteObj} wurden drei verschiedene Ans"atze f"ur

verteilte Objektsysteme vorgestellt und mit dem Tycoon-System verglichen. An

dieser Stelle werden jetzt die Tycoon Business Conversations als System f"ur

kooperative Informationsysteme mit den kommerziellen Ans"atzen verglichen.



Mit den Tycoon Business Conversations wurde ein System geschaffen, das einen

Rahmen f"ur die Kooperation verschiedener Systeme in einer

Kunde-Dienstleister-Beziehung vorgibt. Wenn ein Kooperationsmuster mit

einer Konversation modelliert ist, kann es zur Kommunikation und zur

Visualierung benutzt werden. Dies ist ein Vorteil gegen"uber CORBA und dem DCE,

weil dort die Benutzerf"uhrung von Applikationen nicht besonders 

ber"ucksichtigt wird.

Lediglich CORBA soll in Zukunft mit der Common Facility f"ur das User-Interface

(siehe Abschnitt \ref{OMA}) eine

Schnittstelle zur Programmierung der Benutzerinteraktion bereitstellen.

Ansonsten

unterst"utzen diese Systeme lediglich die Kommunikation von Applikationen.



In den Tycoon Business Conversations wird der dynamische Aspekt von

Dienstleistungen betrachtet. W"ahrend bei CORBA und dem DCE die entfernten

Dienstleistungen isoliert durch einzelne Methoden- oder Prozeduraufrufe

realisiert werden, wird in den Tycoon Business Conversations der Vor- und

Nachlauf einer Dienstleistung ebenfalls ber"ucksichtigt.



Die Schnittstellen, die mit der Interface Definition Language bei CORBA oder

dem DCE spezifiziert wurden, sind keine Objekte erster Klasse, wie es die

Spezifikationen der Tycoon Business Conversations sind. Jede Schnittstelle steht

bei CORBA oder dem DCE f"ur einzelne Dienste, die zusammenhanglos nebeneinander

stehen. In den Tycoon Business Conversations bieten die Konversationen eine

Einbettung der Dienste in eine geeignete Umgebung. Die Spezifikationen mit der

Interface Definition Language sind systemn"aher als die Spezifikationen der

Tycoon Business Conversations, die sich an der Anwendung orien\-tier\-en.



Im Vergleich mit OLE bieten die Tycoon Business Conversations den Vorteil der

klareren Strukturierung. Mit OLE k"onnen sich Applikationen auch visualisieren.

Jedoch sind die Objekte in OLE nur eine Ansammlung von Schnittstellen, die von

den anderen Kommunikationspartnern aufgerufen werden. 

Die

Konversationsspezifikation der Tycoon Business Conversations kann --- wie ein Typ

einer Programmiersprache --- vor der Benutzung daraufhin untersucht werden, ob

sie zu den

Erwartungen pa"st. Mit diesem Mechanismus wird die Wiederverwendung von

Konversationsspezifikationen unterst"utzt. Zum Beispiel kann in einer

Konversation zum Einkaufen in einem Warenhaus f"ur die Abwicklung der Bezahlung 

der Konversationsteil 

von einem Kreditinstitut benutzt werden. Das Kreditinstitut wiederum kann die

Konversation auch anderen Dienstleistern zur Verf"ugung stellen. F"ur diesen

Mechanismus wurde in Abschnitt \ref{conv-spec} das Dialogattribut {\em ellipses}

eingef"uhrt.







