Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Swordfish Documentation: Architecture: Interceptor Framework
Revision as of 10:45, 12 November 2009 by Unnamed Poltroon (Talk)
Contents
Option 1 (proposed by Jürgen)
In option 1, we would have four interfaces representing the four processing positions. An interceptor might implement only a subset of these interfaces.
Example of interceptor registration:
<bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/> <osgi:service ref="exampleInterceptor"> <osgi:interfaces> <value>org.eclipse.swordfish.core.ConsReqInterceptor</value> <value>org.eclipse.swordfish.core.ConsResInterceptor</value> <value>org.eclipse.swordfish.core.ProvReqInterceptor</value> <value>org.eclipse.swordfish.core.ProvresInterceptor</value> </osgi:interfaces> </osgi:service>
Option 2 (proposed by Zsolt)
In option 2, we would have a uniform interface but up to four different classes implementing this interface, one for each processing position.
Example of interceptor registration:
<bean id="exampleConsReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsReqInterceptor"/> <bean id="exampleConsResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsResInterceptor"/> <bean id="exampleProvReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvReqInterceptor"/> <bean id="exampleProvResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvResInterceptor"/> <osgi:service ref="exampleConsReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“consumer“/> <entry key=“scope“ value=“request“/> </osgi:service-properties> </osgi:service> <osgi:service ref="exampleConsResInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“consumer“/> <entry key=“scope“ value=“response“/> </osgi:service-properties> </osgi:service> <osgi:service ref="exampleProviderReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“provider“/> <entry key=“scope“ value=“request“/> </osgi:service-properties> </osgi:service> <osgi:service ref="exampleProvResInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“provider“/> <entry key=“scope“ value=“response“/> </osgi:service-properties> </osgi:service>
If the interceptor should exhibit the same behaviour in all four processing positions, only one implementation class would be needed that is registered as shown below:
<bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/> <osgi:service ref="exampleConsReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“consumer,provider“/> <entry key=“scope“ value=“request,response“/> </osgi:service-properties> </osgi:service>
Pros
- New dimensions can easily be added by defining additional properties
- Unified interface makes chain execution straightforward (no conditional processing)
Cons =
- Interceptor implementation scattered over multiple classes if different behaviour is required