Skip to main content
Jump to: navigation, search

Difference between revisions of "Swordfish Documentation: Architecture: Interceptor Framework"

Line 16: Line 16:
 
</osgi:interfaces>
 
</osgi:interfaces>
 
</osgi:service>
 
</osgi:service>
</pre>
+
</pre>  
 
+
 
==== Pros  ====
 
==== Pros  ====
  
 
*Only one implementation class required  
 
*Only one implementation class required  
*Service registration straightforward  
+
*Service registration straightforward
  
==== Cons =====
+
==== Cons ====
  
*different method names require conditional processing in chain execution  
+
*different method names require conditional processing in chain execution
  
 
== Option 2 (proposed by Zsolt)  ==
 
== Option 2 (proposed by Zsolt)  ==
Line 77: Line 76:
  
 
*New dimensions can easily be added by defining additional properties  
 
*New dimensions can easily be added by defining additional properties  
*Unified interface makes chain execution straightforward (no conditional processing)  
+
*Unified interface makes chain execution straightforward (no conditional processing)
  
==== Cons =====
+
==== Cons ====
  
 
*Interceptor implementation scattered over multiple classes if different behaviour is required
 
*Interceptor implementation scattered over multiple classes if different behaviour is required

Revision as of 10:49, 12 November 2009

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.

Interceptor Framework Option1.png

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.

Interceptor Framework Option2.png

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

Back to the top