Nächste Seite: Projektmanagement Aufwärts: Einführung Vorherige Seite: Die Ausschreibung Inhalt Index
So gab es zu Anfang die Idee, das System als eine Art invertiertes Ebay zu gestalten, in dem Anbieter ihre Produkte frei, oder auf spezielle Bedarfsanzeigen der Uni hin anbieten. Auch eine Art Link-Liste , in der alle ,,willigen`` Anbieter Links zu ihren Angeboten posten, oder mobile Agenten, die auf Anfragen hin selbstständig auf der Suche nach den günstigsten Angeboten durchs Web streifen, waren als Anregungen eingebracht worden.
Nach und nach wurden viele Ideen jedoch wieder verworfen. Zumeist entpuppte sich deren Umsetzung als viel zu komplex, oder, wie im Fall der mobilen Agenten, gab es keine flächendeckenden Standards und Techniken, auf die man sich stützen konnte.
Im Endeffekt einigten wir uns auf einen Entwurf, der hauptsächlich aus Client(client), Applicationserver(AppServer) und Workflowmanager(WFM) bestand :
Anfangs versuchten wir uns, für die 3 Hauptkomponenten: Client, Application-Server und Workflowmanager, möglichst an bereits existierenden Lösungen zu orientieren: Wir verbrachten einige Woche damit kommerzielle Produkte auf dem Sektor der ,,Arbeitsverteiler`` herauszusuchen, uns mit den Firmen in Verbindung zu setzten und die wenigen Trial-Versions, die uns darauf hin vereinzelt zur Verfügung gestellt wurden, auszuprobieren. Bei den meisten Anbietern scheiterte es bereits am Kontakt und so kamen wir lediglich dazu, 2 kommerzielle Workflowmanager zu testen.
Bei dem ersten handelte es sich um ,,BizTalk`` von Microsoft:
Der Microsoft BizTalk Server ist ein komplettes Workflow-Management System. Es hat eine eigene Datenbank. Man kann mit diesem System Frontends bauen, die komplette Daten-Haltung machen, Microsofts Sicherheitspakete in Zusammenhang mit dem Active Directory implementieren und alle Kommunikationsanforderungen befriedigen. Der BizTalk Server ist ein sehr mächtiges Werkzeug. Zuerst war für uns der Preis abschreckend.
In der für uns brauchbaren Version kostet der BizTalk Server etwa 15.000,- Euro.
Das größere Problem jedoch bestand darin, geeignete Zugangs-Möglichkeiten zu diesem System zu erhalten. Wir hatten keine Probleme, die Software zu beschaffen. Microsoft selbst unterstützte uns mit Trial-Versionen der notwendigen Programme. Wir bekamen auch ein Buch mit der offiziellen Entwickler-Dokumentation.
Dies waren sie allerdings schon, die positiven Momente! Das Buch erwies sich als in keinem Fall als hilfreich. Es waren viele Dinge beschrieben, wie ,,Klicken Sie dort`` oder ,,öffnen Sie dieses Fenster``. Die hinter der Software und der GUI verborgenen Konzepte, die uns eigentlich interessierte, blieb und bleibt uns verborgen.
Diese Konzepte jedoch waren uns wichtig, da es sich bei dem zu entwickelnden Produkt auch eine sicherheitskritische Anwendung handelte,in der es um erheblich Geldbeträge gehen wird. Des weiteren mussten wir kompatibel zu der vorhandenen HIS-Datenbank bleiben, welche auf einem IBM Informix-System basiert. Die gesamte BizTalk Daten-Haltung basiert auf einem SQL-Server. Ein Faktor bei der Vorbetrachtung des BizTalk-Servers war die angepriesene Möglichkeit, durch Nutzer Workflows erstellen zu lassen, was durch ein grafisches Interface möglich sein sollte.
Diese Information war schön, aber die Umsetzung dem Produkt in keiner Weise zu entlocken!!!
Die letzte und dann auch wahrscheinlich ausschlaggebenden Hürde war die Programmierbarkeit, die zwar als flexibel angepriesen wurde, wir aber mangels Dokumentation nicht in ganzer Tiefe testen konnten. Wir hatten eine Anwendung geschrieben, die mit dem BizTalk Server interagieren sollte. Dies war jedoch in einer unverhältnismäßigen Weise kompliziert, so dass das Projekt BizTalk-Server der Firma Microsoft damit abgeschlossen wurde.
Das Xerox Document Center mit ihrem Sparten-Produkt: ,,onRamp`` war die zweite Möglichkeit. Nachdem die ersten Installationsprobleme ausgeräumt waren, stellte sich schnell heraus, daß es sich hauptsächlich um eine Art E-Mail-Client handelte, der erfolgreiche Arbeitsschritte weiter meldete. Auch dieses Produkt reichte also nicht annähernd an die Anforderungen heran, die wir an einen Workflowmanager stellten. In diesem Fall wurden sie sogar weit unterschritten!
Nachdem also keine adäquaten Lösungen in Sicht waren, haben wir uns entschlossen, trotz des erheblichen Mehraufwandes, den Workflowmanager doch selbst zu implementieren. Wir wollten nun einen komplett arbeitsfähigen Baustein mit möglichst loser System-Bindung programmieren, um die Möglichkeit zu erhalten, später doch ein fremdes, aber ausgereifteres Produkt einzubinden
Weiterhin war die Einbindung von ,,LDAP`` als Directory-Service geplant, um eine Benutzer-Zertifizierung auch von System fremden Rechnern zu ermöglichen. Auch ein Web-Portal, über das Angebote eingeholt, oder Ausschreibungen ausgehängt werden können, sowie die Verwendung des Projekts ,,undine`` des Software-Hauses ,,AskNet`` waren vorgesehen. Diese Vorhaben sind letztlich aber ebenfalls der begrenzten Bearbeitungszeit zum Opfer gefallen, könnten aber durch nachfolgende Projekt-Gruppen eingebunden werden!
Im Verlaufe des Vorbereitungsseminars stellten sich verschiedenste Probleme heraus, auf die wir bei der Umsetzung unseres Vorhabens stoßen würden!
Nicht alle dieser Fragen haben wir im Verlaufe der Vorbereitung endgültig klären können. So halten wir z.B. den Gebrauch von Chip-Karten durchaus für sinnvoll und umsetzbar. Jedoch blieb uns durch den doch selbst erstellten Workflowmanager zu wenig Zeit, um solchen Feinheiten noch ausreichend Zeit zu widmen. Das Problem der Authentifizierung wollen wir nun zunächst mit einem ,,klassischen`` Login-Name-Passwort-Konzept lösen. Dieses kann jedoch später, vielleicht auch von der nachfolgenden Projekt-Gruppe, durch die Chipkartenlösung ersetzt werden.
Als wir endlich die Rahmenbedingungen für unsere kommende Semesteraufgaben fest geklopft hatten, beraumten wir ein Treffen mit Herrn Friedrich Oppelt, dem Entwicklungschef von ,,FSV`` der HIS GmbH, an. Er stellte uns sein System vor, das mit unserer Aufgabenstellung viele Parallelen aufwies und bot seine Hilfe an. Nach diesem Treffen hatten wir einen ungefähren Eindruck von dem, was auf uns zukommen würde. Dank den Ausführungen von Herrn Oppelt waren wir auf etliche Unwägbarkeiten vorbereitet und konnten uns zunächst auf die wesentlichen Grundlagen konzentrieren.
Weitere Treffen mit Leuten der iFORe GmbH, die ein Mittelbewirtschaftungs-System zum "FSV ëntwickelt hatten, brachte uns endgültig auf den Weg. Hier erhielten wir zahlreiche einschlägige Fachliteratur, sowie viel Hilfe im Umgang mit unseren späteren Haupt-Tools.
