Technisches Whitepaper k-infinity

Transkript

1 Technisches Whitepaper k-infinity Mit diesem Whitepaper möchten wir Ihnen eine erste Übersicht über die Komponenten von k-infinity, über ihr Zusammenspiel und die Schnittstellen zu externen Systemen geben. Wir beschreiben wie eine typische k-infinity-installation aufgebaut ist und wie k-infinity sich in die IT-Infrastruktur Ihres Unternehmens einfügt. Im letzten Abschnitt haben wir Hardware- und Betriebssystemanforderungen zusammengestellt. Für eine stärker anwenderbezogene Einführung in k-infinity und die zugrundeliegenden semantischen Technologien empfehlen wir die Lektüre unseres allgemeinen Whitepapers k-infinity; wer anstatt zu lesen lieber selber aktiv werden möchte, findet auf unseren Webseiten unter eine online-demo, die sich mit dem Thema Reisen beschäftigt und unter eine Tryout- Version zum Download zum Ausprobieren. Ansprechpartner: Achim Steinacker Mai 2015

2 2/12 Inhaltsverzeichnis k-infinity... 3 Architektur... 3 Aufbau eines Wissensnetzes... 4 Semantische Objekte... 4 Suchen... 4 Indizes... 5 Rechtesystem... 5 Trigger... 5 Skripte, Programmierschnittstellen/APIs... 5 KEM-Java-API... 5 REST... 6 Import und Export von Daten... 6 Datenabbildungen... 6 RDFS / OWL... 6 Staging... 7 Backend... 7 Mediator... 7 Bridge... 7 Job-Processor... 7 Shell... 8 Apache Lucene... 8 Modellierung und Administration... 8 Frontend... 9 Knowledge Portal... 9 Net-Navigator Alternative Frontends Installation und Betrieb Systemvoraussetzungen Mediator Knowledge Portal Knowledge-Builder / Admin-Tool Unterstützte Browser Skalierbarkeit Vertikale Skalierung Horizontale Skalierung Clustering Virtualisierung Authentifizierung Typische Systemkonfigurationen... 12

3 3/12 k-infinity Wissensnetze repräsentieren Wissen, indem sie Objekte miteinander verknüpfen. Solche Objekte sind typischerweise Produkte, Projekte, Technologien, Mitarbeiter, Kunden etc. Sie werden durch Relationen verbunden: Mitarbeiter sind mit der Relation leitet oder arbeitet mit in mit Projekten verknüpft, sie sind aber auch Abteilungen zugeordnet (beschäftigt bei). Projekte werden durchgeführt im Auftrag von Kunden und nutzen Technologien etc. Architektur Abbildung 1: Überblick über die k-infinity-architektur Das Wissensnetz von k-infinity ist in einer semantischen Datenbank abgelegt. Diese Datenbank wird von der Mediator-Komponente bereitgestellt und verwaltet. Alle anderen Komponenten greifen über den Mediator auf die Datenbank zu. Dabei wird ein k-infinityspezifisches Kommunikationsprotokoll verwendet. Anwendungsschnittstellen werden von Bridge-Komponenten bereitgestellt. Dazu gehören eine Java-API sowie HTTP-basierte Schnittstellen wie zum Beispiel REST.

