1. Interceptor Pattern A&D Eva P.O.S.A 2 By bbum.

2. Agenda Service Access and Configuration Service Access and Configuration Issues Issues Example Example Context Context Problem Problem Solution Solution Structure Structure Dynamics Implementation Example Resolved Variants Known Uses Consequences See Also

3. Service Access and Configuration  In a stand-alone, collaborate within a single address space.  So communicate using passing parameters via function calls and accessing global variables.  In network, use other Mechanisms for communication.  IPC, Communication Protocols (Telnet, FTP, SMTP, HTTP), high-level middleware (CORBA, Com+)  Application and components can access these mechanisms via programming APIs.  Network System are inherently heterogeneous.  How to effectively design and configure application access to the Services and Component? APIs for Service Access and Configuration is Important.

4. Issues One of the Main Issue is Extensibility of service Provided by Framework. One of the Main Issue is Extensibility of service Provided by Framework.

5. Example Mission Mission  MiddleORB : General ORB Core Service Core Service  Communication Service : Connection Management, Transport Protocols. Additional Request Service Additional Request Service  Transactions and Security, Load balancing and fault tolerance, auditing, logging, non-standard communication mechanisms, monitoring and debugging tools.

6. Example Strategy 1. Strategy 1. Integrate as many services as possible into the default MiddleORB configuration. Integrate as many services as possible into the default MiddleORB configuration.  Problems Not all ORB services can be anticipated at its development time. Not all ORB services can be anticipated at its development time. ORB framework expand to include new features. ORB framework expand to include new features. Complicate ORB design and maintenance.

7. Example Strategy 2. Strategy 2. Keep the MiddleORB as simple and concise as possible.  Application developers must implement services in their own client and server code himself.  Problems Developer must implement much code that was unrelated to their application logic. Developer must implement much code that was unrelated to their application logic. Cannot Implement solely at the application level. Cannot Implement solely at the application level. Ex) Security service

8. Example Conclusion Conclusion  Neither strategy is entirely satisfactory.  We must devise a better strategy for integrating application-specific services into MiddleORB

9. Context Developing frameworks that can be extended transparently. Developing frameworks that can be extended transparently.

10. Problem Framework cannot anticipate all the services they must offer to users. Framework cannot anticipate all the services they must offer to users. Framework may be not originally designed to support certain services. Framework may be not originally designed to support certain services. It defeats reuse that application implement all the necessary service. It defeats reuse that application implement all the necessary service.

11. Forces A framework should allow integration of additional services without requiring modifications to its core architecture. A framework should allow integration of additional services without requiring modifications to its core architecture. The integration of application-specific services into a framework should not affect existing framework component. Reverse equal. The integration of application-specific services into a framework should not affect existing framework component. Reverse equal. Applications using framework may need to monitor and control its behavior Applications using framework may need to monitor and control its behavior

12. Solution Allow application to extend a framework transparently by registering ‘out-of-band’ services with the framework via predefined interface. Allow application to extend a framework transparently by registering ‘out-of-band’ services with the framework via predefined interface. Let the framework trigger services automatically when certain events occur. Let the framework trigger services automatically when certain events occur. Open the framework’s implementation so that the out-of- band services can access and control certain aspects of the framework’s behavior. Open the framework’s implementation so that the out-of- band services can access and control certain aspects of the framework’s behavior.

13. Solution - Detail  Specify and expose an interceptor callback interface.  For a designated set of events processed by framework.  Provide a dispatcher for each interceptor.  To allows applications to register their concrete interceptors with the framework.  Define context object.  To allow a concrete interceptor to introspect and control certain aspects of the framework’s internal state and behavior in response to events.

14. Structure Overview Overview

15. Structure Concrete Framework Concrete Framework   A concrete framework instantiates a generic and extensible architecture to define the services.  Client concrete ORB framework  Common services  Server concrete ORB framework  Complementary services

16. Structure Interceptor & Concrete Interceptor Interceptor & Concrete Interceptor   Interceptors are associated with a particular event or set of events exposed by a concrete framework.   Concrete interceptors specialize interceptor interfaces and implement their hook methods to handle these events in an application-specific manner.

