A key aspect of delivering reusable services is that they introduce service layers that are not limited to a single processs or solution environment. It is important to highlight this one point, as it can blur the architectural boundary of a service-oriented solution.
An application-level SOA containing solution-agnostic services does, in fact, extend beyond the application. And, in the same manner, an application-level SOA that depends on the use of existing solution-agnostic services also does not have a well defined application boundary.
To expand on this point, let's take another look at those services more prone to providing reusable logic.
As shown in Figure 9.6, services can be process- and solution-agnostic while still being used as part of a service layer that connects different processes and solutions.
Figure 9.6. Services uniting previously isolated business processes and solution environments.
If the services you are delivering collectively represent the logic of an entire solution, then the architectural scope is essentially that of an application-level SOA. However, if you are building services that only extend an existing solution (or are being deployed with immediate reuse in mind), then the architectural scope can vary.
An enterprise that invests heavily in agnostic services easily can end up with an environment in which a great deal of reuse is leveraged. This is the point at which building service-oriented solutions can become more of a modeling exercise and less of an actual development project.
SUMMARY OF KEY POINTS