Skip to main content
Jump to: navigation, search

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

(Overview)
 
(20 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Option 1 (proposed by Jürgen)  ==
+
== Overview ==
 +
The Interceptor Framework provides generic support for intercepting messages in different stages of the communication between consumer and provider. It enables implementations that allow the distinguishing role (consumer / provider) 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.
+
== Description ==
 +
The basic ideas of the interceptor framework are:
 +
* Interceptors are exposed as OSGi services with properties that the [http://www.eclipse.org/swordfish/docs/apidocs/org/eclipse/swordfish/core/planner/Planner.html planner] uses to construct interceptor chains based on [http://www.eclipse.org/swordfish/docs/apidocs/org/eclipse/swordfish/core/planner/strategy/package-summary.html implemented strategies].
 +
* The interceptor interface has to be as simple as possible to allow straightforward processing of the elements in the chain.
 +
* In order to allow simple implementations, interceptor should not have to verify the current communication stage. (As the planner constructs the chain of interceptors based on implemented strategies the communication stage is clear when the interceptor is called.)
 +
* It should be possible to plug in an instance of a generic interceptors in different interceptor chains.
 +
* Although interceptors should not have to rely on context information they should be able to access, store and even modify it, if necessary:
 +
** a message tracking interceptor may want to store information about when a message was sent to check how long it took to get a response
 +
** an interceptor on consumer side may want to add information to a message that is picked up by an interceptor on provider side
  
[[Image:Interceptor Framework Option1.png]]  
+
=== Example scenarios  ===
 +
==== Context based Interceptor registration ====
 +
===== Sampe Interceptors =====
 +
In the example scenario below there are 4 different interceptors implementing the <code>process(...)</code> method defined in the base interface [http://www.eclipse.org/swordfish/docs/apidocs/org/eclipse/swordfish/core/Interceptor.html Interceptor].
 +
The names of the interceptor classes indicate the purpose of the interceptor. Basically they are supposed to be plugged in on consumer (Example'''Cons'''ResInterceptor) and provider side (example'''Prov'''ReqInterceptor) to process requests (ExampleCons'''Req'''Interceptor) and responses (exampleProv'''Res'''Interceptor).
 +
<br/>
 +
[[Image:Interceptor Framework Option2.png]]
  
=== Example of interceptor registration:  ===
+
===== Configuration =====
<pre>&lt;bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/&gt;
+
<pre>
 
+
&lt;!-- Instances of the interceptors --&gt;
&lt;osgi:service ref="exampleInterceptor"&gt;
+
&lt;bean id="exampleConsReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsReqInterceptor"/&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>
+
== 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.
+
 
+
[[Image:Interceptor Framework Option2.png]]
+
 
+
=== Example of interceptor registration:  ===
+
<pre>&lt;bean id="exampleConsReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsReqInterceptor"/&gt;
+
 
&lt;bean id="exampleConsResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsResInterceptor"/&gt;
 
&lt;bean id="exampleConsResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsResInterceptor"/&gt;
 
&lt;bean id="exampleProvReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvReqInterceptor"/&gt;
 
&lt;bean id="exampleProvReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvReqInterceptor"/&gt;
 
&lt;bean id="exampleProvResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvResInterceptor"/&gt;
 
&lt;bean id="exampleProvResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvResInterceptor"/&gt;
  
 +
&lt;!-- Expose the exampleConsReqInterceptor as an OSGi service to be used on outgoing requests on consumer side --&gt;
 
&lt;osgi:service ref="exampleConsReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
&lt;osgi:service ref="exampleConsReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
&lt;osgi:service-properties&gt;
 
&lt;osgi:service-properties&gt;
Line 35: Line 35:
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service&gt;
 
&lt;/osgi:service&gt;
 +
 +
&lt;!-- Expose the exampleConsResInterceptor as an OSGi service to be used on incoming responses on consumer side --&gt;
 
&lt;osgi:service ref="exampleConsResInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
&lt;osgi:service ref="exampleConsResInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
&lt;osgi:service-properties&gt;
 
&lt;osgi:service-properties&gt;
Line 41: Line 43:
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service&gt;
 
&lt;/osgi:service&gt;
 +
 +
&lt;!-- Expose the exampleProviderReqInterceptor as an OSGi service to be used on incoming requests on provider side --&gt;
 
&lt;osgi:service ref="exampleProviderReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
&lt;osgi:service ref="exampleProviderReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
&lt;osgi:service-properties&gt;
 
&lt;osgi:service-properties&gt;
Line 47: Line 51:
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service-properties&gt;
 
&lt;/osgi:service&gt;
 
&lt;/osgi:service&gt;
 +
 +
&lt;!-- Expose the exampleProvResInterceptor as an OSGi service to be used on outgoing responses on provider side --&gt;
 
&lt;osgi:service ref="exampleProvResInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
&lt;osgi:service ref="exampleProvResInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
 
&lt;osgi:service-properties&gt;
 
&lt;osgi:service-properties&gt;
Line 55: Line 61:
 
</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:
+
==== Generic Interceptor registration ====
 +
If an interceptor should exhibit the same behaviour in all four processing positions, only one instance of the implementation class would be needed and registered as shown below:  
 +
<pre>&lt;bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/&gt;
  
<pre>
+
&lt;osgi:service ref="exampleInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“&gt;
&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 68: Line 73:
 
</pre>
 
</pre>
  
==== Pros ====
+
== See also ==
<ul>
+
[[Swordfish_Documentation:_Architecture | Architecture overview ]]
<li>New dimensions can easily be added by defining additional properties</li>
+
 
<li>Unified interface makes chain execution straightforward (no conditional processing)</li>
+
[http://www.eclipse.org/swordfish/docs/apidocs Swordfish JavaDoc]
</ul>
+
==== Cons =====
+
<ul>
+
<li>Interceptor implementation scattered over multiple classes if different behaviour is required</li>
+
</ul>
+

Latest revision as of 05:06, 20 November 2009

Overview

The Interceptor Framework provides generic support for intercepting messages in different stages of the communication between consumer and provider. It enables implementations that allow the distinguishing role (consumer / provider) and scope (request, response).

Description

The basic ideas of the interceptor framework are:

  • Interceptors are exposed as OSGi services with properties that the planner uses to construct interceptor chains based on implemented strategies.
  • The interceptor interface has to be as simple as possible to allow straightforward processing of the elements in the chain.
  • In order to allow simple implementations, interceptor should not have to verify the current communication stage. (As the planner constructs the chain of interceptors based on implemented strategies the communication stage is clear when the interceptor is called.)
  • It should be possible to plug in an instance of a generic interceptors in different interceptor chains.
  • Although interceptors should not have to rely on context information they should be able to access, store and even modify it, if necessary:
    • a message tracking interceptor may want to store information about when a message was sent to check how long it took to get a response
    • an interceptor on consumer side may want to add information to a message that is picked up by an interceptor on provider side

Example scenarios

Context based Interceptor registration

Sampe Interceptors

In the example scenario below there are 4 different interceptors implementing the process(...) method defined in the base interface Interceptor. The names of the interceptor classes indicate the purpose of the interceptor. Basically they are supposed to be plugged in on consumer (ExampleConsResInterceptor) and provider side (exampleProvReqInterceptor) to process requests (ExampleConsReqInterceptor) and responses (exampleProvResInterceptor).
Interceptor Framework Option2.png

Configuration
<!-- Instances of the interceptors -->
<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"/>

<!-- Expose the exampleConsReqInterceptor as an OSGi service to be used on outgoing requests on consumer side -->
<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>

<!-- Expose the exampleConsResInterceptor as an OSGi service to be used on incoming responses on consumer side -->
<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>

<!-- Expose the exampleProviderReqInterceptor as an OSGi service to be used on incoming requests on provider side -->
<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>

<!-- Expose the exampleProvResInterceptor as an OSGi service to be used on outgoing responses on provider side -->
<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>

Generic Interceptor registration

If an interceptor should exhibit the same behaviour in all four processing positions, only one instance of the implementation class would be needed and 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>

See also

Architecture overview

Swordfish JavaDoc

Back to the top