4 4/12 Über die Java-Schnittstelle der Bridge greifen das Knowledge Portal, Portlets und der Net- Navigator auf das Wissensnetz zu. Knowledge Portal und Portlets laufen innerhalb eines Java-Servlet-Containers. Verschiedene Aufgaben, wie z.b. die Generierung von Dokumenten, können in Jobs ausgelagert werden, die von Job-Processor-Komponenten abgearbeitet werden. Zur Modellierung des Wissensnetzes dient der Knowledge-Builder. Dieser ermöglicht es Administratoren und Fachanwendern, Schema und Inhalte des Wissensnetzes zu bearbeiten, zu importieren und zu exportieren. Außerdem können Berechtigungen, Trigger und JavaScript-Methoden definiert werden. Die Modellierung kann kooperativ und im laufenden Betrieb durchgeführt werden. Administrative Aufgaben werden im Admin-Tool durchgeführt. Dazu gehören Datensicherung, Indexverwaltung oder Leistungsanalyse. Mit Shell-Komponenten kann der Import/Export von Daten sowie die Ausführung von Skripten in automatisierte Betriebsabläufe eingebunden werden. Zusätzlich können weitere externe Komponenten wie z.b. Volltextsuchmaschinen eingebunden werden. Aufbau eines Wissensnetzes Semantische Objekte Der Kern der Datenbank bilden semantische Objekte. Dies sind Begriffe, z.b. Person Individuen, z.b. Peter Müller Attribute, z.b. Nachname: Müller Relationen, z.b. Peter Müller ist Vater von Paul Müller Attribute und Relationen können selbst wieder Attribute und Relationen haben. Dadurch können z.b. Metainformationen wie letzte Änderung feingranular gespeichert werden. k-infinity unterstützt verschiedene Attributtypen: Zeichenketten, Dateien, Zahlen, Geo- Koordinaten usw. Zeichenketten und Dateien können mehrsprachig vorliegen. Im Schema kann man definieren, ob und in welchen Sprachen ein Attributwert gespeichert werden kann. Suchen Einfache Suchen finden zu einer Sucheingabe in Form einer Zeichenkette passende Objekte im Wissensnetz. Je nach Suchkonfiguration werden sowohl übereinstimmende Attributwerte als auch semantische Zusammenhänge berücksichtigt und die Treffer entsprechend gewichtet. Expertensuchen finden Objekte im Wissensnetz, die einer durch die Anfrage vorgegebenen Struktur entsprechen. Hierbei können, ähnlich wie bei Queries in einer herkömmlichen Datenbank, Bedingungen für Relationen und Attribute definiert werden.

5 5/12 Indizes Für eine bessere Suchperformance können auf Attributen und Relationen Indizes eingerichtet werden. Mit Volltextindizes können Suchen in längeren Texten beschleunigt werden. Wortzerlegung, Zeichenersetzung und Filterung von Stoppwörtern können dabei konfiguriert werden. Rechtesystem In k-infinity können Schreib-, Lese- und sonstige Berechtigungen feingranular bis auf die Ebene einzelner Eigenschaften gesteuert werden. Die Definition der Berechtigungsstrukturen erfolgt durch ein Regelsystem, das innerhalb des Wissensnetzes definiert ist und anhand der im Wissensnetz vorliegenden Situation entscheidet, ob eine Berechtigung gewährt werden kann. Das Regelsystem bildet eine Baumstruktur, die bei jedem Zugriff abgefragt wird. Die Regeln geben dabei an, unter welchen Bedingungen ein Recht erteilt oder verwehrt wird. Es können z.b. mit Expertensuchen die betroffenen Objekte beschrieben oder die Art des Zugriffes spezifiziert werden. Wird eine Regel erfüllt, werden die Regeln unterhalb des Baumknotens abgefragt, andernfalls wird mit dem nächsten Nachbarknoten fortgefahren. Die Blätter des Baumes erteilen oder verweigern die Berechtigung, den Zugriff durchzuführen. Trigger Mit einer Regelstruktur analog zum Rechtesystem können Trigger definiert werden. Die Blätter des Baums sind in diesem Fall Aktionen wie z.b. die Ausführung einer JavaScript- Funktion oder der Versand einer . Skripte, Programmierschnittstellen/APIs k-infinity bietet eine JavaScript-API Sie wird u.a. in Triggern, REST-Services und Berichten verwendet. Mit der API kann man sowohl lesend auf das Wissensnetz zugreifen (Suchen ausführen, Eigenschaften abfragen usw.) als auch Änderungen vornehmen (neue Objekte anlegen, Attribute ändern usw.). Es gibt mehrere Möglichkeiten, über eine Programmierschnittstelle (API) lesend oder schreibend auf Wissensnetzinhalte zuzugreifen. Im Folgenden werden zwei im Standardprodukt enthaltene APIs vorgestellt. Darüber hinaus können als Kundenanpassung anwendungsspezifische SOAP-APIs implementiert werden, die sich über einen Plug-in- Mechanismus in das Standardprodukt einfügen. APIs zum Zugriff auf das Wissensnetz werden von der Bridge bereitgestellt. KEM-Java-API Die KEM-API (KEM=Knowledge Editor Model) kann sowohl zur Integration von k-infinity in bestehende Java-Anwendungen als auch zur Entwicklung hochskalierbarer Web- und

