Pulsar

Apache Pulsar

Beam Capability Matrix

Beam Capability Matrix

RocketMQ

RocketMQ

Delivery Patterns

• At-Most-Once : Messages may be lost, least desirable
• At-Least-Once : Messages may be redelivered - no loss but may include duplicates
• Exactly-Once : Messages are delivered once and only once - no loss and no duplicates, but difficult to guarantee

In order to manage state, messages may be stored in an embedded key-value store, a distributed file system, or use a higher level of abstraction.

Solace

Solace

Alternatives to Kafka

Kinesis
RabbitMQ
ZeroMQ
Kudu
Storm
Samza
SQS
Redis
Aeron
MAPR Streams

Kafka for Beginners
Confluent

One must make note that Storm and Samza can in fact be used along side Kafka in a data pipeline. It is the context of how one plans to use a platform, invariably dictated by the given constraints of the problem at hand, which may be in form of either batch or real-time streams for that matter.

Asynchronous Communication Approaches

asynchronous communication in soa/msa

Mule In Perspective

Service Oriented Architectures are big step towards integration of disparate systems. However, over time the approach of Web Services have branched out from SOAP to REST. There have also emerged many integration approaches from component to mediators as well as full enterprise service bus. Almost every software engineering area has a significant set of design patterns in which to approach large scale solutions. Mule has over the years become a strong contender in the enterprise service bus area. It provides a very open and holistic approach to integration, facilitated by connectors as well as a visual flow mechanisms. However, the platform does have its many quirks and drawbacks that leaves one wondering whether quality assurance was compromised over the sake of releases. The visual flow mechanism is also a very buggy and limiting perspective for a developer who may want to directly utilize XML to gain flexibility. Also, even their training course instructors dispel many truths to significant buggy areas of the platform especially within the Mule Studio. One has to really get their head around the whole idea of visual flows and how to wire them in the most optimized and efficient way. Using Mule most likely will also lead to vendor lock in as well as complexities when it comes to upgrading versions from which backward compatibility of flow components can only be left as questionable. These days one rarely has a full need for such heavy weight enterprise service bus within enterprise architectures. Often using mediators and such can be sufficient. Loose coupling is paramount for service oriented delivery of business applications. However, using Mule one could question whether loose coupling comes at a cost of excessive XML and rigid methods in implementation. These days even integration services provide for multiple forms of functionality towards the full Big Data support for ETL. Although, Mule does support batch processing, one could argue that such implementations should really be separate from the use of ESB. Alternatives, that can provide for a more flexible option for integration include Camel in comparison to Mule, even if they strictly speaking cater to different functional domains. Utilizing Mule in new projects and within large teams could require an investment in time. But, one is always left wondering whether using such a technology is perhaps just over engineering on the problem which can better be solved through more loosely coupled approaches and even a wide range of open source libraries.