XML-‐basierte Kommunikation im IHE - Institute of Health ...
XML-‐basierte Kommunikation im IHE - Institute of Health ... XML-‐basierte Kommunikation im IHE - Institute of Health ...
5. Diskussion anfragen-‐Editor erlaubt somit die flexible Erstellung der Suchanfragen. Es ist jedoch un-‐ klar, in wie weit der Benutzer in der Praxis sich selbst Suchanfragen zusammenstellen möchte bzw. ob er nicht eher auf die vorgefertigten Suchen bzw. Suchschablonen zurück-‐ greift. Die Erstellung einer freien Suche ist mit mehr Zeit verbunden, was unter Umstän-‐ den zu einer Inakzeptanz führen kann. Speziell zu Beginn verlangt es einige Übung, bis eine freie Suchanfrage schnell erstellt werden kann. Das Schnittstellenkonzept erlaubt durch seine flexible Kommunikation über proprietäre XML-‐Nachrichten eine einfache Anbindung an andere Akteure. Möchte ein neuer ATR-‐ Akteur (z.B. mit Archetypen zur Krankheit Leukämie) an den Document Consumer binden, muss dieser nur eine der Spezifikation entsprechenden XML-‐Nachricht erzeugen können. Dasselbe gilt für den Document Crawler Akteur: werden mehrere Crawler-‐Akteure in ei-‐ nem System integriert (z.B. pro Repository ein Crawler), muss der jeweilige Crawler nur eine valide (der Spezifikation entsprechende) XML-‐Query empfangen können. Die Schnitt-‐ stellen binden somit nicht fix an die Akteure, sondern können flexibel verwendet werden. 5.2.2 Zu Teilziel 2: Implementierung der Schnittstellen Allgemein werden intern im Document Consumer ausschließlich JAVA-‐Objekte für die Modellierung bzw. Verarbeitung einer Suchanfrage verwendet. Somit müssen intern keine komplizierten Transformationen aus XML-‐Daten stattfinden. Das Einlesen der Infoitem-‐ XML wird beim Start einmal durchgeführt, anschließend wird nur mehr mit der erstellten Node-‐Struktur gearbeitet. Die Implementierung der ATR Schnittstelle (Node-‐Klasse) ist in der Lage, alle Infoitems als strukturiertes XML-‐Dokument aus einem ATR anzufordern und diese in eine Node-‐ Struktur zu parsen. Der rekursive Ansatz beim Einlesen der Infoitem-‐XML erlaubt eine dynamischere Erstellung der internen Objekte. Zum Parsen hätte auch ein reiner DOM-‐ Parser verwendet werden können, welcher die komplette Node-‐Struktur in einem Schritt als Baumstruktur integriert. Mit dem sequentiell rekursivem Parsen kann jedoch schon beim Einlesen entschieden werden, wie die Daten in den Objekten differenziert gespei-‐ chert werden sollen. So können zum Beispiel die Datentypen eines Infoitems schon beim Einlesen in ein DataContainer-‐Objekt verpackt werden, um die Information später effizien-‐ ter nutzen zu können. Diese effiziente Speicherung wird bei der Erstellung einer Suchan-‐ frage ausgenutzt. Da eine Suchanfrage im Grunde aus „Teilbäumen“ der ursprünglichen Node-‐Struktur besteht, beinhalten die Objekte bereits einen Großteil der nötigen Informa-‐ tionen für der Suche. Auswahlmöglichkeiten, Datentypen, Einheiten, etc. sind somit schon 66
5. Diskussion aus dem ATR direkt im Node-‐Objekt vorhanden und können für die Parametrisierung ei-‐ nes Infoitems übernommen werden. Für die Suchanfrage muss dann nur noch die Ver-‐ knüpfung der gewählten Infoitems untereinander und die Werteeinschränkung einzelner Infoitems vom Benutzer definiert werden. Die gesammelt (in jedem Node-‐Objekt) gespei-‐ cherte Information erlaubt dann eine einfache Erstellung der XML-‐Suchanfrage: Da aus jedem Node-‐Objekt in der SearchQuery ein „TUPLE“ in der XML-‐Ausgabe erstellt wird, kann JDOM alle nötigen Variablen (ItemCode, Unit, Operator, Value) für die Erstellung oh-‐ ne zusätzlichen Aufwand direkt aus dem jeweiligen Node-‐Objekt beziehen. Eine Schwäche der ATR Schnittstelle könnte die Inflexibilität in Betracht auf Erweiterun-‐ gen bzw. Änderungen des ATR sein. Wird die Struktur des Infoitem-‐XML aus dem ATR erweitert oder geändert, so muss auch die Schnittstelle im Document Crawler diesen Än-‐ derungen angepasst werden. Entscheidet man sich zum Beispiel neben Deutsch und Eng-‐ lisch eine weitere Sprache zu integrieren und fügt diese als weiteres Sprachenlabel im ATR ein, so muss die Schnittstelle so umgebaut werden, dass auch die neue Sprache in der No-‐ de-‐Struktur eingelesen und gespeichert wird. Da die Implementierung der SearchQuery-‐Klasse auf dem Suchanfragen-‐Editor aufbaut, lassen sich die Vor-‐ und Nachteile des Editors auch in der Implementierung im Back-‐End erkennen. Die bisherige Lösung des Suchanfragen-‐Editors ist nicht sehr benutzerfreund-‐ lich: Die Erstellung einer Suchanfrage sollte für den Benutzer flexibel sein. Die Implemen-‐ tierung erlaubt jedoch durch den „Cursor“ nur das Einfügen eines Elementes an einer Posi-‐ tion, d.h. der Benutzer kann nicht frei wählen, wo in der Suchanfrage das nächste Infoitem hinzugefügt wird. Eine Lösung wäre hier eine benutzerfreundliche grafische Bedienober-‐ fläche, welche das Editorkonzept besser umsetzt. In der aktuellen Umsetzung des Editors fehlen weiters grundlegende Funktionen, um damit in der Praxis arbeiten zu können. Zum Beispiel das Löschen eines geklammerten Bereichs (einer Ebene) ist im aktuellen Prototy-‐ pen noch nicht möglich. Aus diesen Gründen wurde die Editorfunktion für den folgenden Projektschritt (Evaluation der Implementierung) auf eine Funktion reduziert: Der Benut-‐ zer des Document Consumers kann in freien Suche nur nach einem beliebigen Infoitem suchen, welches er jedoch parametrisieren kann (Kurzabfrage). Die SearchQuery-‐Klasse baut dennoch auf dem Editorkonzept auf und unterstützt eine frei erstellte Suche auch weiterhin. Die interne Speicherung der XML-‐Information in Node-‐ Objekten erlaubt eine flexible bzw. programmiertechnisch einfache Verwendung für eine Suchanfrage. Diese Kriterien sind wichtig für die Erstellung einer freien Suche: Eine kom-‐ 67
- Seite 23 und 24: 2. Grundlagen und Stand der Forschu
- Seite 25 und 26: 2. Grundlagen und Stand der Forschu
- Seite 27 und 28: 2. Grundlagen und Stand der Forschu
- Seite 29 und 30: 3. Methoden und Vorgehensplanung Da
- Seite 31 und 32: 3. Methoden und Vorgehensplanung 3.
- Seite 33 und 34: 3. Methoden und Vorgehensplanung Di
- Seite 35 und 36: 3. Methoden und Vorgehensplanung 3.
- Seite 37 und 38: 3. Methoden und Vorgehensplanung 3.
- Seite 39 und 40: 3. Methoden und Vorgehensplanung 2.
- Seite 41 und 42: 3. Methoden und Vorgehensplanung Au
- Seite 43 und 44: 3. Methoden und Vorgehensplanung 3.
- Seite 45 und 46: 3. Methoden und Vorgehensplanung de
- Seite 47 und 48: 3. Methoden und Vorgehensplanung 3.
- Seite 49 und 50: 3. Methoden und Vorgehensplanung Au
- Seite 51 und 52: 3. Methoden und Vorgehensplanung Ab
- Seite 53 und 54: 4. Ergebnisse Abbildung 14: Anwendu
- Seite 55 und 56: 4. Ergebnisse 4.1.2 Schnittstellenk
- Seite 57 und 58: 4. Ergebnisse Abbildung 16: Klassen
- Seite 59 und 60: 4. Ergebnisse • Values: Werte, we
- Seite 61 und 62: 4. Ergebnisse Abbildung 17: Grafisc
- Seite 63 und 64: 4. Ergebnisse Nach Ausführen des P
- Seite 65 und 66: 4. Ergebnisse ... CLUSTER Interpre
- Seite 67 und 68: 4. Ergebnisse Im Folgenden wird die
- Seite 69 und 70: 4. Ergebnisse werden. Dazu generier
- Seite 71 und 72: 4. Ergebnisse Der Benutzer kann dan
- Seite 73: 5. Diskussion Echtzeit 16. Dies bed
- Seite 77 und 78: 5. Diskussion die Schnittstellen, w
- Seite 79 und 80: 7. Danksagung Ich möchte mich hier
- Seite 81 und 82: 7Literaturverzeichnis 16. epSOS - t
- Seite 83 und 84: Abbildungsverzeichnis Abbildung 1:
- Seite 85 und 86: Tabellenverzeichnis Tabelle 1: Kont
5. Diskussion<br />
aus dem ATR direkt <strong>im</strong> Node-‐Objekt vorhanden und können für die Parametrisierung ei-‐<br />
nes Infoitems übernommen werden. Für die Suchanfrage muss dann nur noch die Ver-‐<br />
knüpfung der gewählten Infoitems untereinander und die Werteeinschränkung einzelner<br />
Infoitems vom Benutzer definiert werden. Die gesammelt (in jedem Node-‐Objekt) gespei-‐<br />
cherte Information erlaubt dann eine einfache Erstellung der <strong>XML</strong>-‐Suchanfrage: Da aus<br />
jedem Node-‐Objekt in der SearchQuery ein „TUPLE“ in der <strong>XML</strong>-‐Ausgabe erstellt wird,<br />
kann JDOM alle nötigen Variablen (ItemCode, Unit, Operator, Value) für die Erstellung oh-‐<br />
ne zusätzlichen Aufwand direkt aus dem jeweiligen Node-‐Objekt beziehen.<br />
Eine Schwäche der ATR Schnittstelle könnte die Inflexibilität in Betracht auf Erweiterun-‐<br />
gen bzw. Änderungen des ATR sein. Wird die Struktur des Infoitem-‐<strong>XML</strong> aus dem ATR<br />
erweitert oder geändert, so muss auch die Schnittstelle <strong>im</strong> Document Crawler diesen Än-‐<br />
derungen angepasst werden. Entscheidet man sich zum Beispiel neben Deutsch und Eng-‐<br />
lisch eine weitere Sprache zu integrieren und fügt diese als weiteres Sprachenlabel <strong>im</strong> ATR<br />
ein, so muss die Schnittstelle so umgebaut werden, dass auch die neue Sprache in der No-‐<br />
de-‐Struktur eingelesen und gespeichert wird.<br />
Da die Implementierung der SearchQuery-‐Klasse auf dem Suchanfragen-‐Editor aufbaut,<br />
lassen sich die Vor-‐ und Nachteile des Editors auch in der Implementierung <strong>im</strong> Back-‐End<br />
erkennen. Die bisherige Lösung des Suchanfragen-‐Editors ist nicht sehr benutzerfreund-‐<br />
lich: Die Erstellung einer Suchanfrage sollte für den Benutzer flexibel sein. Die Implemen-‐<br />
tierung erlaubt jedoch durch den „Cursor“ nur das Einfügen eines Elementes an einer Posi-‐<br />
tion, d.h. der Benutzer kann nicht frei wählen, wo in der Suchanfrage das nächste Infoitem<br />
hinzugefügt wird. Eine Lösung wäre hier eine benutzerfreundliche grafische Bedienober-‐<br />
fläche, welche das Editorkonzept besser umsetzt. In der aktuellen Umsetzung des Editors<br />
fehlen weiters grundlegende Funktionen, um damit in der Praxis arbeiten zu können. Zum<br />
Beispiel das Löschen eines geklammerten Bereichs (einer Ebene) ist <strong>im</strong> aktuellen Prototy-‐<br />
pen noch nicht möglich. Aus diesen Gründen wurde die Editorfunktion für den folgenden<br />
Projektschritt (Evaluation der Implementierung) auf eine Funktion reduziert: Der Benut-‐<br />
zer des Document Consumers kann in freien Suche nur nach einem beliebigen Infoitem<br />
suchen, welches er jedoch parametrisieren kann (Kurzabfrage).<br />
Die SearchQuery-‐Klasse baut dennoch auf dem Editorkonzept auf und unterstützt eine frei<br />
erstellte Suche auch weiterhin. Die interne Speicherung der <strong>XML</strong>-‐Information in Node-‐<br />
Objekten erlaubt eine flexible bzw. programmiertechnisch einfache Verwendung für eine<br />
Suchanfrage. Diese Kriterien sind wichtig für die Erstellung einer freien Suche: Eine kom-‐<br />
67
Change language