[ACCEPTED]-Why would you use a message based system?-servicebus

There are multiple advantages to using message 4 based systems.

1. Messages form a well defined technology neutral interface between applications.
2. Enables loose coupling of applications.
3. Lots of options for performance, tuning and scaling:
   • Deploy requester and service process on different hardware
   • Multiple requesters sharing single server
   • Multiple requesters sharing multiple servers
4. The various messaging middlewares implement the common messaging patterns independently from you application.
   • Request/Reply
   • Fire and Forget offline updates
   • Publish/Subscribe
5. Many of the middleware products handle message transformation (e.g. SWIFT to SWIFTXML).
6. Many of the middleware products can decompose a single large request into several smaller requests.
7. They nearly all support multiple platforms.

Incidentally the two market 3 leaders in this area are IBM with their 2 Websphere MQ and related products, and, TIBCO 1 with their Enterprise Service Bus.

A message-based architecture de-couples 5 producers and consumers of messages, both 4 in time and space. This has a lot of benefits:

• producers and consumers can run on different machines
• producers and consumers can run at different times.
• producers and consumers can run on different hardware/software platforms (they only need to understand the same message protocol)
• it's easy to coordinate multiple producers / consumers (e.g. for compute-intensive jobs that need multiple machines, as Dave Markle has described)
• higher stability when services are temporarily unavailble (e.g. when doing order processing, using a messaging system can help avoid "dropping" orders)

You 3 lose most of these benefits when you do 2 RPC-style communication (i.e. when you block 1 while waiting for service responses)

One use case is when you have a pool of 15 resources that can work on a given item, and 14 a list of work which needs to be distributed 13 in a scalable fashion.

I once had a project 12 where I had to do mainframe integration 11 with a number of 3270 screen scrapers (all 10 slow). I could have at most 10 of these 9 processes open on a box at a time. I had 8 thousands of accounts to screen-scrape and 7 update, so I put the work in a queue, and 6 my machines (I had about 3 of em) just picked 5 up work items off the message queue (MSMQ) and 4 did their screen scraping, and that was 3 it. I could easily spin up a new machine, or 2 deactivate old ones without interrupting 1 the flow of work, so that was nice.

the benefits are really down to decoupling 39 the parts of your application. Once you 38 have the bus set up, and applications are 37 added, you can easily extend your app by 36 adding new pieces that you can guarantee 35 will not affect the other parts. Its a very 34 good way of continually adding to a system 33 over time.

eg. we have a system like this, each 32 command is implemented as a part to the 31 overall GUI, if we want to add a new feature, or 30 modify an existing one, we just write a 29 new part and add it to the system. When 28 it gets called, it has no dependencies on 27 the rest. It means we can extend our app 26 very easily. Also, we have a message passing 25 between nodes on our network - when something 24 gets changed in 1 computer, a message is 23 sent to all others so they can update themselves. We 22 have a hundred different messages for different 21 events, so we can extend the system by dropping 20 a new service in that reacts to the appropriate 19 messages.

Message passing architectures typically 18 have the same features as web services, you 17 have discrete services you can call, you 16 can add new ones easily.

Don't think that 15 message passing architectures require fancy 14 (and expensive!) middleware products though, Windows 13 runs on a message passing architecture - every 12 WM_* message passed to a window is.. well, a 11 message, and I think that shows the best 10 example of the architecture - no part of 9 a system needs to know about any other part, you 8 can extend it infinitely as you can handle 7 as many controls as you like on any dialog, etc 6 etc.

Message passing is a fabulous architecture, though 5 it can be slower than tightly coupling your 4 application together, that's not much of 3 a reason not to use it nowadays especially 2 if you're already using scripting or .net 1 apps.

I helped develop one for a system that used 16 C# and Remoting, the client (a service or 15 GUI) could send a message complete with 14 some custom data and the recipient(s) would 13 receive it, either when they next connected 12 or instantly). They could then process the 11 message (by taking ownerships of it in the 10 case of the load-balancing services). It 9 was also used to update GUIs when long running 8 processes had finished.

The messaging system 7 itself had configurable pipelines that processed 6 each message, here are some examples of 5 a few of the pipelines we developed:

• Storage (created/ saved the message to the database)
• Routing (worked out where the message needs to be sent)
• Security (worked out if the client was allowed to receive it)
• Delete (works out if the message needs to be deleted from the system, which means clients need to be notified and the message removed from it's cache and flagged in the DB).
• TakeOwnership (deals with making sure only one client can modify the state of a message at a time as only messages that are owned can be changed)

So in 4 answer to your question, messaging systems 3 are a brilliant means of sending information 2 about when you don't know or care the who 1 client is.

Message oriented system are generally good 14 for certain classes of integration problems. Other 13 alternatives are having a shared data store 12 (file or DB based perhaps) for applications 11 to communicate with or applications integrating 10 via RPC.

The advantages of messaging over 9 these integration patterns are that you 8 aren't coupling both applications to the 7 same data store schema and you aren't tying 6 applications to a point to point RPC integration 5 scenario (which gets more complex the more 4 applications are involved).

There's also 3 the benefits of asynchronous communication 2 (like email vs. online chat) and message 1 routing and transformation possibilities.

A message-based system can lay the groundwork 29 for the entire digital side of your business. These 28 days, having digital solutions that are 27 seamlessly integrated is paramount for collecting, storing, and 26 analyzing data, and it's crucial that your 25 data help you make the most informed decisions 24 possible when it comes to your business 23 processes. Essentially, a message-based 22 service is a form of API (application programming 21 interface) that can send requests in the 20 form of messages from one application to 19 another. Using a message-based system means 18 that all of your digital solutions can be 17 connected easily, and they'll communicate 16 reliably with each other.

Requests can be 15 sent to any endpoint within the system, and 14 once verified, they can be sent through 13 multiple pathways simultaneously. This greatly 12 speeds up processes compared to a traditional 11 request/respond model which would only be 10 able to use one pathway at a time. With 9 a service like TIBCO messaging, you can 8 communicate across a wide variety of APIs, support 7 mobile and IoT devices, scale your messaging 6 service to your needs, and simplify application 5 development and adoption. Naturally, the 4 platform provides a secure messaging environment 3 as well, so you can rest assured that your 2 data is only shared between your own applications 1 for your specified purposes.

There is one main issue, and that is of 16 reliability. In distributed systems, sync 15 calls can fail of downstream system is getting 14 overloaded. Downstream systems all would 13 then need to be tuned to load coming from 12 upstream, which is impractical. Messaging 11 systems can take care of spikes. Even better 10 is to use load balancers in addition to 9 messaging system. While downstream application 8 is autoscaling up (which can take a few 7 minutes), the messaging system can take 6 care of reliably storing spikes. Also, messaging 5 system and do pub - sub reliably. Imagine 4 if there are thousands of trades coming 3 and to be dispatched to hundreds of traders.. easily 2 done with pub - sub. So operative word is 1 Reliability.

I would suggest to have a look on this blog 3 post . It shows the end to end workflow 2 and explains how we can integrate the messaging 1 platform programmatically.

https://eduwebmonster.com/implementing-message-based-communication-in-modern-application-architecture/