Extraordinary IT.
When to use JMS and when to use REST? – Stack Overflow
Over on Stack Overflow, someone asked “When to use JMS and when to use REST?” We’ve been getting asked the same thing a quite few times recently, so it seams worthwhile to share it.
That is a good response. At the end of the day I see the approaches (MOM and REST) as being similar and both capable of achieving a desired set of goals. For me at the end of the day which implementation to use will often get back to the skill sets and culture within the organisation. There’s no point in trying to implement a MOM based solution (using JMS…) if you have a development house full of Web Developers with a heap of existing web infrastructure that would allow implementation of REST a lot easier. It works the same the other way around.
There are some factors not discussed in your response though. The biggest gap I see is the implementation of Governance. The ability to monitor and control an integration platform in a large complex organisation requires careful consideration, regardless of the patterns that you implement. I’m sure there are suitable ways to implement appropriate levels of control using both patterns, each with it’s own set of pros and cons.
I think there are more aspects of the Enterprise that would influence a decision such as this, for example, what technologies already exist and what forms of integration do they support? Any decent integration specialist would be able to implement either or both patterns, which makes me think, wouldn’t it be possible, with an appropriate level of abstraction between transport and function, to implement both patterns across a common code set or functional base?
http://windyroad.org/2012/08/27/rest4bw-v1-released/
This way you can support newer implementations and technologies and your legacy applications all at the same time. Just a thought ;-D
You’re right, any decent integration specialist should be able to implement MOM or REST based integrations, however many (from our experience) can do MOM, but not REST. This results in the golden hammer anti-pattern, where all they know is MOM and so that’s all they implement.
If both approaches were equal then this wouldn’t be a problem, however from our experience REST is far better than MOM in almost every scenario (hello high frequency traders. You are the exception).
I know “better” is a subjective term, so I should define what we mean by better. Better for us means that it provides better business value. REST based integrations do just that. They are more flexible, scalable, supportable and maintainable, which means they cost the business less overall.
In terms of abstracting the implementation from the transport, that would be more like comparing a JMS implementation and HTTP. In this scenario yes, you could provide both transports for the same functionality. What you describe however is implementing two architectures. While possible, it would be highly complex and would certainly cost far more to implement and maintain. Far better in these situations to have a definitive service implemented once, with a Service Broker or Legacy Facade for the clients that need it.
Agree, however I see that your view of business value is only coming from a technical perspective and is ignoring the people aspect, how can a style be more supportable if there aren’t as many people that understand it?
Often the wider impacts of decisions to implement different architectural styles in an enterprise and move to fast will impact the ability for that enterprise to realise any investment that it makes or has made in a particular style. It also makes transition to a new style more difficult when you have multiple starting points.
My point is that I think the implementation of a new integration style in an enterprise is not one that can be summed up in a single small article (and I know that’s not what you are trying to do, run with me on this). There are external influences that need to be considered. It’s important to remember the role of the enterprise architect in this discussion as the decision to move from MOM to REST in an attempt to realise the benefits and value you discuss, must be one that is supported at all levels of technology design and implementation or you simply will not achieve the goal you’re aiming for.
— As always, great to chat!
It’s always a difficult decision. Do you stick to and approach that is sub-optimal, but consistent or do you take on new more optimal approaches, creating a whole heap of technical debt to bring the old implementations in-line with the new?
I don’t think there is any right or wrong answer, but I do favor taking on the new. Sticking with the old does provide the confort of consistency, however it comes at the cost of accepting waste as part of your integration delivery process rather than actively working to reduce waste in all its forms. I would far prefer something inconsistent that get’s better and better with each new extension, compared to something that is consistently bad and impossible to improve.
Does that mean I think we should always rush head first into new technologies and/or approaches? No. But we should allow ourselves the opportunity to evaluate new technologies and/or approaches and redefine out true north based on the outcome.