I am an inexperienced Java developer trying to wrap my head around some fundamental middleware/SOA concepts and technologies, specifically:
- Service-Oriented Architecture (SOA)
- Message-Oriented Middleware (MOM)
- Message Queue
- Apache Camel
- Mule
- EJBs
- Endpoints & Routes
- Service Bus/ESB
- JMS
After looking each of these up online/on Wikipedia, I was able to get (for the most part) decent definitions for each of these. What I am not understanding is how all of these technologies/concepts work together on the backend to provide a 2nd/business tier solution.
Can someone please give an example of an architecture that would use all of these technologies/concepts, and explain what role each of them play in the overall solution? Once I see a working example I'm sure it will help me connect most of the dots.
Edit : Since I added the bounty, I've had several answers that suggest reading books. Although I appreciate all feedback here, I simply can't part ways with 300 reputation points for an answer that, essentially, boils down to "RTM" (especially when I'm flat broke and can't afford the manual!) To reiterate, the bounty and definitive answer will go to someone who can hit all of these bullets in a meaningful, practical example. This does not have to be a middleware compendium!!! Just a paragraph or two that shows how all these can be used together in harmony to produce a Java business-tier solution. Thanks again.
Source: Tips4all
SOA main principles: Build systems as set of services where each service is
ReplyDeleteCoarse-grained
Interoperable
Loosely coupled
A company offers a lot of business services (coarse-grained) developed over many years and exposed to the users (human or other systems) in some form. There are more chances that each of these features have been designed and developed not keeping the above three principles in mind. Moreover, each of those features might be running on disparate heterogeneous platforms, using different technologies etc.
What if you want to integrate these disparate features thus creating new solutions (For e.g. Amazon store front is a new service composed of their catalog service, shopping cart service etc)?
You have two choices:
Building the new feature from scratch keeping the 3 principles in mind. But it is a very costly endeavor, and one that’s almost never successful.
An effective and less risky alternative is to assemble/compose it from existing, proven (well tested) services.
Option 2 is where ESBs can help with their support for routing, transformation, monitoring etc. Apache Camel, Mule are open-source ESB's. Endpoints & Routes are the terminology used in EIP (Enterprise Integration Patterns) that these ESB's implement. ESB's can take help of MOM's when they want to route/integrate services that are running on heterogeneous platforms (For e.g. the catalog service might be running on a mainframe system but the shopping cart is implemented using stateful EJBs running in a Java Application server). Message queue is a concept in MOM that acts a temporary storage of the message between the sender and receiver. This temporary storage provides lot of benefits like asynchronous delivery, guaranteed delivery etc. Now, there can me multiple MOM vendors like IBM (WebSphere MQ), open-source ActiveMQ etc. We can use JMS to keep your code independent of the vendor.
I tried to relate all the concepts with an example. I also tried to keep it short. Please
ask follow up questions to gain more understanding.
MOM is not a requirement to implement SOA. For e.g. if all of your services are exposed over SOAP via HTTP then you doesn't need a MOM in this case.
Enterprise Integration Patterns can help you understand how everything fits together.
ReplyDelete[update:] Your follow-up question on another answer made me realise that you're confused about specific products. That's partly because software in practice tends to map to more than one concept and partly because different companies argue that they provide "everything", when really they don't.
The ESBs are toolkits / libraries that let you connect everything together. They are neither the services themselves, nor the messaging implementations, but the goo that fills the odd little gaps in-between. If you were writing everything from scratch you might not even need one, because what they are best at is fixing the mismatch between a whole pile of different technologies, and if you are starting from scratch you can avoid that mess.
The services are, well, the services. You might use some EJBs when implementing one (I only mention this because for some reason you include them in your question).
The messaging middleware is software that gets messages from A to B. That's extremely useful, but also complex, and everyone and their brother has invented their own. So you need some abstraction that lets you avoid lock-in. That can be an ESB or, if you are all-Java then it can be JMS. But even when you are all-Java with JMS you may still want to use an ESB because they are libraries of all the bits of Java code you would still need to write (random bits of routing logic, message reformatting, etc etc).
Hope that helps. My original answer is more about the abstract patterns that you build with these tools - when you're wiring things together the same problems come up again and again.
Taking all of your requirements and packaging them into a query, I came across an excellent case study that should meet your needs:
ReplyDeleteService Oriented Architecture: An Integration Blueprint
I went ahead and fulltext searched the book using Amazon's "Search Inside This Book" feature. It covers all of the integration cases you've discussed, appears to be thorough, and steps you through the entire design and implementation process.
I'm embarrassed to state I haven't read through this myself, but I highly recommend using the same tools I did to see if it fits your needs before investing in a copy. It seems more thorough, more complete, and more helpful than simply foisting you on a whole lot of incomplete documentation or spooling out content into an answer here.
You are sharing great things, I was searching this kind of information. Nice Work.
ReplyDelete