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

Revision as of 03:49, 20 November 2009

Overview

The interceptor framework needs to provide generic support for intercepting messages in different stages of the communication between consumer and provider. Most importantly it should enable implementations that allow the distinguishing role (consumer / provider) and scope (request, response).

Description

Example scenario

Sampe Interceptors

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

Interceptor registration

<!-- 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>

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