Click here for the english version

I     nach oben

Interceptor

EJB 3.0

Mit EJB 3.0 ist es möglich - analog CORBA -basierten Systemen, in denen Interceptor-Mechanismen seit langem bekannt sind und eingesetzt werden - Methodenaufrufe von Geschäftsmethoden abzufangen, die darin enthaltenen Parameterwerte zu untersuchen, bei Bedarf zu manipulieren und die Aufrufe weiterzuleiten oder bei Bedarf abzubrechen bzw. zu verhindern.

Mit dem Interceptor-Mechanismus hält die aspektorientierte Programmierung - zumindest in Ansätzen - Einzug in die EJB-basierte Entwicklung. Interceptors ermöglichen das transparente Einflechten von Funktionalitäten (z.B. Logging, Tracing, Zeitmessung, Sicherheitsprüfungen), die fachliche Entwickler von technischen Aspekten entkoppelt.

Der Entwickler eines Interceptors kann für eine abgefangene Methode innerhalb des aktivierten Interceptors beliebigen von ihm hinterlegten Code ausführen zu lassen.

Inversion of Control

EJB 3.0

Inversion of Control (IoC) ist eine allgemeine Eigenschaft von Frameworks, wird gemeinhin gerne mit dem Satz "don't call us, we call you" umschrieben und soll ausdrücken, dass die Verantwortlichkeiten bei der Programmausführung beim Framework liegen und nicht bei den Komponenten, die auf Basis eines Frameworks entwickelt und ausgeführt werden.

D.h. das die Komponenten umgebende Framework verlangt von den Komponenten, dass bestimmte Callback-Methoden durch sie implementiert werden, über die das Framework bzw. der Container zur Laufzeit Informationen in die Komponenten injiziert ober bestimmtes Verhalten (über Methodenaufrufe) auslöst.

Im Kontext von EJB 3.0 wird IoC und Dependency Injection vielfach synonym verwendet, auch wenn es im Detail sehr wohl Unterschiede gibt (siehe hierzu auch Dependency Injection). Das, was bei EJB 3.0 zum Einsatz kommt, ist eine spezialisierte Form von Inversion of Control und wird als Dependency Injection bezeichnet.