Dynamische Proxy Klassen

Transkript

1 Dynamische Proxy Klassen Seminar Enterprise Computing Seminararbeit von André Markwalder, IB99 Fachhochschule Aargau Departement Technik Studiengang I Betreuender Dozent: Dr. D. Gruntz Windisch, 28. Januar 2002

2 Summary Seite 1 Der vorliegende Bericht stellt eine Einführung ins Thema der dynamischen Proxy Klassen dar. Die dynamischen Proxy Klassen bestehen grundsätzlich aus zwei Teilen, dem Proxy Design Pattern einerseits und dem JAVA Reflection API andrerseits. Der vorliegende Bericht gibt Aufschluss über die beiden Themen. Im ersten Teil wird tiefer auf das Proxy Design Pattern eingegangen. Anhand eines Beispiels wird die Verwendung dieses Patterns gezeigt. Weitere Proxy Anwendungen runden den ersten Teil ab. Der zweite Teil ist dem JAVA Reflection API gewidmet. Es wird dabei verzichtet das JAVA Reflection API im Detail zu zeigen. Vielmehr wird auf den für die dynamischen Proxy Klassen wichtigen Teil eingegangen. Es handelt sich dabei um die Proxy Klasse im Package java.lang.reflect. Der dritte und letzte Teil soll anhand eines Beispieles den Einsatz von dynamischen Proxy Klassen zeigen. Es wird dabei eine bestehende Anwendung zuerst mittels eines Proxy s, später mit einem dynamischen Proxy, erweitert. Hinweise auf weiterführende Literatur runden den Bericht ab.

3 Inhaltsverzeichnis Seite 2 Einleitung Proxy Design Pattern Motivation und Absicht Anwendung des Proxy Design Patterns Struktur und Design Java Reflection API in Bezug auf die dynamischen Proxy Klassen Was ist das Reflection API Die Packages java.lang und java.lang.reflect Das Interface InvocationHandler und die Klasse Proxy Beispiele von dynamischen Proxy Klassen Das Vehicle Beispiel Das Basisbeispiel Erweiterung mit einem Proxy Erweiterung mit einem dynamischen Proxy Erweiterung zum generischen Logger Weitere Beispiele...14 Schluss...15 A. Anhang...16 A1. Code Beispiele...16 A1.1. Vehicle Proxy Beispiel...16 A1.2. Security Proxy Beispiel...16 A1.3. Remote Proxy Beispiel...16 A1.4. Virtual Proxy Beispiel...17 A2. Bibliographie...18

4 Seite 3 Einleitung Der vorliegende Seminar Bericht richtet sich an die Studierenden des 5. und 6. Semester im Departement (Ausbildungsbereich) Technik Studiengang Informatik der FHA in Windisch. Weiter an interessierte Softwarearchitekten und Softwareentwickler. Die dynamischen Proxy Klassen umfassen im wesentlichen zwei Bereiche: Das Proxy Design Pattern einerseits und das JAVA Reflection API andrerseits. Der vorliegende Bericht beschränkt sich nicht nur auf die theoretische Erklärung der beiden Materien, sondern versucht mittels Beispielen die Umsetzung mit der Programmiersprache JAVA zu zeigen. Die richtige Verwendung von Design Patterns bedingt ein sehr gutes Verständnis der Materie und Erfahrung im Bau von Software. Der vorliegende Bericht gibt einen Überblick über das Proxy Design Pattern und dessen Umsetzung. Die JAVA Technologie Reflection wird kurz beschrieben und im Zusammenhang der dynamischen Proxy Klassen genauer erklärt. Im Bericht werden nur Codefragmente aufgelistet. Im Anhang befindet sich eine Beschreibung des gesamten Source Codes der verwendeten Beispielen.

