Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Swordfish Documentation: Architecture: Interceptor Framework"
| Line 1: | Line 1: | ||
== Option 1 (proposed by Jürgen) == | == 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. | ||
[[Image:Interceptor Framework Option1.png]] | [[Image:Interceptor Framework Option1.png]] | ||
| Line 16: | Line 18: | ||
</pre> | </pre> | ||
== Option 2 (proposed by Zsolt) == | == 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. | ||
[[Image:Interceptor Framework Option2.png]] | [[Image:Interceptor Framework Option2.png]] | ||
=== Example of interceptor registration: === | === Example of interceptor registration: === | ||
| − | <pre> | + | <pre><bean id="exampleConsReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsReqInterceptor"/> |
| − | <bean id="exampleConsReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsReqInterceptor"/> | + | |
<bean id="exampleConsResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsResInterceptor"/> | <bean id="exampleConsResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsResInterceptor"/> | ||
<bean id="exampleProvReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvReqInterceptor"/> | <bean id="exampleProvReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvReqInterceptor"/> | ||
| Line 51: | Line 54: | ||
</osgi:service> | </osgi:service> | ||
</pre> | </pre> | ||
| + | |||
| + | 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: | ||
| + | |||
| + | <pre> | ||
| + | <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> | ||
| + | </pre> | ||
| + | |||
| + | ==== Pros ==== | ||
| + | <ul> | ||
| + | <li>New dimensions can easily be added by defining additional properties</li> | ||
| + | <li>Unified interface makes chain execution straightforward (no conditional processing)</li> | ||
| + | </ul> | ||
| + | ==== Cons ===== | ||
| + | <ul> | ||
| + | <li>Interceptor implementation scattered over multiple classes if different behaviour is required</li> | ||
| + | </ul> | ||
Revision as of 10:45, 12 November 2009
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