Announcement Announcement Module
No announcement yet.
Exposing Services in a JMS based application Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Exposing Services in a JMS based application


    I'm designing an application framework based around a JMS bus (and Spring), so I can easily distribute the components across multiple cheap serves, keep things loosley coupled, and potentially provide some fault tolerance by providing multiple queue consumers.

    What I'm struggling with, is choosing the best way to expose the services that each of the components provides. I do use some publish/subscribe, mostly to handle notifications, but there are a bunch of services I want to expose as well (e.g mostly managers for different things, eg, user, schedules, jobs etc).

    My client list is currently:

    1. .NET client
    2. Other Java/Spring apps, connected to the bus
    3. ESB integration
    4. Possible web interface (classic, or rich UI with Flex or Laszlo)

    What's the best/simplest way to expose my services (which I'd ideally like to have distributed on different machines, connected via the JMS bus)?

    Here are some ideas I've had:

    1. Deploy the services within a container (e.g. tomcat, jboss etc), and expose with ActiveSOAP, AXIS or something similar, providing SOAP and potentially REST interfaces to my services. However, this centralizes my services in a single container (I'm not saying this is a bad thing, but just not what I had initially planned).

    2. Deploy a very simple facade layer in the container, which just proxies request/responses to and from JMS. I was thinking about using Lingo if I went for this approach (can lingo servers only work with lingo clients?). I'm worried about having to maintain the facade layer as well as the actual servce though.

    3. I'm likely to be using ActiveMQ for my JMS, and it supports a number of protocols, including REST, allowing for .NET clients to product/consume messages. However, most of the .NET client use will be request/response RPC like interactions, so an RPC like approach may be simpler. One drawback of this is that I'd still have to expose something to the ESB (either a webservice or JMS messages of some kind).

    4. A combination of these.

    5. Something else entirely?

    I'm thinking that 1 or 2 may be the most standard way, but what do people think? Any recommendations? I'd really like to have a single set of external interfaces if possible, but I'd also like to keep the implementation of the services distributed.

    Any feedback would be great.

    Many thanks,

  • #2
    I've responded here...