SOA, EDA and MPI.NET

I had another good question from Miguel, this time referring to my post on SOA and EDA where he asked whether distributed systems built using MPI.NET conform to the SOA or EDA style of architecture.

MPI.NET is a platform for building a single distributed application where different parts of the application run on different nodes within a cluster of machines. Often, the same program runs on different nodes, but takes on different roles on each node. The role each program instance takes on each node can be determined by a unique rank assigned by the MPI environment to each MPI process.

Messages can then be passed between different processes to coordinate their activities. Often the program detects if it is rank zero and if so takes on the "root" responsibility, handing data and control messages to the other nodes, coordinating their activities and aggregating their results.

The message exchange patterns offered by MPI.NET are point-to-point, all-to-one (gathering data), one-to-all (broadcast) and all-to-all. These message exchange patterns differ from the message exchange pattern inherent to EDA, publish-subscribe.

With publish-subscribe, systems subscribe to specific topics or topic specifications. Messages published onto a given topic are routed to all subscribers that have subscribed to a matching topic specification. Alternatively, subscriptions may be defined based on message content-based rules.

With MPI.NET, there are no subscriptions as such. Messages may be broadcasted to every node, which then decides whether the message is relevant. This is a subtle difference, and perhaps one might argue it represents a highly simplified form of EDA.

With regards to SOA, it is extremely bad practice for services to share the same business rules or data representation as it couples services too tightly. The fundamental principle of MPI.NET is that the same logic can/will run on multiple nodes. The purpose is quite different from SOA.

With MPI.NET, you are distributing execution of the same logic across multiple servers for the purpose of increasing performance. With SOA each service is responsible for its own logic, encapsulated behind its service boundary.

Furthermore, the number of nodes allocated in an MPI.NET application is dynamic by design. With SOA, each service has specific rules and responsibilities. The number of services cannot be dynamically increased or decreased.

Certainly within a service the number of nodes allocated to handle messages could be dynamically adjusted based on load. However, these nodes are not directly addressable. They are not visible to the consumers of the service.

Another difference is that MPI.NET nodes do not have the concept of endpoints. One cannot deliver messages to an MPI.NET node across a variety of different bindings via different endpoints.

MPI.NET should be seen as a way to implementing a single service internally across multiple machines for the purpose of improving performance.

I would say therefore that MPI.NET is not a platform for implementing SOA. It could be considered as supporting the EDA style of architecture, but only in a very simplistic sense.

SOA and EDA

So far I've posted a large amount of material on SOA, pushing very heavily for an event driven approach - with specific attention to business services, where business-relevant events are surfaced as event messages published over a service bus.

There has been an ongoing discussion in the public forum around the relationship between SOA and EDA (Event Driven Architecture). Are they in fact separate architectural styles? Are they separate concerns? Do they complement each other? Does SOA subsume EDA?

SOA and EDA are in fact separate architectural styles. However they describe different concerns of an architecture. They each bring their own benefits. As such, it is possible (and in fact good practice) for the two styles to overlap. An architecture can indeed both be service oriented and event driven. Likewise it is possible for an architecture to be service oriented but not event driven, or event driven and not service oriented. This is illustrated below.


An architecture consisting of services with no endpoints with a publish-subscribe binding conforms to the service oriented style of architecture, but is not event driven. An architecture consisting of messages published over topics, but where there is no notion of services is event driven, but not service oriented. For example, EAI can be achieved by having a number of applications publishing and subscribing over a set of topics, without explicitly defining any services, endpoints or service contracts.

Where SOA and EDA come together, a topic corresponds to a specific endpoint of a specific service. A topic cannot be shared between endpoints or services, and messages published onto a topic must conform to an explicitly defined service contract. SOA brings benefits to EDA and vice versa. Therefore we get the best result when the two architectural styles are combined.