Die Anforderungen eines x an einen Dienst k"onnen vielf"altig sein. \dots

Ein Kriterium bei der Auswahl ist sicherlich der Typ des Dienstes, der
allerdings um eine Menge von Dienstattributen erweitert werden m"u"ste, die
evtl. "uber die Lebensdauer des Dienstes nicht konstant sind. Um die Menge der
m"oglichen Dienste nicht durch ein enges Attributierungs-Schema zu begrenzen,
bietet es sich an, "ahnlich den Diensttypen beliebige Attribut-Typen
zuzulassen, die ebenfalls "uber die dynamische Typ"uberpr"ufung verglichen
werden. 

\begin{center}
{\tt Dyn Attributes \subtype Ok}
\end{center}

Beispiele sind

\begin{center}
\begin{minipage}{4cm}
\begin{verbatim}
Attributes = Tuple
  cost     :Real
  currency :Currency
end
\end{verbatim}
\end{minipage}
\end{center}
f"ur einen kostenpflichtigen Dienst oder
\begin{center}
{\tt Attributes = String}
\end{center}
um eindeutige Benennung zu benutzen.

Sind f"ur einen Dienst Typ und Attribut-Typ passend zur Anfrage eines
, d.h. stehen in Subtypbeziehung, kann die Anforderung des  an die
Attribute des Dienstes verglichen werden. z.B.

\begin{center}
{\tt attribute.cost < 4}
\end{center}

f"ur den oben beschriebenen kostenpflichtigen Dienst.

Dynamische Attribute lassen sich einfach dadurch realisieren, da"s das
initiale Protokoll zwischen  und  das in Kapitel  zur
Typ"uberpr"ufung diente, um den Austausch des Attribut-Typs und einer
Attribut-Bedingung erweitert wird. Da in Tycoon Funktionen Werte erster Klasse
sind, kann die Bedingung einfach als beliebige Funktion "uber den Attributwert
mit booleschem Ergebnis formuliert werden.

\begin{center}
{\tt condition(:Attributes) :Bool}
\end{center}

F"ur das Beispielszenario, k"onnte man die Bedingung wie folgt formulieren

\begin{verbatim}
let condition(attribute :Attributes) = 
  if attributes.currency=DM then 
    attribute.cost < 4
  else
    false
  end
\end{verbatim}

um einen Dienst zu erhalten, der in Deutscher Mark abgerechnet wird und nicht
mehr als 4 DM kostet.

Nach der strukturellen Auswahl durch Diensttyp und Attribut-Typ, die
Typsicherheit der Bindung respektive Anwendbarkeit der Attribut-Pr"adikate
sicherstellen, kann durch den eine beliebige boolesche Funktion "uber den
Attribut-Typ "ubergeben werden, anhand derer ein Dienst ausgew"ahlt werden
kann. Konkret bedeutet dies f"ur die Implementierung, da"s auf alle Dienste,
die zu Diensttyp und Attribut-Typ passen, die Auswahlfunktion angewendet
wird. Aus den Diensten, die diese Funktion erf"ullen, wird beliebig einer
ausgew"ahlt und im  gebunden.

Tycoon: \cite{RMS95}


\section{Persistente Bindungen an entfernte Objekte}
\label{PersistenteBindungen}
Die in Abschnitt  angerissene Benutzung des Mapping Daemons,
zeigt, wie f"ur die Bindung eines Dienstes 

\begin{center}
  {\tt let svc = client.bind(:DienstType  :Attributes  condition  1)}
\end{center}

dessen Identifikator erhalten werden kann. Die nachfolgende Abbildung auf eine
konkrete Netzwerkadresse scheint an dieser Stelle trivial, da ja die lokale
Komponente und damit der Rechner, auf dem der Dienst angeboten wird, bekannt
ist. Dabei wird aber von einer zeitlichen N"ahe dieser beiden Anfragen
ausgegangen, die f"ur langlebige Prozesse wir in Tycoon nicht gilt
\cite{***wennsgeht}. Bei der Bindung wird hier aber mit der gleichen Suchtiefe
auch die Aufl"osung der Adresse angefordert.

\begin{center}
  {\tt let p :port.T = mad.translate(sid  1)}
\end{center}

Danach kann bis zu einem Fehlerfall der entfernte Dienst direkt mit der
konkreten Netzwerkadresse, also wie in Kapitel \ref{portCS}, benutzt
werden. Im Fehlerfall mu"s im \dn{} eine neue Abbildung auf die konkrete
Adresse erreicht werden.

