1 / 8

Architectural pattern: Interceptor

Architectural pattern: Interceptor. Source: POSA II pp 109 – 140 Environment: developing frameworks that can be extended transparently Recurring problem: Frameworks cannot anticipate all of the services they will need

ramona-may
Télécharger la présentation

Architectural pattern: Interceptor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architectural pattern: Interceptor • Source: POSA II pp 109 – 140 • Environment: developing frameworks that can be extended transparently • Recurring problem: • Frameworks cannot anticipate all of the services they will need • The benefit of a framework is lost if new services have to be implemented by applications

  2. Requirements for extensibility • Add a service without requiring modifications to the framework’s core architecture • Adding application-specific services should not break existing components or applications • Applications using a framework may need to monitor and control its behavior

  3. Examples of framework services that might use such an extension mechanism • Security • Event logging • Load balancing • Transaction management

  4. (Core of a) solution - interceptors • Interceptor interfaces provide hooks that can call service code when certain events occur • Event example: arrival of a client request • Dispatchers manage the concrete interceptors registered for framework events • Context objects provide access to event information and the framework’s internal state and behavior

  5. Dynamics • Application instantiates a concrete interceptor and registers it with the appropriate dispatcher • Framework receives an event • Framework passes a context object to the dispatcher for that type of event • Dispatcher calls registered interceptors in the appropriate order, passing the context object • Interceptors do their thing, using the context object for event data and methods to control certain aspects of the framework’s behavior

  6. Implementation • Model framework’s internal behavior • Identify and model interception points • Specify context objects • Specify the interceptors • Specify the dispatchers • Registration interface • Callback interface • Implement callback mechanisms • Implement concrete interceptors

  7. Known uses • Component-based application servers • EJB, CORBA components, COM+ • CORBA ORBs • Web browsers • Plug-ins are concrete interceptors • Non-software: paper mail forwarding

  8. Consequences • Benefits • Extensibility and flexibility • Separation of concerns • Support for monitoring and control • Layer symmetry • Reuse of interceptors across applications • Liabilities • Complex design issues • Malicious or erroneous interceptors • Risk of interception cascades

More Related