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.
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. | + | 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 16: | ||
</osgi:interfaces> | </osgi:interfaces> | ||
</osgi:service> | </osgi:service> | ||
− | </pre> | + | </pre> |
+ | |||
+ | ==== Pros ==== | ||
+ | |||
+ | *Only one implementation class required | ||
+ | *Service registration straightforward | ||
+ | |||
+ | ==== Cons ===== | ||
+ | |||
+ | *different method names require conditional processing in chain execution | ||
+ | |||
== 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. | + | 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]] | ||
Line 53: | Line 63: | ||
</osgi:service-properties> | </osgi:service-properties> | ||
</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="exampleInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | <osgi:service ref=" | + | |
<osgi:service-properties> | <osgi:service-properties> | ||
<entry key=“role“ value=“consumer,provider“/> | <entry key=“role“ value=“consumer,provider“/> | ||
Line 66: | Line 73: | ||
</osgi:service-properties> | </osgi:service-properties> | ||
</osgi:service> | </osgi:service> | ||
− | </pre> | + | </pre> |
+ | ==== Pros ==== | ||
+ | |||
+ | *New dimensions can easily be added by defining additional properties | ||
+ | *Unified interface makes chain execution straightforward (no conditional processing) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
==== Cons ===== | ==== Cons ===== | ||
− | + | ||
− | + | *Interceptor implementation scattered over multiple classes if different behaviour is required | |
− | + |
Revision as of 10:48, 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>
Pros
- Only one implementation class required
- Service registration straightforward
Cons =
- different method names require conditional processing in chain execution
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="exampleInterceptor" 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