Skip to main content
Jump to: navigation, search

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:
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service&gt;
 
&lt;/osgi:service&gt;
</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>&lt;bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/&gt;
  
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:
+
&lt;osgi:service ref="exampleInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
+
<pre>
+
&lt;bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/&gt;
+
 
+
&lt;osgi:service ref="exampleConsReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
+
 
&lt;osgi:service-properties&gt;
 
&lt;osgi:service-properties&gt;
 
&lt;entry key=“role“ value=“consumer,provider“/&gt;
 
&lt;entry key=“role“ value=“consumer,provider“/&gt;
Line 66: Line 73:
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service&gt;
 
&lt;/osgi:service&gt;
</pre>
+
</pre>  
 +
==== Pros  ====
 +
 
 +
*New dimensions can easily be added by defining additional properties
 +
*Unified interface makes chain execution straightforward (no conditional processing)
  
==== 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 =====
 
==== Cons =====
<ul>
+
 
<li>Interceptor implementation scattered over multiple classes if different behaviour is required</li>
+
*Interceptor implementation scattered over multiple classes if different behaviour is required
</ul>
+

Revision as of 10:48, 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