Announcement Announcement Module
Collapse
No announcement yet.
want to restrict options available with int:gateway to keep the config very simple Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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
    Code:
     
    	<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
    Code:
    <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?

  • #2
    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:
    Code:
    <bean class="com.mycompany.MyGateway">
      <property name="service-interface">client.interface</property>
    </bean>
    Last edited by Keith Patton; Nov 13th, 2011, 03:43 PM.

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment

        Working...
        X