!--a11y-->
Java-Proxy-Objekte 
Alle Java-Objekte, die ausgehend von einem Message-Interface aus dem Integration Repository im SAP-System angelegt werden, nennt man Java-Proxy-Objekte. Zu einem Message-Interface werden mehrere Proxy-Objekte im System angelegt (Java-Klassen oder Java-Interfaces).

Message-Interfaces enthalten Message-Typen und diese wiederum Datentypen. Alle zum Message-Interface referenzierten Objekte (auch Fault-Message-Typen) nennt man zusammenfassend auch Interface-Objekte. Sie sind das Pendant zu den daraus generierten Proxy-Objekten.
Man kann die unterschiedlichen Interface-Objekte in zwei Klassen einteilen: Das Message-Interface selbst und die Parameter und Datentypen dazu (siehe auch: Umsetzung von WSDL in die Zielsprache).

Auch nach der Generierung lässt sich jedes generierte Proxy-Objekt seinem zugehörigen Interface-Objekt im Integration Repository zuordnen.
Interfaces haben eine Richtung (outbound oder inbound) und eines Modus (synchron oder asynchron), siehe Kommunikationsparameter.

Die Java-Laufzeit stellt noch kein Queueing für die asynchrone Verarbeitung von Messages zur Verfügung. Tritt beim Versenden einer asynchronen Message ein Fehler auf, wird eine Ausnahme ausgelöst.
Abhängig von der Richtung werden folgende Proxy-Objekte generiert:
· Inbound-Interfaces werden gerufen, um einen Service zu starten, der im synchronen Fall ein Ergebnis zurückliefert. Die Proxy-Generierung generiert für ein Inbound-Interface ein Java-Interface. Um den Service bereitzustellen, implementieren Sie dieses Interface mit Hilfe einer Java-Klasse. Für die implementierende Klasse ist folgendes zu beachten: Ist JavaInterface der Name des generierten Java-Interfaces, dann muss die implementierende Klasse JavaInterfaceImpl heißen und im gleichen Paket wie das generierte Java-Interface liegen.
· Outbound-Interfaces werden gerufen, um eine Message an ein Inbound-Interface zu senden. Ein Outbound-Interface wird auf eine Java-Klasse abgebildet.
· Für J2EE-Anwendungen müssen Sie zusätzliche Bean-Klassen generieren. In diesem Fall senden und empfangen Sie Messages nicht direkt über die Proxy-Klassen, sondern über die Bean-Klassen. Für Java-Standalone-Anwendungen werden diese Klassen nicht benötigt.
Allgemein sieht die Signatur der generierten Methode zu einem Message-Interface MI aus dem Integration Repository folgendermaßen aus (im asynchronen Fall ohne Rückgabeparameter):
· Im Outbound-Fall: public <Klasse für Input Message> MI(<Klasse Output Message>)
· Im Inbound-Fall: public <Klasse für Output Message> MI(<Klasse für Input Message>)
Die Klasse für die Input- beziehungsweise Output-Message entspricht dabei dem Datentyp, auf den der verwendete Message-Typ verweist. Für Message-Typen selbst werden keine öffentliche globale Klassen erzeugt (Ausnahme sind Fault-Message-Typen).
Unabhängig von Out- oder Inbound werden folgende Objekte erzeugt:
· Eine Klasse für jeden komplexen Datentyp erzeugt, die set/get-Methoden für den Zugriff auf die jeweiligen Felder enthält.
· Für einfache Datentypen werden keine Klassen benötigt. Wird zum Beispiel ein einfacher Datentyp vom Typ xsd:string verwendet, generiert die Java-Proxy-Generierung keine eigene globale Klasse für den Datentyp, sondern benutzt direkt den korrespondierenden Java-Datentyp java.lang.String.
Außerdem können Sie in XSD Elemente definieren, die unbegrenzt oft in der Message auftreten können. Dieser spezielle Fall wird unter Tabellen beschrieben.
Die folgende Grafik gibt ein Beispiel, wie ein Interface aus dem Integration Repository auf ein Java-Proxy abgebildet wird:

Die ursprünglichen Namen der Interface-Objekte sind fett hervorgehoben. Man sieht, dass die Java Proxy-Generierung die Namen etwas erweitert (siehe auch: Namensvergabe für Java-Proxy-Objekte). Die Methode bookOut erwartet als Formalparameter om vom Typ Ct_Type. Sie übergeben also direkt den Datentyp – der Message-Typ wird von der Proxy-Laufzeit über die private Klasse Om_Message intern berücksichtigt.