The third master class: Loosely Coupled Business Systems: SOA on the Microsoft platform
Udi Dahan - The Software Simplist had been hired to present the third LEAP master class in Oslo. He is an well known international expert on enterprise software architecture and design, and is the author of the open source messaging framework nServiceBus.
The entire class was based on discussion and interaction with the audience, and the only Power Point slide used was the one showing the agenda.
He started out with sketching a naive traditional n-tier application (big ball of mud), and based on suggestions from the audience we explored different solutions which might improve the solution. Whatever suggestions we threw at him, he always had a thoroughly considered answer describing pros and cons with the suggested solution. He obviously has a lot of experience with real world enterprise SOA applications.
The goal was to create autonomous services - standalone services with loose coupling to other services. The system should be scalable and reliable and use as few resources as possible.
Topics discussed
Coupling
- Avoid coupling by slicing independent logic into separate vertical autonomous boundaries / services
- Example of services: Order, inventory management, billing, shipping
- How should services communicate with each other?
Where to put the orchestration/workflow logic?
- Layer on top of the business layer components?
- In an Enterprise Service Bus on the side of the services?
- In the GUI?
When to use...
- Fire and forget
- Messaging (async / synchronous)
- Events
Duplicate data in order to remove dependencies and keep services autonomous?
- How to synchronize the data?
- Publish / subscribe pattern can be used. E.g. when an address is updated in the customer service, the customer service can publish the updated address.
- Context of the update is important. Why did the change happen? This is information which is available close to the user and the business process (i.e. NOT at the data base tier), and is usually triggered from the UI.
- Versioning - published events have to be backwards compatible with subscribers
- Duplication of data is usually considered a bad practice, but for SOA it may have advantages:
- Avoid service calls (e.g. retrieve customer address RPC style when needed)
- Services become more reliable and autonomous. What if the customer service is down? The the shipment service won't be able to do it's work since the address can't be retrieved.
- The duplicated data can be considered a local cache for the service
Publish/subscribe vs. request/response
- Doesn't both solutions create dependencies between services?
- Request/response creates design-time dependencies
- Pub/sub makes it possible to create services which are both design-time and run-time autonomous
- Run-time autonomous: Will continue to work even when other services goes down
- Design-time autonomous: Has no direct references to other services
- Pub/sub advantages:
- Better performance
- Local cache (duplicated data) in each service
- No blocking transactions across service boundaries
- Easier to run processes in parallel - scales better
- Fire and forget gives faster response in the UI
- Better resource utilization
- Messages can be queued up and processed when resources get available
- Pub/sub disadvantages:
- Systems might be harder to design correctly (requires untraditional thinking)
- Systems get harder to understand and debug
- Request/response advantages:
- Explicit service calls / dependencies makes the system easier to implement, understand and debug
- Request/response disadvantages:
- Synchronous blocking architecture requires more resources
- Ties up more resources over longer time periods, ie. the system will not scale well.
- Choose the right architecture for the right place, there is no silver bullet.
Achieving autonomous services by letting each service have it's own UI
Consider a shipment service which requires a shipment address. The traditional design would be to let the shipment service call the customer service. Another option would be to let the shipment service collect the shipment address through it's own GUI, and thus keeping the service autonomous.
Etiketter: LEAP, SOA