17. Structure Dispatcher & Context Object Dispatcher & Context Object   To allow interceptors to handle the occurrence of particular events, a concrete framework defines dispatchers for configuring and triggering concrete interceptors.   Concrete interceptors can use context objects to access and control certain aspects of a concrete framework.

18. Structure Application Application   An application runs on top of a concrete framework.   An application can implement concrete interceptors and register them with the concrete framework to handle certain events.   When events occur, application trigger the concrete framework and its dispatchers to invoke concrete interceptor callbacks that perform application-specific event processing.

19. Structure Overview (Again) Overview (Again)

20. Dynamics Sequence Diagram Sequence Diagram

21. Implementation Common approach for implementing the Interceptor pattern.   Model the internal behavior of the concrete framework.   Identify and model interception points.   Specify the context objects.   Specify the interceptors.   Specify the dispatchers.   Implement the callback mechanisms in the concrete framework.   Implement the concrete interceptors.

22. Implementation (Pre-Understanding) State Machine State Machine  상태가 순차적으로 발생하는 것을 명세화 한 UML Diagram 이며 State Machine 을 이용하여 개별 Object 의 행동 ( 동적인 측면 ) 을 Modeling 할 수 있다.  개념 정의  State  Transition  Pseudo-State  Superstate Idle Cooling ready / turnOn( ) tooHot(desiredTemp) atTemp Heating Activating Active tooHot(desiredTemp) tooCold(desiredTemp) atTemp Initial State Final State State Event Transition Event Parameter Action Nested State shutDown

23. Implementation (Pre-Understanding) State State  Object 가 생명 주기 동안 가질 수 있는 조건 ( 상황 ) 이며 특정 조건 이 만족된 상태에서 활동을 수행하고 사건을 기다림 Tracking entry / setMode(onTrack) exit / setMode(offTrack) newTarget / tracker.Acquire( ) do / followTarget selfTest / defer 명칭 진입 동작 내부 전이 지연 사건 탈출 동작 활동 IdleRunning 상태 명칭 shutDown keyPress finished

24. Implementation (Pre-Understanding) Transition Transition  특정 Object 가 현 상태에서 어떤 동작을 수행한 후 지정된 상태가 발생하고 지정된 조건이 만족되었을 때 다음 상태로 들어가는 두 상태간의 관계 IdleRunning 상태 명칭 shutDown keyPress finished Idle Engaging 사건 Trigger shutDown After (2 seconds) / send c.isAlive contact SearchingEngaging Tracking targetAt(p) [isThreat] / t.addTarget(p) noise 시간 사건 재귀 전이 매개 변수 있는 사건 Trigger 전이 조건 동작 전송 신호 Trigger 없는 전이

25. Implementation (Pre-Understanding) Pseudo-State Pseudo-State  초기 상태와 끝나는 상태 IdleRunning 상태 명칭 shutDown keyPress finished

26. Implementation (Pre-Understanding) Superstate Superstate  중첩 (Nested) 구조로 된 상태이며 배타적 ( 상 ) 하위상태 ( 순차적 활 성화 ) 나 동시적 ( 상 ) 하위 상태 ( 동시적 활성화 )  Super Class & Concrete Class 의 상속구조의 개념으로 이해. Idle Maintenance [continue] Active Activating maintain SelectingProcessing Printing cardInserted cancel [not continue] entry / readyCard exit / ejectCard 복합 상태의 전이 복합 상태 순차 하위 상태 하위 상태로부터의 전이

27. Implementation (Pre-Understanding) 종합 Example 종합 Example  다시 보면 별거 아님. Idle Cooling ready / turnOn( ) tooHot(desiredTemp) atTemp Heating Activating Active tooHot(desiredTemp) tooCold(desiredTemp) atTemp Initial State Final State State Event Transition Event Parameter Action Nested State shutDown

28. Implementation   Model the internal behavior of the concrete framework.   In general, state machine modeling helps identify where to place interceptors and how to define their behavior in a concrete framework.   Service (Typical)   When the client binds to a new remote object.   When the client can send requests to the remote object.

29. Implementation   Model the internal behavior of the concrete framework. (Cont)   State Machine

30. Implementation   Identify and model interception points.   Identify concrete framework state transitions.   Search Interception Point.   Partition interception points into reader and writer sets.   Divide to access information & modify behavior from Concrete Framework   Integrate interception points into the state machine model.   we can identify the potential interception points.   Partition interception points into disjoint interception groups.   Ex) OutRequest interception group, InRequest interception group

