3. Beispiele in der Bioinformatik

Nachdem wir jetzt wissen, was ein Web Service macht, wie er aufgebaut und implementiert ist, wollen wir natürlich noch die Anwendung in der Bioinformatik betrachten. Hierzu werden wir auf zwei Beispiele näher eingehen.
Das erste ist der XEMBL-Service vom European Bioinformatic Institute. Hier kann man durch einen Web Service Zugang zu den Daten der EMBL Datenbank bekommen, welche Nukleotidsequenzen beinhaltet.
Als zweites betrachten wir OpenBQS. Dieser Service wird vom gleichen Institut zur Verfügung gestellt, bietet jedoch den Zugang zu Publikationen aus den Lebenswissenschaften.

Außerdem wird noch über die Beispiele von Web Services, die direkt auf bestimmten Datenbanken arbeiten, hinaus, OmniGene vorgestellt. OmniGene bietet eine Middleware an, die eine einheitliche Schnittstelle zu verschiedenen Datenquellen inkl. Bio-Datenbanken darstellt.

3.1 XEMBL

Als erstes Beispiel betrachten wir den XEMBL Service vom European Bioinformatics Institute. Dieser Service [XE02] bietet vollständigen Zugriff auf die EMBL Nukleotidsequenz-Datenbank an. Diese Datenbank beinhaltet derzeit über 23 Millionen Einträge, die insgesamt fast 35,5 Milliarden Basen (Stand: 15. Januar 2003) enthalten. Außerdem wird der Zugang zu kompletten Genomen ermöglicht, wie dem des Menschen oder der Fruchtfliege.