6 6/12 Desktop-Anwendungen auf Basis von k-infinity verwendet werden. Die KEM-API umfasst die folgenden Funktionen: Speichern, Modifizieren und Löschen von Informationen in Wissensnetzen unter Transaktionsschutz. Alle Zugriffe auf Informationen im Wissensnetz über KEM unterliegen der Kontrolle durch das Rechtesystem. Zugriff auf Ordner, semantische Suchen, Reports und Exporte, die im Wissensnetz definiert sind. Anfragen an das Rechtesystem. REST Über die REST-Schnittstelle werden Objekte des Wissensnetzes als Ressourcen über das HTTP-Protokoll bereitgestellt. Die Definition und Konfiguration der REST-Services erfolgt ebenfalls durch Objekte im Wissensnetz; das eigentliche Schnittstellenverhalten kann mittels JavaScript-Methoden implementiert werden. Die REST-Schnittstelle unterstützt die HTTP-Methoden GET, PUT, POST und DELETE vollen Zugriff auf die HTTP-Header für Request und Response die Steuerung der Mehrsprachigkeit per HTTP-Header (accept-language) die Authentifizierung und HTTPS (beides optional) HTTP-Statuscodes beliebige Response-Types und Sonderfunktionen für XML und JSON Zugriffe über die REST-Schnittstelle unterliegen der Kontrolle durch das Rechtesystem. Import und Export von Daten Datenabbildungen Zum Import und Export von Daten aus oder in externe Datenquellen können Abbildungen definiert werden. In diesen Abbildungen verknüpft man die Datenquelle mit Elementen des Wissensnetzes. Beim Import können die Daten im Wissensnetz entweder ergänzt oder mit dem Stand in der Datenbank synchronisiert werden. Die unterstützten Schnittstellen / Formate sind: tabellarische Textdateien (CSV, TAB, feste Zeichenposition...) Datenbanken mit ODBC-Schnittstelle herstellerspezifische Datenbanken (Oracle, MySQL, PostgreSQL) XML (nur Import, der Export erfolgt über Scripting) RDFS / OWL Einzelne Wissensnetzobjekte oder vollständige Wissensnetze können in den vom W3C definierten Standardformaten RDFS und OWL exportiert und importiert werden. Dies

7 7/12 erlaubt den Austausch der Daten mit anderen Semantik-Werkzeugen. Außerdem können auf diese Weise auch Daten zwischen unterschiedlichen Wissensnetzen ausgetauscht werden. Staging Es ist möglich, das Wissensnetzschema und die dazugehörigen Konfigurationselemente (Suchen, Skripte usw.) komplett oder in Ausschnitten in eine Archivdatei zu exportieren. Diese Archivdatei kann dann in ein Zielnetz eingespielt werden. Auf diese Weise kann man Staging-Systeme realisieren: Schema und Konfiguration werden in einem Master-System konfiguriert und über die Transferdatei in Integrations- und Produktionssysteme übertragen. Backend Mediator Der Mediator sorgt für konsistente und persistente Datenhaltung und für die Aktualität der Daten auf den angeschlossenen Clients. Die Datenhaltung erfolgt in einer objektorientierten Datenbank, die auf die spezifischen Anforderungen semantischer Netze ausgelegt ist und die durch ein optimistisches Transaktionssystem kooperatives Arbeiten auf dem Wissensnetz ermöglicht. Die Clients werden durch aktive Updates über Änderungen am Wissensnetz benachrichtigt. Die Sicht der Clients auf das Wissensnetz ist dadurch immer aktuell. Die von Clients verwendeten Caches werden feingranular aktualisiert, d.h. bei einer Änderung werden nur diejenigen Caches zurückgesetzt, die von der Änderung betroffen sind. Bridge Die Bridge stellt Anwendungsschnittstellen (KEM-API, REST) bereit. Zur Lastverteilung können beliebig viele Bridges eingesetzt werden. Für die KEM-API ist ein eingebauter Load-Balancing-Mechanismus verfügbar. Für die REST-Schnittstelle können vorgeschaltete Webserver mit Lastverteilungsfunktionen verwendet werden. Job-Processor Der Job-Processor arbeitet Jobs asynchron ab. Neben projektspezifisch implementierten Jobs können Indexierungsaufgaben und Skripte in Jobs ausgelagert werden. Es können beliebig viele Job-Processors eingesetzt werden, um die Last zu verteilen. Pro Job-Processor kann konfiguriert werden, für welche Art von Jobs er zuständig ist. Wenn für einen Job mehrere Job-Processors zur Verfügung stehen, wird der Job vom nächsten freien Job-Processor abgearbeitet.