5 Seite 4 1 Proxy Design Pattern 1.1 Motivation und Absicht Der Proxy ist ein sogenanntes Design Pattern (Muster). Diese Muster wurden entworfen um den Bau von Software zu erleichtern und erprobte Mechanismen zu formalisieren und dokumentieren. Der Proxy ist eine weitverbreitete Technik um Funktionalität von Objekten zu verbergen und ist ebenfalls unter dem Namen Surrogate (Platzhalter) bekannt. Bild 1 Der Proxy ist ein Platzhalter für ein konkretes Subjekt. Der Zugriff auf dieses Subjekt wird durch den Proxy gesteuert. Durch diese Steuerung erhält der Proxy die notwendige Fähigkeit wo, wann, wer und wie er auf das konkrete Subjekt zugreifen will/darf. Da die Aufrufe auf das konkrete Subjekt durch den Proxy gesteuert werden, verbirgt er Funktionalität vor dem Benutzer (Programmierer). Natürlich muss diese Funktionalität trotzdem programmiert werden, jedoch für die Anwendung des Subjektes, scheint der Zugriff transparent zu sein. Ein möglicher Ablauf eines Aufrufes über einen Proxy ist in Bild 1 zu sehen. Ein Grund für die Kontrolle des Zugriffs können die Initialisierungs- und Instanzierungskosten sein. An einem kleinen Beispiel kann dies gezeigt werden. Unsere Aufgabe ist es ein Textverarbeitungsprogramm bzw. einen Texteditor zu entwickeln. Dieses Textverarbeitungsprogramm soll zusätzlich Bilder anzeigen können. Bilder haben die Eigenschaft, dass sie zuerst in den Hauptspeicher geladen werden müssen und es dadurch lange dauert bis sie geladen sind. Wenn nun ein Dokument in unserem Textverarbeitungsprogramm geöffnet wird, würde bei einem schlechten Design der Software, ziemlich viel Zeit beim Laden der Bilder verbracht. Wenn man diese Problematik genauer analysiert, bemerkt man, dass die Bilder grundsätzlich gar noch nicht gebraucht werden, sondern erst wenn diese in den sichtbaren Bereich des Editors gescrollt werden. Man müsste dann die Bilder erst laden, wenn sie wirklich sichtbar werden. Diesen Mechanismus nennt man creating/loading on demand (erzeugen/laden nach Bedarf). Es gibt nun mehrere Möglichkeiten den bereits bestehenden Code zu verändern, damit wir dieses creating bzw. loading on demand bewerkstelligen können. Eine schlechte Lösung wäre, wenn wir den Ladecode anpassen. Das ist deshalb schlecht, weil wir die Funktionalität des Ladens verändern. Es gibt vielleicht Fälle in denen man dieses loading on demand nicht braucht und man müsste dann den Ladecode parametrisieren. Viel schöner wäre es, wenn wir den Code einfach durch verschiedene Instanzzierungen von Objekten parametrisierbar machen. Dies erreichen wir durch einen Decorator/Wrapper 1. Ein Beispiel für solche Decorator sind die IO Klassen in JAVA (BufferedReader, PrintWriter etc.). Der springende Punkt ist nun der, unser Decorator ist ein Platzhalter und stellt die Bildfunktionalität zur Verfügung, das Bild wird jedoch noch nicht geladen, sondern erst, wenn das Bild gezeichnet werden soll. Das heisst wenn die Methode draw 1 Der Decorator bzw. Wrapper ist ein anderes Design Pattern und wird in diesem Bericht nicht näher behandelt, da es den Umfang sprengen würde. Kurzerklärung; der Decorator delegiert alle Aufrufe, welche an ihn getätigt werden, an ein anderes Objekt.