In der Tycoon-Client/Server-Bibliothek ist auch eine Standardfunktion
enthalten, die zu einem Dienstidentifikator einen Standort im Netz solange
sucht, bis er aufgefunden wurde im Sinne voller Persistenz der Bindung. Diese
Funktion ist jedoch nicht Bestandteil des Moduls, das \dn{} generiert.

Genau wie die Attribute ist auch das Standort-Wechsel-Verhalten
dienstabh"angig. Das Szenario, da"s ein Dienst an einem Ort abbricht und
wieder neu gestartet wird bzw. im gleichen lokalen Netz auf einem anderen
Rechner wieder anl"auft, mag typisch sein, es kann aber nicht davon ausgegangen
werden, da"s dies f"ur alle Arten von Diensten sinnvoll ist. Es sind auch
Dienste denkbar, die an eine Person gebunden sind, die tags"uber im lokalen
Netz einer Abteilung arbeitet und nachts in einer Netz-Domain zum externen
Einw"ahlen erreichbar ist. Dabei ist dann ein Suchen im lokalen Netz nie
sinnvoll, sondern bei der Suche sind nur zwei konkrete Standorte zu
ber"ucksichtigen, wenn keine unn"otige Netzbelastung bewirkt werden soll.

Zu einem Dienst kann eine Suchfunktion definiert werden, die auf die Art des
Dienstes zugeschnitten ist oder die oben beschriebene Standard-Suchfunktion
eingesetzt werden (Abbildung \ref{SearchFun}). Damit wird in Tycoon eine
persistente Bindung von Netzdiensten angeboten aber dar"uber hinaus ergibt
sich ein generischen Bindungsverhalten, das von jeweiligen Dienst abh"angig
sein kann. Die Suchfunktion wird bei Bindung des Dienstes von \de{} in den
\dn{} kopiert und steht dort lokal zur Verf"ugung. Sie ist damit auch ein
weiteres Beispiel f"ur Code-Mobilit"at zwischen Tycoon-Systemen.

\begin{figure}[htb]
  \begin{verbatim}
let searchFun(S <:Dienst  s :sid.T(S)  var at :port.T) :Ok begin
  try
    let madOfOldSite :port.T = tuple
                                  madDienst.portNumber
                                  oldLocation.host
                                end
    (*trying to find Dienst at old host *)
    let m = portClient.bind(madOfOldSite  :madDienst.T 
                            madDienst.tRep  madDienst.name)
    at := m.translate(s  0)
  end
  while at.portNumber == ~1 do
    (* searching Dienst in LAN *)
    try
      let m = madDienst.bind()
      at := m.translate(s 1)
    end (* try *)
  end (* while *)
end (* searchFun() *)\end{verbatim}
  \caption{Standard-Suchfunktion in Server-Modul}
  \label{SearchFun}
\end{figure}

Die dienstabh"angigen Suchfunktionen behandeln auf dieser Ebene (Module {\tt
  client} und {\tt server}) auch einen Teil der Frage der
Aufrufsemantik. Abgesehen von Netzwerkfehlern, nachdem ein Dienst (wieder)
aufgefunden wurde, kann je nach Standort-Wechsel oder Aufall jede der
in  Abschnitt \ref{rpc} dargestellten M"oglichkeiten abgebildet werden.
Aus Effizienz-Gr"unden ist aber festgelegt, da"s zun"achst an der letzten
erfolgreichen konkreten Netzwerk-Adresse ein Aufruf-Versuch unternommen wird.

Zum Abschlu"s soll dann das Suchszenario mit den dynamischen Attributen
zusammengef"uhrt werden. Die Dienstbindung stellt ja nur einen Spezialfall der
Suche dar, bei der der konkrete Dienst noch nicht bekannt ist. Statt des
Identifikators wird daher eine Typbeschreibung und Anforderungen an weitere
Attribute des Dienstes "ubergeben. 

Genau wie die Suchfunktion bei der Bindung
auf die \dn{}-Seite "ubertragen werden mu"s, migriert der Code der
Attribut-Bedingung in den lokalen Mapping Daemon und evtl., wenn die Anfrage
lokal nicht befriedigt werden kann, "uber den LAN-Daemon in weitere Mapping
Daemons im Netz. Dort kann die Funktion nur angewendet werden, wenn die
vorhandenen \de{} die aktuellen Attributwerte der Dienste angeben (Abbildung
\ref{searching}). Die dazu notwendige Kontaktierung aller Dienste, die
Typkompatibel mit der Anfrage sind, stellt jedoch keinen gro"sen zus"atzlichen
Aufwand dar, da die Verf"ugbarkeit eines Dienstes ohnehin "uberpr"uft werden
mu"s, bevor seine Existenz mit herausgabe eines Dienstidentifikators
best"atigt wird. Die Nachfrage der Attribute oder der reinen Existenz vom
Standpunkt der Netzkommunikation nahezu gleichwertig, es sein denn, die
Bewertung der Attribute ist f"ur den Dienst eine aufwendige Funktion, was eine
dynamische Bewertung dann aber wohl ohnehin erfordern w"urde.

