Characteristics of a service - SOA Service Oriented Architecture

Characteristics of a service - SOA Service Oriented Architecture

Another way to understand Service Oriented Architecture SOA is by looking at it from the perspective of the characteristics of its services. Consider these factors as you evaluate whether the services you define adhere to Service Oriented Architecture SOA principles:

Services should be meaningful. Ideally, you'll design services to meet business requirements as well as functional requirements. These services should be at an appropriate level of granularity tailored to their location in the architecture. (We'll discuss granularity in more detail in a later section.)

Services should be contract-based. The service itself is implemented with the clear understanding that it is fulfilling a set of obligations that are expressed in a contract that is shared between the service provider and the service consumer. As a result, service's consumer can better understand what it must provide to that service and what that service will provide in return. This is more than a definition of operations on a service, but it also should include the semantics of how the service is used. The contract should include specific policies that define who may access the services, what service levels might be expected, etc.

Services should be self-contained and modular. Services should be able to stand on their own with few dependencies. Where dependencies exist to other application functionality or other services, access should be as loosely coupled as possible. In addition, much like you would define an object in object-oriented analysis, services should be cohesive. They should have a single cohesive purpose for existing and a clear definition of the scope of what the service does. If done properly, services will be composable, meaning that several services may be leveraged and composed to create new applications or services with minimal additional programming.

Services should be loosely coupled. This has two key implications. First, the service interface or contract should be independent of the implementation or application code used to fulfill service requests. Second, the contract should not expose any assumptions about the language or data representations used to implement the service request. In this way, service consumers aren't forced to process data types that may not be native to the language used to implement the consumer.

Services should be location-independent. Don't build assumptions into service providers or consumers as to the physical location of the service. This enables flexibility in moving where the service is hosted, routing requests to multiple instances of the service, or even substituting a different service implementation that might adhere to the same service contract. Instead, the Service Oriented Architecture SOA should leverage a service repository or registry where services can register themselves and where consumers can go to locate a service instance. (For more on registries, see The importance of a registry for a service-oriented architecture.)

Services should utilize models. One of the significant characteristics of an Service Oriented Architecture SOA is that services express themselves as models. Models define service capabilities and attributes as well as describe relationships between services. Models can also be used to describe the data being exchanged. This approach is powerful because models make it possible to transform data so that service consumers aren't necessarily bound to the data definitions exposed by the service provider. This freedom gives an Service Oriented Architecture SOA its ability to adapt and to enable rapid composition of services.