8 8/12 Shell Mit Shell-Komponenten kann der Import/Export von Daten sowie die Ausführung von Skripten automatisiert werden. Apache Lucene Zur Volltextindexierung von Textinhalten kann alternativ zum k-infinity-eigenen Volltextindex auch Apache Lucene eingesetzt werden. Suchen werden von k-infinity in die Lucene-Syntax umgesetzt. Mehrsprachige Inhalte werden unterstützt Suchen sind sowohl sprachübergreifend als auch gezielt nur in bestimmten Sprachen möglich. Modellierung und Administration Der Knowledge-Builder ist die Modellierungskomponente von k-infinity. Er ermöglicht die Bearbeitung aller Elemente des Wissensnetzes von der Definition des Begriffsschemas über die Konfiguration von Suchen, Indizes, Triggern etc., bis hin zur gezielten Modifikation einzelner Wissensnetz-Inhalte. Die Änderungen können dabei im laufenden Betrieb des Frontends erfolgen, sodass Schema-Anpassungen ohne Unterbrechungen des Produktivbetriebs möglich sind. Der Knowledge-Builder ist eine Mehrbenutzer-Anwendung, die sowohl synchron als auch asynchron nutzbar ist. Änderungen im Wissensnetz werden unmittelbar für alle Anwender des Knowledge-Builders sichtbar, und ein kooperativer Graph-Editor erlaubt die Diskussion und Bearbeitung des Wissensmodells über Standortgrenzen hinweg. Abbildung 2: Screenshot Knowledge-Builder und Graph-Editor