31. Implementation   Specify the context objects.   Determine the context object semantics.   Define Accessor & Mutator Method and degree to which a framework is ‘open’   Determine the number of context object types.   Multiple interfaces (specific) & Single interface (general) In Interception Point.   Define how to pass context objects to concrete interceptors.   Per-registration (general) & Per-event (specific)

32. Implementation   Specify the interceptors.   Interceptor Interception Group   Designed callback hook method Interception Point public interface ClientRequestInterceptor { public void onPreMarshalRequest (UnmarshaledRequest context); public void onPostMarshalRequest (MarshaledRequest context); } Interception Group Interception Point Concrete Interceptor : Observer Callback Method : If ‘Per-event’, Context is Passed

33. Implementation   Specify the dispatchers.   Specify the interceptor registration interface.   Observer Pattern : Dispatcher  Subject, Interceptor  Observer.   Specify the dispatcher callback interface.   Event occur  Find registered concrete interceptor  Invoke the corresponding hook methods

34. Implementation   Implement the callback mechanisms in the concrete framework.   Event Propagation Mechanism   Double Observer : First : Concrete Framework (Subject) – Dispatcher (Observer) Second : Dispatcher (Subject) – Interceptor (Observer)   Internal Callback Mechanism (Ordering)   Base : Iterator Pattern, Select : Strategy Pattern FIFO, LIFO. Priority Order. Chain of Responsibility.

35. Implementation   Implement the concrete interceptors.   Derived from and be implemented the corresponding interceptor interface in application-specific ways.   Use Context Object : Accessor & Mutator   Extension Interface Pattern : Minimize Number of Interceptor type, public class Client { static final void main (String args[]) { ClientRequestInterceptor myInterceptor = // Use an anonymous inner class. new ClientRequestInterceptor () { public void onPreMarshalRequest (UnmarshaledRequest context) { System.out.println (context.getObj () + " called"); //... } public void onPostMarshalRequest (MarshaledRequest context) { /*... */ } }; ClientRequestDispatcher.theInstance (). registerClientRequestInterceptor (myInterceptor); // Do normal work. }

36. Example Resolved Bind interceptor.   When a client binds to a remote object, the bind interceptor determines whether subsequent invocations on the CORBA object should be load balanced.   Information on load balancing is in the ORB's Implementation Repository. Client request interceptor.   When a client invokes an operation on a remote object, the client request concrete interceptor is dispatched.   If the Object is replicated, the interceptor finds a server machine with a light load and forwards the request to the appropriate target object.   Client Developer can use his own load algorithm using Strategy Pattern without affecting the ORB infrastructure.

37. Example Resolved Illustrates the scenario (3) It then consults a table containing the object's replicas to identify a server with a lightest load.  Step 3. (4) The client ORB forwards the request to the server with a light load. (5) The server's ORB then delivers it to the object implementation residing on this server. (6) Dispatches its operation.  Step 1.  A client invokes an operation.  Step 2. (2) The client request interceptor intercepts this request.

38. Variants Interceptor Proxy. (also known as Delegator).   Be used often on the server-side of a distributed system to intercept remote operations. Single Interceptor-per-Dispatcher.   Allows only one interceptor to register with a specific dispatcher. Interceptor Factory.   Applicable when the concrete framework instantiates the same class multiple times Implicit Interceptor Registration.   Rather than registering interceptors via dispatchers explicitly, a concrete framework can load interceptors dynamically.

39. Known Uses Component-based application servers CORBA implementations Fault-tolerant ORB frameworks. COM Web browsers. DynamicTAO reflective ORB Change of address surface mail forwarding.

40. Consequences Benefits Benefits   Extensibility and flexibility.   Separation of concerns.   Support for monitoring and control of frameworks.   Layer symmetry.   Reusability.

41. Consequences Liabilities Liabilities   Complex design issues.   Malicious or erroneous interceptors.   Potential interception cascades.

42. See Also The Template Method Pattern. The Chain-of-Responsibility Pattern. The Pipes and Filters Pattern. The Proxy Pattern. The Observer and Publisher-Subscriber Patterns. The Reflection Pattern. The Reactor Pattern.