[Article] EDA: SOA through the looking glass
Tuesday, September 29th, 2009.My latest article has been published in issue 21 of the Microsoft Architecture Journal:
EDA: SOA Through The Looking Glass
Business events create natural temporal boundaries across which there is no business expectation of immediate consistency or confirmation. When they are mapped to technical solutions, the loosely coupled business domains on either side of business events simply result in autonomous, loosely coupled services whose contracts explicitly reflect the inherent publish/subscribe nature of the business.
This article will describe how all of these concepts fit together, as well as how they solve thorny issues such as high availability and fault tolerance.
UPDATE: Unfortunately, Microsoft has removed a bunch of their older stuff, so I’m reposting the content here:
Introduction
While event-driven architecture (EDA) is a broadly known topic, both giving up ACID integrity guarantees and introducing eventual consistency make many architects uncomfortable. Yet it is exactly these properties that can direct architectural efforts toward identifying coarsely grained business-service boundaries—services that will result in true IT-business alignment.
Business events create natural temporal boundaries across which there is no business expectation of immediate consistency or confirmation. When they are mapped to technical solutions, the loosely coupled business domains on either side of business events simply result in autonomous, loosely coupled services whose contracts explicitly reflect the inherent publish/subscribe nature of the business.
This article will describe how all of these concepts fit together, as well as how they solve thorny issues such as high availability and fault tolerance.
Commands and Events
To understand the difference in nature between “classic” service- oriented architecture (SOA) and event-driven architecture (EDA), we must examine their building blocks: the command in SOA, and the event in EDA.
In the commonly used request/response communication pattern of service consumer to service provider in SOA, the request contains the action that the consumer wants to have performed (the command), and the response contains either the outcome of the action or some reaction to the expressed request, such as “action performed” and “not authorized.”
Commands are often named in imperative, present-tense form—for example, “update customer” and “cancel order.”
In EDA, the connection between event emitters and event consumers is reversed from the previously described SOA pattern. Consumers do not initiate communication in EDA; instead, they receive events that are produced by emitters. The communication is also inherently unidirectional; emitters do not depend on any response from consumers to continue performing their work.
Events are often named in passive, past-tense form—for example, “customer updated” and “order cancelled”—and can represent state changes in the domain of the emitter.
Events can be thought of as mirror images of the commands in a system. However, there might be cases in which the trigger for an event is not an explicit command, but something like a timeout.
Business Processes with Commands and Events
The difference between commands and events becomes even more pronounced as we look at each one as the building block in various business processes.
When we consider commands such as “create customer” and “create order,” we can easily understand how these commands can be combined to create more involved scenarios, such as: “When creating an order, if a customer is not provided, create a new customer.” This can be visualized as services that operate at different layers, as shown in Figure 1.
.png)
Figure 1. Commands and service orchestration
One can also understand the justification for having activity services perform all of their work transactionally, thus requiring one service to flow its transactional context into other lower-level services. This is especially important for commands that deal with the updating of data.
When working with commands, in each step of the business process, a higher-level service orchestrates the work of lower-level services.
When we try to translate this kind of orchestration behavior into events, we must consider the fact that events behave as mirror images of commands and represent our rules by using the past tense.
Instead of: “When creating an order, if a customer is not provided, create a new customer.”
We have: “When an order has been created, if a customer was not provided, create a new customer.”
It is clear that these rules are not equivalent. The first rule implies that an order should not be created unless a customer—whether provided or new—is associated with it. The second rule implies that an order can be created even if a customer has not been provided—stipulating the creation as a separate and additional activity.
To make use of EDA, it is becoming clear that we must think about our rules and processes in an event-driven way, as well as how that affects the way in which we structure and store our data.
Event-Driven Business Analysis and Database Design
When we analyze the “When an order has been created, if a customer was not provided, create a new customer” rule, we can see that a clear temporal boundary splits it up into two parts. In a system that has this rule, what we will see is that at a given point in time, an order might exist that does not have a corresponding customer. The rule also states the action that should be taken in such a scenario: the creation of a new customer. There might also be a nonfunctional requirement that states the maximum time that should be allowed for the action to be completed.
From a technical/database perspective, it might appear that we have allowed our data to get into an inconsistent state; however, that is only if we had modeled our database so that the Orders table had a non-nullable column that contained CustomerId—a foreign key to the Customers table. While such an entity-relationship design would be considered perfectly acceptable, we should consider how appropriate it really is, given the requirements of business consistency.
The rule itself indicates the business perspective of consistency; an order that has no connection to a customer is valid, for a certain period of time. Eventually, the business would like a customer to be affiliated with that order; however, the time frame around that can be strict (to a level of seconds) or quite lax (to a level of hours or days). It is also understandable that the business might want to change these time frames in cases in which it might provide a strategic advantage. An entity-relationship design that would reflect these realities would likely have a separate mapping table that connected Orders to Customers—leaving the Orders entity free of any constraint that relates to the Customers entity.
That is the important thing to understand about eventual consistency: It starts by identifying the business elements that do not have to be 100-percent, up-to-the-millisecond consistent, and then reflecting those relaxed constraints in the technical design.
In this case, we could even go so far as to have each of these transactions occur in its own database, as shown in Figure 2.
.png)
Figure 2. Event-driven data flows
Benefits of Event-Driven Architecture
Given that EDA requires a rethinking of the core rules and processes of our business, the benefits of the approach must be quite substantial to make the effort worthwhile— and, indeed, they are. By looking at Figure 2, we can see very loose coupling between the two sides of the temporal boundary. Other than the structure of the event that passes from left to right, nothing is shared. Not only that, but after the event is published, the publisher no longer even needs to be online for the subscriber to process the event, so long as we use a durable transport (such as a queue).
These benefits become even more pronounced when we consider integration with other systems. Consider the case in which we want to integrate with a CRM, whether it is onsite or hosted in the cloud. In the EDA approach, if the CRM is unavailable (for whatever reason), the order will still be accepted. Contrasting this with the classic command- oriented service-composition approach, we would see there that the unavailability of the CRM would cause the entire transaction to time out and roll back. The same is true during integration of mainframes and other constrained resources: Even when they are online, they can process only N concurrent transactions (see Figure 3). Because the event publisher does not need to wait for confirmation from any subscriber, any transactions beyond those that are currently being processed by the mainframe wait patiently in the queue, without any adverse impact on the performance of order processing.
.png)
Figure 3. Load-leveling effect of queues between publishers and subscribers
If all systems had to wait for confirmation from one another—as is common in the command-oriented approach—to bring one system to a level of 5 nines of availability, all of the systems that it calls would need to have the same level of availability (as would the systems that they call, recursively). While the investment in infrastructure might have business justification for one system (for example, order processing), it can be ruinous to have to multiply that level of investment across the board for nonstrategic systems (for example, shipping and billing).
In companies that are undergoing mergers or acquisitions, the ability to add a new subscriber quickly to any number of events from multiple publishers without having to change any code in those publishers is a big win (see Figure 4). This helps maintain stability of the core environment, while iteratively rolling out bridges between the systems of the two companies. When we look practically at bringing the new subscriber online, we can take the recording of all published events from the audit log and play them to the new subscriber, or perform the regular ETL style of data migration from one subscriber to another.
.png)
Figure 4. Adding new subscriber to existing publisher
IT-Business Alignment, SOA, and EDA
One of the more profound benefits that SOA was supposed to bring was an improved alignment between IT and business. While the industry does not appear to have settled on how this exactly is supposed to occur, there is broad agreement that IT is currently not aligned with business. Often, this is described under the title of application “silos.”
To understand the core problem, let us try to visualize this lack of alignment, as shown in Figure 5.
.png)
Figure 5. Lack of IT/Business Alignment
What we see in this lack of alignment is that IT boundaries are different from business boundaries, so that it is understandable that the focus of SOA on explicit boundaries (from the four tenets of service orientation) would lead many to believe that it is the solution.
Yet the problem that we see here is while there are explicit technical boundaries between App 1 and App 2, the mapping to business boundaries is wrong.
If SOA is to have any chance of improving IT-business alignment, the connection between the two needs to look more like the one that is shown in Figure 6.
.png)
Figure 6. Services aligned with business boundaries
One could describe such a connection as a service “owning” or being responsible for a single business domain, so that anything outside the service could not perform any actions that relate to that domain. Also, any and all data that relates to that domain also would be accessible only within the service. The EDA model that we saw earlier enabled exactly that kind of strict separation and ownership— all the while, providing mechanisms for interaction and collaboration.
We should consider this strong connection when we look at rules such as: “When an order has been created, if a customer was not provided, create a new customer.” The creation of the order as an object or a row in a database has no significance in the business domain. From a business perspective, it could be the acceptance or the authorization of an order that matters.
What SOA brings to EDA in terms of IT-business alignment is the necessity of events to represent meaningful business occurrences.
For example, instead of thinking of an entity that is being deleted as an event, you should look for the business scenario around it— for example, a product that is being discontinued, a discount that is being revoked, or a shipment that is being canceled. Consider introducing a meaningful business status to your entities, instead of the technically common “deleted” column. While the business domain of sales will probably not be very interested in discontinued products and might treat them as deleted, the support domain might need to continue troubleshooting the problems that clients have with those products—for a while, at least. Modern-day collaborative business- analysis methodologies such as value networks can help identify these domains and the event flows between them.
What an EDA/SOA Service Looks Like
In the context of combined EDA and SOA, the word “service” is equivalent to a logical “thing” that can have a database schema, Web Services, and even user-interface (UI) code inside it. This is a very different perspective from the classic approach that considers services as just another layer of the architecture. In this context, services cut across multiple layers, as shown in Figure 7.
.png)
Figure 7. Services logically connecting code from different layers
In this model, the processes that are running on various computers serve as generic, composite hosts of service code and have no real logical “meat” to them.
When we look at the code in each of the layers in light of the business domain that it addresses, we tend to see fairly tight coupling between a screen, its logic, and the data that it shows. The places in which we see loose coupling is between screens, logic, and data from different business domains; there is hardly any coupling (if at all) between the screen that shows employee details and the one that is used to cancel an order. The fact that both are screens and are categorized in the UI “layer” appears not to have much technical significance (if any business significance). Much the same can be said for the code that hooks those screens to the data, as well as the data structures themselves.
Any consistency concerns that might have arisen by this separation have already been addressed by the business acceptance of eventual consistency. If there are business demands that two pieces of data that have been allocated to different services always be consistent, this indicates that service boundaries are not aligned with business boundaries and must be changed.
This is extremely valuable. Architects can explain to the business the ramifications of their architectural decisions in ways that the business can understand—“There might be a couple of seconds during which these two bits of data are not in sync. Is that a problem?”—and the answer to those kinds of question is used to iterate the architecture, so as to bring it into better alignment with the business.
As soon as service boundaries reflect business boundaries, there is great flexibility within each service; each can change its own database schema without having to worry about breaking other services, or even choose to change vendors and technology to such things as object or XML databases. Interoperability between services is a question of how event structures are represented, as well as how publish/subscribe is handled. This can be done by using basic enterprise service bus (ESB) functionality, such things as the Atom Publishing Protocol, or a mix.
Integration of legacy applications in this environment occurs within the context of a service, instead of identifying them as services in their own right. Use of Web Services to ease the cost of integration continues to make sense; however, from the perspective of a business domain, it really is nothing more than an implementation detail.
Conclusion
EDA is not a technical panacea to Web Services–centric architectures. In fact, attempting to employ EDA principles on purely technical domains that implement command-centric business analysis will almost certainly fail. The introduction of eventual consistency without the ratification of business stakeholders is poorly advised.
However, if in the process of architecture we work collaboratively with the business, map out the natural boundaries that are inherent in the organization and the way in which it works, and align the boundaries of our services to them, we will find that the benefits of EDA bring substantial gains to the business in terms of greater flexibility and shorter times to market, while its apparent disadvantages become addressed in terms of additional entity statuses and finer-grained events.
By itself, EDA ignores the IT-business alignment of SOA—so critical to getting boundaries and events right. Classic SOA has largely ignored the rock-solid foundation of publish/subscribe events—dead Web Services eventing and notification standards notwithstanding. It is only in the fusing of these two approaches that they overcome the weaknesses of each other and create a whole that is greater than the sum of its parts.
Interestingly enough, even though we have almost literally turned the classic command-driven services on their heads, the service- oriented tenets of autonomy and explicit boundaries have only become more pronounced, and the goal of IT-business alignment is now within our grasp.
Beyond just being a sound theoretical foundation, this architecture has weathered the trials of production in domains such as finance, travel and hospitality, aerospace, and many others—each with its own challenging constraints and nonfunctional demands. Organizations have maximized the effectiveness of their development teams by structuring them in accordance with these same service boundaries, instead of the more common technical specialization that corresponds to layered architectures. These loosely coupled service teams were able to wring the most out of their agile methodologies, as competition for specialized shared resources was eliminated.
Oracle once named this approach SOA 2.0. Maybe it really is the next evolutionary step.
If you liked this article, you might also like articles in these categories: ![]() I've gone through the hundreds of articles I've written over the past 6 years and put together a list of the best ones as ranked by my 5000+ readers. You won't be disappointed. ![]() Subscribe right here. ![]() Something on your mind? Got a question? I'd be thrilled to hear it. Leave a comment below or email me, whatever works for you. 9 CommentsYour comment... |
September 30th, 2009 at 3:23 am
Nice piece. Bill Poole blogged along the same lines too. As an added benefit to Business / IT alignment, this is a view of SOA that seems to put some sanity into SOA solution development because coarser grained services allows us to better leverage OO and DDD.
I have always felt that command-based layered service architecture, as advocated by Thomas Erl and others, will ultimately impede enterprise agility by increasing the cost and risk of change.
Hugh Taylor published a book on SOA and EDA this year, I haven’t read it yet, but the TOC suggests it supports and elaborates on the same arguments.
Is it possible that we’re witnessing a maturer SOA being born? Something that will finally removes Fowler’s (A)mbiguity from SO(A). Should we give it its own name? Perhaps EDSOA, or maybe SOEDA!
Ameer
September 30th, 2009 at 12:04 pm
Ameer,
Glad you liked it. I share your hope for a more viable SOA/EDA approach that will gain broad industry adoption.
September 30th, 2009 at 5:52 pm
What timing! I just delivered this presentation to a government info sharing conference: http://www.slideshare.net/cdeweese/integrating-systems-with-niem-using-soa
EDA has been milling around my head for a few months now and it clicked. I think I get it and the more I conceptualize about systems and problems I’m having I see a good fit for EDA. EDA is a much better model for the real-world, a cleaner abstraction because things don’t happen request-response or in the order you want them to. The last 35 minutes of my presentation was Q&A and there were several people doing SOA implementations saying the same thing – when you conceptualize things in events it’s a better model. You can account for all kinds of things you couldn’t before, including time. Which, in justice & LE is ever prevalent.
There must be some sort of awesome EDA energy lighting up the web because the more people I talk to the more sense it makes. I’ve got a long way to go, but the gears are turnin.
Keep up the great work man, it’s shaping thoughts to a better way to deal with the real-world and align business with IT!
October 2nd, 2009 at 4:35 am
Great article! One question:
Continuing with your example of an order service and a customer service – who would hold the ordercustomer data? If a requirment was for a list of orders with associated customers to be printed (or used for some other purpose), would the printing service simply request data from both services or would this be pre-cached by listening for order and customer events?
October 3rd, 2009 at 12:35 pm
Chris,
Synchronicities abound 🙂
October 3rd, 2009 at 12:38 pm
Olav,
Glad you liked the article. To your question:
> Who would hold the ordercustomer data?
The sales service would hold the order data indexed by customer Id.
Printing isn’t a service and can be thought of as a physical endpoint on which multiple services can run – each contributing the part of the data it owns.
As a goal, we should see services not requiring each others data beyond just IDs.
Does that answer your question?
October 5th, 2009 at 1:33 am
I think i focused too much on data types instead of business meaning – i had my mind set on a many to many relation with meaning to both sides. It makes perfect sense that the “Sales” service would hold the order->customer information. Thinking about it, such info would not fit very well in the Customer service 🙂
I’m not quite sure i understand the second part of your answer. Could a concrete implementetion be two services each collecting data and storing this in a common database from where reports could be generated and printed?
October 5th, 2009 at 5:27 am
Olav,
About the printing – no, there wouldn’t need to be a common database. Both services would be involved in the printing, as well as another layout service.
Hope that makes sense.
October 5th, 2009 at 6:20 am
It does – thank you for taking the time 🙂