Swordfish Documentation: Architecture: Interceptor Framework

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