Embed Size (px)
Citation preview
Diplomarbeit
Analyse und Implementierung einer Schnittstelle
zwischen Skill-Management-Systemen und
Web 2.0 Applikationen - am Beispiel einer
prototypischen Applikation und
IBM Lotus Connections
Prof. Dr. Ludwig Nastansky
Wintersemester 2008/2009
vorgelegt von:
Dirk Stelloh
Wirtschaftsinformatik
3382511
Dirk Stelloh
Langer Weg 9
33100 Paderborn
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbständig und nur unter Verwendung der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nichtveröffentlicht.
Paderborn, 30.03.2009 _____________________________
Inhalt
Inhaltsverzeichnis
1 Einleitung____________________________________________________________11.1 Ausgangssituation und Problemstellung_______________________________________1
1.1.1 Skill-Management___________________________________________________________11.1.2 Web 2.0-Anwendungen im Unternehmensumfeld___________________________________31.1.3 Berührungspunkte zwischen Skill-Management und Web 2.0_________________________3
1.2 Abgrenzung_____________________________________________________________51.3 Vorgehensweise__________________________________________________________5
2 Theoretische Grundlagen_______________________________________________72.1 Grundlagen des Skill-Managements__________________________________________7
2.1.1 Wissensmanagement als Basis des Skill-Managements_______________________________72.1.2 Skill-Management__________________________________________________________112.1.3 Die Anwendung SkiP________________________________________________________14
2.2 Web 2.0 – Das neue WWW?_______________________________________________172.2.1 Neue Dienste_______________________________________________________________182.2.2 Verlängerte Beta-Phase______________________________________________________202.2.3 Mash-ups_________________________________________________________________202.2.4 Verschlagwortung – Tags_____________________________________________________212.2.5 Immer aktuell: Feeds________________________________________________________232.2.6 Web 2.0-Anwendungen am Beispiel von Connections______________________________24
2.3 Berührungspunkte zwischen Skill-Management und Web 2.0_____________________34
3 Konzeption der Schnittstelle____________________________________________363.1 Organisatorische Rahmenbedingungen_______________________________________363.2 Technische Vorüberlegungen_______________________________________________37
3.2.1 Die technische Basis von SkiP_________________________________________________373.2.2 Die technische Basis von Connections___________________________________________37
3.3 Atom-Feeds und das Atom Publishing Protocol________________________________383.3.1 HTTP (Hypertext Transfer Protocol)____________________________________________383.3.2 Das Atom Syndication Format_________________________________________________393.3.3 AtomPub (Atom Publishing Protocol)___________________________________________423.3.4 Das Framework Abdera______________________________________________________43
3.4 Auswahl der Programmiersprache___________________________________________443.5 Analyse der Integrationsszenarien___________________________________________47
3.5.1 In SkiP vorhandene Informationen______________________________________________473.5.2 Arten von Integrationsszenarien________________________________________________483.5.3 Integrationsszenarien mit Connections___________________________________________493.5.4 Integrationsszenarien für die Implementierung____________________________________58
4 Implementierung der Schnittstelle_______________________________________604.1 Architektur der Schnittstelle________________________________________________60
4.1.1 Vorüberlegungen___________________________________________________________604.1.2 Schematische Architektur_____________________________________________________62
4.2 Das Klassendiagramm____________________________________________________644.2.1 Zugriff auf die Anwendungen von Connections___________________________________654.2.2 Zugriff auf die Konfiguration__________________________________________________684.2.3 Zugriff auf die Benutzerinformationen___________________________________________69
4.3 Beispielhafte Integration in das Benutzerinterface______________________________704.4 Bewertung der Implementierung____________________________________________73
i
Inhalt
5 Zusammenfassung und Ausblick________________________________________745.1 Zusammenfassung_______________________________________________________745.2 Ausblick_______________________________________________________________75
6 Literaturverzeichnis__________________________________________________77
7 Anhang_____________________________________________________________837.1 Die Anwendung ConnectionsGateway_______________________________________83
7.1.1 Installation________________________________________________________________837.1.2 Konfiguration______________________________________________________________837.1.3 Der Agent Query___________________________________________________________84
7.2 Das Framework „Abdera“_________________________________________________867.3 Alternative „Java-Bibliothek“______________________________________________87
ii
Inhalt
AbbildungsverzeichnisAbbildung 1: Drei Triebkräfte steigern die Bedeutung der Ressource Wissen.................2Abbildung 2: Thematische Einordnung.............................................................................5Abbildung 3: Wissenserzeugung und -transformation......................................................9Abbildung 4: Bausteine des Wissensmanagements.........................................................10Abbildung 5: Der Prozess des Skill-Managements.........................................................12Abbildung 6: Erfassungsmaske für Skill-Profile in SkiP................................................15Abbildung 7: Konfigurationsmaske für Skills in SkiP....................................................16Abbildung 8: Darstellung von Tags als Liste und als Wolke..........................................22Abbildung 9: Beispiel eines Profils in der Anwendung Profiles.....................................25Abbildung 10: Die Anwendung Communities................................................................28Abbildung 11: Die Anwendung Blogs............................................................................30Abbildung 12: Die Anwendung Dogear..........................................................................32Abbildung 13: Die Anwendung Activities......................................................................33Abbildung 14: Beispiel für einen einfachen Atom-Feed.................................................40Abbildung 15: Implementierung der Schnittstelle als eigenständige Komponente........62Abbildung 16: Schematischer Ablauf „Suchanfrage“.....................................................63Abbildung 17: Schematischer Ablauf „Informationsrückfluss“......................................63Abbildung 18: Klassendiagramm....................................................................................64Abbildung 19: Ableitung der Zugriffsklassen.................................................................65Abbildung 20: Ableitung der Konfigurationsklassen......................................................68Abbildung 21: Ableitung der Konfigurationsklassen......................................................69Abbildung 22: Integration der Schnittstelle in das Benutzerinterface von SkiP.............71Abbildung 23: Einblendung von Suchergebnisse aus Profiles in einem Fenster............72Abbildung 24: Einblendung eines Bestätigungsdialogs vor der Datenübertragung........72Abbildung 25: Erfassung der Benutzerinformationen.....................................................84Abbildung 26: Erfassung der URL-Angaben zu den einzelnen Anwendungen..............84
iii
Inhalt
TabellenverzeichnisTabelle 1: Gegenüberstellung von Diensten im Web 1.0 und Web 2.0..........................19Tabelle 2: Elemente von <Feed>.....................................................................................41Tabelle 3: Elemente von <Entry>....................................................................................42Tabelle 4: Die Grundlegenden Aktionen des Atom Publishing Protocol........................43Tabelle 5: Bewertung der verfügbaren Programmiersprachen........................................46Tabelle 6: Bewertungskriterien für Integrationsszenarien...............................................50Tabelle 7: Profiles: Integrationsszenarien.......................................................................50Tabelle 8: Profiles: Bewertung der Integrationsszenarien...............................................51Tabelle 9: Communities: Integrationsszenarien..............................................................52Tabelle 10: Communities: Bewertung der Integrationsszenarien....................................53Tabelle 11: Blogs: Integrationsszenarien........................................................................54Tabelle 12: Blogs: Bewertung der Integrationsszenarien................................................55Tabelle 13: Dogear: Integrationsszenarien......................................................................56Tabelle 14: Dogear: Bewertung der Integrationsszenarien.............................................56Tabelle 15: Activities: Integrationsszenarien..................................................................57Tabelle 16: Activities: Bewertung der Integrationsszenarien..........................................58Tabelle 17: Agent „Query“ - Parameter..........................................................................85Tabelle 18: Agent „Query“ - Werte für den Parameter „application“.............................85Tabelle 19: Agent „Query“ - Werte für den Parameter „action“.....................................85Tabelle 20: Dateien des Archivs „apache-abdera-0.4.0-incubating.zip“.........................86
iv
Inhalt
AbkürzungenAPI Aplication Programming InterfaceAPP Atom Publishing Protocoll (auch AtomPub)CMS Content Management SystemHTTP HyperText Transfer ProtocolWWW World Wide WebREST REpresentational State TransferURI Uniform Resource IdentifierURL Uniform Resource LocatorXML eXtensible Markup Language
v
1 Einleitung
1 Einleitung
1.1 Ausgangssituation und Problemstellung
1.1.1 Skill-Management
Die Wertschöpfung moderner Unternehmen beruht heute mehr und mehr auf dem
Wissen und der Erfahrung der Mitarbeiter:
„Der Anteil des Wissens an der Gesamtwertschöpfung eines Unternehmens liegt heute bei ca. 60% - mit steigender Tendenz“1
Für die steigende Bedeutung der Ressource Wissen identifizierte schon North, K.
(2005) drei Triebfedern (vergl. Abbildung 1, S. 2)2:
• Struktureller Wandel
Die Gesellschaft wandelt sich zur Informations- und Wissensgesellschaft. Das
Wissen löst damit andere knappe Ressourcen ab und ist zu einem weiteren
Produktionsfaktor geworden.
• Globalisierung
Die Globalisierung der Wirtschaft führt auch zu einer Globalisierung des
Wissens. Lokaler und globaler Wettbewerb erhöhen den Konkurrenzdruck auf
die Unternehmen, schneller und besser zu sein als andere, die verfügbaren
Ressourcen besser zu nutzen.
• Informations- und Kommunikationstechnologien
Letztlich erlauben diese Technologien nahezu verzögerungsfreien Informations-
austausch über weiter Strecken und Landesgrenzen hinweg. Informationen sind
nur einen Mausklick entfernt und in vielen Fällen dennoch schwer in der Menge
des Wissens ausfindig zu machen.
Durch die steigende Bedeutung des Wissens steigt ebenso die Bedeutung des
Wissensmanagements: Es folgt die Notwendigkeit des Wissensmanagements durch
„Wissensarbeiter als Hauptwertschöpfer“3.
1 Aus BMWi (2006), S. 1 2 Vergl. North, K. (2005), S. 13 3 Vergl. Probst, G.; Raub, S.; Romhardt, K. (2003), S. 18
1
1 Einleitung
Abbildung 1: Drei Triebkräfte steigern die Bedeutung der Ressource Wissen4
Wissen allein ist aber nicht der Schlüssel zum Erfolg: Das Wissen muss von den
Mitarbeitern auch praktisch in Handlung umgesetzt werden können. Hinzu kommt, dass
Wissen nur begrenzt erworben und zwischen Mitarbeitern transferiert werden kann.
Somit ist der Aufbau und die Pflege der Fähigkeiten von Mitarbeitern, im Englischen
„Skills“, essentieller Teil einer zukunftsgerichteten Unternehmensstrategie.
Oft genug werden die Aufgaben im Bereich des Skill-Managements aber vernachlässigt
oder als lästige Pflicht ohne ersichtlichen Gegenwert empfunden. Die Pflege von Skill-
Profilen hat für den einzelnen Mitarbeiter zunächst keinen erkennbaren positiven Effekt.
Erst später, wenn der Mitarbeiter selbst einen Experten sucht, bedient er sich dieser
Daten, ohne den Nutzen mit den vorangegangenen Pflichten zu assoziieren.
4 Vergl. North, K. (2005), S. 13
2
Struktureller Wandel zur Informations- und Wissensgesellschaft
Informations- und Kommunikations
technologieGlobalisierung
Bedeutungder RessourceWissen steigt
● Wissen wird knappe Ressource● Informations- und Wissensmärkte entstehen
● beschleunigt Transaktionen● reduziert Transaktionskosten
● Lokaler und globaler Werttbewerb● Beschleunigte internationale Lernprozesse
● weltweite Informationstransparenz● weltweite Steuerung von Geschäftsprozessen
1 Einleitung
1.1.2 Web 2.0-Anwendungen im Unternehmensumfeld
Mit der Verbreitung des Internets und des darauf basierenden World Wide Webs
(WWW) hat es sich von einem reinen Informationsmedium immer mehr hin zu einem
interaktiven „Mitmach-Medium“ entwickelt5.
Das Schlagwort „Web 2.0“ ist Ausdruck für eine neue Qualität im Bezug auf die
Möglichkeiten für Jedermann Inhalte im Internet zu publizieren. Möglich wurde dies
durch Projekte wie bspw. Wikipedia6, StudiVZ7, Flickr8 oder del.icio.us9, die es auch
unbedarften Benutzern auf einfache Art und Weise erlauben, Inhalte bereitzustellen10.
Web 2.0-Anwendungen haben auch in Unternehmen vielfältige Verwendungsgebiete.
Sie können sowohl intern (bspw. zur Kommunikation zwischen Projektbeteiligen), als
auch extern (bspw. zur Kommunikation mit Kunden und Geschäftspartnern) genutzt
werden11.
Die Pflege von Daten in Web 2.0 Anwendungen wird gern freiwillig, ja sogar in der
Freizeit, übernommen, da eine direkte Rückkopplung mit dem Nutzen (bspw. besserer
Artikel im Lexikon, mehr Kontakte, etc.) erfolgt.
Das gleichzeitige Abrufen und Bereitstellen von Wissen macht die für das Web 2.0
typische „Social Software“ gerade im Rahmen von Skill-Management so interessant12.
Daher ist ein Kopplung von Systemen des Skill-Managements und Web 2.0
Anwendungen ein logischer nächster Schritt.
1.1.3 Berührungspunkte zwischen Skill-Management und Web 2.0
Durch die Beschäftigung mit dem Mitarbeiter und der aktiven Planung seiner
Entwicklung entsteht ein hoher Bedarf an Informationsaustausch.
5 Vergl. Locke, C. (2000)6 Offene Enzyklopädie, unter http://www.wikipedia.de bzw. http://de.wikipedia.org zu finden 7 Soziales Netzwerk für Studenten, unter http://wwwstudivz.net zu finden 8 Plattform zur Publikation von Bildern, unter http://www.flickr.com zu finden 9 Öffentliche Sammlung und Austausch von Lesezeichen, unter http://www.delicious.com zu finden 10 Vergl. Van Eimeren, B.; Frees, B. (2006) 11 Beispielhaft sei hier auf die Anwendungsmöglichkeiten in Groß, M.; Hülsbusch, W. (2005) oder in
Schiller García, J. (2007), S. 89ff hingewiesen. 12 Vergl. Burg, T. N.; Pircher, R. (2006)
3
1 Einleitung
Wie kann also die Brücke zwischen den zwei Welten geschlagen werden? Welche
Informationen aus dem jeweilig anderen System sind interessant und sollten nutzbar
gemacht werden?
Skill-Profile können dabei als Informationsquelle, bspw. für besondere Interessen und
Fähigkeiten, dienen:
• Wen kann ich zu bestimmten Themen fragen?
• Wer kann mir bei der Weiterbildung in einem bestimmten Bereich helfen?
Zur Beantwortung solcher Fragen können neben klassischen Expertensystemen auch
Web 2.0-Anwendungen als Informationsquelle herangezogen werden, sofern diese mit
den notwendigen Informationen versorgt wurden.
Weitere Fragen im Zuge des Skill-Managements verweisen ebenfalls auf Web 2.0-
Anwendungen:
• Wo finde ich weitere Informationen zum Thema?
• Wo finde ich Gleichgesinnte?
• Welche Erfahrungen haben andere in diesem Bereich gemacht?
Hier können Diskussionsforen, Blogs oder Wikis helfen, die gewünschten
Informationen zu erschließen.
Skill-Management und Web 2.0 ergänzen sich, sofern die jeweils vorhandenen
Informationen im anderen System nutzbar gemacht werden können. Es ergeben sich
zwei zentrale Fragestellungen für einen Datenaustausch:
• Welche Informationen aus einem Skill-Profil können in welcher Form sinnvoll
in welche Anwendung transferiert werden?
• Wie finde ich passende Beiträge in Web 2.0-Anwendungen basierend auf einem
Skill-Profil?
4
1 Einleitung
1.2 Abgrenzung
Ziel der Arbeit ist die Analyse und prototypischen Erstellung einer Schnittstelle
zwischen Anwendungen des Skill-Managements und Web 2.0-Anwendungen (siehe
Abbildung 2).
Auf eine Marktanalyse im Bereich Skill-Management oder Web 2.0-Anwendungen wird
bewusst verzichtet. Die praktischen Betrachtung erfolgt exemplarisch seitens des Skill-
Management anhand der prototypisch entwickelten Anwendung „SkiP“ (SkillProfile),
auf Seiten des Web 2.0 auf Basis des kommerziellen Produktes IBM Lotus
Connections13.
Abbildung 2: Thematische Einordnung
SkiP basiert auf der Plattform IBM Lotus Domino14, die vielfältige Möglichkeiten der
Anpassung und der Integration mit anderen Systemen bereitstellt.
Connections bietet sich aufgrund der Vielfältigkeit der angebotenen Anwendungen,
sowie der umfangreichen und gut dokumentierten Schnittstelle zur Integration an.
13 IBM Lotus Connections wird im folgenden kurz „Connections“ genannt. 14 IBM Lotus Domino wird im folgenden kurz „Domino“ genannt.
5
Web 2.0 Skill-Management
SkiP ConnectionsSchnitttstelle
1 Einleitung
1.3 Vorgehensweise
Zunächst werden die theoretischen Grundlagen geklärt. Hierzu werden die Begriffe
„Skill-Management“ und „Web 2.0“ präzisiert. Die Anwendung SkiP wird als Vertreter
des Skill-Managements näher betrachtet. Die Erläuterung von Web 2.0-Anwendungen
erfolgt exemplarisch am Beispiel der von Connections bereitgestellten Anwendungen.
Zur Konzeption der Schnittstelle werden anschließend die Rahmenbedingungen
erläutert. Die Betrachtung der technischen Grundlagen der zwei Systeme und deren
bereitgestellter Schnittstellen (Application Programming Interface, API) sowie die
Auswahl der Umgebung und Programmiersprache klären die technische Basis der
Schnittstelle. Die Analyse von Berührungspunkten und möglicher Integrationsszenarien
schließen die Konzeption der Schnittstelle ab.
Basierend auf den Vorüberlegungen erfolgt die Beschreibung der Architektur und
Implementierung von beispielhaft ausgewählten Szenarien.
In den Schlussüberlegungen werden die Ergebnisse diskutiert und bewertet. Ein
Ausblick auf mögliche weitere Schritte beendet die Betrachtungen.
6
2 Theoretische Grundlagen
2 Theoretische Grundlagen
Um Skill-Management-System und Web 2.0 Anwendungen zu verstehen werden
zunächst die jeweiligen Ursprünge erläutert und Begriffe angegrenzt.
Vor der Betrachtung des Skill-Managements wird zunächst der Ansatz des Wissens-
managements als Basis erläutert. Darauf aufbauend werden dann die Prozesse und
Systeme des Skill-Managements vorgestellt. Die Anwendung SkiP, als einfacher
Vertreter der Skill-Management-Systeme, wird abschließend beschrieben.
Das Schlagwort „Web 2.0“, die Konzepte und Technologien für die es steht, wird in
Abgrenzung zum traditionellen WWW erläutert. Die Beschreibung von Web 2.0-
Anwendungen erfolgt exemplarisch am Beispiel der von Connections bereitgestellten
Anwendungen.
Die theoretischen Vorüberlegungen schließen mit der Diskussion von Berührungs-
punkten der zwei Themenkomplexe.
2.1 Grundlagen des Skill-Managements
2.1.1 Wissensmanagement als Basis des Skill-Managements
Die Ressource Wissen gewinnt immer mehr an Bedeutung15. Damit steigt auch die
Wichtigkeit des Umgangs mit dieser knappen Ressource. Schindler, M. (2001) gibt
einen Überblick über verschiedene Kategorisierungen von Wissen16. Die weitgehend
anerkannte17 Kategorisierung von Nonaka, I.; Takeuchi, H. (1995) unterteilt das Wissen
in zwei Bereiche18:
• Implizites Wissen
Der größte und wichtigste Teil des Wissens in Unternehmen ist implizites
Wissen. Es kann nicht einfach dokumentiert und somit in explizites Wissen
gewandelt werden. Der Erwerb von implizitem Wissen erfolgt häufig über die
15 Vergl. North, K. (2005), S. 13ff16 Vergl. Schindler, M. (2001), S. 29ff17 Siehe Schindler, M. (2001), S. 3018 Vergl. Nonaka, I.; Takeuchi, H. (1995), S. 18ff
7
2 Theoretische Grundlagen
persönliche Erfahrung und lässt sich nur schwerlich mit Schulungen oder
Handbüchern unterstützen.
• Explizites Wissen
Demgegenüber lässt sich das explizite Wissen „(...) in Worten und Zahlen
ausdrücken und problemlos mit Hilfe von Daten, wissenschaftlichen Formeln,
festgelegten Verfahrensweisen oder universellen Prinzipien mitteilen“19.
Explizites Wissen kann bspw. in Dokumenten oder Datenbanken bereitgestellt
werden.
Implizites und explizites Wissen können ineinander umgewandelt werden20. Die
Abbildung 3 auf S. 9 zeigt die von Nonaka, I.; Takeuchi, H. (1995) identifizierten
Prozesse:
• Sozialisation
Wissen wird durch den direkten Austausch zwischen zwei Personen, bspw.
durch Beobachtung oder den traditionellen Austausch von Lehrling und Meister,
vermittelt.
• Externalisierung
Durch die Dokumentation von Wissen in allgemein zugänglicher Form wird
dieses Wissen konserviert und kann weitergegeben werden.
• Kombination
Die Erzeugung von neuem expliziten Wissen erfolgt durch die Kombination von
anderem, bereits bekanntem explizitem Wissen.
• Internalisierung
Explizites Wissen wird durch eine Person aufgenommen und verinnerlicht,
bspw. durch „Learning-by-doing“.
19 Aus: Nonaka, I.; Takeuchi, H. (1995), S. 1820 Vergl. Nonaka, I.; Takeuchi, H. (1995), S. 75f
8
2 Theoretische Grundlagen
ZielpunktImplizites Wissen Explizites Wissen
Aus-gangs-punkt
Implizites Wissen Sozialisation Externalisierung
Explizites Wissen Internalisierung Kombination
Abbildung 3: Wissenserzeugung und -transformation21
Nonaka, I.; Takeuchi, H. (1995) konstruieren aus den Prozessen der Wissenserzeugung
und -transformation die „Spirale des Wissens“22. Die stete Abfolge der einzelnen
Prozesse in der oben aufgeführten Reihenfolge durch verschiedene Mitarbeiter lässt das
Wissen des Unternehmens und des Einzelnen wachsen.
Probst, G.; Raub, S.; Romhardt, K. (2003) fassen den Begriff des Wissensmanagements
weiter und beschreiben ihn mit Hilfe von sechs Kernprozessen23:
• Wissensidentifikation
Das Wissensumfeld wird analysiert und beschrieben.
• Wissenserwerb
Das Wissen wird durch den externen Zukauf von Wissen, bspw. in Form neuer
Mitarbeiter oder Software, erweitert.
• Wissensentwicklung
Innerhalb des Unternehmens wird gezielt (noch nicht vorhandenes) Wissen
aufgebaut.
• Wissensverteilung
Vorhandenes Wissen wird innerhalb des Unternehmens bereitgestellt und
verbreitet.
21 Aus Nonaka, I.; Takeuchi, H. (1995), S. 75 22 Vergl. Nonaka, I.; Takeuchi, H. (1995), S. 85ff 23 Vergl. Probst, G.; Raub, S.; Romhardt, K. (2003), S. 28ff
9
2 Theoretische Grundlagen
• Wissensnutzung
Die Nutzung des des Wissens im produktiven Einsatz wird sichergestellt.
• Wissensbewahrung
Zum Schutz vor Wissensverlusten wird Wissen konserviert.
Abbildung 4 ergänzt die zuvor genannten Kernprozesse des Wissensmanagements um
die strategische Komponente der Lenkung zu einem geschlossenen Regelkreis24:
• Wissensziele
Ziele und Richtung für das Wissensmanagement werden vorgegeben.
• Wissensbewertung
Die Erreichung der Zielvorgabe wird überprüft.
Beide Ansätze verfolgen den Aufbau sowohl von implizitem wie explizitem Wissen,
haben aber letztlich die Überführung von impliziten in explizites Wissen zum Ziel.
Wissens-ziele
Wissens-bewertung
Wissens-identifikation
Wissens-bewahrung
Wissenserwerb Wissens-nutzung
Wissens-entwicklung
Wissens-verteilung
Abbildung 4: Bausteine des Wissensmanagements25
24 Vergl. Probst, G.; Raub, S.; Romhardt, K. (2003), S. 3225 Aus Probst, G.; Raub, S.; Romhardt, K. (2003), S. 32
10
Feedback
2 Theoretische Grundlagen
2.1.2 Skill-Management
Das Wissen an sich gewinnt für Unternehmen erst dann an Bedeutung, wenn es auch
angewendet, also in Handlungen umgesetzt werden kann26.
Das Skill-Management befasst sich, ähnlich wie das Wissensmanagement, mit dem
Erwerb und der Nutzung des Wissens, stellt aber den Wissensträger, den Mitarbeiter
eines Unternehmens, in den Mittelpunkt der Betrachtungen:
„Die Bewirtschaftung fachlichen Könnens von Mitarbeitenden (engl. Skill-Management) unterstützt die ressourcenorientierte Sicht durch Identifikation, Bewertung und Visualisierung der in einem Unternehmen vorhandenen Kenntnisse und Kompetenzen.“27
Hier steht also nicht die Schaffung von explizitem Wissen, sondern das Management
des fachlichen Könnens der Mitarbeiter im Vordergrund. Da implizites Wissen sich
nicht, oder nur mit großem Aufwand dokumentieren lässt28, muss also ein Weg
gefunden werden, dieses Wissen dennoch nutzbar zu machen. Faix, W. G.; Buchwald,
C.; Wetzler, R. (1991) umschreiben das Skill-Management auch als
„(...) das Management von menschlichen Fähigkeiten und Qualifikationen in Organisationen und Unternehmungen“29.
Sie sehen vornehmlich das Management in der Verpflichtung, Skill-Management zu
betreiben30. Allerdings bezieht sich diese Äußerung nur auf das Forcieren des Skill-
Managements: Sie teilen die Aufgaben des Skill-Managements in zwei verschiedene
Bereiche, die „(...) übergeordnete unternehmensweite Planungsstrategie (...)“31 und die
„(...) operationale Personalplanung (...)“32. Sie unterscheiden also zwischen der
Vorgabe von der Seite des Managements und der operative Umsetzung dieser Vorgabe.
Die Umsetzung von Skill-Management kann, ja sollte, durch entsprechende Systeme
unterstützt werden:
„Effizientes Skill-Management erfordert den Einsatz von Informationstechnologie (...)“33
26 Vergl. North, K. (2005), S. 3427 Aus Gerbert, H.; Kutsch, O. (2003), S. 22728 Vergl. Schütt, P. (2002), S. 5129 Aus: Faix, W. G.; Buchwald, C.; Wetzler, R. (1991), S. 1130 Siehe Faix, W. G.; Buchwald, C.; Wetzler, R. (1991), S. 1331 Vergl. Faix, W. G.; Buchwald, C.; Wetzler, R. (1991), S. 63ff32 Vergl. Faix, W. G.; Buchwald, C.; Wetzler, R. (1991), S. 63ff33 Aus Gerbert, H.; Kutsch, O. (2003), S. 227
11
2 Theoretische Grundlagen
Gronau, N.; Uslar, M. (2004) identifizieren die zentralen Einsatzgebiete von Systemen
zur Unterstützung des Skill-Managements daher wie folgt34:
• Expertensuche
Die Suche nach Personen mit bestimmten Skills ermöglicht das leichte
Auffinden von Experten zur Unterstützung.
• Personalbeschaffung
Durch Abgleich von Soll- mit Ist-Profilen können Stellen im Unternehmen
intern, ohne aufwändiges Bewerbungsverfahren, vergeben werden.
• Personalentwicklung
Aus den Differenzen zwischen Soll- und Ist-Profilen können gezielte
Maßnahmen zur Qualifizierung abgeleitet werden.
• Projektmanagement
Aus den Anforderungen eines Projektes können Soll-Profile für Beteiligte
ermittelt werden. Über einen Abgleich mit den Profilen verfügbarer Mitarbeiter
können geeignete Personen herausgefiltert werden.
1. Strategie Check
6. Erfolgskontrolle 2. Anforderungsprofile
5. Umsetzungsstrategie 3. Fähigkeitsprofile
4. Soll-Ist-Analyse
Abbildung 5: Der Prozess des Skill-Managements35
34 Vergl. Gronau, N.; Uslar, M. (2004), S. 32f35 In Anlehnung an Faix, W. G.; Buchwald, C.; Wetzler, R. (1991), S. 66
und Pieler, D.; Schuh, M. (2003), S. 21f
12
2 Theoretische Grundlagen
Der Einsatz von Skill-Management-Systemen in den zuvor beschriebenen Gebieten
setzt das Vorhandensein von Skill-Katalogen, Soll- und Ist-Profilen bereits voraus.
Diese müssen jedoch zunächst erarbeitet werden. Abbildung 5 auf S. 12 zeigt in
Anlehnung an Faix, W. G.; Buchwald, C.; Wetzler, R. (1991) und Pieler, D.; Schuh, M.
(2003) den Prozess des Skill-Managements:
• Strategie-Check
Für Vorgabe der Ziele für das Skill-Management und die Ableitung des Skill-
Katalogs wird die Unternehmensstrategie analysiert.
• Anforderungsprofile
Aus den Vorgaben werden die Anforderungsprofilen zur Zielerfüllung
abgeleitet.
• Fähigkeitsprofile
Auf Basis Anforderungsprofile erfolgt die Bewertung der Fähigkeiten.
• Soll-Ist-Analyse
Die Fähigkeitsprofile werden mit den Anforderungsprofile abgeglichen und
Gaps (Abweichungen) werden aufgedeckt.
• Umsetzungsstrategie
Aus dem Ergebnis der Soll-Ist-Analyse werden Maßnahmen zur Behebung der
Gaps abgeleitet.
• Erfolgskontrolle
Anhand eines erneuten Abgleichs der Fähigkeits- und Anforderungsprofile wird
der Erfolg kontrolliert und ein Rückfluss in die Unternehmensstrategie generiert.
Es ergibt sich ein wiederholender Regelkreislauf. Pieler, D.; Schuh, M. (2003) stellen
fest:
„Skill Management ist als nie abgeschlossener, kontinuierlicher Prozess zu verstehen, der sich je nach Innovationsgeschwindigkeit der Branche, zumindest aber einmal jährlich wiederholen sollte.“36
36 Aus Pieler, D.; Schuh, M. (2003), S. 22
13
2 Theoretische Grundlagen
Systeme, deren primärer Zweck es ist, Wissensträger zu finden, heißen
Expertensysteme oder auch „Yellow Pages“37. Diese Systeme verschaffen keinen
direkten Zugriff auf Wissen, sondern bieten einen Verweis auf den Experten. Dennoch
ist dies häufig ausreichend, um Probleme zu lösen oder Fragen zu beantworten38.
Expertensysteme erfordern zum einen das Vertrauen der Mitarbeiter (aufgrund der
Preisgabe persönlicher Daten), als auch die Bereitschaft zur Pflege dieser Daten.
Oftmals leiden diese Systeme in der Praxis daran, dass die Pflege der Informationen
nicht oder nicht zeitnah erfolgt und die Datenbasis daher kaum Nutzwert bietet39.
2.1.3 Die Anwendung SkiP
Die Anwendung „SkiP“ wurde prototypisch im Rahmen dieser Arbeit zur Erfassung
und Verwaltung von Skill-Profilen entwickelt. Es handelt sich um ein einfaches System,
in dem Profile dokumentenbasiert hinterlegt werden können. Die Erfassung erfolgt in
einer einfach aufgebauten Bildschirmmaske (siehe Abbildung 6, S. 15).
In dieser Maske können die folgenden Informationen erfasst werden:
• Name und Rolle des Benutzers
• Bewertung der einzelnen Skills
• Kommentare
Die zur Bewertung angebotenen Skills leiten sich aus der Rolle des Benutzers ab. Die
Skills, die bspw. für einen Projektleiter angeboten werden, unterscheiden sich von
denen, die für einen Entwickler angeboten werden.
Für jeden Benutzer können mehrere Profile angelegt werden, die bspw. einen zeitlichen
Verlauf widerspiegeln.
Ein differenziertes Berechtigungskonzept, Vergleichsmöglichkeiten oder die
Dokumentation der Entwicklung einzelner Mitarbeiter, wie in kommerziellen
Produkten40 verfügbar, fehlen in dieser Version noch. Die Anwendung SkiP ist ein
37 Vergl. Probst, G.; Raub, S.; Romhardt, K. (2003), S. 6738 Vergl. Probst, G.; Raub, S.; Romhardt, K. (2003), S. 115f39 Vergl. Schütt, P. (2001)40 Als Beispiel für eine Betrachtung verschiedener verfügbarer Systeme sei auf Seegmüller, K. (2006)
verwiesen
14
2 Theoretische Grundlagen
erster Versuch der Einführung eins Skill-Management-System in einem mittel-
ständischen Unternehmen und soll mit den Anforderungen des Unternehmens wachsen.
Gerade dieses einfache System eignet sich aber besonders zur Erstellung einer
Schnittstelle, da der Zugriff auf die gespeicherten Informationen vergleichsweise
einfach erfolgen und somit das Hauptaugenmerk auf die Integration gelegt werden kann.
Abbildung 6: Erfassungsmaske für Skill-Profile in SkiP
Die einzelnen Skills werden über eine Konfiguration in einem Katalog hinterlegt. Die
Skills sind dabei bereits in Gruppen unterteilt, wie sie anschließend bei der Bewertung
in der Erfassungsmaske verwendet werden. Für jede Gruppe kann ein Titel und eine
Beschreibung hinterlegt werden. Für die einzelnen Skills wiederum werden zusätzlich
Schlüsselwörter erfasst (siehe Abbildung 7, S. 16).
15
2 Theoretische Grundlagen
Abbildung 7: Konfigurationsmaske für Skills in SkiP
16
2 Theoretische Grundlagen
2.2 Web 2.0 – Das neue WWW?
Der Begriff „Web 2.0“ entstand 2004 auf einer Brainstorming-Sitzung für eine neue
Internet-Konferenz41. Diese Konferenz kennzeichnet den Umbruch in der Zeit nach dem
Platzen der Dotcom-Blase im März 200042.
Als Hauptunterschied zwischen „Web 1.0“43 und Web 2.0 wird vorrangig die
Interaktivität der angebotenen Dienste herausgestellt44. Jeder Benutzer und damit
Konsument von Informationen kann gleichzeitig zum Autor werden und anderen
Nutzern Informationen zur Verfügung stellen. Diese Interaktivität war jedoch vom
Erfinder des WWW, Tim Berners-Lee45, bereits ursprünglich beabsichtigt:
„I wanted the Web to be what I call an interactive space where everybody can edit. And I started saying 'interactive', and then I read in the media that the Web was great because it was 'interactive', meaning you could click. This was not what I meant by interactivity“46
Dies bekräftigte Berners-Lee auch 2006 in einem Interview mit IBM DeveloperWorks:
„Web 1.0 was all about connecting people. It was an interactive space, and I think Web 2.0 is, of course, a piece of jargon, nobody even knows what it means. (...) So Web 2.0, for some people, it means moving some of the thinking client side so making it more immediate, but the idea of the Web as interaction between people is really what the Web is.“47
Das Web 2.0 ist also kein grundlegender Umsturz, sondern eine Weiterentwicklung des
Web 1.0. Viele der Techniken, die die Basis von Web 2.0 bilden, sind schon seit dem
Jahr 2000 oder sogar noch früher bekannt und wurden lediglich weiterentwickelt und
verfeinert48. Die weitere Verbreitung breitbandiger Internetzugänge49 und die weltweit
steigende Anzahl der Internetbenutzer50 treiben die Verbreitung der Web 2.0-Nutzung
weiter voran.
41 Vergl. Schiller García, J. (2007), S. 1 42 Im März 2000 kam es an den internationalen Aktienmärkten zu drastischen Kursverlusten, die vor
allem so genannte Dotcom-Unternehmen (junge, z.T. Dramatisch überbewertete IT-Unternehmen) betraf. Dies wird allgemein auch als das „Platzen der Dotcom-Blase“ bezeichnet. Siehe bspw. Wikipedia - Dotcom-Blase (2008)
43 Als „Web 1.0“ wird hier und im Folgenden der Zustand vor „Web 2.0“ betitelt. 44 Vergl. O'Reilly, T. (2005) 45 Vergl. Berners-Lee, T. (1989) 46 Aus Berners-Lee, T. (1999) 47 Aus Laningham, S. (2006) 48 Vergl. Krasser, N.; Foerster, M. (2007) 49 Vergl. die Langzeitstudie Fisch, M.; Gscheidle, C. (2006) bzw. aktuelle Ergebnisse in Fisch, M.;
Gscheidle, C. (2008a) 50 Vergl. World Internet Statistics (2008)
17
2 Theoretische Grundlagen
Vieles, was mit dem Web 2.0 möglich ist, war es vorher auch schon – nur ist es jetzt
einfacher. Der Begriff des Web 2.0 ist daher nicht scharf abgrenzbar. Zur
Unterscheidung werden im folgenden wichtige Kennzeichen bzw. Kriterien für
Web 2.0-Dienste erörtert.
2.2.1 Neue Dienste
Tim O'Reilly definierte 2005 Web 2.0 vor allem über neue Dienste (siehe Tabelle 1).
Prinzipiell bieten diese neuen Dienste dem Benutzer einen vergleichbaren Nutzwert
gegenüber den traditionellen Web 1.0-Diensten. Geändert hat sich allerdings die Art, in
der die Dienste Informationen bereitstellen und die Benutzer teilhaben können.
Web 1.0 Web 2.0DoubleClick Google AdSense
Ofoto FlickrAkamai BitTorrent
mp3.com NapsterBritannica Online Wikipediapersonal websites blogging
evite upcoming.org and EVDBdomain name speculation search engine optimization
page views cost per clickscreen scraping web services
publishing participationcontent management systems wikis
directories (taxonomy) tagging ("folksonomy")stickiness syndication
Tabelle 1: Gegenüberstellung von Diensten im Web 1.0 und Web 2.051
Stellte „Mp3.com“52 zentrale Server, bei denen Musik heruntergeladen werden konnte,
so waren die Inhalte bei Napster53 und dessen Nachfolger in einem Peer-to-peer-
Netzwerk verfügbar. Jeder Nutzer wird zugleich auch zum Anbieter von Inhalten.
Inzwischen ist Napster von der Tauschbörse zum kommerziellen Musikanbieter
gewandelt. 51 Aufstellung neuer Dienste aus O'Reilly, T. (2005) 52 Musikdienst, zu finden unter http://www.mp3.com/53 Musikdienst, zu finden unter http://www.napster.com/ Napster.com war ursprünglich ein Peer-to-peer-
Dienst, später wurde das Geschäftsmodell auf Musikabonnements umgestellt.
18
2 Theoretische Grundlagen
Konnten Benutzer die Inhalte von bspw. „Britannica Online“54 konsumieren, so können
sie bei Wikipedia55 hingegen aktiv eingreifen und die Inhalte ändern. Der Leser wird
zum Autor und kann so das Gesamtwerk verbessern.
Die neuen Dienste sind vorrangig durch die direkte Möglichkeit der Interaktion
gekennzeichnet. Der Konsument der Informationen wird zugleich zur Informations-
quelle.
2.2.2 Verlängerte Beta-Phase
Viele Web 2.0-Dienste werden in einer frühen Entwicklungsphase für einen begrenzten
Benutzerkreis geöffnet. Die Teilnahme an einem solchen Beta-Test erfolgt auf
Einladung56. GoogleMail57, der E-Maildienst des amerikanischen Suchmaschinen-
betreibers Google, ist auch heute noch, über 5 Jahre nach dem Start, in der Beta-Phase.
Der klassische Entwicklungszyklus von Software wird hier durch eine permanente Beta-
Phase abgelöst. Die Entwicklung des Dienstes erfolgt vor den Augen der Nutzer und
bezieht diese aktiv mit ein58.
54 Online-Nachschlagewerk, zu finden unter http://www.britannica.com/ Mittlerweile versucht auch Britannica Online den Benutzer über Kommentar- und Feedback-Möglichkeiten einzubinden.
55 Online-Nachschlagewerk, zu finden unter http://de.wikipedia.org/Alle Artikel von Wikipedia werden von der Gemeinschaft der Nutzer erstellt und gepflegt.
56 Zum Start im April 2004 war die Teilnahme an GoogleMail nur auf eingeladene Benutzer beschränkt. Die Benutzerkonten bei GoogleMail waren allerdings so begehrt, dass Einladungen zur Eröffnung eines Kontos im Internet gehandelt wurden. Anfang Juli 2004 versuchte Google dies über eine Änderung der Benutzungsbedingungen zu unterbinden (vergl. Pakalski, I. (2004)). Anfang Februar 2007 schließlich öffnete Google den Dienst endgültig für alle interessierten (vergl. Pakalski, I.(2007)).
57 E-Maildienst, zu finden unter http://mail.google.com/International ist der Dienst als GMail bekannt, aufgrund von Namensrechten wurde der Dienst in Deutschland im Juni 2005 in GoogleMail umbenannt. Im Oktober 2005 musste auch der Dienst in England aufgrund ähnlicher Namensstreitigkeiten in GoogleMail umbenannt werden.
58 Vergl. Alby, T. (2008), S. 155
19
2 Theoretische Grundlagen
2.2.3 Mash-ups
Durch offene APIs ermöglichen die Dienste Mash-ups59, die Erweiterung eines Dienstes
um die Funktionen eines Anderen. Beispielsweise ermöglicht Google Earth60 die
Anzeige von Bildern, die bei der Bilderdatenbank Flickr hinterlegt sind, anhand
virtueller Stecknadeln auf dem Globus61.
Durch die Kombination von Diensten in Mash-ups entsteht ein Mehrwert für den
einzelnen Dienst. Google Maps62 gewinnt bspw. durch die Möglichkeit, Bilder aus
anderen Diensten wie Flickr anzuzeigen, andere Dienste wie bspw. Qype63 gewinnen
wiederum durch die Möglichkeit, eine interaktive Kartenansicht von Google Maps
einzubinden und mit ihren Daten anzureichern.
2.2.4 Verschlagwortung – Tags
Neben den eigentlichen Inhalten kommt der Verschlagwortung eine große Bedeutung
zu. Im traditionellen Web 1.0 erfolgte diese zentral durch den Autor innerhalb einer
festgelegten Kategorisierung. Die Benutzer konnten diese Kategorisierung nicht
verändern und mussten sie hinnehmen. Im Web 2.0 hingegen erlauben es fast alle
Anwendungen dem Benutzer „Tags“ (Etiketten) frei zu vergeben. Jeder kann somit dazu
beitragen, dass Inhalte kategorisiert und somit leichter gefunden werden.
In Tabelle 1 auf S. 18 wird die „Taxonomy“ durch die „Folksonomy“64 (eine
Zusammensetzung aus „Folks“ (Leute) und „Taxonomy“ (Klassifizierung)) abgelöst.
Nach Tim O'Reilly kommt das Tagging der Funktionsweise des menschlichen Gehirns
näher als eine einfache Kategorisierung:
„Tagging allows for the kind of multiple, overlapping associations that the brain itself uses, rather than rigid categories.“65
59 Der Begriff „Mash-up“ beschreibt die Neuzusammenstellung bereits vorhandener Tonspuren zu einem neuen Lied und wird hier auf die neue Zusammenstellung vorhandener Anwendungen übertragen. Vergl. hierzu Cruger, R. (2003).
60 Google Earth stellt einen virtuellen dreidimensionalen Globus bereit. Das hierzu notwendige Programm kann unter http://earth.google.de heruntergeladen werden.
61 Vergl. Kaufmann, T. (2005) 62 Google Maps stellt die Daten von Google Earth in modernen Browser ohne Softwareinstallation zur
Verfügung. Die Darstellungs- und Navigationsmöglichkeiten sind gegenüber Google Earth einge-schränkt, aber dafür kann dieser Dienst leicht in andere Web 2.0-Dienste integriert werden.
63 Qype bietet ein Verzeichnis lokaler Gaststätten und ein entsprechendes Bewertungssystem an. Qype ist im Internet unter http://www.qype.com/ zu finden.
64 Vergl. Smith, G. (2004) 65 Vergl. O'Reilly, T. (2005)
20
2 Theoretische Grundlagen
O'Reilly, T. (2005) brachte bereits die Blogs66 und deren Vernetzung innerhalb der
Blogger mit der „Weisheit der Vielen“67 in Verbindung68. Auch für Tags ergibt sich
eine ähnliche Wirkung durch die Vergabe von Tags durch viele Personen.
Da Tags frei vergeben werden können, ergibt sich fast zwangsläufig ein große Menge
zur Beschreibung eines Inhaltes. Zur übersichtlichen Darstellung wird häufig eine der
zwei im Folgenden beschriebenen Anzeigeformen verwendet.
Abbildung 8: Darstellung von Tags als Liste und als Wolke
• Darstellung als Liste
In der Listendarstellung werden die Tags nach der Häufigkeit ihrer Nennung
sortiert aufgelistet. Die zuerst gelisteten Tags sind für viele Benutzer die Tags,
die den Inhalt am Besten beschreiben. Die absolute bzw. relative Häufigkeit
kann dabei als zusätzliche Orientierungshilfe angezeigt werden.
• Darstellung als Wolke (Tag-Cloud)
Bei der Darstellung als Wolke werden alle Tags alphabetisch sortiert in einem
meist rechteckigen Bereich aufgelistet. Die Schriftgröße und -farbe richtet sich
dabei nach der Häufigkeit der Nennung. Somit treten die Tags, die für die
meisten Benutzer den Inhalt am Besten beschreiben, optisch hervor.
Abbildung 8 zeigt die Darstellung von Tags, einmal in Listenform mit Angabe der
absoluten Häufigkeit (linke Seite) und einmal als Wolke (rechte Seite). Beiden 66 Die Erläuterung von Blogs und der Blogosphäre erfolgt in Kapitel 2.2.6.3 67 Vergl. Surowiecki, J. (2004) 68 Vergl. O'Reilly, T. (2005)
21
2 Theoretische Grundlagen
Darstellungsformen liegt die selbe Menge Tags zugrunde. Gut ist zu erkennen, dass die
Darstellung als Wolke mehr Tags übersichtlicher darstellen kann, ohne die wichtigen
Tags untergehen zu lassen. Die Darstellung in einer Liste fügt hingegen eine Ordnung
auf Basis der Häufigkeiten hinzu, die wie im Fall der beiden letztgenannten Tags („cio“
und „teste“) allerdings nicht eindeutig ist.
2.2.5 Immer aktuell: Feeds
Die Technik der Feeds ist ebenfalls nicht neu – bereits 1999 wurden Feeds von
Netscape für „My Netscape Network“ (eine Nachrichtenseite) genutzt69. Rein technisch
betrachtet handelt es sich bei Feeds um Daten in einem definierten Format. Die
Aufbereitung zielt dabei auf die Lesbarkeit durch Maschinen bzw. Programme70. Es gibt
verschiedene Formate, die fast alle noch Verwendung finden und in Koexistenz genutzt
werden71:
• RSS (v0.9072, v0.9173, v9.274, v1.075, v2.076)
• Atom
Atom wurde im Dezember 2005 von der Internet Engeneering Steering Group77 unter
dem Namen RFC 428778 als empfohlener Standard verabschiedet und veröffentlicht.
Durch den vermehrten Einsatz von Systemen (bspw. Content Management Systeme,
kurz CMS) zur Verwaltung und Erzeugung von Inhalten im WWW kann die
Aktualisierung von Feeds zeitnah und automatisiert mit der Einstellung der eigentlichen
69 Vergl. Alby, T. (2008), S. 48 bzw. Netscape (1999) 70 Alby, T. (2008), S. 147ff erläutert die technischen Ausgestaltung und die Unterschiede der einzelnen
Formate. 71 Einen Überblick über die zeitliche Entwicklung der einzelnen Standards für Feeds ist bei Möller, E.
(2005), S. 151 nachzulesen. 72 Die Definition von RSS 0.90 war ursprünglich bei Netscape unter der Adresse
http://my.netscape.com/publish/help/quickstart.html zu finden. Allerdings ist diese Seite nicht mehr verfügbar. Eine Kopie der Seite ist jedoch unter http://www.purplepages.ie/RSS/netscape/rss0.90.html zu finden. Vergl. Netscape (1999).
73 Zur Definition von RSS 0.91 vergl. UserLand Software (2000) 74 Zur Definition von RSS 0.92 vergl. UserLand Software (2003) 75 Zur Definition von RSS 1.0 vergl. Beged-Dov, G. et al. (2008) 76 Zur Definition von RSS 2.0 vergl. Winer, D. (2007) 77 Die Internet Engeneering Steering Group ist ein Teil der Internet Engineering Task Force (IETF),
einer nicht kommerziellen Organisation, die sich die Standardisierung und Verbesserung des Internets zum Ziel gesetzt hat. Siehe auch http://www.ietf.org/iesg.html. Die Beschreibung des Ziels der Organisation ist unter http://www.ietf.org/rfc/rfc3935.txt nachzulesen.
78 RFC steht für „Request for Comments“ und bezeichnet Dokumente, die noch kein Standard sind. Allerdings erhebt die IETF RFCs zum Standard, ohne deren Bezeichnung zu ändern. Die vollständige Definition des RFC 4278 ist unter http://www.ietf.org/rfc/rfc4287.txt einsehbar.
22
2 Theoretische Grundlagen
Inhalte erfolgen. Somit kann die Aktualität der per Feed verbreiteten Informationen
sichergestellt werden.
Feeds können durch Webseiten zusammengeführt werden. Beispielsweise können sich
Benutzer von „Mein Yahoo“79 ein individuelles Portal aus verschiedensten Angeboten
und Webdiensten, die ihre Inhalte per Feed liefern, zusammenstellen.
Feeds können aber auch vom Benutzer abonniert werden. Zur Verwaltung der
Abonnements und zum Lesen der Feeds gibt es eine Vielzahl so genannter Feedreader.
Diese Programme rufen die Inhalte periodisch ab, ohne dass der Benutzer sich darum
kümmern muss. Ein Feedreader kann sowohl ein lokal installiertes Programm (bspw.
Mozilla Thunderbird, Mozilla Firefox80, IBM Lotus Notes ab v8.0), aber auch ein
Online-Dienst im Internet (bspw. Google Reader81 oder Bloglines82) sein.
2.2.6 Web 2.0-Anwendungen am Beispiel von Connections
IBM Lotus Connections83 ist ein kommerziell erhältliches Produkt. Es bietet ein Paket
aus fünf verschiedenen Web 2.0 Anwendungen für den Einsatz in Unternehmen.
Anhand dieser Anwendungen werden im Folgenden typische Web 2.0 Anwendungen
im Detail betrachtet.
2.2.6.1 Die Anwendung ProfilesIn einem Profil werden bestimmte persönliche Daten eines Benutzer ähnlich denen auf
einer Visitenkarte gespeichert.
Jeder Benutzer von Connections bekommt automatisch ein Profil. Zur eindeutigen
Identifikation wird die E-Mailadresse des Benutzers verwendet.
Jedem Benutzer ist es möglich, Tags für sein eigenes und die Profile anderer zu
vergeben und somit den Informationsgehalt anzureichern.
79 Mein Yahoo ist in der deutschen Fassung unter http://de.my.yahoo.com/ im Internet zu finden.80 Mozilla Firefox bietet eine rudimentäre Funktion namens „Live Bookmarks“. Über Erweiterungen,
wie bspw. „Sage“ kann Firefox allerdings zu einem vollwertigen Feedreader ausgebaut werden. Sage kann unter der Adresse https://addons.mozilla.org/de/firefox/addon/77 heruntergeladen werden.
81 Zu finden unter http://www.google.de/reader82 Zu finden unter http://www.bloglines.com/83 Aktuelle Informationen zu IBM Lotus Connections sind bei IBM im Internet unter der Adresse http://
www.ibm.com/software/lotus/products/connections/ zu finden.
23
2 Theoretische Grundlagen
Zu den gespeicherten Daten eines Profils zählen:
• Persönliche Informationen (bspw. Name, Beruf, Foto)
• Kontaktinformationen (bspw. Telefonnummer, E-Mailadresse)
• Ortsbezogene Informationen (bspw. Büro, Stockwerk, Gebäude)
• Angaben zur Hierarchie (bspw. Berichtskette, Assistent)
• Beschreibende Angaben (bspw. „Über mich“, „Hintergrund“).
Abbildung 9: Beispiel eines Profils in der Anwendung Profiles
Zudem enthält die Anwendung noch eine Komponente der Sozialen Netzwerke84: Der
Benutzer kann seinem Profil Kollegen zuordnen (siehe Abbildung 9) und somit seine
84 Eine weiterführende Abgrenzung des Begriffs „Soziales Netzwerk“ ist bspw. bei Poller, A. (2008), S. 10 zu finden. In dieser Studie wird zudem auf die Risiken der Nutzung solcher Plattformen im Internet eingegangen.
24
2 Theoretische Grundlagen
Beziehungen im Unternehmen abseits der Hierarchie dokumentieren. Der Vernetzung
zu den anderen Anwendungen wird dadurch Rechnung getragen, dass bspw. die
Lesezeichen, die der Benutzer in der Anwendung „Dogear“ (siehe Kapitel 2.2.6.4)
angelegt hat, im Kontext seines Profils angezeigt werden. Andere Informationen wie
bspw. Blogeinträge, Diskussionsbeiträge oder Aktivitäten werden ebenfalls im Kontext
eines Profiles angezeigt.
Diese Anwendung weist durch die geführten Informationen (Tags, Beschreibung von
Tätigkeiten und Projekterfahrung, etc.) Übereinstimmungen mit Expertensystemen85
auf. Daher zählt sie sowohl zu den Skill-Management-Anwendungen, als zu denen des
Web 2.0.
Typische Vertreter dieser Art von Applikation im Web 2.0 sind bspw. Xing86 oder
LinkedIn87. Auf diesen Portalen sollen mögliche Geschäftspartner gefunden und
bestehende Geschäftsbeziehungen gepflegt werden. Xing verbindet ebenso wie
LinkedIn den Gedanken des sozialen Netzwerks mit dem der Diskussionsforen88.
2.2.6.2 Die Anwendung CommunitiesDiskussionsforen erfreuen sich im WWW großer Beliebtheit89. Sie stellen eine
Plattform zum gemeinsamen Austausch im Internet dar. Jeder Benutzer (zumeist ist eine
Anmeldung erforderlich) kann eine Diskussion (Thread) eröffnen. Große Diskussions-
foren sind häufig in kleinere Unterforen aufgeteilt. Die Mitglieder eines Forums können
sich üblicherweise per E-Mail über neue Beiträge informieren lassen.
Communities stellt eine Erweiterung diese Anwendungsgattung dar: Benutzer können
beliebig Gemeinschaftsbereiche, hier Communities genannt, eröffnen und sich darin
austauschen. Communities können frei zugänglich, auf Anfrage zugänglich oder privat
sein.
Innerhalb einer Community ist die zentrale Funktion das eingangs erwähnte
Diskussionsforum, in das die Mitglieder Diskussionsbeiträge einstellen können.
Weiterhin können gemeinsame Lesezeichen verwaltet werden. Feeds aus anderen
85 Vergl. Kapitel 2.1.2 86 Xing ist als Open Business Club, kurz OpenBC, zum 01.01.2004 offiziell gestartet, wurde aber zum
01.10.2006 umbenannt und ist nun unter http://www.xing.com erreichbar. 87 LinkedIn ist im amerikanischen Raum sehr verbreitet und unter http://www.linkedin.com zu finden. 88 Vergl. hierzu Kapitel 2.2.6.2 89 Vergl. Fisch, M.; Gscheidle, C. (2008b), S. 361
25
2 Theoretische Grundlagen
Bereichen von Connections oder dem Internet können für eine Community abonniert
werden und stehen somit allen Mitgliedern zentral zur Verfügung.
Auch Communities werden von Ihren Mitgliedern mittels Tags verschlagwortet.
Abbildung 10 zeigt eine Übersicht über alle verfügbaren Communities innerhalb der
Connections-Installation. Die daraus generierte Tag-Cloud ist am linken Rand
eingeblendet.
Benutzer können Communities als Feed abonnieren, um immer über aktuelle
Meldungen informiert zu werden. Ein Abonnement in Form von E-Mail ist nicht
vorgesehen.
Abbildung 10: Die Anwendung Communities
26
2 Theoretische Grundlagen
Die Integration mit den übrigen Anwendungen ermöglicht es bspw., dass eine
Community eine eigene Sammlung von Lesezeichen (siehe Kapitel 2.2.6.4) anlegt oder
ihre Aktivitäten (siehe Kapitel 2.2.6.5) verwaltet.
Diskussionsforen werden häufig und zu den verschiedensten Themen im WWW
angeboten. Als Beispiele hierfür sei auf das Diskussionsforum der Tagesschau90 als
Vertreter der nachrichtenbezogenen Foren und die Winfo-Foren der Universität
Paderborn91 als bildungsorientierte Foren hingewiesen.
2.2.6.3 Die Anwendung BlogsDer Begriff „Blog“ ist die Abkürzung des Begriffs „Weblog“. „Weblog“ wiederum ist
die Zusammensetzung von „Web“ und „Log“ (Log bzw. Tagebuch). Doctorow, C. et al.
(2002) definieren einen Blog folgendermaßen:
„A blog is a web page that contains brief, discrete hunks of information called posts. These posts are arranged in reverse-chronological order (the most recent posts come first). Each post is uniquely identified by an anchor tag, and it is marked with a permanent link that can be referred to by others who wish to link to it.“92
Im Unterschied zu den zuvor beschriebenen Communities geht die Initiative bei Blogs
immer vom Autor aus. Zwar können auch mehr als eine Person Autor eines Blogs93
sein, generell ist die Zahl der Autoren aber sehr viel kleiner als bei Diskussionsforen.
Robert Basic umschreibt den Unterschied in einem Blogeintrag so:
„Blogs sind keine Gemeinschaftswohnungen. Es gibt einen Hausbewohner, den Gäste je nach Bedarf besuchen, weil er möglicherweise leckeren Kaffee und Kuchen anzubieten hat. Auf Foren und Newsgroups machen die Hausbewohner gemeinsam die Musik, jeder kann dazu seinen Kuchen mitbringen. Party! Auf einem Blog macht nur einer die Musik, er bestimmt die Lautstärke, er backt den Kuchen.“94
Über Blogs können große Mengen an Empfängern angesprochen werden, ähnlich etwa
zu E-Mail-Newslettern. Da die Inhalte von Blogs vom Benutzer aktiv abgerufen werden
müssen, füllen diese nicht ungefragt den Posteingang des Benutzers. Blogs können
typischerweise als Feed abonniert werden.
90 Das Diskussionsforum der Tagesschau ist unter http://forum.tagesschau.de zu finden. 91 Die Winfo-Foren sind unter http://pbwi2b.uni-paderborn.de/accessdb/public/pn-talk.nsf zu finden. 92 Definition aus Doctorow, C. et al. (2002), S. 1 93 Vergl. Alby, T. (2008), S. 22 94 Aus Basic, R. (2005)
27
2 Theoretische Grundlagen
Blog-Einträge können von den Lesern kommentiert werden. Dabei ist es möglich,
mittels eines Trackback-Links95 auf einen eigenen Blog zu verweisen. Gängige Blog-
Systeme bieten sogenannte Permalinks96, permanente Verweise, auf die einzelnen
Blogeinträge.
Auch bei Blogs spielt das Thema Tagging eine wichtige Rolle: Ein Blog selbst, aber
auch die einzelnen Beiträge, können mit Tags versehen werden. Dies erfolgt allerdings
ausschließlich durch den Autor, nicht durch die Leser.
Abbildung 11: Die Anwendung Blogs
95 Das Konzept von Trackback-Links erläutert Alby, T. (2008), S. 23, Das entsprechende Protokoll ist in Six Apart (2004) dokumentiert.
96 Vergl. Alby, T. (2008), S. 23
28
2 Theoretische Grundlagen
Die Anwendung Blogs bietet neben der Möglichkeit der Kommentierung auch die
Möglichkeit, Blogeinträge zu empfehlen. Die Anzahl der Empfehlungen für einen
Beitrag wird über Stern-Symbole visualisiert (siehe Abbildung 11, S. 28).
Es gibt viele Dienste im Internet, die es ermöglichen, kostenlos einen eigenen Blog zu
schreiben. Beispiel hierfür sind wordpress.com97 oder blog.de98. Zudem gibt es spezielle
Portale und Suchmaschinen99, die das Auffinden von Blogs für potentielle Leser
einfacher gestalten sollen.
2.2.6.4 Die Anwendung DogearDogear bedeutet übersetzt soviel wie Eselsohr, also Lesezeichen. Bereits 2005
beschäftigten sich Mitarbeiter von IBM mit dem Thema „Social Bookmarking“ in
Unternehmen100. Benutzer verwalten ihre Lesezeichen üblicherweise direkt im Browser.
Hier sind die Lesezeichen aber nur für sie persönlich zugänglich. Beim Social
Bookmarking werden die Lesezeichen nicht lokal, sondern bei einem Web-Dienst
gespeichert. Prominente Vertreter dieser Dienste sind bspw. del.icio.us101 oder
Mister Wong102.
Lesezeichen werden anderen Benutzern so zugänglich gemacht. Diese erhalten dadurch
qualifizierte Verweise103 auf interessante Internetseiten.
Lesezeichen können vom Ersteller per Tag verschlagwortet werden. Eine Suche nach
Informationen ist aber nicht auf die Suche über Tags beschränkt. So ist es bspw.
möglich, die Lesezeichen eines bestimmten Benutzers anzeigen zu lassen. Dies ist
besonders interessant, wenn man den Benutzer kennt und um dessen Interessen weiß.
Durch das Finden neuer Lesezeichen und das Erkunden der weiteren Lesezeichen des
zugehörigen Benutzers lassen sich verwandte Informationen finden, nach denen nicht
direkt gesucht wurde.
97 Unter http://www.wordpress.com zu finden 98 Deutschsprachiges Blog-Portal und Anbieter für private Blogs, unter http://www.blog.de zu finden 99 bspw. Technorati, ein internationales Blog-Portal, unter http://www.technorati.com zu finden 100 Vergl. Millen, D.; Feinberg, J.; Kerr, B. (2005) 101 Englischsprachiger Lesezeichen-Dienst, der Ende 2003 von Joshua Schachta entwickelt wurde, unter
http://del.icio.us oder http://www.delicious.com zu finden 102 Deutschsprachiger Lesezeichen-Dienst, unter http://www.mister-wong.de zu finden 103 Nach Abrams, D.; Baecker, R.; Chignell, M. (1998), S. 42 erstellen Benutzer Lesezeichen für
qualitativ gute Seiten, die sie persönlich interessieren und von denen sie denken, dass sie sie auch künftig noch nutzen werden.
29
2 Theoretische Grundlagen
Die Verknüpfung der Informationen bei einem solchen Dienst erlaubt es, Lesezeichen
nach ihrer Häufigkeit zu bewerten. Hier ergibt sich eine neue Qualität der Bewertung:
Die Verweise werden nicht automatisiert (bspw. bei Suchmaschinen wie Google) oder
redaktionell (bspw. bei Portalen wie Web.de), sondern von den Benutzern selbst
gewichtet104.
Abbildung 12: Die Anwendung Dogear
Firmeninterne Verweise auf das Intranet sollen aus Sicherheits- und
Geheimhaltungsgründen nicht im Internet verfügbar sein. Die Anwendung Dogear
(siehe Abbildung 12) erlaubt es daher, firmeninternes Social Bookmarking zu betreiben.
Die Integration mit den anderen Anwendungen (bspw. Profiles oder Communities)
schafft einen zusätzlichen Nutzen. Lesezeichen einer Community können bspw. neben
den eigenen Lesezeichen verwaltet werden.
104 Vergl. Alby, T. (2008), S. 95
30
2 Theoretische Grundlagen
2.2.6.5 Die Anwendung ActivitiesDie letzte Anwendung von Connections dient der Verwaltung von Aktivitäten. Diese
Aktivitäten können dabei alleine (analog einer Aufgabenverwaltung) oder im Team
bearbeitet werden. Der Inhalt einer Aktivität ist nicht festgelegt: Angefangen von der
einfachen Beschaffung von Druckerpapier bis hin zur hoch komplexen Organisation
einer internationalen Messe sind viele verschiedene Anwendungsfälle denkbar.
Aktivitäten können über ein Berechtigungssystem gesteuert werden. Es gibt drei
verschiedene Benutzerrollen (Besitzer, Autor und Leser) und Aktivitäten können privat
oder öffentlich sein.
Durch das Hinzufügen von Aufgaben, setzen von Terminen und der Gliederung in
Teilabschnitte können Aktivitäten strukturiert werden. Dabei kann flexibel auf die
aktuelle Situation eingegangen werden.
Abbildung 13: Die Anwendung Activities
Aktivitäten können viele verschiedene Informationen aufnehmen, die im Kontext der
Aufgabe wichtig sind (siehe Abbildung 13). Durch das Hinzufügen von Dokumenten,
E-Mails oder Chat-Protokollen wird nachvollziehbar für alle Teilnehmer dokumentiert,
31
2 Theoretische Grundlagen
wie sich die Bearbeitung entwickelt hat. Jedes Element kann dabei mittels Tags
verschlagwortet werden.
Änderungen an Aktivitäten sind als Feed105 abonnierbar. So ist es den Mitgliedern
mehrerer Aktivitäten möglich, unkompliziert auf dem aktuellsten Stand zu sein.
Eine durchgeführte Aktivität kann als Vorlage für die Struktur einer neuen dienen. So
können bewährte Abläufe wiederverwendet werden. Die Stärke der Aktivitäten liegt in
der flexiblen Abwicklung schwach strukturierter Abläufe.
Aktivitäten können gegenüber unternehmensfremden Personen geöffnet werden und
ermöglichen so eine unternehmensübergreifende Zusammenarbeit.
2.3 Berührungspunkte zwischen Skill-Management und Web 2.0
Die Anwendungen des Web 2.0 speichern zum Teil ähnliche Informationen zu den
Fähigkeiten von Personen, wie die Anwendungen des klassischen Skill-Managements.
Das beste Beispiel hierfür ist die Anwendung Profiles, die von der Grundintention her
ein Benutzerverzeichnis ist, durch die zusätzlichen Informationen wie selbstverfasste
Kurzbeschreibungen und die Möglichkeit der Vergabe von Tags aber bereits ein
einfaches Expertensystem darstellt.
Auch die anderen Anwendungen sind im Zusammenhang mit Skill-Management
interessant: Durch die Verwendung der Anwendungen Communities, Blogs und Dogear
wird ein Wissensbestand dokumentiert, der in dieser Tiefe nicht in klassischen
Wissensdatenbanken oder Dokumenten erfasst würde. Durch die Vernetzung dieser
Informationen mit den Personen aus Profiles ergibt sich hier eine leicht zugängliche
Informationsquelle, deren Pflege „synchron“ zur eigentlichen Arbeit erfolgt. Diese
Anwendungen liegen daher dem Wissensmanagement näher. Aber auch das Skill-
Management kann von den gespeicherten Informationen profitieren.
Activities dienen eher zur Arbeitsorganisation. Aber auch sie können Grundlagenwissen
dokumentieren. Wenn bspw. zum zweiten Mal ein Messe-Auftritt organisiert werden
muss, ist der Rückgriff auf bereits gemachte Erfahrungen sehr wertvoll.
105 Siehe Kapitel 2.2.5
32
2 Theoretische Grundlagen
Der Ansatz des Web 2.0, jeden Benutzer zugleich zum Autor zu machen, stellt die
Wissensbasis auf ein breites Fundament. Surowiecki, J. (2004) erkannte, dass
„(...) under the right circumstances groups are remarkebly intellegent, and are often smarter than the smartest people in them. Groups do not need to be dominated by exeptionally intelligent people in order to be smart. Even if most of the people within the group are not especially well-informed or rational, it can still reach a collectivly wise decision.“106
Diese „Weisheit der Vielen“ lässt sich bspw. anhand der Vergabe von Tags nutzen: Die
Tags, die von vielen Personen vergeben werden, sind meist treffender als die
Schlagworte, die bspw. redaktionell vergeben wurden.
Die Anwendung Profiles ist zum Teil dem Skill-Management zuzuordnen und die
Vergabe von Tags in Web 2.0 Anwendungen spiegelt die Einschätzung der Skills von
vielen Kollegen wieder. Ein einfacher Austausch zwischen den Systemen ist daher ein
logischer Schritt.
106 Aus Surowiecki, J. (2004), S. xiii-xiv
33
3 Konzeption der Schnittstelle
3 Konzeption der Schnittstelle
Wie bereits in den vorangehenden Kapiteln aufgezeigt, gibt es offensichtliche
Berührungspunkte zwischen Anwendungen des Skill-Managements und Web 2.0-
Anwendungen.
Für die Konzeption einer Schnittstelle zwischen SkiP und Connections, als ausgewählte
Vertreter dieser beiden Bereiche, werden zunächst die organisatorischen Rahmen-
bedingungen geklärt.
Die technischen Vorüberlegungen ergänzen diese anschließend um den Aspekt der
technischen Machbarkeit.
Zum Verständnis des API von Connections wird die Basis-Technologie, Atom-Feeds
und das Atom Publishing Protocol, genauer betrachtet.
Zur inhaltlichen Ausgestaltung der Schnittstelle werden schließlich mögliche
Integrationsszenarien aufgestellt, bewertet und ausgewählt.
3.1 Organisatorische Rahmenbedingungen
Die Anwendung SkiP verarbeitet sensible personenbezogene Informationen. Daher soll
die hier betrachtete Integration nur von der Anwendung SkiP selbst ausgehen. In SkiP
gespeicherte Informationen dürfen aus Sicherheits- und Datenschutzgründen nicht von
außerhalb verändert werden.
Jegliche Aktion zur Datenübertragung zwischen den Systemen soll vom Benutzer selbst
ausgelöst werden. So wird verhindert, dass der Eindruck entsteht, die vertraulichen
Informationen seien in SkiP nicht sicher.
Die Integration soll den normalen Benutzer im Fokus haben. Er soll durch die
Integration einen Vorteil in der Verknüpfung der beiden Welten sehen und somit soll
die Nutzung beider Anwendungsbereiche gefördert werden.
34
3 Konzeption der Schnittstelle
3.2 Technische Vorüberlegungen
3.2.1 Die technische Basis von SkiP
Als technische Basis für SkiP wurde IBM Lotus Domino107 verwendet. Diese Plattform
zeichnet sich unter anderem durch ihre vielfältigen Möglichkeiten zur Integration von
Dritt-Software und zur Entwicklung von Anwendungen aus108. Aufgrund dieser
Eigenschaften von Domino ist diese Plattform ebenfalls als Basis einer Schnittstellen-
komponente gut geeignet.
Da es sich bei SkiP weder um eine kommerzielle Software, noch um ein fertiges
Produkt handelt, kann auf kein existierendes API zurückgegriffen werden.
SkiP ist eine Browser-Anwendung. Bei der Integration ist also entsprechend darauf zu
achten, dass die zu entwickelnde Schnittstelle mittels Web-Techniken in das Benutzer-
interface von SkiP integriert werden kann.
3.2.2 Die technische Basis von Connections
Connections basiert auf einem IBM WebSphere Application Server, braucht aber keine
bereits vorhandene Software – alle benötigten Server-Komponenten werden in
speziellen Versionen mitgeliefert und dürfen gemäß der Lizenz nur für Connections
eingesetzt werden.
Zur Nutzung von Connections kann ein Server zum Betrieb einer eigenen Connections-
Installation aufgesetzt werden. Die Voraussetzungen und Vorgehensweise für die
Installation und den Betrieb einer eigenen Connections-Installation sind in Dokument
IBM - Connections Install (2008) aufgeführt.
Außerdem bietet IBM die Nutzung von Connections als Service an. Auf der Internet-
Seite Lotus Live109 wird dieser Service unter dem Namen „Lotus Live Engage“ als
Mietsoftware angeboten. Derzeit110 sind jedoch lediglich Test-Zugänge und noch
keinerlei Preisangaben verfügbar.
107 Aktuelle Informationen zu IBM Lotus Domino sind bei IBM im Internet unter der Adresse http://www.ibm.com/software/lotus/products/domino/ zu finden
108 Knäpper, M.; Donskoj, M. (2007) geben einen Überblick über die Entwicklung von Anwendungen auf Basis von IBM Lotus Domino.
109 Im Internet unter http://www.lotuslive.com/ zu finden 110 Stand März 2009
35
3 Konzeption der Schnittstelle
Um einen Eindruck111 von Connections zu erhalten, kann auf der Seite Lotus Green-
house112 der Umfang von Connections getestet werden. Dieser Zugang wurde auch im
Rahmen dieser Arbeit zum Test und zur Entwicklung genutzt.
Connections stellt ein auf offenen Web-Standards basierendes API bereit. Eine
Dokumentation des API ist im Internet113 abrufbar.
Bei der Durchsicht der Dokumentation wird schnell klar, dass es sich eigentlich um fünf
eigenständige Anwendungen handelt. Zwar sind die APIs technisch gleich, sind aber in
jeder Anwendung etwas abweichend implementiert. Dies wird vor allem bei den
unterschiedlich konstruierten URLs und den URL-Parametern deutlich. Eine spezielle
Implementierung je Applikation ist daher unumgänglich.
3.3 Atom-Feeds und das Atom Publishing Protocol
3.3.1 HTTP (Hypertext Transfer Protocol)
Die Basis für den Austausch von Daten mit Connections bildet das Hypertext Transfer
Protocol (HTTP)114 bzw. die gesicherte Variante Hypertext Transfer Protocol Secure
(HTTPS)115. Dieses Protokoll ist durch die Verwendung im WWW zum Abrufen von
Internet-Seiten bekannt.
HTTP116 ist ein zustandsloses Protokoll. Das bedeutet, dass jede Anfrage vom Server
getrennt von anderen Anfragen betrachtet wird. Sitzungsinformationen (bspw. die
Authentifizierung eines Benutzers gegenüber einem Server) müssen auf Anwendungs-
ebene verwaltet werden. Im WWW werden hierfür verschiedene Techniken, bspw. die
Mitgabe einer Session-ID in den aufgerufenen URLs117 oder das Setzen von Session-
Cookies118, verwendet.
111 Die einzelnen Anwendungen, die von Connections bereitgestellt werden, sind im Kapitel 2.2.6 beschrieben.
112 Im Internet unter http://greenhouse.lotus.com/ zu finden 113 Die Dokumentation des APIs in der aktuellen Version 2.0.1 ist im Internet unter
http://publib.boulder.ibm.com/infocenter/ltscnnct/v2r0/index.jsp zu finden 114 Das Hypertext Transfer Protocol ist von der IETF im RFC 1945 (HTTP/1.0, 1996) und RFC 2616
(HTTP/1.1, 1999) standardisiert worden. Die jeweilige Definition ist unter http://www.ietf.org/rfc/rfc1945 bzw. http://www.ietf.org/rfc/rfc2616 nachzulesen.
115 Das Hypertext Transfer Protocol Secure wurde von der IETF im RFC 2818 (HTTP Over TLS, 2000) standardisiert. Die Definition ist unter http://www.ietf.org/rfc/rfc2818 nachzulesen.
116 Im folgenden wird HTTP synonym für HTTP und HTTPS verwendet. 117 URL steht für Uniform Resource Locator. URLs dienen der Identifikation und Lokalisierung einer
Ressource über das verwendete Protokoll (bspw. HTTP oder HTTPS) sowie den Ort der Ressource. 118 Cookies sind auf dem Client persistente/gespeicherte Daten, die in HTTP-Requests mitgegeben
36
3 Konzeption der Schnittstelle
Eine Authentifizierung eines Benutzers gegenüber Connections erfolgt mittels der
HTTP-Basisauthentifizierungsmethode119 (Basic Authentication) über einen Benutzer-
namen und das zugehörige Kennwort.
3.3.2 Das Atom Syndication Format
Connections liefert Daten über HTTP als Feed im Atom Syndication Format120, kurz als
„Atom-Feed“. Verschiedene Formate von Feeds wurden bereits in Kapitel 2.2.5 kurz
vorgestellt. Das Atom Syndication Format, die Basis der Schnittstelle, wird hier
technisch genauer erläutert.
Atom-Feeds müssen nach bestimmten Regeln konstruiert sein. Die wichtigsten dieser
Regeln sind121:
• Alle Elemente eines Atom-Feeds müssen innerhalb des Namensraums122 http://
www.w3.org/2005/Atom liegen.
• Die Zeitangaben in einem Atom-Feed müssen nach dem RFC 3339123 erfolgen.
• Das Format von Werten muss angegeben werden, wenn es nicht Text ist. Dies
ist einer der Hauptunterschiede zu den RSS-Formaten124.
• xml:lang125 kann zur Angabe der Sprache bei Texten, die von Menschen gelesen
werden können/sollen, genutzt werden.
• xml:base kann genutzt werden, um zu bestimmen, wie relative URL-Angaben
aufgelöst werden sollen.
werden können. Methoden, mit Cookies Sitzungsinformationen zu verwalten sind im RFC 2109 (HTTP State Management Mechanism, 1997) bzw. RFC 2965 (HTTP State Management Mechanism, 2000) unter http://www.ietf.org/rfc/rfc2109.txt bzw. http://www.ietf.org/rfc/rfc2965.txt nachzulesen.
119 Details zu den verschiedenen möglichen Authentifizierungsmethoden und zu der hier verwendeten HTTP-Basisauthentifizierungsmethode sind unter http://www.ietf.org/rfc/rfc2617 nachzulesen.
120 Das Atom Syndication Format wurde vom IETF im RFC 4287 (The Atom Syndication Format, 2005) standardisiert. Die Definition ist unter http://www.ietf.org/rfc/rfc4287.txt nachzulesen.
121 Vergl. Alby, T. (2008), S. 154 122 Ein Namensraum definiert in XML Schlüsselwörter, und wie diese zu interpretieren sind. Weiter
Informationen hierzu in Bray, T. et al. (2006) 123 Vergl. RFC 3339 (Date and Time on the Internet: Timestamps, 2002) unter
http://www.ietf.org/rfc/rfc3339.txt124 Die RSS-Formate werden ebenfalls in Kapitel 2.2.5 vorgestellt. 125 XML-Elemente dürfen nicht mit der Zeichenkette „xml“ anfangen. An „xml“ ist ein Namensraum für
Elemente und Attribute gebunden, den das W3-Konsortium für Erweiterungen von XML reserviert hat. Die URI dieses Namensraums ist http://www.w3.org/XML/1998/namespace und muss nicht explizit angegeben werden. xml:lang und xml:base sind innerhalb dieses Namensraums definiert.
37
3 Konzeption der Schnittstelle
Abbildung 14 zeigt ein Beispiel eines einfach aufgebauten Atom-Feeds.
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom">
<title>Beispiel Feed</title><link href="http://www.beispiel.de/"/><updated>2005-03-30T00:33:02Z</updated><author>
<name>Dirk Stelloh</name></author><id>urn:uuid:30031975-c8ff-2345-a6cd-fafa6aefdbaa</id>
<entry><title>Beispieleintrag</title><link href="http://www.beispiel.de/2005/03/30/test"/><id>urn:uuid:1225c695-ffc8-4321-abcd-facfac4efa6a</id><updated>2005-03-30T00:33:02Z</updated><summary>Jubiläum!</summary>
</entry>
</feed>Abbildung 14: Beispiel für einen einfachen Atom-Feed
Element Pflicht Mehrfach Beschreibungid erforderlich - Eindeutige und permanente URL zur Identifi-
kation des Feeds title erforderlich - menschenlesbarer Titel des Feeds updated erforderlich - Datum und Uhrzeit der letzten Änderung author empfohlen x Autoren
Auf Ebene des Feeds darf dieses Element nur fehlen, wenn alle Eintrags-Elemente ein sol-ches Element besitzen.
link empfohlen x Link auf zugehörige Web-Seiten. Die Art der Zugehörigkeit wird über das Attribut „<rel>“ ausgedrückt.
category optional x Kategorien contributor optional x Mitwirkende generator optional - Software, die den Feed erstellt hat icon optional - Kleines Logo logo optional - Großes Logo rights optional - Rechte, bspw. Copyright subtitle optional - menschenlesbare Beschreibung oder Unterti-
tel des Feeds
Tabelle 2: Elemente von <Feed>
38
3 Konzeption der Schnittstelle
Ein Atom-Feed besteht aus Metadaten, die den Feed selbst (äußerer Kasten in
Abbildung 14, S. 38) beschreiben, und aus einem oder mehreren Einträgen (innerer
Kasten in Abbildung 14, S. 38). Die Elemente, die für einen Feed angegeben werden
können, sind in der Tabelle 2 auf S. 38, die Elemente für einen Entry sind in Tabelle 3
aufgelistet126. Einige Elemente dürfen mehrfach vorkommen, diese sind in der Spalte
„Mehrfach“ entsprechend markiert. Erforderliche Elemente sind in der Spalte „Pflicht“
entsprechend gekennzeichnet. Zudem wird für einige Elemente empfohlen, diese
aufzuführen. Auch diese Elemente sind in der Spalte „Pflicht“ gekennzeichnet. Alle
übrigen Elemente sind optional.
Einige Elemente, wie bspw. „author“, können wahlweise auf Ebene des Feed oder des
einzelnen Entry definiert werden. Diese Elemente und die Bedingungen sind in der
Spalte „Beschreibung“ näher erläutert.
Element Pflicht Mehrfach Beschreibungid erforderlich - Eindeutige und permanente URL zur Identifi-
kation des Eintrags title erforderlich - menschenlesbarer Titel des Eintrags updated erforderlich - Datum und Uhrzeit der letzten Änderung author empfohlen x Autoren
Auf Ebene des Eintrags darf dieses Element nur fehlen, wenn der Feed mindestens ein sol-ches Element besitzt.
content empfohlen - Link zum kompletten Inhalt des Eintrags link empfohlen x Link auf zugehörige Web-Seiten. Die Art der
Zugehörigkeit wird über das Attribut „<rel>“ ausgedrückt.
summary empfohlen - Kurze Zusammenfassung des Inhaltes category optional x Kategorien contributor optional x Mitwirkende published optional - Datum und Uhrzeit der Erstellung oder Zeit-
punkt zu dem der Eintrag zuerst zur Verfü-gung gestellt wurde
source optional - Verweis auf den ursprünglichen Feed, wenn der Eintrag aus einem anderen Feed kopiert wurde.
rights optional - Rechte, bspw. Copyright
Tabelle 3: Elemente von <Entry>
126 Eine englischsprachige Einführung in das Atom Syndication Format ist unter der folgenden Adresse abrufbar: http://www.atomenabled.org/developers/syndication/
39
3 Konzeption der Schnittstelle
3.3.3 AtomPub (Atom Publishing Protocol)
Das Atom Publishing Protocol127 wird von der Connections-API zur Kommunikation
verwendet. Dieses Protokoll baut auf der Kommunikation per HTTP auf und ermöglicht
die Abfrage, Bearbeitung, Erstellung und Löschung von Inhalten über vier elementare,
in Tabelle 4 aufgeführte, Aktionen128. Jede ausgetauschte Nachricht enthält dabei alle
notwendigen Informationen, um diese Nachricht zu verstehen.
Aktion BeschreibungGET Lesender Zugriff auf ein ElementPUT Schreibender Zugriff auf ein ElementPOST Erstellen eines neuen ElementsDELETE Löschen eines bestehenden Elements
Tabelle 4: Die Grundlegenden Aktionen des Atom Publishing Protocol
Connections folgt mit diesem API der Representational State Transfer Architektur
(REST), die Fielding, R.T. (2000) in seiner Dissertation definierte. Er fasst in seiner
Arbeit wie folgt zusammen:
“REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.”129
Der Vorteil einer REST-Architektur für eine Schnittstelle ist, dass keinerlei
Zustandsinformationen außerhalb der ausgetauschten Nachrichten vorgehalten werden
müssen. Jede der Nachrichten kann für sich interpretiert werden, ohne dass die
vorhergehenden bekannt sind.
127 Das Atom Publishing Protocol ist ebenfalls vom IETF standardisiert worden. Der Text RFC 5023 (The Atom Publishing Protocol, 2007) ist unter http://www.ietf.org/rfc/rfc5023.txt nachzulesen.
128 Diese vier Aktionen werden auch als CRUD-Operationen bezeichnet: Create, Read, Update und Delete
129 Aus Fielding, R.T. (2000), S. 98f. Eine detaillierte Beschreibung des Konzeptes REST ist im Kapitel 5 (S. 76-106) zu finden.
40
3 Konzeption der Schnittstelle
3.3.4 Das Framework Abdera
Ursprünglich hat IBM selbst ein Framework zur Implementierung des Atom Publishing
Protocol in Anwendungen entwickelt. Im Juni 2006 hat IBM jedoch den Quellcode der
Apache Software Foundation gestiftet130. Seitdem stellt die Apache Software
Foundation131 das Framework unter dem Namen Abdera132 frei133 zur Verfügung.
Dieses in der Programmiersprache Java verfasste Framework stellt Klassen zur
Vereinfachung der HTTP-Kommunikation und zur Verarbeitung von Atom-Feeds
bereit. Die wichtigsten Klassen134 aus dem Framework sind:
• Klasse „Abdera“
Die Wurzel aller Objekte im Abdera Framework ist die Abdera-Klasse.
Basierend auf dieser Klasse können weitere Objekt-Instanzen erstellt werden.
• Klasse „AbderaClient“
Diese Klasse stellt benötigte Funktionen von der Kommunikation bis zur
Verarbeitung von Feeds zur Verfügung. Viele der Funktionen werden dabei
durch weitere Klassen implementiert. Die AbderaClient-Klasse ist aber die Basis
für eine Anwendung, die mittels Atom Publishing Protocol kommunizieren
möchte.
• Klasse „ClientResponse“
Antworten, die mittels der AbderaClient-Klasse empfangen werden, sind
Instanzen der Klasse ClientResponse. Aus dieser Klasse können weitere
Informationsobjekte erstellt werden.
130 Vergl. Cappellato, J. (2006) 131 Im Internet zu finden unter http://www.apache.org/132 Das Framework Abdera ist nach dem Namen einer Stadt im antiken Griechenland benannt. Abdera ist
der Geburtsort des Philosophen Demokrit, der als Vater der Atomtheorie gilt. Vergl. hierzu auch Snell, J. (2006), Wikipedia - Abdera (2009) und Wikipedia - Demokrit (2009). Abdera kann unter http://abdera.apache.org heruntergeladen werden.
133 Abdera steht unter der Apache License 2.0. Diese Lizenz erlaubt die freie Verwendung, Verteilung und Modifikation in beliebigen Umfeldern ohne die Pflicht zur Offenlegung oder Weitergabe der Quelltexte. Modifikationen müssen nicht an Apache zurück geleitet werden und die entstandene Software muss nicht unter der selben Lizenz stehen. Der volle Text der Lizenz ist unter http://www.opensource.org/licenses/apache2.0.php abrufbar.
134 Die vollständige Dokumentation des Abdera-Framework ist als Java-Dokumentation unter http://abdera.apache.org/docs/api/index.html im Internet abrufbar.
41
3 Konzeption der Schnittstelle
• Klasse „Feed“
Antworten, die ein Atom-Feed sind, können bequem über die Klasse Feed
ausgelesen und manipuliert werden. Für das Erstellen neuer Objekte kann ein
Feed-Objekt auch neu erstellt werden.
• Klasse „Service“
Service-Dokumente werden durch die Service-Klasse abgebildet. Diese
Dokumente sind spezielle Feeds, die Informationen zur angesprochenen
Anwendung beinhalten und von denen aus weitere Funktionen einer Anwendung
zugänglich sind.
3.4 Auswahl der Programmiersprache
Die Programmiersprache, die zur Implementierung der Schnittstelle genutzt werden
kann, muss verschiedene Möglichkeiten bieten. Um eine Auswahl zu treffen, werden
zunächst die Kriterien aufgestellt und anschließend mittels einer einfachen Skala mit der
Einteilung + (gut), o (neutral), - (schlecht) bewertet.
Die folgenden Kriterien dienen zum einen der Beurteilung, ob die entsprechende
Programmiersprache einen ausreichenden Funktionsumfang für die Implementierung
hat. Zum anderen dienen Sie dazu zu bestimmen, wie gut sich eine Programmiersprache
zur Umsetzung eignet.
• Domino-Zugriff
Die Informationen von SkiP sind in Domino gespeichert. Ein Zugriff auf diese
Daten ist daher notwendig.
• HTTP-Kommunikation
Es müssen Informationen über HTTP ausgetauscht werden können und die
HTTP-Basisauthentifizierung muss verfügbar sein.
• Atom-Verarbeitung
Die ausgetauschten Daten sind im Atom-Format und die Interaktion bedient sich
des Atom Publishing Protokolls.
42
3 Konzeption der Schnittstelle
• Simplizität
Das Hauptaugenmerk der Entwicklung der Schnittstelle liegt auf dem
Datenaustausch zwischen den Systemen. Dies sollte möglichst einfach
realisierbar sein.
• Objektorientierung
Um Funktionalitäten verschiedener Objekte gegeneinander abzugrenzen, sollte
die Programmiersprache eine objektorientierte Implementierung ermöglichen.
Bedingt durch die organisatorischen Rahmenbedingungen kommt nur eine
Implementierung auf Basis von IBM Lotus Domino in Frage. Diese Plattform bietet vier
mögliche Programmiersprachen (siehe Tabelle 5, S. 44) an, die für die Implementierung
in Frage kommen.
Die einfachste der betrachteten Programmiersprachen ist die „@Formel“-Sprache135.
Die Programmierung erfolgt in einer einfachen Makro-Sprache mit sehr begrenztem
Befehlssatz. Der Zugriff auf Domino-Objekte erfolgt einfach und direkt. Allerdings
bringt diese Sprache weder gute Mittel zur HTTP-Kommunikation, noch zur
Verarbeitung von Atom-Feeds mit. Objektorientierung ist mit @Formeln nicht möglich.
LotusScript136 ist eine Basic-ähnliche Sprache. Sie ist am Besten mit etwa Microsoft
VisaulBasic zu vergleichen. Auch mit LotusScript ist ein direkter Zugriff auf Domino-
Objekte möglich. Die Möglichkeiten im Bezug auf HTTP-Kommunikation und die
zugehörige Authentifizierung sind jedoch eingeschränkt. Auch die Verarbeitung von
XML-Dialekten jenseits von DXL137 ist möglich, aber nicht sehr komfortabel.
Programmieren in LotusScript ist nicht so einfach, wie in @Formel-Sprache, bietet
dafür aber auch grundlegende Konzepte der Objekltorientierung.
Die Betrachtung von C und C++ wird zusammengefasst und auf die Sprache C++
beschränkt, da diese einen objektorientierten Ansatz verfolgt. Domino als Plattform
bietet ein API, auf das aus C++ heraus zugegriffen werden kann. Dieser Zugriff ist vom
Umfang her dem von LotusScript gleichwertig. HTTP-Kommunikation und Atom-
135 In Knäpper, M.; Donskoj, M. (2007) wird in den Kapitel 16 und 17 (S. 377-456) der Funktionsumfang der Formelprache umfassend beschrieben.
136 Der Funktionsumfang und der Einsatz von LotusScript wird ebenfalls umfassend von Knäpper, M.;Donskoj, M. (2007) in den Kapiteln 18 bis 20 (S. 457-556) beschrieben.
137 DXL ist die Abkürzung von DominoXML und bezeichnet einen speziell für Domino entwickelten XML-Dialekt.
43
3 Konzeption der Schnittstelle
Verarbeitung ist realisierbar, allerdings ist diese Sprache gegenüber den anderen
betrachteten Sprachen kompliziert. Die Objektorientierung ist eine Stärke von C++.
Domino-Zugriff
HTTP-Kommuni-
kation
Atom-Verarbeitung
Simplizität Objekt-orientierung
@Formel + - - + -LotusScript + o o o oC/C++ + o o - +Java + + + o +
Tabelle 5: Bewertung der verfügbaren Programmiersprachen
Seit der Version 4.6138 kann in Domino auch die Sprache Java139 eingesetzt werden.
Java ist rein objektorientiert und bietet ausgereifte Konstrukte wie abstrakte Klassen,
Interfaces, Polymorphie, etc. Der Zugriff auf Domino-Objekte ist zu den Möglichkeiten
in C++ oder LotusScript äquivalent. Die Klassen zur HTTP-Kommunikation sind
umfangreich und bieten viele Möglichkeiten bei gleichzeitigem Komfort. Die
Verarbeitung von Atom-Feeds ist ohne zusätzliche Hilfsmittel möglich, diese
Möglichkeiten können aber durch den Einsatz von Abdera140 erweitert werden.
Basierend auf den bewerteten Kriterien ist Java die beste Programmiersprache zur
Erstellung einer Schnittstelle zu Connections unter Domino.
3.5 Analyse der Integrationsszenarien
3.5.1 In SkiP vorhandene Informationen
Die Anwendung „SkiP“ speichert Bewertungsprofile, die jeweils einer bestimmten
Person zugeordnet sind. Der Großteil der Information bezieht sich auf die Bewertung
vorgegebener, in Gruppen zusammengefasster Skills. Neben der eigentlichen
Bewertung können in Freitextfeldern Kommentare oder Beschreibungen hinterlegt
werden.
138 Die Entwicklung von Java innerhalb der Entwicklungsumgebung ist erst seit Version 5.0 möglich. 139 Neben Knäpper, M.; Donskoj, M. (2007), S. 557-692 erläutert Eckert, T. (2006) umfassend die Ver-
wendung von Java in IBM Lotus Domino. Eine generelle Einführung in die Programmiersprache Java gibt Ullenboom, C. (2007).
140 Abdera wurde bereits in Kapitel 3.3.4 näher beschrieben.
44
3 Konzeption der Schnittstelle
3.5.1.1 Vom Skill-Profil zur PersonDie Skill-Profile in SkiP sind eindeutig einer Person zugeordnet. Die Benutzer-
verwaltung erfolgt dabei durch IBM Lotus Domino, der technischen Plattform, auf der
SkiP entwickelt wurde. Die E-Mailadresse des jeweiligen Benutzers wird, sofern im
Domino-Kontext vorhanden, automatisch im Profil hinterlegt.
Über diese E-Mailadresse lässt sich eine Person auch in den Anwendungen von
Connections identifizieren. Inhalte in Connections können also über das gemeinsame
Merkmal „E-Mailadresse“ den Informationen in SkiP zugeordnet werden. Voraus-
setzung hierfür ist, dass die E-Mailadressen in beiden Systemen übereinstimmen.
3.5.1.2 Von der Skill-Bewertung zum TagDurch die Bewertung der einzelnen Skills werden diese gewichtet. Die Bewertung
erfolgt auf einer Skala von 0 (exzellent) bis 5 (mangelhaft). Interessant sind dabei die
besonders hoch (bspw. 0 oder 1) oder besonders niedrig (bspw. 4 oder 5) bewerteten
Skills:
• Zu Themen, deren Skills für eine Person besonders hoch bewertet sind, kann
diese Person offenbar anderen weiterhelfen:
Sie kann Informationen anbieten.
• Auf der anderen Seite bedarf eine Person zu Themen, deren Skills für sie
besonders niedrig bewertet sind, Hilfestellung durch andere:
Sie hat einen Informationsbedarf.
In der Anwendung „SkiP“ sind den einzelnen Skills bereits Schlüsselwörter zugeordnet,
so dass sich diese Schlüsselwörter durch die Bewertungen zu zwei Gruppen verdichten
lassen:
Die erste Gruppe kennzeichnet die Themengebiete, in denen die Person als
Informationsanbieter auftreten kann. Die zweite Gruppe kennzeichnet hingegen die
Themen, bei denen die Person einen Informationsbedarf hat.
Diese Schlüsselwörter können wie Tags141 behandelt werden, auch wenn diese nicht
(direkt) vom Benutzer vergeben werden.
141 Vergl. Kapitel 2.2.4
45
3 Konzeption der Schnittstelle
Ausgehend von diesen Tags können Informationen in Anwendungen von Connections
zugeordnet werden. Das setzt voraus, dass die in Connections verwendeten Tags mit
den in SkiP verwendeten übereinstimmen.
3.5.2 Arten von Integrationsszenarien
Ein Integrationsszenario, das wie in diesem Fall von einer Anwendung ausgehen soll,
kann prinzipiell zwei Richtungen des Informationsaustausches haben. Entweder werden
Informationen in einer anderen Anwendung veröffentlicht oder aber Informationen aus
einer anderen Anwendung herausgesucht.
3.5.2.1 Szenarien zur Informationsveröffentlichung in ConnectionsWie in Kapitel 2.1.2 bereits beschrieben, haben automatisierte Skill-Management-
Systeme das Problem der Datenaktualität und -pflege. Genau hier könnten Szenarien der
Veröffentlichung von Informationen in Connections ansetzen.
Die Informationen, die veröffentlicht werden können, sind die aus den Bewertungen
gewonnen Tags142. Somit sind grundsätzlich die folgenden zwei Varianten möglich:
• Veröffentlichung als Informationsquelle
Diese Veröffentlichung der Information dient dazu, anderen Benutzern die
Suche nach einer solchen zu erleichtern bzw. überhaupt zu ermöglichen:
Der Benutzer weist sich als Experte aus.
• Veröffentlichung als Informationsbedarf
Werden Informationen als Informationsbedarf veröffentlicht, so möchte der
Benutzer andere animieren ihm zu helfen:
Er weist sich als Fragender aus.
Es können auch noch weitere Informationen (bspw. könnten Aktivitäten oder
Diskussionsbeiträge zu freien Themen erstellt werden) veröffentlicht werden. Diese
stehen aber nicht im direkten Zusammenhang mit der Anwendung SkiP und den dort
verarbeiteten Informationen143 und werden hier daher nicht betrachtet.
142 Vergl. Kapitel 3.5.1.2143 Vergl. Kapitel 3.5.1
46
3 Konzeption der Schnittstelle
3.5.2.2 Szenarien zur Suche von Informationen in ConnectionsBei der Suche nach Informationen in Connections werden ebenfalls die aus den
Bewertungen gewonnen Tags zugrunde gelegt. Auch hier ergeben sich somit zwei
verschiedene Varianten:
• Suche nach Information zur Informationsabgabe
Eine Suche mit den positiv bewerteten Tags liefert Ergebnisse, zu denen der
Benutzer etwas beitragen kann.
• Suche nach Informationen zur Informationsbeschaffung
Bei der Suche mit den negativ bewerteten Tags werden Ergebnisse geliefert, bei
denen sich der Benutzer informieren kann.
3.5.3 Integrationsszenarien mit Connections
Auf der Basis der ermittelten Arten von Integrationsszenarien können für jede der
Anwendungen von Connections entsprechende Szenarien aufgestellt werden.
Zur Bewertung der einzelnen Szenarien werden die Kriterien Praxisnutzen/-relevanz,
Vollständigkeit der Datenbasis und Allgemeingültigkeit (siehe Tabelle 6) herangezogen.
Die Bewertung der Kriterien erfolgt dabei mittels einer einfachen Skala mit der
Einteilung in + (gut), o (neutral), - (schlecht).
Die Bewertung der Szenarien erfolgt getrennt nach den einzelnen Anwendungen. Dies
geschieht vor dem Hintergrund der exemplarischen Umsetzung von mindestens einem
Szenario je Anwendung. Basierend auf der Bewertung wird je Anwendung ein
besonders gut geeignetes Szenario zur weiteren Betrachtung ausgewählt.
Kriterium BeschreibungPraxisnutzen/-relevanz
Wie sehr kann das Szenario in der Praxis einen relevanten Nutzen er-bringen? Je größer der Nutzen, desto höher ist die erwartete Akzep-tanz und umso besser ist das Szenario geeignet.
Datenbasisvollständig
In wie fern werden zusätzliche (Konfigurations-)Daten benötigt? Je weniger zusätzliche Daten gepflegt werden müssen, umso besser.
Allgemein-gültigkeit
Wie allgemeingültig lässt sich das Szenario anwenden und von wel-chen speziellen Rahmenbedingungen ist es abhängig? Je allgemeiner ein Szenario anwendbar ist, umso besser.
Tabelle 6: Bewertungskriterien für Integrationsszenarien
47
3 Konzeption der Schnittstelle
3.5.3.1 Integrationsszenarien mit ProfilesIn Profiles existiert für jeden Benutzer genau ein entsprechendes Profil. Daher können
hier keine neuen Profile eingestellt, sondern nur bestehende Profile aktualisiert werden.
Szenario BeschreibungVeröffentlichung als Informationsquelle
Veröffentlichung der Themen (Tags), zu denen der Benutzer als Informationsquelle dienen kann.
Veröffentlichung als Informationsbedarf
Veröffentlichung der Themen (Tags), zu denen der Benutzer Informationsbedarf hat.
Suche zur Abgabe von Informationen
Suche nach anderen Benutzern, die zu den selben Themen Experte sind.
Suche zur Beschaffung von Informationen
Suche nach einem Experten zu einem Thema, in dem der Benutzer Informationsbedarf hat.
Tabelle 7: Profiles: Integrationsszenarien
Die Veröffentlichung von Informationen bezieht sich also auf die Aktualisierung der
Profilinformationen. Hier besteht die Möglichkeit, den Bereich der Informationsquelle
oder den des Informationsbedarfes zu kennzeichnen (vergl. Tabelle 7).
In Web 2.0-Anwendungen werden Inhalte mit Tags gekennzeichnet, die Attribute dieses
Inhalts sind144. Daher hat es keinen Praxisnutzen, ein Profil mit Tags zu kennzeichnen,
für die die entsprechende Person einen Informationsbedarf hat. Als Daten für die beiden
Szenarien zur Veröffentlichung sind nur die entsprechenden Tags notwendig und somit
ist die Datenbasis vollständig vorhanden. Auch eine allgemeingültige Umsetzung ist
möglich, da die Tags der Profile ein vorgegebenes Attribut eines Profils sind.
Szenario Praxisnähe DatenbasisAllgemein-gültigkeit
Veröffentlichung als Informationsquelle + + +
Veröffentlichung als Informationsbedarf - + +
Suche zur Abgabe von Informationen + + +
Suche zur Beschaffung von Informationen + + +
Tabelle 8: Profiles: Bewertung der Integrationsszenarien
144 Vergl. Kapitel 2.2.4
48
3 Konzeption der Schnittstelle
Die Suche nach Profilen kann aus zwei verschiedenen Gründen erfolgen: Suche nach
ähnlichen Experten zum Zweck des gemeinsamen Austausches oder Suche nach
Experten, die auf einem bestimmten Gebiet weiterhelfen können. Grundlage für eine
solche Suche wären jeweils die aus den Bewertungen ermittelten Tags. Im ersten Fall
würden die Tags der hoch bewerteten Skills, im zweiten Fall die der niedrig bewerteten
Skills verwendet. Beide Szenarien sind praxisnah, die Datenbasis ist vollständig und die
Allgemeingültigkeit ist dadurch gegeben, dass nur die Tags verwendet werden.
Drei der möglichen Szenarien bieten sich für eine Umsetzung an (vergl. Tabelle 8,
S. 48). Da in SkiP Informationen generiert werden, ist das Szenario „Veröffentlichung
von Profilinformationen als Informationsquelle“ am Besten für die weiteren
Betrachtungen geeignet.
Da die Szenarien zur Suche von Informationen ebenfalls durchweg positiv bewertet
wurden, sollten diese zusätzlich für eine Implementierung in Betracht gezogen werden.
Somit wird dem Benutzer auch sofort der Nutzen der Aktualisierung seines Profils
bewusst.
3.5.3.2 Integrationsszenarien mit CommunitiesIn der Anwendung Communities müssen die Szenarien differenzierter betrachtet
werden. Ein Benutzer kann sowohl eine Community, als auch einen Beitrag in einer
Community veröffentlichen bzw. suchen (vergl. Tabelle 9, S. 50).
Die Erstellung einer Community zu einem Thema, bei dem der Benutzer ein Experte ist,
ist sinnvoll. Er kann dort andere, gleichgesinnte Benutzer einladen und sich mit Ihnen
austauschen. Allerdings ist es nicht sinnvoll, für jedes Thema eine neue Community zu
eröffnen, da eine ähnliche bereits vorhanden sein könnte.
Für das Erstellen einer Community fehlen weitergehende Informationen (Beschreibung,
Titel etc.), die per Abfrage oder Konfiguration hinzugefügt werden müssen.
Ähnlich ist die Erstellung einer Community zu einem Informationsbedarf. Hier kommt
allerdings hinzu, dass anfangs noch keine Experten vorhanden sind. Diese müssten also
die Community selbst finden, oder über andere Mechanismen hinzugefügt werden.
49
3 Konzeption der Schnittstelle
Je nachdem, wie Communities im Unternehmen genutzt werden, kann es sinnvoll sein
eine Community als Informationsquelle oder zu einem Informationsbedarf zu eröffnen.
Eine allgemeingültige Entscheidung kann hier nicht getroffen werden.
Szenario BeschreibungVeröffentlichung als Informationsquelle
Erstellen einer Community (oder eines Diskussionsbeitrags), in der der Benutzer als Informationsquelle auftritt.
Veröffentlichung als Informationsbedarf
Erstellen einer Community (oder eines Diskussionsbeitrags), in der der Benutzer seinen Informationsbedarf beschreibt.
Suche zur Abgabe von Informationen
Suche nach einer Community (oder eines Diskussionsbei-trags), in der der Benutzer Informationen beisteuern kann.
Suche zur Beschaffung von Informationen
Suche nach einer Community (oder eines Diskussionsbei-trags), in der der Benutzer Informationen recherchieren kann.
Tabelle 9: Communities: Integrationsszenarien
Die Erstellung eines Diskussionsbeitrages in einer Community ist für den Fall, dass der
Benutzer Informationsquelle ist sinnvoll. Aber auch hier fehlen zusätzliche Daten (Titel,
Text, etc.) und, viel wichtiger, die entsprechende Community muss bekannt sein und
auch von anderen Benutzern genutzt werden. Damit fehlt die Datenbasis für dieses
Szenario. Eine allgemeingültige Realisierung ist ebenfalls vor dem Hintergrund der
Nutzungskultur von Communities nicht möglich.
Um bei einem Informationsbedarf einen sinnvollen Diskussionsbeitrag erstellen zu
können fehlen ähnliche Daten (Titel, Text). Auch ist die entsprechende Community
nicht ohne Konfiguration bekannt und somit die Allgemeingültigkeit nicht gegeben
(vergl. Tabelle 10, S. 51).
Die Suche nach einer Community oder einem Diskussionsbeitrag kann einem Benutzer
Zugang zu neuen Erkenntnissen und Kontakten verschaffen. Dies ist sowohl für den
Fall „Informationsquelle“, als auch für den Fall „Informationsbedarf“ sinnvoll.
Die für die Suche notwendigen Tags sind vorhanden und das Szenario zur Suche nach
Communities ist allgemeingültig realisierbar.
Die Suche nach Diskussionsbeiträgen gestaltet sich allerdings schwieriger, da diese
nicht einzeln per Tag verschlagwortet werden können. Einzig eine Volltextsuche bliebe
50
3 Konzeption der Schnittstelle
als Möglichkeit Beiträge zu finden. Hier müssen die Suchkriterien (Tags) aber auch im
entsprechenden Beitragstext vorkommen, damit die Suche Erfolg hat.
Somit ist Datenbasis für dieses Szenario nicht vollständig und damit auch die
allgemeingültige Realisierbarkeit nicht in der Form gegeben, wie es bei der Suche nach
Communities der Fall ist.
Szenario Praxisnähe DatenbasisAllgemein-gültigkeit
Veröffentlichung als Informationsquelle + / + o / - o / -
Veröffentlichung als Informationsbedarf - / o o / - o / -
Suche zur Abgabe von Informationen + / + + / o + / o
Suche zur Beschaffung von Informationen + / + + / o + / o
Bewertung: Community / Beitrag in Community
Tabelle 10: Communities: Bewertung der Integrationsszenarien
Durch Bewertung der Kriterien ergibt sich, dass sowohl die Suche nach Communities
für die Informationsabgabe, als auch für die Informationsbeschaffung sinnvoll für die
weitere Betrachtung sind.
3.5.3.3 Integrationsszenarien mit BlogsIn der Anwendung Blogs müssen die Szenarien analog zur Anwendung Communities
differenziert nach Blog und Blogeinträgen betrachtet werden (vergl. Tabelle 11).
Szenario BeschreibungVeröffentlichung als Informationsquelle
Erstellen eines Blogs (oder eines Blogeintrags), in dem der Benutzer als Informationsquelle auftritt.
Veröffentlichung als Informationsbedarf
Erstellen eines Blogs (oder eines Blogeintrags), in dem der Benutzer seinen Informationsbedarf beschreibt.
Suche zur Abgabe von Informationen
Suche nach einem Blog (oder einem Blogeintrag), in dem der Benutzer Informationen beisteuern kann.
Suche zur Beschaffung von Informationen
Suche nach einem Blog (oder einem Blogeintrag), in dem der Benutzer Informationen recherchieren kann.
Tabelle 11: Blogs: Integrationsszenarien
51
3 Konzeption der Schnittstelle
Möchte ein Benutzer über ein bestimmtes Thema, in dem er Experte ist, berichten, so ist
die Erstellung eines Blogs durchaus sinnvoll. Die Erstellung eines neuen Blogs für jedes
neue Thema ergibt hingegen vor dem Hintergrund, dass dieser Blog von nur einem
Autor bearbeitet und von den Lesern maximal kommentiert wird keinen Sinn145.
Blogs können nicht wie Communities für Autoren öffentlich zugänglich sein. Die
Erstellung eines Blogs zu einem Informationsbedarf ist daher nicht sinnvoll.
Bei der Erstellung eines Blogs fehlen wie bei den Communities die weitergehenden
Informationen (Titel, Beschreibung, etc.). Dies widerspricht zudem einer allgemein-
gültigen Implementierung (vergl. Tabelle 12).
Szenario Praxisnähe DatenbasisAllgemein-gültigkeit
Veröffentlichung als Informationsquelle o / + o / - o / -
Veröffentlichung als Informationsbedarf - / o o / - o / -
Suche zur Abgabe von Informationen + / + + / + + / +
Suche zur Beschaffung von Informationen + / + + / + + / +
Bewertung: Blog / Blogeintrag
Tabelle 12: Blogs: Bewertung der Integrationsszenarien
Die Erstellung eines Blogeintrags ist sinnvoll für den Fall, dass der Benutzer
Informationsquelle ist.
Die Veröffentlichung eines Blogeintrags im Falle des Informationsbedarfs ist aufgrund
der Restriktionen bzgl. der Möglichkeiten zur Interaktion anderer Benutzer weniger
sinnvoll.
In beiden Fällen fehlen aber zusätzliche Daten (Titel, Text, etc.) und, analog zu den
Communities, muss der Blog, in dem veröffentlicht werden soll, bekannt sein und auch
von anderen Benutzern genutzt werden. Daher ist dieses Szenario nicht allgemeingültig
realisierbar.
145 Vergl. auch Kapitel 2.2.6.3
52
3 Konzeption der Schnittstelle
Auch bei der Suche sind viele Parallelen zu den Communities zu finden: Die Suche
nach einem Blog/Blogeintrag kann einem Benutzer Zugang zu neuen Erkenntnissen und
Kontakten verschaffen. Auch hier ist das für beide Fälle (Informationsabgabe /
Informationsbeschaffung) sinnvoll. Die für die Suche notwendigen Tags sind vorhanden
und das Szenario ist allgemeingültig.
Im Gegensatz zu den Diskussionsbeiträgen sind Blogeinträge separat per Tag
verschlagwortet. Daher können auch einzelne Blogeinträge ebenso sinnvoll wie ganze
Blogs gesucht werden.
Wiederum sind es die Szenarien der Informationssuche, die nach Anwendung der
Bewertungskriterien für eine Umsetzung weiter untersucht werden müssen. Dabei ist
die Suche nach Blogeinträgen zu bevorzugen, da der Benutzer direkt Informationen zum
gesuchten Thema erhält.
3.5.3.4 Integrationsszenarien mit DogearDie in SkiP verarbeiteten Informationen umfassen keinerlei Verweise, die als
Lesezeichen in Dogear veröffentlicht werden könnten. Daher werden diese Szenarien
nicht weiter betrachtet (vergl. Tabelle 13).
Szenario BeschreibungVeröffentlichung als Informationsquelle
- (Kein Verweisziel vorhanden)
Veröffentlichung als Informationsbedarf
- (Kein Verweisziel vorhanden)
Suche zur Abgabe von Informationen
Suche nach einem Verweis auf eine Web-Seite, in die sich der Benutzer als Experte einbringen kann.
Suche zur Beschaffung von Informationen
Suche nach einem Verweis zu Informationen, die der Benut-zer verwenden kann.
Tabelle 13: Dogear: Integrationsszenarien
Da Lesezeichen mit Tags verschlagwortet werden, können Sie über die aus den
Bewertungen ermittelten Tags gesucht werden. Die Suche nach einem Lesezeichen zur
Informationsabgabe ist jedoch nicht sinnvoll. Für diesen Einsatzzweck sollten
Communities gesucht werden. Zur Informationsbeschaffung ist eine Suche nach
Lesezeichen jedoch gut geeignet (vergl. Tabelle 14, S. 54).
53
3 Konzeption der Schnittstelle
Szenario Praxisnähe DatenbasisAllgemein-gültigkeit
Veröffentlichung als Informationsquelle ohne Bewertung ohne Bewertung ohne Bewertung
Veröffentlichung als Informationsbedarf ohne Bewertung ohne Bewertung ohne Bewertung
Suche zur Abgabe von Informationen o + +
Suche zur Beschaffung von Informationen + + +
Tabelle 14: Dogear: Bewertung der Integrationsszenarien
Als geeignetes Szenario wurde durch die Anwendung der Bewertungskriterien das
Szenario „Suche von Lesezeichen zur Informationsbeschaffung“ identifiziert.
3.5.3.5 Integrationsszenarien mit ActivitiesAktivitäten in Activities scheinen zunächst ähnlich wie Einträge in Communities oder
Blogs zu sein (vergl. Tabelle 15). Sinn und Zweck, die sich hinter Aktivitäten verbergen
sind aber Andere: Aktivitäten bündeln verschiedene Informationen im Zusammenhang
mit einer Aktivität, sie ähneln einer Aufgabenverwaltung.
Szenario BeschreibungVeröffentlichung als Informationsquelle
Erstellen einer Aktivität (oder eines Eintrags) zur Nutzung als Informationsquelle.
Veröffentlichung als Informationsbedarf
Erstellen einer Aktivität (oder eines Eintrags) zur Deckung seines Informationsbedarfs.
Suche zur Abgabe von Informationen
Suche nach einer Aktivität (oder einem Eintrag), in der der Benutzer Informationen beisteuern kann.
Suche zur Beschaffung von Informationen
Suche nach einer Aktivität (oder einem Eintrag), in der der Benutzer Informationen recherchieren kann.
Tabelle 15: Activities: Integrationsszenarien
Die Erstellung einer Aktivität zur Nutzung als Informationsquelle durch den Benutzers
ist nicht sehr praxisnah, da anderen Benutzern (Experten) die Aufgabe zur
Informationsbeschaffung zugewiesen werden müsste.
Die Erstellung einer Aktivität zur Deckung eines Informationsbedarfs hingegen ist
sinnvoll. Hier könnte der Benutzer bspw. alle Aktionen dokumentieren, die er zur Suche
und Teilnahme an einer geeigneten Schulung vollziehen muss.
54
3 Konzeption der Schnittstelle
Allerdings fehlen für die Szenarien der Veröffentlichung Informationen in SkiP, bspw.
der Aktivitätstext, der Inhalt der Aktivität, weitere Mitglieder etc. so dass eine
allgemeingültige Realisierung schwer möglich ist (vergl. Tabelle 16).
Zur Deckung eines Informationsbedarfs hat die Erstellung einer Aufgabe in einer
Aktivität eine gewisse Praxisnähe, da der Benutzer sich selbst eine solche Aufgabe
zuweisen könnte.
Eine Aufgabe in einer Aktivität als Informationsquelle zu erstellen hat ohne die
Kenntnis einer bestimmten Aktivität keinerlei Praxisnutzen.
In beiden Fällen gilt, dass die Veröffentlichung einzelner Aufgaben eine bekannte
Aktivität erfordert und analog zu Communities und Blogs zusätzliche Konfiguration
(Titel, Inhalt, etc.) notwendig ist.
Dieses Szenarien sind sehr speziell, da ein Mitarbeiter auch eine passende Aktivität für
die Aufgabe bereithalten muss. Somit ist eine Allgemeingültigkeit nicht gegeben.
Szenario Praxisnähe DatenbasisAllgemein-gültigkeit
Veröffentlichung als Informationsquelle o / - o / - o / -
Veröffentlichung als Informationsbedarf + / o o / - o / -
Suche zur Abgabe von Informationen o / - + / + + / +
Suche zur Beschaffung von Informationen + / o + / + + / +
Bewertung: Aktivität / Aufgabe in Aktivität
Tabelle 16: Activities: Bewertung der Integrationsszenarien
Die Suche nach Aktivitäten zur Informationsabgabe ist ein durchaus denkbares
Szenario, näher an der Praxis liegt aber das Szenario der Suche nach „Aktivitäten zur
Informationsbeschaffung“: Diese Suche könnte bspw. dazu dienen von den Erfahrungen
anderer zu partizipieren oder gemeinsam mit anderen eine Aktivität zur Informations-
beschaffung durchzuführen.
Die Daten zur Suche sind vorhanden (Tags) und auch die Allgemeingültigkeit ist
gegeben.
55
3 Konzeption der Schnittstelle
Die Suche nach einzelnen Aufgaben ist von den Kriterien Datenbasis und
Allgemeingültigkeit positiv zu bewerten. Allerdings ist es in der Praxis eher relevant,
nach einer ganzen Aktivität, als nach einem Teil einer solchen zu suchen. Sind
Aufgaben zur Weiterbildung aber bspw. in einer einzelnen Aktivität zusammengefasst,
ist auch die Suche nach einzelnen Aufgaben sinnvoll. Gleichwohl schränkt diese
Voraussetzung die Allgemeingültigkeit stark ein.
Bei Betrachtung der Bewertungen ergibt sich für die Anwendung Aktivitäten die
„Suche von Aktivitäten zur Informationsbeschaffung“ als geeignetes Szenario.
3.5.4 Integrationsszenarien für die Implementierung
Die Szenarien zur Implementierung wurden durch die Betrachtung der einzelnen
Anwendungen und die Bewertung der identifizierten Szenarien ausgewählt.
Die Szenarien zur Suche von Informationen in Connections überwiegen. Da der
Umfang der in SkiP gespeicherten Daten relativ gering ist, überrascht das nicht.
Die Ausnahme bildet die Anwendung Profiles, die mit Daten versorgt werden kann.
• Profiles
Aktualisierung der Tags des eigenen Profils
Suche nach Profiles zur Informationsabgabe/-beschaffung
• Communities
Suche nach Communities zur Informationsabgabe/-beschaffung
• Blogs
Suche nach Blogeinträgen zur Informationsabgabe/-beschaffung
• Dogear
Suche nach Lesezeichen zur Informationsabgabe/-beschaffung
• Activities
Suche nach Aktivitäten zur Informationsabgabe/-beschaffung
56
4 Implementierung der Schnittstelle
4 Implementierung der Schnittstelle
Die in Kapitel 3 beschriebenen Integrationsszenarien werden mittels der Programmier-
sprache Java und dem Framework Abdera146 auf der Domino-Plattform realisiert.
Die Implementierung einer Schnittstelle erfordert zunächst Überlegungen im Bezug auf
die Architektur, damit das Ergebnis sicher, tragfähig und zukunftsorientiert ist.
Die Programmiersprache Java ist objektorientiert. Zur Planung der Implementierung
wird daher das Klassendiagramm aufgestellt und erläutert.
Letztlich wird die beispielhafte Integration der Schnittstelle in das bestehende Benutzer-
interface der Anwendung SkiP untersucht.
4.1 Architektur der Schnittstelle
4.1.1 Vorüberlegungen
4.1.1.1 Integration in das bestehende Web-InterfaceDie Anwendung SkiP existiert bereits und wird über ein Web-Interface in einem
Browser bedient. Die neue Schnittstelle muss in dieses Interface integrierbar sein, ohne
große Änderungen an der bestehenden Anwendung zu erfordern. In einer Web-
Anwendung sind die technischen Möglichkeiten, gerade im Bezug auf die Integration
zweier Systeme, auf Webtechnologien wie URL-Aufrufe, JavaScript, etc. beschränkt.
Für die meisten der in Kapitel 3.5.3 aufgezeigten Szenarien ist die Anzeige der
Ergebnisse ausreichend. Suchresultate müssen bspw. nicht gespeichert werden, da diese
an Aktualität verlieren. Die Schnittstelle kann in einem solchen Fall direkt die
Darstellung der Suchergebnisse als Web-Seite zurückliefern.
Bei der Veröffentlichung von Informationen, bei der bestehende Objekte aktualisiert
werden ist ebenfalls der Aufruf einer URL ausreichend. Statt Suchergebnissen kann in
diesem Fall eine Bestätigung oder eine Fehlermeldung angezeigt werden.
146 Eine Anleitung zur Installation von Abdera wird im Anhang in Kapitel 7.2 gegeben.
57
4 Implementierung der Schnittstelle
In einer Anwendung auf einem Domino-Server können über den Aufruf einer URL
auch Programmroutinen aufgerufen werden. Diese Programmroutinen werden
Agenten147 genannt und über die URL können zusätzliche Parameter übergeben werden.
Die Ausgaben eines Agenten, der über eine URL aufgerufen wird, kann direkt im
Browser angezeigt werden.
In Szenarien, in denen Informationen in die ursprüngliche Anwendung zurückfließen
sollen, ist ein Aufruf der Schnittstelle über eine URL ebenfalls ausreichend. Allerdings
muss eine Referenz auf das ursprüngliche Objekt mitgegeben werden, damit hier
Informationen ergänzt werden können. Da in SkiP keine Informationen verändert
werden dürfen148, kommt hier lediglich die Erstellung zugeordneter Informationsobjekte
in Frage, die im Kontext der Skill-Profile angezeigt werden.
4.1.1.2 FlexibilitätDie Funktionen der Schnittstelle können auch außerhalb von SkiP nutzbar gemacht
werden. Durch den Aufruf der Schnittstelle über eine URL mit entsprechenden
Parametern ist dies leicht zu gewährleisten. Die einfachen Such-Szenarien können ohne
großen Aufwand in andere Anwendungen übernommen werden.
Für Szenarien mit Rückfluss von Informationen in die ursprüngliche Anwendung muss
diese mit den zurückgelieferten Daten umgehen können. Dies bedeutet, dass
entsprechende Anpassungen in der jeweiligen Anwendung vorzunehmen sind.
4.1.1.3 Komfort- und SicherheitsaspekteFür den Zugriff auf Connections muss sich der Benutzer authentifizieren. Damit dies
nicht wiederholt durch den Benutzer erfolgen muss, werden die Authentifizierungs-
informationen der Benutzer in einem sicheren Container hinterlegt. Damit wird
ebenfalls vermieden, dass die Angaben häufiger als notwendig über das Netzwerk
übertragen werden müssen. Jeder Benutzer darf nur Zugriff auf sein Passwort haben und
muss die Möglichkeit bekommen, dieses auch zu ändern.
Die Schnittstelle darf nur von legitimen Benutzern des Domino-Servers verwendet
werden. Der Benutzer muss sich also mit seinen Login-Informationen gegenüber dem
Domino-Server authentifizieren. Dies ist bereits der Fall, da der Benutzer sich für den
147 Vergl. Knäpper, M.; Donskoj, M. (2007), S. 345-370 148 Siehe Kapitel 3.1
58
4 Implementierung der Schnittstelle
Zugriff auf SkiP ebenfalls am Domino-Server anmelden muss. Alle Aktionen der
Schnittstellenkomponente erfolgen „im Namen“ des Benutzers, d. h. alle Operationen
erfolgen mit seinen Rechten und werden, technisch gesehen, von ihm durchgeführt.
Der Datentransfer zwischen Anwendung und Schnittstellenkomponente erfolgt
innerhalb des Firmennetzwerks. Es ist im Einzelfall abzuwägen, ob eine sichere
HTTPS-Verbindung notwendig ist. Die Daten, die nach Connections übertragen
werden, oder von Connections gelesen werden sind gewöhnlich offen zugänglich. Eine
Absicherung der Verbindung ist also Ermessenssache.
4.1.2 Schematische Architektur
Der Aufruf der Schnittstelle über eine URL mit Parametern ist komfortabel, sicher und
bietet zudem eine große Flexibilität im Hinblick auf die Anbindung weiterer
Anwendungen, weil die eigentlichen Schnittstellenfunktionen in eine separate
Komponente, hier „ConnectionsGateway“ genannt, ausgelagert werden können (siehe
Abbildung 15).
Abbildung 15: Implementierung der Schnittstelle als eigenständige Komponente
Aufbauend auf diesem Schema ergeben sich zwei verschiedene Abläufe.
4.1.2.1 Schematischer Ablauf „Suchanfrage“Bei einer Suchanfrage werden Informationen von Connections abgefragt. Die
Ergebnisse müssen aufbereitet und dem Benutzer präsentiert werden.
Der Ablauf ist in Abbildung 16 auf S. 60 schematisch dargestellt. Der Benutzer bedient
die Anwendung SkiP in seinem Browser. Durch den Aufruf bestimmter URLs wird
ein neues Browser-Fenster geöffnet und die Anfrage-Parameter an die
Schnittstellenkomponente „Connections Gateway“ gesendet . Diese kommuniziert via
59
Connections ServerDomino Server
SkiP ConnectionsAnfrage
AntwortConnections
Gateway
4 Implementierung der Schnittstelle
Atom Publishing Protocol mit dem API von Connections . Das Ergebnis wird als
HTML aufbereitet und zur Darstellung zurück an das zuvor erstellte Browser-Fenster
geliefert .
Abbildung 16: Schematischer Ablauf „Suchanfrage“
4.1.2.2 Schematischer Ablauf „Informationsrückfluss“Sollen die Ergebnisse nicht nur dargestellt, sondern auch in der ursprünglichen
Anwendung gespeichert werden, unterscheidet sich der Ablauf:
Abbildung 17: Schematischer Ablauf „Informationsrückfluss“
60
Benutzer
Domino Server Connections Server
Browser URLneues
Browser-fenster
SkiP ConnectionsGateway
ConnectionsAtomPub
AtomPub
API
Para
met
er
HTM
L
HTML
Benutzer
Domino Server Connections Server
Browser
URL
SkiP
API
HTML
URL
Connections
Domino
ConnectionsGateway AtomPub
AtomPub
4 Implementierung der Schnittstelle
Der Benutzer bedient auch in diesem Szenario SkiP in seinem Browser (siehe
Abbildung 17, S. 60). Der Aufruf einer bestimmten URL erfolgt aber nicht in einem
separaten Browser-Fenster. Auch hier werden mit der URL die Anfrage-Parameter an
die Schnittstellenkomponente „Connections Gateway“ übertragen . Die Kommuni-
kation zwischen der Komponente und Connections erfolgt per Atom Publishing
Protocol . Die Ergebnisse werden in der ursprünglichen Anwendung gespeichert .
Hierzu müssen zusätzliche Angaben als Anfrage-Parameter übergeben werden, damit
die Schnittstellenkomponente die Ergebnisse korrekt zuordnen kann. Schließlich wird
im ursprünglichen Browser-Fenster eine URL neu geladen, damit die Ergebnisse auch
für den Benutzer sichtbar werden .
4.2 Das Klassendiagramm
Im Mittelpunkt der Implementierung steht die Klasse ConnectionsAccess. Dieser Klasse
sind bis zu fünf von der abstrakten Klasse AbstractAccess abgeleitete Klassen
zugeordnet. Diese Klassen verfügen über die Klassen des Frameworks Abdera (siehe
Abbildung 18, links). Die Klasse ConnectionsAccess selbst verfügt über Klassen, die
die Konfigurationsdaten speichern (siehe Abbildung 18, rechts).
Abbildung 18: Klassendiagramm
61
1
1
1
1
AbstractAccess{abstract}
<<Interface>>Configuration
<<Interface>>CredentialsAbderaClient
Abdera
1
1
1
*
ConnectionAccess
1
1
5 1
4 Implementierung der Schnittstelle
Die Klassen des Frameworks Abdera werden von der Klasse AbstractAccess selbst
erzeugt. Die Konfigurationsklassen Configuration und Credentials müssen dem
Konstruktor der Klasse ConnectionsAccess mitgegeben werden. So ist es möglich, von
den Interfaces „Configuration“ und „Credentials“ eigene Klassen abzuleiten und der
Schnittstelle zur Verfügung zu stellen.
4.2.1 Zugriff auf die Anwendungen von Connections
Die Klassen zum Zugriff auf die einzelnen Anwendungen werden von einer zentralen
abstrakten Klasse abgeleitet (siehe Abbildung 19). Die abstrakte Klasse implementiert
die Basis-Kommunikation mit Connections mittels des Frameworks Abdera. Außerdem
stellt diese Basisklasse auch noch allgemeine Zugriffsmethoden, bspw. für die Suche
per Tags, abstrakt zur Verfügung. Die abgeleiteten Klassen müssen diese dann
implementieren.
Abbildung 19: Ableitung der Zugriffsklassen
Der Vorteil der abstrakten Klasse gegenüber der Verwendung eines Interfaces liegt in
der Möglichkeit, bereits Code implementieren zu können. Dennoch kann in Java einer
Variablen mit dem Typ der abstrakten Klasse jede abgeleitete Klasse zugewiesen
werden. Dies erleichtert die Programmierung von Fallunterscheidungen beim Zugriff
auf gemeinsame Methoden.
62
AbstractAccess
AccessProfiles
AccessCommunities
AccessBlogs AccessActivities
AccessDogear
4 Implementierung der Schnittstelle
Für jede der Anwendungen wird eine spezielle Klasse von der Basis-Klasse abgeleitet.
Methoden, die nur speziell für eine der Anwendungen zur Verfügung gestellt werden
können, sind in dieser Klasse implementiert. Außerdem müssen die abstrakten
Methoden der Basis-Klasse implementiert werden. Hierbei kann dann auf die
Besonderheiten der jeweiligen Anwendung, wie bspw. URL-Angaben oder die
Aufbereitung von URL-Parametern, eingegangen werden.
Die Klasse AbstractAccess stellt die folgenden Methoden zur Abfrage von Connections
Verfügung:
• getSearchAll()
Diese Methode führt eine Suchen innerhalb einer Anwendung durch. Die
Parameter der Suchanfrage müssen als URL-Parameter aufbereitet mitgegeben
werden. Die Rückgabe erfolgt als Feed.
• abstract getSearchAllByTags()
Diese Methode dient zur anwendungsspezifischen Aufbereitung spezieller
Parameter für eine Suchanfrage per Methode „getSearchAll()“ und wurde in den
abgeleiteten Klasse implementiert.
• abstract getSearchAllByEmail()
Diese Methode bereitet spezielle Parameter für eine Suchanfrage per Methode
„getSearchAll()“ anwendungsspezifisch auf. Auch diese Methode wurde in den
abgeleiteten Klassen implementiert.
• getServiceDocument()
Mit dieser Methode kann das Service-Dokument ausgelesen werden. Das
Service-Dokument ist eine Art Inhaltsverzeichnis für eine Anwendung und
enthält Verweise auf bereitgestellte Funktionen.
63
4 Implementierung der Schnittstelle
Die Kommunikation mit Connections erfolgt mittels der folgenden Methoden:
• getResponse()
Mittels eines HTTP-Requests vom Typ „GET“149 wird mit Connections
kommuniziert. Diese Methode liefert eine unverarbeitete Antwort.
• getFeedDocument()
Diese Methode benutzt die Methode getResponse() um mit den gegebenen
Parametern aus der Antwort seitens Connections das „Document“, als den Text
der Antwort, zu extrahieren.
• getFeed()
Aufbauend auf der Methode getFeedDocument() interpretiert diese Methode das
gelieferte „Document“ als Feed und gibt diesen zurück.
• getCategoriesDocument()
Diese Methode dient zum abrufen eines Kategorie-Dokumentes und arbeitet
analog zur Methode getFeedDocument(). Ein solches Dokument enthält eine
Auflistung von Tags.
• getCategories()
Aufbauend auf der Methode getCategoriesDocument() interpretiert diese
Methode das gelieferte „Document“ als „Categories“ und gibt diese zurück.
• putElement()
Ähnlich wie die Methode getResponse() dient diese Funktion zum allgemeinen
Zugriff auf Connections. Allerdings erfolgt bei dieser Methode ein schreibender
und kein lesender Zugriff.
• putCategories()
Diese Methode schreibt ein Objekt vom Typ Categories an die angegebene
URL.
• updateCategories()
Diese Methode kommuniziert nicht direkt mit Connections, sondern aktualisiert
die Tags eines Objektes vom Typ Categories. Dabei wird eine mitgegebene
Menge von Tags zu den bereits gespeicherten hinzugefügt.
149 Vergl. Kapitel 3.3.3
64
4 Implementierung der Schnittstelle
Zur Anpassung an die entsprechende Anwendung wurden in den abgeleiteten Klassen
jeweils die folgenden abstrakten Methoden implementiert:
• getURLBase()
Die Implementierung dieser Methode liefert die Basis-URL der Anwendung.
Alle weiteren URLs werden aufbauend auf dieser Basis-URL zusammengesetzt.
• getURLService()
Diese Methode gibt die URL zurück, unter der die entsprechende Anwendung
das Service-Dokument liefert.
• getURLSearchAll()
Die Implementierung dieser Methode ermittelt die URL, unter der die
Anwendung das Suchergebnisse über alle gespeicherten Informationen liefert.
4.2.2 Zugriff auf die Konfiguration
Für den Zugriff auf Konfigurationsdaten ist ein Interface definiert. Dieses Interface
definiert die Methoden, die die notwendigen Konfigurationswerte liefern müssen.
Abbildung 20: Ableitung der Konfigurationsklassen
65
<<Interface>>Configuration
ConfigurationGreenhouse ConfigurationConnectionsGateway
4 Implementierung der Schnittstelle
Die folgenden Methoden müssen jeweils die Basis-URL der entsprechenden
Anwendung zurückliefern und werden von dem Interface „Configuration“ gefordert:
• getActivitiesUrl()
• getBlogsUrl()
• getCommunitiesUrl()
• getDogearUrl()
• getProfilesUrl()
Steht eine Anwendung nicht zur Verfügung, so liefert die entsprechende Methode einen
Leerstring zurück.
Beispielhaft wurden zwei Klassen implementiert, die wiederum das Interface
Configuration implementieren (siehe Abbildung 20, S. 65):
• ConfigurationGreenhouse
Diese Implementierung gibt die Konfigurationsdaten von Lotus Greenhouse150
zurück, ohne dass es die Möglichkeit einer Konfiguration gibt.
• ConfigurationConnectionsGateway
Diese Klasse liest die Konfigurationsdaten aus der Anwendung Connections-
Gateway aus.
Für den Einsatz in anderen Umgebungen kann das Interface in einer neuen Klasse
implementiert werden. Die Konfiguration ist somit vollständig von der
Implementierung der Schnittstelle getrennt.
4.2.3 Zugriff auf die Benutzerinformationen
Ähnlich wie bei den Konfigurationsdaten wurde auch für den Zugriff auf die Benutzer-
informationen zur Authentifizierung ein Interface definiert. Auch hier wurde die
Implementierung des Zugriffs auf die Benutzerinformationen strikt von der
Implementierung der Schnittstelle getrennt.
150 Vergl. Kapitel 3.2.2
66
4 Implementierung der Schnittstelle
Abbildung 21: Ableitung der Konfigurationsklassen
Die folgenden Methoden werden von dem Interface „Credentials“ gefordert:
• getUserName()
Diese Methode muss den Benutzernamen für Connections zurückliefern. Dabei
ist wichtig, dass dies für den Benutzer, der die Funktion ausführt, geschieht.
• GetUserPassword()
Analog zur Methode getUserName() muss diese Methode das zugehörige
Passwort zurückgeben.
Beispielhaft wurden auch hier zwei Klassen implementiert, die wiederum das Interface
Credentials implementieren (siehe Abbildung 21):
• CredentialsGreenhouse
Diese Implementierung liefert fest vorgegebene Benutzerinformationen für den
Zugriff auf Lotus Greenhouse. Die im Quelltext angegebenen Informationen
sind nicht gültig.
• CredentialsConnectionsGateway
Diese Klasse liest die Benutzerinformationen aus der Anwendung
ConnectionsGateway aus und gibt sie entsprechend der Zugriffsmethoden
zurück.
67
<<Interface>>Credentials
CredentialsGreenhouse CredentialsConnectionsGateway
4 Implementierung der Schnittstelle
Wenn also bereits eine Anwendung im Domino-Umfeld verfügbar ist, die die
entsprechenden Anmeldeinformationen speichert, so kann über das Interface eine
Klasse für den Zugriff auf diese Daten implementiert werden.
4.3 Beispielhafte Integration in das Benutzerinterface
Die in Kapitel 3.5.3 identifizierten Szenarien teilen sich in zwei Gruppen, die Suche
nach Informationen basierend auf Tags und die Veröffentlichung von Tags im Profil des
Benutzers.
Abbildung 22 zeigt die Integration in das bestehende Benutzerinterface151 von SkiP.
Abbildung 22: Integration der Schnittstelle in das Benutzerinterface von SkiP
151 Zum Vergleich zeigt Abbildung 6 auf S. 15 das ursprüngliche Benutzerinterface von SkiP
68
4 Implementierung der Schnittstelle
Jeder einzelne Skill-Bereich ist um eine Liste von Links zur Suche in den
entsprechenden Connections Anwendungen ergänzt worden. Aus den Bewertungen der
Skills werden jeweils die besten zwei und die schlechtesten zwei ausgewählt und zur
Suche angeboten. Sind jeweils mehr als zwei gleich bewertet, so werden nur die jeweils
ersten zwei verwendet. Somit bekommt der Benutzer sowohl die Möglichkeit nach
seinen Interessen, als auch nach Informationen zur Weiterbildung zu suchen. Klickt der
Benutzer einen dieser Links an, so wird mit den entsprechenden Tags in der
Anwendung nach Informationen gesucht und die Ergebnisse werden in einem Fenster
(siehe Abbildung 23) ebenfalls als Links dargestellt. Ein Klick auf einen dieser Links
führt den Besucher direkt zu der Information.
Abbildung 23: Einblendung von Suchergebnisse aus Profiles in einem Fenster
Die Übertragung der Tags in das Profil des Benutzers erfolgt über die Aktion „Profil
aktualisieren“ (siehe Abbildung 24, S. 70, oben rechts). Ein Klick auf diese Aktion
öffnet zunächst einen Bestätigungs-Dialog (siehe Abbildung 24, S. 70), in dem
aufgelistet ist, welche Tags in das Profil übertragen würden. Bestätigt der Benutzer
diesen Dialog, werden die Informationen in das Profil der Anwendung Profiles
übertragen.
69
4 Implementierung der Schnittstelle
Abbildung 24: Einblendung eines Bestätigungsdialogs vor der Datenübertragung
4.4 Bewertung der Implementierung
Mit der vorgestellten Implementierung konnten die gestellten Forderungen an die
Schnittstelle erfüllt werden.
Der organisatorischen Rahmenbedingungen zur Wahrung der Informationen in SkiP
wird in erster Linie durch die ausgewählten Szenarien Rechnung getragen. Jegliche
Aktion im Bezug auf die Schnittstelle muss vom Benutzer ausgehen. Somit ist
gewährleistet, dass das Vertrauen in das Skill-Management-System nicht vermindert
wird.
Die in Kapitel 3.5.4 ausgewählten Szenarien konnten mit der gewählten Architektur
einer separaten Schnittstellenkomponente realisiert werden. Auch konnte der Forderung
nach Flexibilität durch eine offene Parameterübergabe per URL-Aufruf nachgekommen
werden. Dieses Art des Schnittstellenaufrufs ermöglicht die Problemlose Integration in
das Benutzerinterface von SkiP und ermöglicht auch die Integration in andere
Anwendungen. Durch die Rückgabe von aufbereiteten Ergebnisinhalten muss eine
Quell-Anwendung nur wenig angepasst werden.
Im Bezug auf Sicherheitsaspekte wird die sichere Benutzer- und Anmeldungs-
verwaltung von Domino verwendet. Dies bietet dem Benutzer zudem den Komfort einer
70
4 Implementierung der Schnittstelle
einmaligen Anmeldung am System, ohne dass er sich für weitere Interaktionen mit der
Schnittstelle erneut authentifizieren muss.
Die Betrachtung der Schnittstellen der einzelnen Anwendungen im Detail hat ergeben,
dass eine spezielle Implementierung der Schnittstelle je Anwendung notwendig ist, auch
wenn die technische Basis gemeinsam genutzt werden kann.
71
5 Zusammenfassung und Ausblick
5 Zusammenfassung und Ausblick
5.1 Zusammenfassung
Die Berührungspunkte zwischen Skill-Management und Web 2.0-Anwendungen
werden allein schon durch die thematische Überschneidung von Expertensystemen und
der Anwendung Profiles deutlich. Auch wenn die thematischen Übereinstimmungen bei
den übrigen betrachteten Anwendungen geringer sind, so ist eine Nutzung der Web 2.0-
Anwendungen als Informationsquelle eine Bereicherung für Anwendungen des Skill-
Managements und umgekehrt.
Die Analyse der möglichen Integrationsszenarien im Kapitel 3.5 hat gezeigt, dass nicht
alle Ansätze zur Koppelung der betrachteten Systeme den selben Nutzen stiften. Eine
Integration muss auch immer neben der technischen Machbarkeit die Sinnhaftigkeit
einer Umsetzung zugrunde legen. Die ermittelten und bewerteten Szenarien basieren auf
den organisatorischen Vorgaben. Dennoch ist das Grundmuster der Informations-
veröffentlichung und der Suche nach Informationen universell anwendbar.
Die Implementierung einer Schnittstelle auf Basis des Atom Publishing Protocol wird
technisch gesehen durch die Verwendung des Frameworks Abdera vereinfacht: Die
grundlegende HTTP-Kommunikation wird bereit gestellt und auch die Verarbeitung der
zurückgelieferten Informationen gestaltet sich dank der entsprechenden Klassen als
einfach. Trotzdem ist jede anzubindende Anwendung anders und erfordert gesonderte
Behandlung. Das zeigt sich auch bei den fünf betrachteten Anwendungen, die zwar
unter einem gemeinsamen Namen und miteinander integriert vertrieben werden, sich
aber in der konkreten Implementierung der Schnittstelle jeweils unterscheiden. Dennoch
war es möglich, den Ansatz der Schnittstelle so generisch zu halten, dass auch
Erweiterungen auf künftige Anwendungen unter dem Namen Connections als auch
andere Web 2.0 Anwendungen möglich bleibt.
Die Integration in die Benutzeroberfläche bestehender Applikation kann schnell und
ohne große Eingriffe erfolgen. Eine starre Kopplung und die dadurch bedingten
Abhängigkeiten konnte aufgrund der verwendeten Web-Technologien vermieden
werden.
72
5 Zusammenfassung und Ausblick
5.2 Ausblick
Die vorgestellte Schnittstelle kann ohne weitere Anpassung genutzt werden. Allerdings
sind viele interessante Erweiterungsmöglichkeiten denkbar. Im Kapitel 3.5 wurden weit
mehr Integrationsszenarien vorgestellt und bewertet, als exemplarisch im Rahmen
dieser Arbeit umgesetzt werden konnten. Die Aufstellungen und Bewertungen dieser
Szenarien helfen bei der Auswahl künftiger Erweiterungen.
Natürlich sind auch Szenarien außerhalb des Fokus des einzelnen Mitarbeiters denkbar.
Diese Szenarien wurden hier nicht betrachtet. Ein Beispiel wären Integrationsszenarien
für Vorgesetzte, die für eine Gruppe von Mitarbeitern bspw. eine Aktivität zur
Organisation einer Schulung anlegen könnten. Die vorgestellte Implementierung ist für
die Erweiterung um neue Szenarien offen.
Eine Ausweitung der vorgestellten Lösung auf verschiedene Connections-Instanzen ist
ebenso möglich, wie die Anbindung weiterer Web 2.0-Anwendungen.
Technisch gesehen, können die vorgesehenen Konstrukte zur Konfiguration leicht
dahingehend erweitert werden, dass entsprechende Connections-Instanzen über
zusätzliche Parameter identifiziert und angesprochen werden können. Die abstrakte
Klasse, die Basis jeder anwendungsspezifischen Klasse ist, kann dank des allgemeinen
Aufbaus auch als Basis für die Anbindung weiterer Anwendungen dienen.
Eine zweite Connections-Instanz könnte bspw. außerhalb des Firmennetzwerks
erreichbar sein. Dort könnte die Anwendung Profiles mit Tags versorgt werden,
während in einer internen Activities-Instanz Weiterbildungsmaßnahmen und interne
Vorhaben koordiniert werden.
Zur Anbindung weiterer Ziel-Anwendungen, die ein API via Atom Publishing Protocol
bereitstellen, können die Basisfunktionen genutzt und in abgeleiteten Klassen auf die
entsprechenden Ziel-Systeme angepasst werden.
Die Schnittstelle ist in der Implementierung so allgemein gehalten, dass auch andere
Anwendungen als SkiP Ausgangspunkt einer Integration sein können. Insbesondere die
Szenarien zur Suche nach Informationen können aus nahezu beliebigen anderen
Anwendungen ebenfalls aufgerufen und sinnvoll genutzt werden. Damit kann der
Nutzung der Web 2.0-Anwendungen weiter Vorschub geleistet werden. Gleichzeitig
73
5 Zusammenfassung und Ausblick
engt die technische Kopplung die Weiterentwicklung der jeweiligen Anwendungen
nicht ein.
Die Akzeptanz der Schnittstelle in so sensiblen Systemen wie denen des Skill-
Managements muss erst noch geprüft werden. Dennoch ist eine Öffnung dieser
Anwendungen zur Integration mit Web 2.0-Anwendungen ein wichtiger Schritt und
kann die Nutzung beider Ansätze voranbringen. Aufgrund der Sensibilität ist hier
jedoch äußerst vorsichtig vorzugehen, was etwa die Implementierung automatisierter
Schnittstellen anbelangt.
Web 2.0-Anwendungen haben das Potential, die Generierung und Dokumentation von
Wissen in Unternehmen nachhaltig zu beeinflussen. Die Nutzung solcher Software ist
gerade für technikbegeisterte Benutzer der Generation „Internet“ nahezu selbst-
verständlich. Die Dokumentation von Wissen ist durch den Einsatz dieser Systeme nicht
mehr lästige Pflicht, sondern erfolgt durch die Verwendung automatisch und ohne
großen zusätzlichen Aufwand für den Benutzer.
Skill-Management und Web 2.0-Anwendungen ergänzen sich gegenseitig, ohne dass es
durch die Überschneidungen zu Redundanzen kommt. Die zeitgleiche Verfolgung
beider Ansätze ist für den jeweils anderen förderlich.
74
6 Literaturverzeichnis
6 Literaturverzeichnis
Abrams, D.; Baecker, R.; Chignell, M. (1998) Abrams, David; Baecker, Ron; Chignell, Mark; Information archiving with bookmarks - Personal Web space construction and organization In: Proceedings ACM SIGCHI, (1998), S.41-48
Alby, T. (2008) Alby, Tom; Web 2.0 - Konzepte, Anwendungen, Technologien, 3. überarbeitete Auflage, Carl Hanser Verlag München 2008
Basic, R. (2005) Basic, Robert; Unterschied Forum, Chat, Newsgroup, Blog, 2005; Aus: http://www.basicthinking.de/blog/2005/12/21/unterschied-forum-chatnewsgroup-blog/ am 27.12.2008
Beged-Dov, G. et al. (2008) Beged-Dov, Gabe; Brickley, Dan; Dornfest, Rael; Davis, Ian; Dodds, Leigh; Eisenzopf, Jonathan; Galbraith, David; Guha, Ramanathan V.; MacLeod, Ken; Miller, Eric; Swartz, Aaron; van der Vlist, Eric; RDF Site Summary (RSS) 1.0, 2008; Aus: http://web.resource.org/rss/1.0/spec am 13.02.2009
Berners-Lee, T. (1989) Berners-Lee, Tim; Information Managment: A Proposal, 1989; Aus: http://www.w3.org/History/1989/proposal.html am 22.03.2009
Berners-Lee, T. (1999) Berners-Lee, Tim; Talk to the LCS 35th Aniversary celebrations, 1999; Aus: http://www.w3.org/1999/04/13-tbl.html am 18.11.2008
BMWi (2006) Bundesministerium für Wirtschaft und Technologie; e-f@cts Nr. 10 - Wissensmanagement, Berlin, 2006
Bray, T. et al. (2006) Bray, Tim; Hollander, Dave; Layman, Andrew; Tobin, Richard; W3C - Namespaces in XML 1.0 (Second Edition), 2006; Aus: http://www.w3.org/TR/REC-xml-names/ am 04.03.2009
Burg, T. N.; Pircher, R. (2006) Burg, Thomas N.; Pircher, Richard; Social Software im Unternehmen In: wissensmanagement, 03/2006 (2006), S.26-28
Cappellato, J. (2006) Cappellato, Jacopo; Monthly reports to the Apache Software Foundation Board of Directors from incubator projects June 2006, 2006; Aus: http://wiki.apache.org/incubator/June2006 am 04.03.2009
75
6 Literaturverzeichnis
Cruger, R. (2003) Cruger, Roberta; The mash-up revolution, 2003; Aus: http://dir.salon.com/story/ent/music/feature/2003/08/09/mashups_cruger/print.html am 27.12.2008
Doctorow, C. et al. (2002) Doctorow, Cory; Dornfest, Rael; Johnson, J. Scott; Powers, Shelly; Trott, Benjamin; Trott, Mena G.; Essential Blogging, 1. Auflage, O'Reilly Sebastopol 2002
Eckert, T. (2006) Eckert, Thomas; Java unter Lotus Domino - Know-how für die Anwendungsentwicklung, 1. Auflage, Springer Verlag Berlin 2006
Faix, W. G.; Buchwald, C.; Wetzler, R. (1991) Faix, Werner G.; Buchwald, Christa; Wetzler, Rainer; Skill Management - Qualifikationsplanung für Unternehmen und Mitarbeiter, 1. Auflage, Gabler Wiesbaden 1991
Fielding, R.T. (2000) Fielding, Roy T.; Architectural Styles and the Design of Network-based Software Architectures, 2000; Aus: http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf am 02.03.2009
Fisch, M.; Gscheidle, C. (2006) Fisch, Martin; Gscheidle, Christoph; Onliner 2006: Zwischen Breitband und Web 2.0 - Ausstattung und Nutzungsinnovation In: Media Perspektiven, 08/2006 (2006), S.431-440
Fisch, M.; Gscheidle, C. (2008a) Fisch, Martin; Gscheidle, Christoph; Technische Ausstattung der Onliner in Deutschland In: Media Perspektiven, 07/2008 (2008), S.345-349
Fisch, M.; Gscheidle, C. (2008b) Fisch, Martin; Gscheidle, Christoph; Mitmachnetz Web 2.0: Rege Beteiligung nur in Communitys In: Media Perspektiven, 07/2008 (2008), S.356-364
Gerbert, H.; Kutsch, O. (2003) Gerbert, Henning; Kutsch, Oliver; Potenziale des Skill-Managements In: Wirtschaftsinformatik 2, 02 (2003), S.227-229
Gronau, N.; Uslar, M. (2004) Gronau, Norbert; Uslar, Mathias; Skill-Management: Anwendungen und Erfahrungen In: Personalführung, 10 (2004), S.28-38
Groß, M.; Hülsbusch, W. (2005) Groß, Mathias; Hülsbusch, Werner; Weblogs und Wikis - Potenziale für betriebliche Anwendungen und E-Learning In: wissensmanagement, 01/2005 (2005), S.50-53
76
6 Literaturverzeichnis
IBM - Connections Install (2008) IBM ; Lotus Connections 2.0.1 - Installation Guide, 2008; Aus: http://www.ibm.com/developerworks/lotus/documentation/connections/ am 02.03.2009
Kaufmann, T. (2005) Kaufmann, Tim; Google Earth mit Flickr-Fotos und Deutschlanddaten, 2005; Aus: http://www.golem.de/0507/39210.html am 08.11.2008
Knäpper, M.; Donskoj, M. (2007) Knäpper, Matthias; Donskoj, Markus; Anwendungsentwicklung unter Lotus Notes Domino 7 - Konzepte, Technologien, Realisierung, 1. Auflage, Addison Wesley München 2007
Krasser, N.; Foerster, M. (2007) Krasser, Nikolaus; Foerster, Marcus; Web 2.0. Ein neuer Hype oder nachhaltiger Nutzen für Unternehmen? In: Information Management, 01/2007 (2007), S.51-55
Laningham, S. (2006) Laningham, Scott; developerWorks Interviews - Tim Berners-Lee, 2006; Aus: http://www.ibm.com/developerworks/podcast/dwi/cm-int082206txt.html am 18.11.2008
Locke, C. (2000) Locke, Christopher; Internet Apocalypso (1. Kapitel des online verfügbaren Buches "The Cluetrain Manifesto"), 2000; Aus: http://www.cluetrain.com/book/apocalypso.html am 18.11.2008
Millen, D.; Feinberg, J.; Kerr, B. (2005) Millen, David; Feinberg, Jonathan; Kerr, Bernhard; Social bookmarking in the enterprise In: ACM Queue, Vol. 3 No. 9 (2005), S.29-35
Möller, E. (2005) Möller, Eric; Die heimliche Medienrevolution – Wie Weblogs, Wikis und freie Software die Welt verändern, 1. Auflage, Heise Zeitschriften Verlag GmbH & Co KG Hannover 2005
Netscape (1999) Netscape; My Netscape Network - Quickstart, 1999; Aus: http://www.purplepages.ie/RSS/netscape/rss0.90.html am 13.02.2009
Nonaka, I.; Takeuchi, H. (1995) Nonaka, Ikujiro; Takeuchi, Hirotaka; Die Organisation des Wissens - Wie japanische Unternehmen eine brachliegende Ressource nutzbar machen, 1. Auflage, Campus Verlag Frankfurt/New York 1995
North, K. (2005) North, Klaus; Wissensorientierte Unternehmensführung - Wertschöpfung durch Wissen, 4. Auflage, Gabler Wiesbaden 2005
77
6 Literaturverzeichnis
O'Reilly, T. (2005) O'Reilly, Tim; What Is Web 2.0 - Design Patterns and Business Models for the Next Generation of Software, 2005; Aus: http://www.oreillynet.com/lpt/a/6228 am 25.10.2008
Pakalski, I. (2004) Pakalski, Ingo; Google will Handel mit Gmail-Zugängen unterbinden, 2004; Aus: http://www.golem.de/print.php?a=32110 am 13.02.2009
Pakalski, I. (2007) Pakalski, Ingo; Googles Gmail für alle, 2007; Aus: http://www.golem.de/print.php?a=50392 am 13.02.2009
Pieler, D.; Schuh, M. (2003) Pieler, Dirk; Schuh, Michael; Mit Skill Management die richtige Aufstellung für die Zukunft realisieren In: wissensmanagement, 02 (2003), S.20-22
Poller, A. (2008) Poller, Andreas; Privatsphärenschutz in Soziale-Netzwerke-Plattformen, 2008; Aus: http://www.sit.fraunhofer.de/Images/SocNetStudie_Deu_Final_tcm105-132111.pdf am 23.02.2009
Probst, G.; Raub, S.; Romhardt, K. (2003) Probst, Gilbert; Raub, Stefan; Romhardt, Kai; Wissen managen - Wie Unternehmen ihre wertvollste Ressource optimal nutzen, 4. überarbeitete Auflage, Gabler Wiesbaden 2003
Schiller García, J. (2007) Schiller García, Jürgen; Enterprise 2.0 - Web 2.0 im Unternehmen, 1. Auflage, VDM Verlag Dr. Müller Saarbrücken 2007
Schindler, M. (2001) Schindler, Martin; Wissensmanagement in der Projektabwicklung. Grundlagen, Determinanten und Gestaltungskonzepte eines ganzheitlichen Projektwissensmanagement, 2. durchgesehene Auflage, Josef Eul Verlag Lohmar 2001
Schütt, P. (2001) Schütt, Peter; Die Technologietrends im Wissensmanagement, 2001; Aus: http://www.wissensmanagement.net/online/archiv/2001/01_0201/technologietrends.shtml?print am 29.12.2008
Schütt, P. (2002) Schütt, Peter; Wissensmanagement - was ist das eigentlich? In: wissensmanagement, 01/2002 (2002), S.50-52
Seegmüller, K. (2006) Seegmüller, Kirsten; Die Qual der Wahl - Das geeignete Wissensmanagementsystem finden In: wissensmanagement, 05/2006 (2006), S.21-25
78
6 Literaturverzeichnis
Six Apart (2004) Six Apart; TrackBack Technical Specification v1.2, 2004; Aus: http://www.sixapart.com/pronet/docs/trackback_spec am 21.02.2009
Smith, G. (2004) Smith, Gene; Folksonomy - social classification, 2004; Aus: http://atomiq.org/archives/2004/08/folksonomy_social_classification.html am 27.12.2008
Snell, J. (2006) Snell, James; Abdera Proposal, 2006; Aus: http://wiki.apache.org/incubator/AbderaProposal am 02.03.2009
Surowiecki, J. (2004) Surowiecki, James; The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations, 1. Auflage, Doubleday New York 2004
Ullenboom, C. (2007) Ullenboom, Christian; Java ist auch eine Insel - Programmieren mit der Java Standard Edition Version 6, 7. aktualisierte Auflage, Galileo Press Bonn 2007
UserLand Software (2000) UserLand Software; RSS 0.91, 2000; Aus: http://backend.userland.com/rss091 am 13.02.2009
UserLand Software (2003) UserLand Software; RSS 0.92, 2003; Aus: http://backend.userland.com/rss092 am 13.02.2009
Van Eimeren, B.; Frees, B. (2006) Van Eimeren, Birgit; Frees, Beate; Schnellere Zugänge, neue Anwendungen, neue Nutzer? In: Media Perspektiven, 08 (2006), S.402-415
Wikipedia - Abdera (2009) Wikipedia; Abdera, 2009; Aus: http://de.wikipedia.org/wiki/Abdera am 02.03.2009
Wikipedia - Demokrit (2009) Wikipedia; Demokrit, 2009; Aus: http://de.wikipedia.org/wiki/Demokrit am 02.03.2009
Wikipedia - Dotcom-Blase (2008) Wikipedia; Dotcom-Blase, 2008; Aus: http://de.wikipedia.org/wiki/Dotcom-Blase am 27.12.2008
Winer, D. (2007) Winer, Dave; RSS 2.0, 2007; Aus: http://cyber.law.harvard.edu/rss/rss.html am 13.02.2009
79
6 Literaturverzeichnis
World Internet Statistics (2008) Miniwatts Marketing Group; World Internet Usage Statistics, 2008; Aus: http://www.internetworldstats.com/stats.htm am 19.11.2008
80
7 Anhang
7 Anhang
7.1 Die Anwendung ConnectionsGateway
Die Schnittstelle ist in der Domino-Anwendung „ConnectionsGateway“ zusammen-
gefasst. Sie enthält alle notwendigen Möglichkeiten zur Konfiguration und die zentrale
Funktion, die als Agent „Query“ implementiert ist.
7.1.1 Installation
Zum Betrieb der Anwendung sind drei Installationsschritte notwendig:
• Installation von ConnectionsGateway
Die Datei „ConnectionsGateway.nsf“ muss im Datenverzeichnis des Domino-
Servers abgelegt werden.
• Installation der Java-Komponente „ConnectionsAccess“
Die Datei „connections-access-1.0.jar“ muss in den ClassPath der JVM des
Domino Servers kopiert werden. Dieses Verzeichnis befindet sich im
Programmverzeichnis des Domino Servers unter „/jvm/ext“.
7.1.2 Konfiguration
Damit die Schnittstelle mit verschiedenen Installationen und Benutzern verwendet
werden kann, müssen sowohl die Benutzerinformationen (siehe Abbildung 25, S. 82)
als auch die Zugangsinformationen zu Connections (Abbildung 26, S. 82) konfiguriert
werden.
Für jeden Benutzer müssen die folgenden Informationen hinterlegt werden. Die
Verwaltung der Informationen erfolgt direkt in der Anwendung ConnectionsGateway.
• E-Mailadresse
dient zur Identifizierung des Benutzers
• Passwort
dient zur Authentifizierung des Benutzers
81
7 Anhang
Abbildung 25: Erfassung der Benutzerinformationen
Für den Zugang zu Connections selbst müssen die URLs der einzelnen Anwendungen
bekannt sein. Jede Anwendung kann dabei komplett unabhängig von den anderen
konfiguriert werden. Auch hier erfolgt die Konfiguration direkt in der Anwendung
ConnectionsGateway.
Abbildung 26: Erfassung der URL-Angaben zu den einzelnen Anwendungen
7.1.3 Der Agent Query
Der Agent „Query“ kann per URL aufgerufen werden. Die Parameter für den Aufruf
werden dabei wie folgt übergeben:
http://<Pfad_zu_ConnectionsGateway>/(query)?OpenAgent&<parameter>
Tabelle 17, auf S. 83 zeigt die Möglichen Parameter, die übergeben werden können. Die
obligatorischen Parameter sind in der Spalte „Pflicht“ entsprechend gekennzeichnet. Die
82
7 Anhang
einzelnen Parameter müssen wie folgt übergeben werden und durch das Zeichen „&“
voneinander getrennt werden:
&<parameter_1>=<wert_1>[&<parameter_1>=<wert_1>[...]]
Parameter Pflicht Bedeutungapplication x Anwendung die kontaktiert werden sollaction x Aktion die durchgeführt werden solltags - Tags als Parameter für die Aktion, mehrere Tags sind
durch „+“ voneinander zu trennenemail - E-Mailadresse als Parameter für die Aktion
Tabelle 17: Agent „Query“ - Parameter
Der Parameter application gibt an, mit welcher Anwendung von Connections
kommuniziert werden soll. Die möglichen Werte für den Parameter und deren
Bedeutung sind der Tabelle 18 zu entnehmen. Der Parameter application muss in jedem
Fall angegeben werden.
Wert Bedeutungprofiles Anwendung „Profiles“ (Benutzerprofile)communities Anwendung „Communities“ (Diskussionsforen)blogs Anwendung „Blogs“ (Weblogs)dogear Anwendung „Dogear“ (Lesezeichenverwaltung)activities Anwendung „Activities“ (Aktivitäten)
Tabelle 18: Agent „Query“ - Werte für den Parameter „application“
Welche Aktion durchgeführt werden soll, bestimmt der Parameter action. Auch dieser
Parameter muss zwingend angegeben werden und kann die in Tabelle 19 aufgelisteten
Werte annehmen.
Wert BedeutunggetService Liefert das Service-DokumentgetSearchAllByTag Liefert das Ergebnis einer Suche mit Tags als Suchkriterium
Der Parameter tags muss mit übergeben werden.updateTagsByEmail Aktualisiert die Tags eines Profils
Der Parameter application muss den Wert „profiles“ haben.Der Parameter tags muss übergeben werden.
Tabelle 19: Agent „Query“ - Werte für den Parameter „action“
83
7 Anhang
Die Parameter tags und email sind optional. Für bestimmte Werte des Parameters
action müssen sie aber gefüllt sein. Diese Abhängigkeiten sind in der Tabelle 19 bei
dem entsprechenden Wert für den Parameter action nachzulesen.
Der Parameter tags kann mehr als einen Wert aufnehmen. Die einzelnen Werte sind
dabei durch das Zeichen „+“ wie im folgenden Beispiel zu trennen:
tags=connections+api+java
Der Parameter email kann nur eine Email-Adresse aufnehmen. Diese muss dabei so
codiert sein, dass das Zeichen „@“ durch „%40“ wie im folgenden Beispiel ersetzt
wird:
email=peter.meier%40beispiel.de
84
7 Anhang
7.2 Das Framework „Abdera“
Zur Installation des Java-Framework „Abdera“ müssen die in der Tabelle 20 auf S. 85
gelisteten Dateien aus dem Abdera-Archiv ebenfalls in den ClassPath der JVM des
Domino Servers152 kopiert werden.
apache-abdera-0.4.0-incubating.zipabdera-0.4.0-incubating.jarlib/
axiom-api-1.2.5.jaraxiom-impl-1.2.5.jaraxiom-LICENSE.txtcommons-beanutils-1.7.0.jarcommons-codec-1.3.jarcommons-collections-3.2.jarcommons-httpclient-3.1-rc1.jarcommons-lang-2.3.jarcommons-LICENSE.txtcommons-logging-1.0.4.jarezmorph-1.0.4.jarezmorph-LICENSE.txtgeronimo-activation-LICENSE.txtgeronimo-activation_1.0.2_spec-1.1.jargeronimo-stax-api_1.0_spec-1.0.1.jargeronimo-stax-LICENSE.txthtmlparser-1.0.5.jarhtmlparser-LICENSE.txtjaxen-1.1.1.jarjaxen-LICENSE.txtjetty-6.1.5.jarjetty-LICENSE.txtjetty-util-6.1.5.jarjson-lib-2.2.1-jdk15.jarjson-lib-LICENSE.txtservlet-api-2.5-6.1.5.jarservlet-api-LICENSE.txtwstx-asl-3.2.1.jarwstx-asl-LICENSE.txtxalan-2.7.0.jarxalan-LICENSE.txtxmlsec-1.3.0.jarxmlsec-LICENSE.txt
mod/abdera-client-0.4.0-incubating.jarabdera-core-0.4.0-incubating.jarabdera-couchdb-0.4.0-incubating.jarabdera-extensions-gdata-0.4.0-incubating.jarabdera-extensions-geo-0.4.0-incubating.jarabdera-extensions-html-0.4.0-incubating.jarabdera-extensions-json-0.4.0-incubating.jarabdera-extensions-main-0.4.0-incubating.jarabdera-extensions-media-0.4.0-incubating.jarabdera-extensions-oauth-0.4.0-incubating.jarabdera-extensions-opensearch-0.4.0-incubating.jarabdera-extensions-serializer-0.4.0-incubating.jarabdera-extensions-sharing-0.4.0-incubating.jarabdera-extensions-wsse-0.4.0-incubating.jarabdera-filesystem-0.4.0-incubating.jarabdera-i18n-0.4.0-incubating.jarabdera-jcr-0.4.0-incubating.jarabdera-jdbc-0.4.0-incubating.jarabdera-parser-0.4.0-incubating.jarabdera-security-0.4.0-incubating.jarabdera-server-0.4.0-incubating.jarabdera-spring-0.4.0-incubating.jar
Tabelle 20: Dateien des Archivs „apache-abdera-0.4.0-incubating.zip“
152 Vergl. Kapitel 7.1.1
85
7 Anhang
7.3 Alternative „Java-Bibliothek“
Domino bietet die Möglichkeit, Java-Klassen auch in Java-Bibliotheken in den Domino-
Anwendungen direkt zu hinterlegen. Dies entspricht eher dem klassischen Ansatz der
Entwicklung von Domino-Anwendungen als Container für sämtliche Code-
Bestandteile.
Die Java-Komponente „ConnectionsAccess“ (siehe Kapitel 7.1.1) und auch Abdera
(siehe Kapitel 7.2) können in einer solche Java-Bibliothek gespeichert werden. Wenn
diese aber verwendet werden sollen, müssen bei dem entsprechenden Programm-Code
die Java-Bibliotheken explizit hinzugefügt werden.
Aus der Sicht einer kompletten Anwendung ist dies wünschenswert. Ebenso aus
Sicherheitsgründen, da kein Java-Code frei auf dem Server für sämtliche anderen
Komponenten Verfügbar ist.
Andererseits ist die Verwendung von Java-Bibliotheken nicht sehr performant, da die
entsprechenden Dateien bei jedem Aufruf aus der Java-Bibliothek entpackt und auf dem
Server zwischen gespeichert werden müssen, nur um nach der Beendigung des
Programms wieder gelöscht zu werden.
Für welche Alternative man sich entscheidet ist letzten Endes von den eigenen
Ansprüchen an Sicherheit und Performance des Servers abhängig.
86
