$KK(Service Locator) Besorgt und cached alle J2EE-Ressourcen, die eine Komponente für die Abbildung der Geschäftslogik benötigt Typischerweise wird ein Service Locator für das Auffinden von Homes, LocalHomes oder DATA Sources verwendet. Zum Auffinden von J2EE-Ressourcen wird meistens JNDI (Java Naming und Directory Interface) verwendet. Durch Verwendung des Service Locators müssen sich die Clients nicht mit JNDI herumschlagen. $B(Bilder,serviceLocator.gif,Service Locator) Die Komponenten: Ein Client braucht zur Bearbeitung seiner Aufgabe ein BusinessService Objekt. Er verwendet den Service Locator um dieses Objekt zu suchen und zu bekommen. Der ServiceLocator übernimmt für den Clienten die Suche nach dem richtigen BusinessService Objekt. Das InitialContext ist ein Einstiegspunkt für die Suche in einem Directory. Ein Directory ist baumartig strukturiert. Das InitialContext spezifiziert den Startknoten. Es wird dann in dem Directory von dem Startknoten aus gesucht, bis das BusinessService Objekt gefunden wird. Er erzeugt einen InitialContext um die Suche zu starten. Das ServiceFactory wird benötig, da das BusinessService Objekt einen Lebenszyklus wie ein Servlet hat. D.h. ggf muss das ServiceFactory das BusinessService Objekt erst einladen, und instantiieren bevor es verwendet wird. Das BusinessService Objekt bietet dem Clienten hoffentlich genau den Dienst an, den der Client benötigt. Vorteile * Versteckt Komplexität - Die Verantwortlichkeit eine JNDI Umgebung korrekt aufzubauen, wird dem Service Locator überlassen. Der Client muss sich nicht umd programmtechnische Details von JNDI kümmern. * Bietet einheitlicher Zugriff auf Business Service Objekte - Der Service Locator bietet ein einfaches und präzises Interface an, das alle Clienten nutzen können. Es garantiert dass alle Clienten der Applikation auf dieselbe Art und Weise Business Objekte finden bzw. erzeugen. * Erleichtert das Hinzufügen neuer Business Service Objekte - Man kann neue EJBHome Objekte hinzufügen, ohne dass der Code bei den Clienten geändert werden muss. * Reduziert Netzwerk Belastung - Da alle Anfragen der Clienten an JNDI durch den Service Locator gehen, können diese Anfragen gebündelt werden. * Erhöhung der Performance - Das Cachen von z.B: des Initialen Contextes, Referenzen auf Objekte, verhindert das gleiche Aktionen doppelt ausgeführt wird. $KK(Interception Filter) Filter haben Zugriff auf den Request und Response einer Webkomponente und ist somit in der Lage, ihre Funktionalität dynamisch zu erweitern. Mit Filter kann man sich vor und nach der eigentlichen Verarbeitung in einer Webkomponente einklinken. Der Interception Filter erlauben es verschiedene Filter miteinander zu kombinieren. Filter hinzuzufügen oder zu entfernen ohne in den Code eingreifen zu müssen. Filter wurden im Kapitel über das Web Container Model ausführlich behandelt. Vorteile: * Zentrale Kontrolle für eine bestimmte Erweiterung - Ein Filter kapselt zentral eine Erweiterung zB. Authentifizierung oder Logging, diese Erweiterung kann man dann für beliebige Webkomponenten benutzen. Filterketten erlauben diese Erweiterungen beliebig zu kombinieren, da die einzelnen Filter und die Webkomponenten sehr gering miteinander gekoppelt sind. * Erhöht Wiederverwendbarkeit - Da die Filter sehr flexibel kombiniert werden können, können derselbe Filter auch in mehreren Kontexten verwendet werden. * Deklerative und Flexible Konfiguration - Die Konfiguration der Filter erfolgt in der Deployment Descriptor Datei web.xml. D.h. man kann Filter kombinieren ohne den Code ändern zu müssen. Nachteile: * Da Filter sehr loose miteinander gekoppelt sind, ist es schwierig Informationen zwischen den Filtern zu teilen.