6 Seite 5 vom Bildobjekt aufgerufen wird. Operationen wie Bild vergrössern, -verkleinern etc. werden nicht auf dem Bildobjekt ausgeführt, sondern im Decorator gespeichert, erst wenn es nötig ist, wird das Bild geladen. Bild 2 Bild 2 zeigt die Verwendung des ImageProxy. Die Attribute size und filename werden dazu verwendet, die Grösse bzw. das zu ladende Bild zu speichern. Durch diesen Mechanismus ist es möglich, das Bild erst bei Gebrauch zu laden. Das private Attribute image ist die Referenz zum Subjekt auf welchem der Proxy aufsetzt. Die Ähnlichkeit mit dem Decorator Pattern ist nicht zu übersehen. 1.2 Anwendung des Proxy Design Patterns Wie wir gesehen haben ist der Proxy ein Platzhalter Objekt und es gibt nun verschiedene Arten von Platzhaltern. Einer dieser Platzhalter ist der im vorangegangenen Kapitel angesprochene Virtual Proxy. Zu diesem Virtual Proxy gibt es den Remote Proxy, den Protection Proxy und die Smart References. Diese vier Kategorien haben sich im Laufe der Zeit herauskristallisiert und sind heute die meist verwendeten Arten von Proxies. Der Remote Proxy ist ein Platzhalter für Objekte, welche über ein Netzwerk (remote) angesprochen werden. Er versteckt bzw. macht die Funktionalität für Remote Objekte transparent. Für den Anwender bedeutet dies, er muss sich nicht darum kümmern, ob die Objekte auf seinem Computer oder auf einem anderen Computer instanziert werden. Solche Proxies spielen vor allem in verteilten Systemen eine grosse Rolle und werden da auch eingesetzt. In JAVA zum Beispiel basiert die Technologie RMI (Remote Method Invocation) auf dem Prinzip von Remote Proxies. Der virtuelle Proxy ist ein reiner Platzhalter. Wie es der Name schon sagt, ist er nur virtuell vorhanden. Er steuert den Zugriff zu lade- bzw. zeitintensiven Objekten. Der vorher erklärte Image Proxy ist ein Beispiel eines Virtual Proxy. Der Protection Proxy steuert den direkten Zugriff auf das Objekt. Er entscheidet zu Laufzeit, wer welche Methoden aufrufen darf und wem der Zugriff verwährt bleibt. Die Abstufung der Überprüfung kann selber (vom Programmierer des Proxy) gewählt werden und reicht von grob- bis feingranular. Smart References wurden erfunden um Funktionalität von Pointern zu erweitern. Sie führen zusätzliche Aufgaben beim Aufruf des Pointers aus. Beispiele dazu sind Reference Counting, laden von persistenten Objekten in den Hauptspeicher, Locking Mechanismen etc. In den vier Gruppen erkennt man die Einsatzgebiete der Proxies. Grundsätzlich kann man jeden Proxy in eine dieser vier Gruppen einteilen. Eine eindeutige Klassifikation ist jedoch nicht immer möglich und meistens auch nicht nötig. Wenn man jedoch die Einsatzgebiete von Proxies kennt, ist es einfacher Proxies in seiner eigenen Software zu integrieren.

7 1.3 Struktur und Design Seite 6 Die Struktur bzw. das Design des Proxy Design Patterns ähnelt sehr dem Decorator Pattern. Dies wurde auch schon in den vorangegangenen Kapiteln bereits erkannt. Der Proxy, wie auch der Decorator, schalten sich bei einem Aufruf zwischen Aufrufenden und Aufgerufenen. Der Unterschied dieser zwei Design Patterns liegt eigentlich nur in der Bedeutung bzw. in der Implementierung. Der Decorator delegiert alle seine Aufrufe an die entsprechende Methode des im zugrunde liegenden Objektes. Der Proxy ist da etwas freier. Je nach Verwendungszweck des Proxy kann der Aufruf zum Beispiel untersagt werden (Protection Proxy). Was beim einen (Decorator) zwingend, ist beim anderen fakultativ (Proxy). Bild 3 In Bild 3 ist die Struktur des Proxy Patterns zu erkennen. Das Interface Subject wird von beiden Klassen, RealSubject und Proxy implementiert. Das ermöglicht dem Proxy sich als Platzhalter für das RealSubject auszugeben. Da nun sämtlich Aufrufe an das RealSubject durch den Proxy getätigt werden, hat dieser natürlich volle Kontrolle über den Nachrichtenfluss. Durch diese Kontrolle ist es möglich Funktionalität für den Benutzer transparent zu handhaben. Das heisst, der Benutzer muss sich nicht um Netzhandling oder andere Funktionalität kümmern.

