Service oriented architectures (SOAs) are about reuse. The goal of a service-oriented architecture is to build applications using modules that (1) look like network services, (2) are potentially very far away and (3) perhaps owned by someone else. There are some significant benefits to be had including reduced hardware expenses, fewer systems to operate and maintain, and better software reuse. All of these benefits come at the expense of significantly increased complexity. Let's see why.
The two figures to the right show schematically what can happen to add this complexity. The first figure shows five applications with their modules all operating independently. Changes to the yellow application have little impact on the operation and behavior of the other applications.
The second figure shows a similar set of applications that are interdependent because of module sharing. This is more of a problem than simply sharing beans in an EJB application where the application will be built, tested, and maintained separately. Here, because we're sharing services, rather than just code, the operation of many modules affect the overall operation of many applications. For example, the failure of the purple module in this scenario can cause all five applications to fail.
There are basically three problems:
- No one team understands or controls all the moving parts. Problems have much wider impact. As the second schematic shows, there is a big ripple effect for service failures, increased latency, security lapses, and so on.
- Change management is more complex. Parts need to be added, upgraded, fixed, and replaced on the fly with no external impact. In an SOA, expected level of service can change after its put into production. For example, we may put a module into service and then increase its expected service level when it is incorporated into a new, mission critical application.
Web service intermediaries are attempting to solve some of these problems, but there is still little corporate experience with these issues on a large-scale basis and little "best practice" information is available to help companies plan for a move to an SOA.