You can view part 1 of this series here.
Day two opened with an easy module on the bus and broker architectural styles. It was part history lesson and part rationale for what was coming next. Message brokers were an attempt to solve the enterprise software integration problem. The idea was to centralize integration concerns to make it easier to connect all your partners and internal systems. In time, they grew to become central repositories for business rules too. Much of that logic took the form of scripts — lots and lots of scripts. Unfortunately, all that code started to become a proverbial big ball of mud. It just didn’t work.
The bus architectural style, on the other hand, simply allows event sources and sinks to communicate. The bus is just a highway. It doesn’t attempt to route or centralize anything. There is no single point of failure. It is simple.
Unfortunately, the simplicity of the bus comes with a price; It is more difficult to design distributed solutions than centralized ones. I guess that’s why I am at the class.
The second module of the day introduced SOA and started to delve into the real challenges of distributed system design. Service are the technical authority for a specific business capability. All data and business rules reside within the service.
The most difficult aspect of distributed system design is figuring out what services you need. Udi illustrated this point by leading the class through an analysis of the Amazon.com home page. The idea was to figure out what services the home page used. I was surprised by just how many services were involved and how small some of them turned out to be. For example, one service was responsible for the product description and image, but there was another service for price.
The next interesting thing was the idea that a service is not just something you call. It actually extends across all layers of the application from GUI all the way to the data store. That means that the price service is responsible for displaying the price on the Amazon page. There can’t be a display page service because the price service isn’t willing to give control of its data to another service. How does it know that the display page service won’t change the price before displaying it?
The fact that each service owns its own data also challenges the notion that the system has to have one central database. If there is a central database, relational integrity rules cannot stretch across service boundaries. In fact, when you do services right, many of them, maybe even all of them, don’t need a database at all.
Udi’s heresy was shocking but attractive. How can we live without a central database for our systems? How can we live without database RI? Is it really OK to use something else for OLTP and just create a “real” database for OLAP later? Imagine how scalable the system can be once it is not tied to the big database in the middle. Imagine how much easier and less risky it becomes to roll out small, incremental changes when you don’t have to worry about updating the schema in the central database.
The day ended with a homework assignment to identify the service and messages involved in placing reservation and handling guests at the front desk of a hotel. At least at first glance, it didn’t look too hard. Stay tuned to find out how wrong I was.
You can view part 4 of this series here.
Tom Cabanski 