Für die Objektverwaltung muss kein Proxy-Container gestartet sein.
Es ist zwischen folgenden Objekten zu unterscheiden:
MC-CmdHandler Client Instances
Ein Objekt für jeden verwalteten MC-CmdHandler. Über einen MC-CmdHandler können Sie auf das Dateisystem des betreffenden Rechners zugreifen und dort Skripts ausführen.
Communication Services
Ein Objekt für jeden verwalteten Communication Service. Ein Communication Service wird für die Kommunikation mit CICS-Partnern benötigt, er kann sowohl lokal als auch auf einem fernen Rechner ablaufen.
openUTM-LU62 Gateways
Ein Objekt für jedes verwaltete openUTM-LU62 Gateway. Ein openUTM-LU62 Gateway wird zusammen mit dem Communication Service für die Kommunikation mit CICS-Partnern benötigt. Er läuft jeweils auf demselben Rechner wie der zugehörige Communication Service.
BeanConnect Proxy Clusters
Ein Objekt für jeden verwalteten BeanConnect Proxy Cluster. Ein Proxy Cluster besteht aus einem oder mehreren Proxys, die zuvor konfiguriert werden müssen.
BeanConnect Proxies
Ein Objekt für jeden verwalteten BeanConnect Proxy, der nicht in einem Proxy Cluster enthalten ist.
Nur „administrierbare“ BeanConnect Proxys können mit der Management Console verwaltet werden. Ein BeanConnect Proxy wird als administrierbar betrachtet, wenn einer der folgenden Punkte zutrifft:
Bei dem Proxy handelt es sich um einen lokalen Proxy.
Bei dem Proxy handelt es sich um einen entfernten Proxy, dessen zugehöriger MC-CmdHandler verfügbar und über die Management Console bedienbar ist.
Resource Adapters
Jedem Proxy ist ein oder mehrere Resource Adapter zugewiesen. Ein Resource Adapter läuft auf einer Instanz eines Application Servers ab.
MBean Client
Für jeden Resource Adapter kann ein MBean-Client definiert werden. Mit Hilfe des MBeanClients kann die Management Console auf die MBeans des betreffenden JMX-Servers zugreifen (Attribute anzeigen und deren Werte ändern, Operationen ausführen und Notifications empfangen).
Es ist auch möglich, freie (stand-alone) MBean-Clients zu definieren, die keinem Resource Adapter zugeordnet sind. Freie MBean-Clients werden auf der obersten Ebene des Navigationsbaums dargestellt.
EIS Partners
Ein Objekt für jeden verwalteten EIS Partner.
Inbound Users
Der EIS Partner kann die Benutzerinformation (Benutzername und Passwort) über Inbound-Kommunikation weiterleiten. Diese Benutzerinformationen müssen dem Proxy bekannt sein.
Inbound Message Endpoints
Ein Inbound Message Endpoint stellt einen Kommunikationsendpunkt für Inbound-Kommunikation dar. Ein Proxy kann mehrere Inbound Message Endpoints verwalten.
Inbound Services
Ein Inbound Service stellt einen Service dar, den ein EIS Partner bei Inbound-Kommunikation adressiert. Ein Service ist immer genau einem Inbound Message Endpoint zugeordnet, es ist jedoch möglich, einem Inbound Message Endpoint mehrere Services zuzuordnen. Außerdem können Sie für einen Service Codierungseigenschaften definieren.
Outbound Services
Ein Outbound Service stellt einen vom EIS Partner zur Verfügung gestellten Service (Transaktionscode (TAC) oder CICS-Transaktion) dar.
Outbound Communication Endpoints
Für jeden (symbolischen) Service, der in der Konfigurations-Property connectionURL im Application Server angegeben ist, müssen Sie im Proxy einen entsprechenden Outbound Communication Endpoint mit dem gleichen Namen konfigurieren. In der Definition des Outbound Communication Endpoint wird der symbolische Service-Name auf einen realen Service-Namen in der EIS Partneranwendung abgebildet.
Outbound Communication Endpoints sind spezifisch für die EIS Partner. Einem EIS Partner können mehrere Outbound Communication Endpoints zugeordnet werden.
Näheres siehe Outbound Communication Endpoints konfigurieren.