Der Zugang ist über zwei Methoden möglich. Bei der ersten Schnittstelle spezifiziert der Benutzer die Parameter innerhalb einer URL. XEMBL gibt als Ergebnis ein komplettes XML-Dokument zurück.
Als zweites gibt es eine SOAP-Schnittstelle. Dabei werden die Parameter, wie wir das in Abschnitt 2.3.2 gesehen haben, in den SOAP-Nachrichten spezifiziert. Das XML-Dokument befindet sich in diesem Fall in der SOAP-Antwort, die XEMBL sendet.
Wenn man sich die WSDL-Datei (http://www.ebi.ac.uk/xembl/XEMBL.wsdl) in Abbildung 3.1 anschaut, findet man folgende Informationen.

Es werden zwei Nachrichten-Elemente definiert. Die Nachricht getNucSeqRequest, erwartet als Eingabe zwei Parameter: format und ids, welches beides Zeichenketten sind. In der dazugehörigen Dokumentation erfährt man, dass format das Ergebnisformat festlegt und die Werte Bsml und sciobj annehmen kann. Zu ids wird gesagt, dass dies die international Nucleotide Sequence accession numbers sein soll. Die Nachricht getNucSeqResponse, gibt enthält eine Zeichenkette in XML.
Benutzt werden diese Elemente in der Operation getNucSeq, wobei getNucSeqRequest die Anfrage und getNucSeqResponse die Antwort darstellt. Die Operation, so wird in der WSDL-Datei dokumentiert, liefert zu einer angegeben ids Informationen wie z.B. die Sequenz selber, Querreferenzen, Taxonomie, Literatur.

Aus dem Ergebnis-XML-Dokument kann der Benutzer sich die gewünschten Informationen herausfiltern. Hilfreich sind dabei Kenntnisse über Bsml XML bzw. Agave XML, in denen das Ergebnis formatiert ist.

3.2 OpenBQS

Das zweite Beispiel ist OpenBQS, was für Open Bibliographic Query System steht, welches auch vom European Bioinformatic Institute entwickelt wurde.
OpenBQS [SN02] erlaubt den Zugriff zu einer Sammlung von Publikationen aus den Lebenswissenschaften, an die man Anfragen stellen und die man durchsuchen kann. Momentan beinhaltet die Sammlung Zugang zu MEDLINE-Daten. Zukünftig sollen auch andere Publikationssammlungen dazukommen.

Auch BQS unterstützt verschiedene Optionen, um auf die Daten zuzugreifen.
Zum einen CORBA, was für Common Object Request Broker Architecture steht.
Zum anderen gibt es auch hier einen Web Service mit der Verwendung von SOAP und WSDL. Im Gegensatz zu XEMBL wird jedoch eine größere Anzahl von Operationen angeboten, nämlich über 30. Diese werden in der WSDL-Datei >http://industry.ebi.ac.uk/openBQS/copies/BQSWebService.wsdl auf fast 20 Seiten beschrieben. Im Folgenden werden sie kurz vorgestellt.

• find: Bei dieser Operation wird eine Sammlung kreiert, welche die gegebenen Schlüsselwörter enthält. Zwischen den Schlüsselwörtern wird ein logisches UND angewendet. Der Rückgabewert ist eine Collection-ID, welche die neue Sammlung repräsentiert. Diese ID kann im nächsten find wiederverwendet werden, um die Suche weiter zu verfeinern. Für diese Methode gibt es verschiedene Operationen, je nachdem, ob man eine Collection-ID mit angibt oder nicht, bestimmte Kriterien genannt werden oder die Suche auf bestimmten Attributen stattfinden soll.

• query: Im Gegensatz zu find, wird hier die Suche statt durch Schlüsselwörter durch eine Zeichenkette, die eine Anfrage darstellt, spezifiziert. Dabei ist es abhängig von der Implementation des Servers, welche Anfragesprachen unterstützt werden. Um ein Interoperabilität zwischen verschiedenen Servern zu erreichen, gibt es einen Vorschlag zur Benutzung von Anfragesprachen unter http://industry.ebi.ac.uk/openBQS/Specification_BQS.html.
  Auch hier gibt es wieder verschieden Operationen, die von den verschiedenen Eingabenparametern abhängen.

Diese Operationen liefern eine oder mehrere Publikationen als binären Strom zurück. Die meisten benötigen zuerst eine Anfragesammlung, die man durch eine Anfrageoperation erstellt hat. Man kann also nicht auf die gesamte Bibliothek auf einmal zugreifen.

• getByID: Hier wird die Publikation geliefert, deren ID man angegeben hat.

• resetRetrieval: Der Retrieval-Iterator wird auf den Anfang oder an eine bestimmte Stelle auf die darunter liegende Sammlung gesetzt.

• getNext: Es wird die Publikation von einer Sammlung zurückgegeben und eine neue Collection-ID angegeben.

• weitere sind: getMore,hasMore, getAllIDs, getAllBibRefs

• getRefsCount: Es wird die Anzahl der Publikationen in einer Sammlung geliefert.

• exists: Hiermit kann man prüfen, ob eine gegebene Sammlung noch existiert.

• destroy: Dies sendet eine Nachricht an den Servern, dass alle Ressourcen, die mit der gegeben Sammlung etwas zu tun haben, freigegeben werden können.

So genannte controlled vocabularies sind Sammlungen von Begriffen, die zur Benennung bestimmter Dinge verwendet werden sollen. Sie beinhalten unter anderem Listen von verfügbaren Ressourcentypen, wie z.B. Journale und Bücher, von Teilmengen des Bestandes, von für jeden Ressourcetyp bekannte Attribute, von Suchkriterien und einigen anderen Dingen.
Um auch hier möglichst eine Gleichheit beim Erstellen und Verwenden der Begriffe zu erreichen, gibt es in der BQS-Spezifikation detaillierte Beschreibungen.

• unterstützte Methoden: getAllVocabularyNames, contains, getEntryDescription, getAllValues, getAllEntries

Um den Umgang mit all diesen Operationen zu vereinfachen, kann man sich von der BQS-Homepage unter anderem einen SOAP Perl Client und einen SOAP Java Client runterladen. Diese nehmen dann Anfragen entgegen, erstellen und versenden den SOAP-Request. Die SOAP-Response kann dann z.B. in ein Java Datenmodell übersetzt werden oder auch nur einfach der XML-Teil herausgefiltert werden.

In Zukunft will BQS weitere Clients zur Verfügung stellen, den Umgang mit ungewöhnlichen Zeichen wie Umlauten verbessern und auch andere Sammlungen von Publikationen unterstützen.

3.3 OmniGene

Bisher haben wir die Vorteile von Web Services genannt. Die sind unter anderem die Flexibilität im Umgang mit den Daten, die Unabhängigkeit von der Plattform, Datenbankschemas und der verwendeten Programmiersprache.
Jede Entwicklung hat jedoch zwei Seiten. So gibt es auch hier Nachteile.
Viele Benutzer erstellen sich gleich mehrere Skripte, um einen Web Service regelmäßig und effizient nutzen zu können. Ein Skript ist zum Auswerten der WSDL-Datei, eines zum Umgang mit Request und Response, ein weiteres zum Speichern der Daten in die Datenbank und vielleicht noch ein viertes, um diesen Prozess jede Woche zu wiederholen. Das muss für jeden Web Service gemacht werden und sobald das Interface verändert wird, ist ein Teil der Skripte nicht mehr nutzbar. Außerdem entstehen durch die Komplexität und die Vielzahl der zugrundeliegenden Protokolle und Formate ein hoher Zeitaufwand und damit Kosten für die Softwareentwicklung. Deswegen wird diese Technologie auch nur bedingt eingesetzt.
Mehrere Datenbanken bieten auf ihrer Homepage die Möglichkeit eine Suche auszuführen. Für jede Suche müssen dann die Seite geladen und die Ergebnisse kopiert und bearbeitet werden.

Mit der Problematik der verschiedenen Datenquellen und Möglichkeiten hat sich das OmniGene-Team [OM02] auseinandergesetzt und bietet als Lösung eine Middleware an. Diese erlaubt einen transparenten Zugang zu den unterschiedlichen Datenbeständen und Services. Darunter sind Ensembl (Genomische Daten), Swissprot (Proteomische Daten) und Pubmed (Publikationen). Die Middleware soll eine einheitliche Sicht auf all diese Services sein.
Die Umsetzung erfolgt durch die Benutzung von J2EE und der Web-Service-Architektur. OmniGene benutzt Enterprise Java Beans, um auf die Datenbank zuzugreifen; DAS, um ein einheitliches Protokoll zur Befragen bzw. zur Rückgabe der Daten zu haben, SOAP als Transportschicht und UDDI als Registrierungsverzeichnis der Services.

In Abbildung 3.2 ist die Architektur des OmniGene Systems dargestellt, die im Folgenden kurz erklärt wird.
Links befindet sich das Peer-To-Peer-Netzwerk, in welchem sich die Nutzer befinden. Er benutzt Viewers von OmniGene, um mit der Middleware umzugehen. Diese kann man auf der Homepage bekommen. Rechts sind die unterschiedlichen Datenquellen dargestellt: Datenbanken, Dateien, Web Services und HTML-Seiten.
Dazwischen befinden sich die Service-Schicht und die Framework-Schicht, welche die Elemente von OmniGene darstellen. In der Framework-Schicht befindet sich der eigentliche Web Service, werden die Anfragen der Nutzer analysiert und so umgeformt, dass sie an die verschiedenen Quellen gerichtet werden können. Die Service-Schicht basiert auf dem Framework und ist die eigentliche Schnittstelle zum Benutzer.
Leider ist die Homepage von OmniGene nicht so ausführlich, als dass sich die Schichten besser erklären lassen. Aber vielleicht ändert sich das in naher Zukunft.


Abbildung 3.2 OmniGene System Architecture [OM02]