%*****************************************

\section{Dienstauswahl}


Ein Kriterium bei der Auswahl ist sicherlich der Typ des Dienstes, der
allerdings um eine Menge von Dienstattributen erweitert werden m"u"ste, die
evtl. "uber die Lebensdauer des Dienstes nicht konstant sind. Um die Menge der
m"oglichen Dienste nicht durch ein enges Attributierungs-Schema zu begrenzen,
bietet es sich an, "ahnlich den Diensttypen beliebige Attribut-Typen
zuzulassen, die ebenfalls "uber die dynamische Typ"uberpr"ufung verglichen
werden. 

\begin{center}
{\tt Dyn Attributes \subtype Ok}
\end{center}

Beispiele sind

\begin{center}
\begin{minipage}{5cm}
\begin{verbatim}
Attributes = Tuple
  cost     :Real
  currency :Currency
end
\end{verbatim}
\end{minipage}
\end{center}
f"ur einen kostenpflichtigen Dienst oder
\begin{center}
{\tt Attributes = String}
\end{center}
um eindeutige Benennung zu benutzen.

Sind f"ur einen Dienst Typ und Attribut-Typ passend zur Anfrage eines
\dn, d.h. stehen in Subtypbeziehung, kann die Anforderung des \dn{} an die
Attribute des Dienstes verglichen werden. z.B.

\begin{center}
{\tt attribute.cost < 4}
\end{center}

f"ur den oben beschriebenen kostenpflichtigen Dienst.

Dynamische Attribute lassen sich einfach dadurch realisieren, da"s das
initiale Protokoll zwischen \de{} und \dn, das in Kapitel \ref{portCS} zur
Typ"uberpr"ufung diente, um den Austausch des Attribut-Typs und einer
Attribut-Bedingung erweitert wird. Da in Tycoon Funktionen Werte erster Klasse
sind, kann die Bedingung einfach als beliebige Funktion "uber den Attributwert
mit booleschem Ergebnis formuliert werden.

\begin{center}
{\tt condition(:Attributes) :Bool}
\end{center}

F"ur das Beispielszenario, k"onnte man die Bedingung wie folgt formulieren

\begin{verbatim}
let condition(attribute :Attributes) = 
  if attributes.currency=DM then 
    attribute.cost < 4
  else
    false
  end
\end{verbatim}

um einen Dienst zu erhalten, der in Deutscher Mark abgerechnet wird und nicht
mehr als 4 DM kostet.

Auf der Seite des \de{} k"onnte man die Attribute konstant bei der Anmeldung
des Dienstes angeben.

\begin{center}
{\tt let r = server.register(\dots :Attributes tuple DM 3.5 end \dots )}
\end{center}

Die geforderte Ver"anderbarkeit der Attribute ergibt sich durch die Angabe
einer Funktion,

\begin{center}
{\tt let r = server.register(\dots :Attributes attributes \dots )}
\end{center}

die im \de{} bei jeder neuen Anfrage bewertet werden kann. z.B. w"urde man mit

\begin{verbatim}
let attributes() :Attributes = begin
  let t = time.format(time.now())
  if t.hours > 8 /\ t.hours < 18 then
    tuple
      DM
      4
    end
  else
    tuple
      DM
      2.5
    end
  end (* if *)
end (* attributes() *)
\end{verbatim}

einen Dienst erhalten, der zu angenommenen Schwerpunktzeiten tags"uber teurer
ist, als zur "ubrigen Zeit.

Nach der strukturellen Auswahl durch Dienst-Typ und Attribut-Typ, die
Typsicherheit der Bindung respektive Anwendbarkeit der Attribut-Pr"adikate
sicherstellen, kann durch den \dn{} eine beliebige boolesche Funktion "uber den
Attribut-Typ "ubergeben werden, anhand derer ein Dienst ausgew"ahlt werden
kann. Konkret bedeutet dies f"ur die Implementierung, da"s auf alle Dienste,
die zu Dienst-Typ und Attribut-Typ passen, die Auswahlfunktion angewendet
wird. Aus den Diensten, die diese Funktion erf"ullen, wird beliebig einer
ausgew"ahlt und im \dn{} gebunden.


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "da"
%%% End: 
