Announcement Announcement Module
Collapse
No announcement yet.
Channel: PollableChannel vs. PublishSubscribeChannel Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Mark,

    To answer your other question as well:

    Originally posted by Mark Fisher View Post
    ...Interestingly, up to this point, I don't get the sense that the gateway has much widespread usage. Therefore, it really would be helpful if you could provide some information (high-level) about how you are currently using gateway in your applications? Most importantly, are you extending the SimpleMessagingGateway class directly or are you using GatewayProxyFactoryBean? If the latter, are you using the namespace support?...
    As described in my user profile above I am using SI for the following:

    1. In a first approach we are implementing a "lightweight" integration platform agent called PlanCom and RailCom
    On the server-side the implementation is a remote agent (using RMI) delegating incoming request payloads to SI.
    Each request is handled in its own ApplicationContext. The first entry point here is an IIntegrationService endpoint (and not a request channel).

    2. In a second step our PlanCom and RailCom will be migrated into JBoss

    As mentioned above all integration services are configured via XML. Meaning: each endpoint is not aware to SI, any other endpoint or channel. The only exceptional behavior is the entry point with the IIntegrationService. Here we are using explicitely the SimpleMessagingGateway for sending a message to a request channel and receiving a message from a reply channel.

    So far I haven't use the GatewayProxyFactoryBean yet. But isn't there a big difference? As far as I understand:
    - The SimpleMessagingGateway is used (in a bean) for triggering direct channel messaging (bean sends and receives messages)
    - The GatewayProxyFactoryBean is used to be triggered by channels (bean's method is called by a request channel, return argument is send to a reply channel)

    Some noteworthy input to our integration platform:
    - Beans are completely configured in XML without using a component-scan (it might register too many classes)

    - The IRequestPayload send to IIntegrationService contains also a boolean fireAndForget. This allows each caller to decide either:
    - to have a synchronous call (the SimpleMessagingGateway is used to synchronize to the reply) or
    - to have a asynchronous call (payload is passed directly to the channel and null is returned).
    This allows us to avoid unnecessary network traffic e.g. via RMI

    - Each integration service has a "keep alive" flag to decide whether the ApplicationContext should be re-used for other requests or to start another context. That will be quite a challenge for certain 'transient' integration services (that are re-used) to not have any data stored .

    - The agent does also use Jetty and Spring WebServices.

    HTH Tai
    Last edited by ttruong; Sep 29th, 2008, 09:28 AM.

    Comment


    • #17
      Looking into the code of GatewayProxyFactoryBean I see that basically it does the same like the SimpleMessagingGateway: a message is send to the request channel and a message is retrieved from the reply channel.

      The GatewayProxyFactoryBean's advantage is that it makes it SI unaware to the caller. To be precise:
      It creates dynamically a service proxy (implementing the service interface). Behind the proxy the gateway is used to send and receive messages. Meaning: the client/caller is only aware of the proxy/service interface and not the gateway.

      In our case we have concrete implementations of IIntegrationService (like for commands and queries). Also a fireAndForget flag can be passed to the integration service. Only in case of false a reply is returned.

      Tai

      Comment

      Working...
      X