Key SOA service oriented architecture principles

Key SOA service oriented architecture principles

Several key principles can guide you as you plan to create an service oriented architecture SOA-based solution. First, remember this: When you begin applying service oriented architecture SOA principles, always do so with an eye toward a specific business domain. For example, in the above illustration, our domain was banking. When we design the services in this example, we'd typically design them to apply to this specific domain. But in some cases, the services will be useful in other domains as well.

Now let's look at the principles of designing an architecture by layers—evaluating the traits of services, and choosing the appropriate level of granularity for each service.

The architecture layers

When designing an architecture using service oriented principles, keep in mind that there are several key layers to the architecture. Each of these layers serves an important purpose. These layers are:

Service enablement: We can consider this first layer as the foundational layer. Many of the key services for the particular domain live here. In our example above, this is where we'll find services such as the checking account service, customer vault service, etc. Some of the enabling capabilities may exist here as well, such as application servers, management services, etc. But note that we don't really have an service oriented architecture SOA if we stop here. Instead, we may have a collection of loosely coupled components. In fact, it may be that these services aren't even loosely coupled. At this level, it may be tempting to simply build out applications using point-to-point connections to these services. Indeed, this is the way many web services applications have been built to date.

Service architecture: When we move to this next level, we can begin to realize the value of an architecture that is service oriented. Here, we'd include many of the architectural services that may be required for any service oriented architecture SOA-based solution. These are key services (discovery, transformation, security, orchestration, messaging and integration) that other services within the solution can depend on. We may also have some domain-specific services here that the other services can leverage. In the case of our banking domain example, such a leverage-able service might include an auditing service, important in banking because regulations require that all transactions are available for audit.

Service model: In this final layer, we can realize the real power of the service oriented architecture SOA approach. Here, we can begin describing the various services and their relationship to each other in terms of a model that can be stored, exchanged, and used to automate interactions, facilitate the creation of orchestrated services, and so on. This is also where we can begin to describe the relationship of services at the functional level to services as they may be understood by business entities that care more about service levels and semantics of the interactions than they care about which the language the service was implemented in or what business logic was written to realize the service. This is a significant part of service oriented architecture SOA because it allows us to use the same services while creating different models to define different service relationships for different domains or solutions.