Version: GSB7.2Java-Editor Hints
CoreMedia besteht hauptsächlich aus drei Serverkomponenten (ContentServer, WorkflowServer und PublicationServer), mehreren Redaktionsarbeitsplätzen (Java Editor) und anderen Komponenten. Der ContentServer dient der Erstellung und Verarbeitung von Inhalten, der WorkflowServer verteilt Aufgaben an verschiedene Gruppen von Redakteuren, und der PublicationServer führt zusammen mit dem CoreMedia Generator die Präsentation von publiziertem Content im Internet durch. Der Java-Editor ist das primäre Werkzeug eines Redakteurs zur Erstellung, Qualitätssicherung oder Publikation von Inhalten. Administrative Aufgaben, wie die Erstellung von Recherchen, Zuweisung von Rechten an Gruppen (von Redakteuren), werden ebenfalls mithilfe des Java-Editors erledigt. Hierfür greift der Editor über eine HTTP-Verbindung und über eine CORBA-Verbindung auf die zentral beim BVA gehosteten ContentServer und WorkflowServer zu.
Dieses Dokument beschreibt die Konfiguration der Netzwerkumgebung, die zum Betrieb des CoreMedia-Java-Editors innerhalb des IVBB notwendig ist.
Kommunikation
Die gesamte Kommunikation in der CoreMedia Content Application Platform findet mittels CORBA statt. Die Kommunikation findet dabei über TCP/IP-Sockets statt, deren Portnummern in der Regel nicht fest sind und zwischen zwei ORBs frei ausgehandelt werden. Als Protokoll wird IIOP (Internet Inter-ORB Protocol) zwischen zwei ORBs verwandt. Wichtig für die gegenseitige Identifizierung ist, dass alle Maschinen, die mittels CORBA kommunizieren, sich „normal“ über das Internet verbinden können (d.h. DNS-Eintrag, IP-Routing, etc.). Insbesondere kann das bei dem Einsatz von Firewalls nicht immer gewährleistet werden und es ist eine manuelle Konfiguration der ORBs nötig.
Verbindungsaufbau
Die CoreMedia Komponenten ContentServer, WorkflowServer und Java Editor verbinden sich fast ausschließlich über CORBA. Zum Verbindungsaufbau wird aber eine IOR (CORBA-Adresse) benötigt. Man kann eine (CORBA-) IOR in etwa mit einer (HTTP-) URL vergleichen. Da die IOR aber dynamisch nach jedem Server-Start neu festgelegt wird, kann sie nicht als „bekannt“ gelten und per Konfiguration festgelegt werden.
Beim Verbindungsaufbau muss also zuerst die IOR ermittelt werden. Diese wird vom ContentServer über einen genau dafür vorgesehenen HTTP-Port (im Folgenden „IOR-Port“ genannt) angeboten.
Daher öffnet ein Java Editor zuerst eine HTTP-Verbindung zu diesem „IOR-Port“. Die von dort bezogene IOR enthält dann die Server-Adresse, den CORBA-Port und weitere Adressdaten. Die CORBA-Verbindung wird dann zu dieser Adresse aufgebaut.
Konfiguration
Um den Betrieb des CoreMedia-Java-Editors innerhalb des IVBB zu ermöglichen, muss die Netzwerkumgebung entsprechend Konfiguriert werden. Dazu sind die im Folgenden beschrieben Konfigurationsschritte
- HTTP-Konfiguration
- CORBA-Konfiguration
notwendig.
Bei der späteren Einrichtung der Verbindungen über den IVBB ist zu berücksichtigen, dass die HTTP-Kommunikation (einschließlich IOR) über die Proxy-Server des IVBB abzuwickeln ist, die CORBA-Verbindungen (IIOP) aber über die TCP-Relays des IVBB geführt werden müssen.
HTTP-Konfiguration
Der ContentServer und der WorkflowServer der BKCMS können über das IVBB ausschließlich über einen Proxy-Server erreicht werden. Damit sichergestellt ist, dass die richtige Editor-Klasse eingebunden wird, muss der Editor geeignet konfiguriert werden. Dies geschieht bei einer lokalen Installation des Editors der Datei
<syntaxhighlight lang="xml" enclose="div"> <EDITOR_INSTALL_DIR>/bin/editor.jpif </syntaxhighlight>
In dieser Datei darf die ursprüngliche CoreMedia-Klasse
<syntaxhighlight lang="xml" enclose="div"> JAVA_MAIN_CLASS=hox.corem.editor.Editor </syntaxhighlight>
nicht verwendet werden. In dieser Anweisung muss die CoreMedia-Klasse durch eine spezielle BK CMS-Klasse ersetzt werden. Dies geschieht über die Anweisung
<syntaxhighlight lang="xml" enclose="div"> JAVA_MAIN_CLASS=de.bundonline.basis.editor.BolEditor </syntaxhighlight>
Es müssen außerdem die Daten des Proxy-Servers angegeben werden. Dies geschieht in der Anweisung
<syntaxhighlight lang="xml" enclose="div"> JAVA_VM_ARGS=" -DproxySet=true -DproxyHost=ihuru.materna.de -DproxyPort=9999 ${JAVA_VM_ARGS} -DbkcmsProxyBase64Encoded=true –Djava .security.policy=file:${COREM_HOME}${FS}properties${FS}policy${FS}editor.policy" </syntaxhighlight>
Es ist unbedingt darauf zu achten, dass die komplette Anweisung in einer Zeile ohne Zeilenumbrüche und in exakt der obigen Schreibweise (Groß-/Kleinschreibung) angegeben wird. Insbesondere ist darauf zu achten, dass
<syntaxhighlight lang="xml" enclose="div"> -Djava.security.policy </syntaxhighlight>
ohne Leerzeichen eingegeben wird. Die Bedeutungen der einzelnen Parameter sind:
- -DproxySet:
soll überhaupt ein ProxyServer verwendet werden? Mögliche Werte sind true oder false
- -DproxyHost:
Der Rechnername des ProxyServers
- -DproxyPort:
Die Portnummer des ProxyServers
Verlangt der ProxyServer eine Authentifizierung über einen Benutzernamen und ein Paßwort, so werden diese Werte direkt über ein Dialogfenster abgefragt. Sie müssen nun nicht mehr im Klartext in der editor.jpif-Datei angegeben werden. Lediglich der Paramete
- -DbkcmsProxyBase64Encoded
der die Werte true und false annehmen und gibt an, ob Username und
Paßwort per Base64-Kodierung übertragen werden sollen, oder nicht. Wird der Parameter nicht gesetzt, so wird keine Base64-Kodierung vorgenommen.
Durch diese Konfiguration ist sichergestellt, daß sowohl die IOR-Url des ContentServers, wie auch die des WorkflowServers nicht direkt angesprochen werden, sondern jeweils über den ProxyServer anfgefordert werden
Wird der Java-Editor zentral auf dem ContentServer installiert und per Java-WebStart ausgeliefert so wird automatisch die korrekte Java-Klasse benutzt und es werden die Proxy-Einstellungen aus dem WebBrowser bzw. aus der WebStart-Installation verwendet. Eine Angabe des Proxy-Hosts und –Ports sind hier nicht notwendig.
CORBA-Konfiguration
Wird nun der Java-Editor mit den beschriebenen Parametern gestartet, so sendet er seinen initialen HTTP-Request nicht mehr direkt an die IOR-Url des ContentServers oder WorkflowServers ab, sondern fordert den ProxyServer auf, die Anfragen entsprechend weiterzuleiten und die Antworten wiederum an den Java-Editor zurückzusenden.
In dieser Antwort hat jeweils der ContentServer und WorkflowServers seinen eigenen Rechnernamen und seinen IIOP-Port kodiert, über den die nachfolgende CORBA-Kommunikation ablaufen soll. Durch die in 2.1 beschriebene Konfiguration werden CORBA-Requests allerdings nicht beeinflußt, sodass der Java-Editor versucht, direkt auf den Rechnernamen des ContentServers/WorkflowServers zuzugreifen. Um die CORBA-Requests ebenfalls an den ProxyServer zu senden, muss sichergestellt sein, dass der Editor bei der DNS-Auflösung des Rechnernamens des ContentServers und auch des WorkflowServers nicht die IP-Adresse des ContentServers/WorkflowServers, sondern die des ProxyServers erhält.
Diese Umleitung kann lokal auf dem Rechner des Editors geschehen, unter Linux/Solaris z.B. durch Einträge in der Datei /etc/hosts, unter Windows in der analogen Datei unter C:\WINNT\System32\drivers\etc\hosts, oder aber im vom Java-Editor Rechner angesprochenen Nameserver, wodurch eine zentrale Administration dieser Umleitung ermöglicht. wird
Im letzten Schritt muss nun noch der Proxy-Server selber so konfiguriert werden, damit er die gleichen Ports, wie der ContentServer und der WorkflowServer für CORBA-Requests zugänglich macht und die Kommunikation auf diesem Port an den ContentServer weiterleitet, wie auch dessen Antworten an den anfragenden Editor überträgt.
Im Standardfall kodiert der ContentServer/WorkflowServer seine IP-Adresse und nicht seinen Rechnernamen in die IOR-URL ein, sodass in diesem Fall ein umleiten durch Einträge in der /etc/hosts-Datei nicht möglich ist. Daher muß der zu benutzende SERVER_RECHNER_NAME in der Datei
<syntaxhighlight lang="xml" enclose="div"> <CONTENT_SERVER_INSTALL_DIR>/bin/capserver.jpi </syntaxhighlight>
durch folgenden Eintrag explizit angegeben werden:
<syntaxhighlight lang="xml" enclose="div"> JAVA_VM_ARGS=“$JAVA_VM_ARGS=-Dooc.iiop.port=44444 –Dooc.iiop.host=SERVER_RECHNER_NAME“ </syntaxhighlight>
Für den WorkflowServer geschieht dies analog in der Datei
<syntaxhighlight lang="xml" enclose="div"> <WORKFLOW_SERVER_INSTALL_DIR>/bin/workflowserver.jpi </syntaxhighlight>
Auch hier ist unbedingt darauf zu achten, daß die komplette Anweisung in einer Zeile ohne Zeilenumbrüche und in exakt der obigen Schreibweise (Groß-/Kleinschreibung) angegeben wird.
Das angegebene Beispiel legt außerdem den IOR-Port des ContentServers auf 44444 fest. Wird der Port nicht explizit angegeben, so werden dynamisch unterschiedliche Ports vergeben. Der Port des WorkflowServers muß auf einen anderen Wert, etwa 44445.