home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Definition und Technologie

„Ein Webservice ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML-Artefakte definiert, beschrieben und gefunden werden können. Ein Webservice unterstützt die direkte Interaktion mit anderen Softwareagenten durch XML-basierte Nachrichten, die über Internetprotokolle ausgetauscht werden.“

Das muss man nicht sofort verstehen. Zerlegen wir diese Definition: Zum einen lesen wir (rot), dass es sich um Softwareanwendungen handelt. Beispiele wären ein DRG-Grouper, eine Anwendung zum Verwalten von Personendaten oder ein Programm, mit dem man Röntgenbilder abspeichern, suchen und anzeigen kann. Oder ein Programm zum Suchen. Google bietet seine Suche als Webservice an…

Als nächstes steht geschrieben (blau), dass diese Anwendungen über einen URI eindeutig identifiziert seien. Ein URI  ist nichts anderes als eine Zeichenfolge, die eine Ressource identifiziert, beispielsweise unser Programm. Eine bekannte Ausprägung von URIs sind die URLs , die wir täglich in unseren Browser eingeben, beispielsweise http://www.johner.org/.

Weiter lernen wir (grün), dass die Schnittstellen der Softwareanwendungen über XML-Artefakte beschrieben sind. Werfen wir einfach mal einen Blick auf ein solches XML-Dokument, das die Schnittstelle eines (stark vereinfachten) DRG-Groupers*) definiert:

*) ein DRG-Grouper ist vereinfacht gesprochen ein Programm, dem man zwei Parameter übergibt:

  1. den (genauer gesagt die) ICD-Code(s) der Diagnose(n) für einen Patienten
  2. den (genauser gesagt die) OPS-Code(s), welche die Prozeduren man dem Patienten angedeihen ließ. Z.B. Röntgenuntersuchung, Operation des Blinddarms usw.

Als Ergebnis gibt der Grouper einen DRG-Code zurück, welcher aussagt wie viel das Krankenhaus für diesen Patienten erstattet bekommt.

Die XML-Sprache, in der dieses Dokument verfasst ist, heißt WSDL: Webservice Description Language. Ein WSDL-Dokument besteht aus mehreren Teilen, die Sie jetzt kennen lernen: Zum einen gibt es einen Bereich, der sich „portType“ nennt (1). Dieser „portType“ bezeichnet die Schnittstelle der Softwareanwendung und heißt hier „Krankenhaus“. Weiter definiert der „portType“ die Funktionalität (die „Operations“), die nach außen zur Verfügung steht. In unserem Beispiel gibt es nur eine „operation“, nämlich „PatientAbrechnen“ (2). Diese Funktion erwartet eine „input message“ (3a) und eine „output message“ (3b). Offensichtlich möchte die Schnittstelle, dass man ihr etwas schickt („PatientAbrechnenRequest“), damit sie daraufhin etwas zurückschicken kann („PatientAbrechnenResponse“). Was es mit diesem Request und Response auf sich hat, steht weiter oben. So lesen wir (4), dass der „PatientAbrechnenRequest“ eine OPS und eine Diagnose erwartet und der „PatientAbrechnenResponse“ (5) einen Betrag zurückliefert. Sie sehen, dass es sich um einen sehr primitiven Grouper handelt, der nur OPS und Diagnosen berücksichtigt, nicht aber die Beatmungszeit und weitere Parameter. Welche Datentypen (z.B. Zeichenketten, Ganzzahlen, Kommazahlen, Datum) unsere Parameter Diagnose, OPS und Betrag haben, können Sie hier nicht lesen, das steht in dem eingeklappten Bereich „<wsdl:types>“ .

Wie von der der Definition gefordert (grün), beschreibt die WSDL Datei auch, wo die Softwareanwendung zu finden ist, nämlich unter http://www.johner-institut.de (5). Die Nachrichten sollen im XML-Format über Internetprotokolle ausgetauscht werden (oranger Bereich der Definition). In der eingeklappten Sektion (6) steht, dass als Protokoll http zu wählen ist und dass die XML Nachricht eine SOAP Nachricht sein soll. Schauen wir uns zum Schluss noch solche SOAP-Nachrichten an. Einmal die mit der Anfrage (Request) und die mit der Antwort (Response):

Zum Vergrößern klicken

Beide SOAP Nachrichten bestehen aus einem Umschlag, dem „Envelope“, sowie der Nutzlast im „Body“. Optional können diese Nachrichten auch einen „Header“ enthalten, in der Informationen für den oder die Empfänger stehen:

Anwendung

Sie haben bis hierher durchgehalten? Respekt! Sie fragen sich jetzt möglicherweise „und für was sind diese Webservices gut?“ Immer mehr Hersteller verfolgen das Ziel, ihre großen Anwendungen in Komponenten zu zerlegen, beispielsweise das KIS in den Grouper, das RIS, die Patientenstammdatenverwaltung usw. Hat man diese Legosteine geschaffen, lassen sich neue Anwendungen damit zusammensetzen. Die Krankenhäuser können sich aussuchen, in welcher Reihenfolge sie die Bausteine zusammen setzen. Und sie können die Legosteine von verschiedenen Herstellern kaufen (-> Best of Bread). Das klappt, wenn die Legosteine aufeinander passen. Dazu müssen diejenigen, die die gesamten Systeme zusammenstecken , die Schnittstellen dieser Bausteine kennen. Und genau die sind in der WSDL-Datei, die Sie oben kennen gelernt haben, beschrieben. Wo der Webservice betrieben wird und in welcher Programmiersprache er entwickelt ist, spielt beim Zusammensetzen keine große Rolle mehr.