8 Seite 7 2 Java Reflection API in Bezug auf die dynamischen Proxy Klassen 2.1 Was ist das Reflection API Es gibt grundsätzlich zwei Wege um in JAVA Informationen über Klassen und Objekte zu erhalten. Der traditionelle, etwas beschränkte Weg ist der instance of Operator. Mit diesem Operator können Typen zu Kompilierzeit überprüft werden. Der zweite und viel mächtigere Weg ist mittels des JAVA Reflection API s. Mit dieser Sammlung von Klassen können zu Laufzeit Informationen über Objekte und Klassen gesammelt werden. Das JAVA Reflection API enthält viel Funktionalität und kann daher in die folgenden Untergruppen unterteilt werden: Dynamisches Laden von Klassen Class.forName Typenüberprüfung instance of Informationen über Klassen und Objekte Klassen Class, Method, Fields, etc. Dynamische Proxies Klasse Proxy im Package java.lang.reflect Die ersten beiden Punkte (dynamisches Laden und instance of Operator) werden nicht näher beschrieben, da sie für die dynamischen Proxy Klassen keine grosse Rolle spielen. Hingegen die Proxy Klasse bzw. der Rest des java.lang.reflect Packages sind wichtig für das Verständnis der dynamischen Proxy Klassen und werden im nächsten Kapitel näher beschrieben. 2.2 Die Packages java.lang und java.lang.reflect Wie bereits erwähnt, enthält das Package java.lang.reflect die nötigen Klassen um mittels Reflection zu Laufzeit Information über Klassen und Objekte zu sammeln. Damit dies zu Laufzeit geschehen kann, muss irgendwo ein Einstiegspunkt vorhanden sein, um diese Informationen anzufordern. Dieser Einstiegspunkt befindet sich in der Klasse Object. Jede JAVA Klasse ist vom Typ Object abgeleitet und daher ist dies der ideale Angriffspunkt für das JAVA Reflection API. Die Klasse Object enthält die Methode getclass(). Diese Methode gibt ein Objekt vom Typ Class (Package java.lang) zurück. Dieses Objekt repräsentiert das dynamische Objekt bzw. die instanzierte Klasse. Mittels verschiedener Methoden, wie z.b. getmethods() können die Methoden, welche die Klasse besitzt, herausgefunden werden. Näheres zu den verschiedenen Methoden und Klassen im Package java.lang und java.lang.reflect ist der AP I Dokumentation zu entnehmen. Ein wichtiger Bestandteil des Reflection API s und der dynamischen Proxy Klassen ist der ClassLoader. Aus diesem Grund wird er etwas detailierter beschrieben. Jede Klasse besitzt einen sogenannten ClassLoader. Dieser ClassLoader ist zuständig für das Laden der Klasse in den Speicher. Er ist im Package java.lang zu finden und kann durch die Methode <Class/Object>.getClass().getClassLoader() abgeholt werden. Der ClassLoader ist eine abstrakte Klasse und kann daher auch nicht instanziert werden. Der ClassLoader ist wichtig, da er für die später beschriebene Klasse Proxy einen wichtigen Bestandteil darstellt. Das Interface InvocationHandler und die Klasse Proxy schliessen das java.lang.reflect Package ab. Sie stellen die eigentlichen Kernkomponenten der dynamischen Proxy Klassen dar. Sie werden im nächsten Kapitel detailliert beschrieben.