9 9/12 Im Admin-Tool werden administrative Aufgaben wie z.b. Datensicherung oder Indexkonfiguration durchgeführt. Frontend Knowledge Portal Das Knowledge Portal stellt die Standard-Web-Oberfläche von k-infinity dar. Es kann mit beliebigen Wissensnetzen zusammenarbeiten und flexibel konfiguriert werden. Die Benutzeroberfläche (Farben, Schriften etc.) kann mittels CSS angepasst werden. Mittels KScript oder spezieller Java-Komponenten sind funktionale Erweiterungen möglich. Zur Integration externer Suchmaschinen bietet das Knowledge Portal die folgenden Schnittstellen: Schnittstelle zur Integration einer Websuche über den Open Source Webcrawler Nutch ( Schnittstelle zur Anbindung von REST-Webservices, die XML zurückliefern. Das Knowledge Portal basiert auf den Open-Source-Frameworks STRUTS und Spring. Abbildung 3: Beispiel-Screenshot eines Knowledge Portals

10 10/12 Net-Navigator Der Net-Navigator ist ein Werkzeug zur visuellen Erkundung des Wissensnetzes. Die Wissensobjekte selbst sowie ihre Zusammenhänge untereinander werden graphisch dargestellt. Abbildung 4: Visualisierte Zusammenhänge im Net-Navigator Alternative Frontends Für spezialisierte Anwendungen, deren Funktionsumfang durch das Knowledge Portal nicht sinnvoll abgedeckt werden kann, können sowohl Web-Clients auf Basis der beschriebenen KEM-API als auch native Anwendungen als Fat-Clients implementiert werden. In der Systemarchitektur ist auch der Mischbetrieb verschiedener Client-Arten vorgesehen, sodass mit den beschriebenen Komponenten und Technologien auch große und komplexe Anwendungsszenarien flexibel bedient werden können. Installation und Betrieb Systemvoraussetzungen Mediator Microsoft Windows: CPU: x86/x86-64-kompatibler Prozessor OS: Windows Server 2003 / 2008 / 2008 R2. Sowohl 32-Bit als auch 64-Bit- Versionen werden unterstützt. Windows XP SP3, Windows Vista, Windows 7 können für Testinstallationen verwendet werden

11 11/12 Linux CPU: x86/x86-64-kompatibler Prozessor Kernel 2.4 oder höher GNU glibc 2.2 oder höher Bei 64-Bit-Versionen wird die 32-Bit-Version der Laufzeitbibliothek glibc benötigt. Diese ist üblicherweise Teil der Distribution, aber evtl. nicht in einer Standardinstallation enthalten Knowledge Portal Oracle Java 6 o andere Java-Versionen und -Implementierungen, insbesondere OpenJDK, können nach Anfrage unterstützt werden Apache Tomcat 6.0 o andere Servlet-Containern und Versionen können nach Anfrage unterstützt werden Knowledge-Builder/Admin-Tool Microsoft Windows: Linux OS X CPU: x86/x86-64-kompatibler Prozessor OS: Windows XP SP3, Windows Vista, Windows 7. Sowohl 32-Bit als auch 64-Bit Versionen werden unterstützt CPU: x86/x86-64-kompatibler Prozessor Kernel 2.4 oder höher GNU glibc 2.2 oder höher Bei 64-Bit Versionen wird die 32-Bit Version der Laufzeitbibliothek glibc benötigt. Diese ist üblicherweise Teil der Distribution, aber evtl. nicht in einer Standardinstallation enthalten CPU: x86/x86-64-kompatibler Prozessor OS: OSX 10.5 oder höher Unterstützte Browser Internet Explorer 8 oder höher Mozilla Firefox 5 oder höher Google Chrome und andere auf WebKit basierende Browser Die Browser-Kompatibilität hängt auch von projektspezifischen Anpassungen ab

12 12/12 Skalierbarkeit Vertikale Skalierung Zusätzliche CPU-Kerne und Hauptspeicher können dazu genutzt werden, weitere Bridge-/Job-Processor-Instanzen zu betreiben. Den Bridge-/Job-Processor-Instanzen kann man mehr Speicher zuordnen, um größere Datenmengen im Cache zu halten. Dies verbessert das Antwortzeitverhalten bei häufig verwendeten Daten Horizontale Skalierung Es können beliebig viele Server zu einer Installation hinzugefügt werden. Es ist nur eine TCP/IP-Verbindung zum Mediator notwendig Clustering Prinzipiell ist das Backend Clustering-fähig. In Projekten wurden Microsoft-Cluster- Umgebungen erfolgreich eingesetzt. Virtualisierung Die Backend-Komponenten können auch auf virtualisierten Serverumgebungen betrieben werden, sofern diese ausreichende Ressourcen bereitstellen. Authentifizierung Das Knowledge Portal unterstützt vier Arten der Authentifizierung: LDAP: Die Authentifizierung wird an einen LDAP-konformen Directoy Server abgegeben. Bei diesem Vorgang können auch weitere im Directoy Service gespeicherte Nutzerdaten mit dem Wissensnetz abgeglichen werden. Die entsprechende Schnittstelle kann ohne Programmierung vom Wissensnetz- Administrator konfiguriert werden. Eigene Authentifizierung: Die Authentifizierung wird gegen ein im k-infinity- Wissensnetz verwaltetes Passwort vorgenommen. Ausgelagerte Authentifizierung: k-infinity kann nahtlos in eine Single Sign-on- Umgebung integriert werden, bei der sich der Benutzer bereits gegenüber einer anderen Instanz authentifiziert hat. Die k-infinity-authentifizierung ist in diesem Fall deaktiviert. Über die Java-API und die dort angebotenen Funktionen können angepasste Authentifizierungs-Verfahren realisiert werden. Typische Systemkonfigurationen Beispielkonfiguration für den Betrieb eines Knowledge Portals: Mediator: 1 CPU-Kern, 2 GB RAM Apache Tomcat: 2 CPU-Kerne, 4 GB RAM Bridges: 4 CPU-Kerne, 8 GB RAM