Agnostic services

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.

• Entity-centric business services are designed to provide a set of features that provide data management related only to their corresponding entities. They are therefore business process-agnostic. The same entity-centric business services can (and should) be reused by different process or task-centric business services.
• Application services ideally are built according to the utility service model. This makes them highly generic, reusable, and very much solution-agnostic. Different service-oriented solutions can (and should) reuse the same application services.

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.