Skip to main content

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.

Jump to: navigation, search

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

Line 1: Line 1:
−
== Option 1 (proposed by Jürgen)  ==
+
== Overview ==
−
 
+
The interceptor framework needs to support implementations that allow the distinguishing direction (inbound / outbound) and scope (request, response).
−
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]]
+
−
 
+
−
=== Example of interceptor registration:  ===
+
−
<pre>&lt;bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/&gt;
+
−
 
+
−
&lt;osgi:service ref="exampleInterceptor"&gt;
+
−
&lt;osgi:interfaces&gt;
+
−
&lt;value&gt;org.eclipse.swordfish.core.ConsReqInterceptor&lt;/value&gt;
+
−
&lt;value&gt;org.eclipse.swordfish.core.ConsResInterceptor&lt;/value&gt;
+
−
&lt;value&gt;org.eclipse.swordfish.core.ProvReqInterceptor&lt;/value&gt;
+
−
&lt;value&gt;org.eclipse.swordfish.core.ProvresInterceptor&lt;/value&gt;
+
−
&lt;/osgi:interfaces&gt;
+
−
&lt;/osgi:service&gt;
+
−
</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) ==
+
−
 
+
−
In option 2, we would have a uniform interface but up to four different classes implementing this interface, one for each processing position.  
+
  
 +
== Description ==
 
[[Image:Interceptor Framework Option2.png]]  
 
[[Image:Interceptor Framework Option2.png]]  
  
Line 73: Line 46:
 
&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)
 
  
−
==== Cons ====
+
==== Consequences ====
 +
* New dimensions can easily be added by defining additional properties
 +
* Unified interface makes chain execution straightforward (no conditional processing)
  
−
*Interceptor implementation scattered over multiple classes if different behaviour is required
+
== See also ==

Revision as of 12:40, 19 November 2009

Overview

The interceptor framework needs to support implementations that allow the distinguishing direction (inbound / outbound) and scope (request, response).

Description

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>

Consequences

  • New dimensions can easily be added by defining additional properties
  • Unified interface makes chain execution straightforward (no conditional processing)

See also

Retrieved from "https://wiki.eclipse.org/index.php?title=Swordfish_Documentation:_Architecture:_Interceptor_Framework&oldid=179885"

Back to the top