want to restrict options available with int:gateway to keep the config very simple

[kkcmadhu]

Hi,

We are looking for developing a thin framework for mediation using spring integration. Depending upon the invoked service, we use different transports (amqp, http or in java call using service activator). We do not want the client to be aware of the underlying infrastructure and want to abstract out these. So we were planning to use a Gateway as an entry point.

While doing so, we do not want the client code to specify the request channel, reply channel,timeouts etc. and want to control all these with in our frame work.

Also, we would like to want to add few header information to messages originating through these gateway, but do not want clients to add headers to keep the configuration very simple.

Our first choice was to use the

 
	<int:gateway id="someService" service-interface="org.example.service"    default-request-channel="serviceInputChannel">
		<int:method name="someMethod" reply-timeout="2" request-timeout="200"  > 
			<int:header name="serviceName" value="serviceToBeInvoked"/>
			<int:header name="requestor" value="callingService"/>
		</int:method>
</int:gateway>

But the gateway gives way too many options to the client we want to keep it very simple some thing like

<gateway: service-inferface="org.example.service" method="someMethod" />

rest we would want to do behind the scene.


I thought of using a GatewayProxyFactoryBean and writing a custom name space similar to GatewayParser , but i donot want to use the parser for setting message headers. May be use a message converter.

Also i am not sure if there is a way to use a custom MessageConverter with GatewayProxyFactoryBean.

Is there a better approach for achieving this rather than writing a name space handler or extending the GatewayProxyFactoryBean?

[Keith Patton]

One possibility is to make a subclass of GatewayProxyFactoryBean and expose that bean to your clients. Your subclass could then enforce your requirements and prevent unwanted access, and simply delegate the real work to Spring.

Clients would then use this instead:

<bean class="com.mycompany.MyGateway">
  <property name="service-interface">client.interface</property>
</bean>

[Amol Nayak]

But the gateway gives way too many options to the client

Can you let us know what exactly you mean by this? With gateways you donot expose any messaging or Spring integration related classes in these interfaces and the underlying transport is transparent to the client. This is the idea behind using gateways and i am assuming that is what you are targetting.

I thought of using a GatewayProxyFactoryBean and writing a custom name space similar to GatewayParser , but i donot want to use the parser for setting message headers

Parser is used to parse the definition from the config file. Activities like setting message header happens at runtime and cannot possibly be done by parsers.

[oleg.zhurakousky]

Well you can keep your gateway as simple as you've described with the exception of 'default-request-channel' since it is required. But I wouldn't worry about it since all you need is one channel and the routers and header-enrichers downstream (not visible to your client) could take care of everything else.