9 2.3 Das Interface InvocationHandler und die Klasse Proxy Seite 8 Um dynamische Proxy Klassen zu implementieren, braucht es grundsätzlich zwei Komponenten. Einen dynamischen Handler, welcher das InvocationHandler Interface implementiert und den eigentlichen Proxy. Der Proxy ist relativ einfach zu implementieren, der existiert nämlich bereits. Es ist dies die Klasse Proxy. Von der Klasse Proxy muss man nur eine neue Instanz erzeugen und der Proxy ist bereits fertig. Um eine neue Instanz der Proxy Klasse zu erzeugen ruft man spezielle statische Methoden auf der Klasse auf. Es ist dabei zu bemerken, dass dynamische Proxy Klassen nicht auf Klassen beschränkt sind, sie können auch dynamisch ein Interface instanzieren. Anstelle eines Klassen Class Objects wird einfach ein Interface Class Object übergeben. Es folgt nun ein Beispiel, wie man eine Instanz eines Proxy erzeugen kann. Lassen sie sich nicht durch den InvocationHandler irritieren, die Erklärung was ein InvocationHandler ist folgt direkt nach dem Beispiel. Es gibt zwei Varianten eine Instanz eines dynamischen Proxy zu erzeugen. Eine erste Variante sieht folgendermassen aus: InvocationHandler handler = new MyInvocationHandler( ); Class proxyclass = Proxy.getProxyClass( Foo.class.getClassLoader(), new Class[] { Foo.class ); Foo f = (Foo) proxyclass.getconstructor( new Class[] { InvocationHandler.class ). newinstance(new Object[] { handler ); Es ist schön zu sehen wie zuerst eine Proxy Klasse erzeugt wird und danach die eigentliche Instanz der dynamischen Proxy Klasse aus dem Proxy heraus erzeugt wird. Nun diese Variante ist etwas umständlich. Das haben sich wohl auch die Entwickler gedacht und haben eine etwas einfachere Variante hinzugefügt, welche folgendermassen aussieht: InvocationHandler handler = new MyInvocationHandler( ); Foo f = (Foo) Proxy.newProxyInstance( Foo.class.getClassLoader(), new Class[] { Foo.class, handler); Grundsätzlich machen beide Varianten dasselbe, die zweite ist jedoch etwas kompakter und daher auch etwas besser zu lesen. Als erster Parameter erhält die Funktion newproxyinstance einen ClassLoader. Im vorangegangenen Kapitel wurde der ClassLoader erklärt. Er wird hier gebraucht um die Klasse, welche gewrappt wird zu laden. Als zweiten Parameter erhält die Funktion ein Array von Class Objekten. Das sind die Interfaces bzw. Klassen welche implementiert werden. Als letzten Parameter erhält die Funktion den InvocationHandler, welcher später beschrieben wird. Da der Proxy diverse Interfaces dynamisch implementiert, kann das Object, welches zurückgegeben wird auch ohne Probleme in ein solches gecastet werden. Es war nun immer die Rede eines Invocation Handlers. Mittels diesem Handler kann der Programmierer Einfluss auf das Verhalten des Proxy nehmen. Hier geschieht die Implementation des Proxy z.b. die Implementation der Remote Funktionalität für einen Remote Proxy oder die Sicherheitsfunktionalität eines Security Proxy. Die Implementation eines Invocation Handlers ist einfach. Der Handler implementiert das Interface InvocationHandler, dadurch muss er die Funktion invoke(object proxy, Method method, Object[] args) implementieren. Als ersten Parameter erhält die

10 Seite 9 Funktion den Proxy, welcher die invoke Methode aufgerufen hat. Als zweiten Parameter bekommt er die aufgerufene Methode auf dem Objekt. Als dritten Parameter werden die Argumente geliefert. Method1() Client Method2() Method3() Target Bild 4 Bild 4 zeigt ein Problem, welches mit einem dynamischen Proxy modeliert werden könnte, falls die Anforderung käme, man müsse gewisse Funktionalität zwischen Client und Target einbauen, z.b. sämtliche Aufrufe auf dem Target müssten geloggt werden oder es müsse ein Security Konzept implementiert werden, dass nicht jederman Funktionen ausführen darf. Method1() Method1() Method2() Method2() Client Proxy Target Method3() Method3() Bild 5 Bild 5 zeigt die Implementation mit einem normalen Proxy. Der Proxy empfängt den Methodenaufruf, tätigt seine Arbeit und ruft dann die Methode auf dem Target auf. Man sieht hier bereits einen riesen Nachteil eines normalen Proxies. Sämtlich Methodenaufrufe müssen implementiert werden, d.h. wenn eine neue Methode auf dem Target hinzu kommt, dann muss diese ebenfalls auf dem Proxy implementiert werden. Method1() Client Method2() Method3() Proxy invoke() Invocation Handler invoke() Target Bild 6 In Bild 6 ist der Ablauf eines dynamischen Proxy Aufrufs dargestellt. Im ersten Schritt wird auf dem Proxy die Methode 1, 2 oder 3 aufgerufen. Damit dies möglich ist, muss der Proxy das Target Interface implementieren. Der Proxy leitet nun die Anfrage an den Invocation Handler weiter. Dies geschieht mit dem Reflection API von JAVA. Der Invocation Handler entscheidet nun was mit dem Aufruf geschehen soll. Je nach Implementation leitet er den Aufruf weiter, bricht ihn ab oder macht sonst irgendwas. Diese Implementation ist dem Programmierer überlassen. Meistens verwendet der Invocation Handler ebenfalls das Reflection API von JAVA, um den Aufruf zu tätigen. Aus dem Bild ist ebenfalls ersichtlich, dass der Invocation Handler das Target kennen muss, da er Funktionen auf diesem Target ausführen möchte. Wenn nun das Target Interface ändert, muss nicht unbedingt die Implementation des Proxy geändert werden.

11 Seite 10 3 Beispiele von dynamischen Proxy Klassen 3.1 Das Vehicle Beispiel Das Basisbeispiel Im letzten Kapitel haben wir ganz generell eine Applikation schrittweise mit einem Proxy und dann mit einem dynamischen Proxy erweitert. Dies wollen wir nun ebenfalls tun an einem konkreten Beispiel. Das konkrete Beispiele ist ein Vehicle. Dieses Vehicle wird durch einen Client bedient. Dazu werden zwei Klassen und ein Interface benötigt. Das Interface IVehicle sieht folgendermassen aus: public interface IVehicle { public void start(); public void stop(); public void forward(); public void reverse(); public String getname(); Die Implementation des Vehicles macht nichts anderes als die aufgerufene Methode auszugeben. Das Vehicle implementiert natürlich das IVehicle Interface. Die Implementation Car sieht folgendermassen aus: public class Car implements IVehicle { private String name; public Car(String name) {this.name=name; public void start() { System.out.println("Car " + name + " started"); public void stop() { public void forward() { public void reverse() { public String getname() { Der Client macht nun nichts anderes als Car zu instanzieren und die verschiedenen Methoden aufzurufen. Die Client Implementation sieht folgendermassen aus: public class Client { public static void main(string[] args) { new Client();

12 public Client() { IVehicle v = new Car("Audi RS4"); v.start(); v.forward(); v.stop(); Seite 11 Dieses Programm soll nun mit einem Proxy erweitert werden. Die Stärke des Proxy liegt darin, bestehende Funktionalität zu erweitern. Wir wollen nun das Vehicle dahin erweitern, dass jede Funktion auf der Konsole ausgegeben wird. Schlussendlich soll ein generischer Logger entstehen, welcher unabhängig von der Implementation und Interface sämtliche Aufrufe auf die Konsole schreibt Erweiterung mit einem Proxy In einem ersten Schritt erweitern wir das Basisbeispiel mit einem Proxy. Das verwendete Interface bleibt sich gleich. Ebenfalls die Vehicle Klasse, wir wollen die bestehende Funktionalität erweitern. Eine neue Klasse ist die VehicleProxy Klasse. Diese Klasse stellt den Proxy dar. Sie sieht folgendermassen aus: public class VehicleProxy implements IVehicle { private IVehicle v; public VehicleProxy(IVehicle v) { this.v=v; public void start() { System.out.println("VehicleProxy: Begin of start()"); v.start(); System.out.println("VehicleProxy: End of start()"); public void stop() { public void forward() { public void reverse() { public String getname() { Wie wir in den ersten Kapiteln gesehen haben, besitzt der Proxy eine Referenz auf das reale Subjekt. In unserem Fall ist dies das eigentliche Vehicle (Car Objekt). Dieses Vehicle wird in den Konstruktor übergeben. Bei diesem Codesegment ist sehr schön der grosse Nachteil des Proxy zu sehen. Alle Methoden müssen an das Subjekt delegiert werden und müssen daher auch implementiert werden. Bei einer Änderung am Interface muss nicht nur die konkrete Implementierung der Funktionalität geändert werden, sondern auch der Proxy, was ein bisschen mühsam ist. Weitere Änderungen gibt es auf dem Client, denn da muss natürlich der Proxy instanziert werden und die Aufrufe müssen auf diesem Proxy Objekt getätigt werden. Der Client Code sieht folgendermassen aus:

13 public class Client { public static void main(string[] args) { new Client(); public Client() { IVehicle c = new Car("Audi RS4"); IVehicle v = new VehicleProxy(c); v.start(); v.forward(); v.stop(); Seite 12 Bei diesem Codesegment ist schön zu sehen, wie das reale Subjekt (Car) instanziert wird und an den Proxy weitergeleitet wird Erweiterung mit einem dynamischen Proxy Beim dynamischen Proxy muss ebenfalls nur der Proxy (InvocationHandler VehicleHandler) und der Client angepasst werden, der Rest bleibt unverändert. Der Code des InvocationHandler bzw. des VehicleHandler sieht folgendermassen aus: public class VehicleHandler implements InvocationHandler { private IVehicle target; public VehicleHandler(IVehicle target) { this.target=target; public Object invoke(object proxy, Method m, Object[] args) throws Throwable { System.out.println("VH: Invoking " + m.getname()); return m.invoke(target,args); In diesem Handler muss nun nicht mehr jede Methode implementiert werden, da das JAVA Reflection API verwendet wird. Gleich wie beim Proxy muss aber das target bzw. destination Objekt übergeben werden (Konstruktor). In der Methode invoke muss nun nur noch die Ausgabe auf die Konsole erfolgen und die aufgerufene Methode an das Target weitergeleitet werden. Der Client erfährt ebenfalls eine kleine Änderung, in etwa die gleich wie bei der Verwendung des normanlen Proxy. Der Client Code sieht folgendermassen aus: public class Client { public static void main(string[] args) {

14 new Client(); public Client() { IVehicle c = new Car("Audi RS4"); IVehicle v = (IVehicle)Proxy.newProxyInstance( IVehicle.class.getClassLoader(), new Class[] {IVehicle.class, new VehicleHandler(c) ); v.start(); v.forward(); v.stop(); Seite 13 Mit dem bekannten instanzieren des Proxy aus Kapitel 2 wird nun der Proxy und VehicleHandler erzeugt. Zu erwähnen ist auch das casten des Proxy auf das IVehicle Interface. Danach können die Aufrufe ganz normal getätigt werden Erweiterung zum generischen Logger Die Erweiterung zu einem generischen Logger ist sehr einfach. Der VehicleHandler besitzt momentan eine Referenz auf das IVehicle Interface. Grundsätzlich kann dies natürlich irgend eine Referenz sein. Für einen generischen Logger bietet sich natürlich die Klasse Object an. Somit würde der generische Logger folgendermassen aussehen: public class GenericLogger implements InvocationHandler { private Object target; public GenericLogger(Object target) { this.target=target; public Object invoke(object proxy, Method m, Object[] args) throws Throwable { System.out.println("GL: Invoking " + m.getname()); return m.invoke(target,args); Der Client entspricht dem Client für den dynamischen Proxy. Dieser generische Logger kann nun für irgendeinen Client verwendet werden. In den beigelegten Beispielen sind diese Logger zu sehen (CarClient und PetLogger).

15 3.2 Weitere Beispiele Seite 14 In den vorangegangenen Abschnitten haben wir die Implementation bzw. das Weiterentwickeln eines dynamischen Proxy gesehen. Im ersten Kapitel haben wir gesehen, dass es noch weitere Arten von Proxies gibt. Im Anhang bzw. im beigelegten Sourcecode sind weitere Beispiele enthalten, welche die Verwendung von Proxies darstellen. Im Prinzip funktionieren diese aber genau gleich wie das Vehicle Beispiel, behandeln aber eine andere Thematik. Die folgenden Thematiken wurden gewählt: Security Proxy Remote Proxy Virtual Proxy Dies entspricht den momentan gängigen Implementation von Proxies. Wie man die Beispiele verwendet, kann dem Anhang entnommen werden.

16 Seite 15 Schluss Das Proxy Design Pattern wurde entworfen um spezielle Funktionalität vom Benutzer zu verbergen. Eine andere Aufgabe des Patterns kann sein, bestehende Funktionalität zu erweitern. Typische Proxies sind: Virtual Proxy, Remote Proxy, Protection Proxy und Smart References. Das Proxy Design Pattern wird auch Surrogate genannt. Das JAVA Reflection API ist eine Spracherweiterung für JAVA, welche es dem Entwickler erlaubt, zu Laufzeit dynamisch Objekte zu erzeugen. Dies ist aber nicht die einzige Aufgabe des Reflection API, denn es stellt zusätzlich Informationsbehälter zur Verfügung, welche Informationen über Klassen und Objekte enthalten. Wenn man nun die beiden Thematiken mischt, erhält man die dynamischen Proxy Klassen. Man nimmt das Design Pattern Proxy und das dynamische Aufrufen von Methoden und es kommen die dynamischen Proxy Klassen zum Vorschein. Dynamische Proxy Klassen werden mit der Klasse Proxy aus dem java.lang.reflect Package erzeugt. Es werden dabei dynamisch Interfaces implementiert. Diese Interfaces können auch wieder ausgewechselt werden. Dies hat den Vorteil, dass sämtlich Operationen auf dem Proxy typengeprüft sind. Dynamische Proxy Klassen eignen sich hervorragend um bestehende Funktionalität zu erweitern. Man darf jedoch nie das Konzept der dynamischen Proxy Klassen aus dem Auge verlieren. Das Problem der dynamischen Proxy Klassen besteht darin, dass es meistens einfacher ist, die Anforderungen an die Software anzupassen, damit man die dynamischen Proxy Klassen verwenden kann. Diese sollte jedoch auf keinen Fall geschehen. Damit diese nicht passiert, muss man das Konzept, welches hinter den dynamischen Proxy Klassen steht, vollkommen verstanden haben. Die dynamischen Proxy Klassen sind ein tolles und elegantes Werkzeug in der modernen Softwareentwicklung. Ein gezielter und gut überlegter Einsatz sind jedoch Bedingung, damit der Einsatz von dynamischen Proxy Klassen zum Erfolg führt.

17 Seite 16 A. Anhang A1. Code Beispiele Die Beispiele sind im JAR Archiv DynamicProxyClasses.jar zu finden. In diesem JAR Archiv sind der Source Code, wie auch die lauffähigen Programme zu finden. Die folgenden Beispiele sind die meistgebrauchten Arten von Proxies. A1.1. Vehicle Proxy Beispiel Das Vehicle Proxy Beispiel besteht aus mehreren JAVA Programmen, welche in Packages strukturiert bzw. enthalten sind. Es sind dies folgende Programme bzw. Packages: dpc.vehicleexample.client Basis Funktionalität dp.vehicleexample.proxy.standard.client Proxy Implementation des Vehicle Beispiels dpc.vehicleexample.proxy.dynamic.client Dynamische Proxy Implementation des Vehicle Beispiels dpc.vehicleexample.logger.decorator.client Decorator Implementation eines Loggers dpc.vehicleexample.logger.generic.carclient Generische Logger Implementation des Vehicle Beispiels dpc.vehicleexample.logger.generic.petclient Generische Logger Implementation des Pet Beispiels (gleicher Logger wie im Vehicle Beispiel) Anhand dieser Beispiele kann die Verwendung von Dynamischen Proxy Klassen gezeigt werden. Die Beispiele bauen aufeinander auf und mit dem generischen Logger ist das Endprodukt zu sehen. A1.2. Security Proxy Beispiel Nachdem am Vehicle Beispiel die Verwendung der dynamischen Proxy Klassen zu sehen war, wird in den nächsten Beispielen spezielle Arten von Proxies betrachtet. Mit dem Security Proxy wird eine Zugriffssteuerung auf eine sogenannte View gezeigt. Die Security Mechanismen sind auf Methoden Ebene implementiert. Zu startende Klasse: dpc.securityexample.client A1.3. Remote Proxy Beispiel Das Remote Proxy Beispiel zeigt eine Implementation eines Socket Servers. Durch den Proxy wird der Zugriff transparent. Der Socket Server ist ein sogenannter Echo Server. Dieser Echo Server antwortet immer mit dem eingegangenen Aufruf. Zu startende Klasse: dpc.remoteexample.client

18 A1.4. Virtual Proxy Beispiel Seite 17 Das Virutal Proxy Beispiel zeigt eine Implementation des Grafik Beispiels vom ersten Kapitel. Das Laden der Grafik wird nur simuliert. Das Prinzip des Virtual Proxy ist aber ersichtlich. Zu startende Klasse: dpc.virtualexample.client

19 Seite 18 A2. Bibliographie Blosser, Jeremy (2001). Explore the Dynamic Proxy API. Stand Blosser, Jeremy (2001) Java Tip 98: Reflect on the Visitor design pattern. Stand Gamma, Erich; Helm, Richard; Johnson Ralph; Vlissides, John (1995). Design Patterns - Elements of Reusable Object-Oriented Software. 20., Boston u.a.: Addison-Wesley Halloway, Stuart (2001) Dynamic Proxies. ftp://ftp.ora.com/pub/conference/java2001/halloway_dynamic_proxies.zip Stand Jung, Christoph G. (2001) Dynamic Proxies. Stand Lavers, Tim (2001) Java Tip 108: Apply RMI autogeneration. Stand Portwood, Michael T. (2001) Using Java Technology Reflection to Improve Design. Stand Sun Microsystems, Inc. (2001) Dynamic Proxy Classes. Stand Sun Microsystems, Inc. (2001) Using dynamic proxies to layer new functionality over existing code. Stand Sun Microsystems, Inc. (2001) Using java.lang.reflect.proxy to Interpose on Java Class Methods. Stand Tarr, Bob (2001) Dynamic Proxies in Java. Stand