SOA Principles
In this SOA article, we will focus on some of the core principles of Service Oriented Architecture viz service abstraction, service reusability, service composability, service autonomy, service optimization, service discoverability, service-orientation and interoperability, standardized service contract.
Service Abstraction
Abstraction is also known under its full name as service interface level abstraction. It is this principle that allows us to establish services as black boxes, hiding their underlying details from potential customers. Abstraction is achieved through a utilization of service contracts. Through limiting what is made public about a service to what is documented in the service contract, a high level of separation can often be attained between what emerges as public and private. This is because of the fact that it is supportive of loosely coupled relationships.
The amount of logic that a service may represent is indeed limitless. Services can be designed to perform simple tasks. They may also be positioned to serve as gateways to entire automation solutions. There is no restriction when it comes to the source of automation logic a service is able to draw upon. A single service, for instance, may expose logic from several different underlying systems.
As the standardization of service models is something that is moved towards as a means of establishing functional contexts associated with given business tasks or entities, it becomes a given that in environments that have a number of different legacy solutions, at least one service will commonly expose functionality that relies on a number of different systems.
Distributed platforms provide service interface level abstraction as one of its main qualities. Distributed platforms also provide web services based architectures. The utilization of web services can be especially synergetic owing to the fact that they elevate the degree of attainable abstraction beyond functionality. Web services abstract proprietary implementation details of the automation logic that lies beneath the service. This effectively frees up potential consumers of the service from the strain of having to interface with particular vendor technologies.
Despite the fact that abstraction can be viewed as a service characteristic, in truth it is the individual operations that work to collectively abstract the service’s underlying logic. Services merely perform as containers for such operations. Any service’s given level of abstraction will thus be determined to a large degree by the collective levels of abstraction that are acquired by each of its service operations.
Service Reusability
One of the most vital principles of Service Oriented Architecture is service reusability. And in this day and age, it can be said that we have been making a lot of progress towards improving both this central tenet and Service Oriented Architecture in general. One sign that a significant degree of progress in the field has been made is the fact that more and more questions regarding Service Oriented Architecture these days are aimed at the architecture itself, rather than infrastructure and implementation.
One question that has come up in recent years is: Should all services be reusable? This question has a deceptively simple answer. Since it is one of the tenets of Service Oriented Architecture to build services that are reusable, then indeed all of them should be, right? But upon further examination, finding an answer to this question may require greater demands of subtlety – as well as deeper thinking in architectural terms.
Service Composability
The principle of Service Oriented Architecture known as service composability can be broken up in to two basic principles: service discoverability and service composition. When it comes to the realm of service design, a lot of attention is paid to the enabling of those characteristics that are so commonly associated with Service Oriented Architecture marketing – reuse and loose coupling. While these two aspects are undoubtedly vital, indeed critical to the attainment of long-term Service Oriented Architecture transition projects, there is a lot more that should be taken in to consideration.
While we have discussed in earlier articles how abstraction can be utilized to support the realization of loosely coupled, reusable services, we have to confront the fact that even the services that are most reusable will not be useful if they cannot be found by those who are responsible for the creation of potential clients. What is more, even loosely coupled services will not have a great deal of reuse potential if they are not able to be assembled in to compositions in an effective fashion. Thus, it is vital to take in to consideration the principles of service composition and service discoverability.
Service Autonomy
As businesses continue to step up the process of constructing enterprise automation logic in the service format, there is also an increasing need to step up both the efficiency and reliability that the services are intended to take on at run time. This dire need is increased when it comes time to assemble a service inventory with a vast quantity of reusable services.
Service Optimization
The principle of optimization states that high quality services should always be employed rather than low quality ones.
Service Discoverability
Service discoverability is meant to help one avoid the accidental creation of services that are either redundant or implement logic that is redundant. Owing to the fact that each particular service operation is meant to provide a potentially reusable piece of automation logic, metadata that comes attached to a service must describe not only the service’s overall purpose in an efficient manner, but also the functionality that its individual operations offer.
This particular principle of service orientation is similar to discoverability on the level of architecture, in which case the term “service discoverability” is meant to refer to the technology architecture’s ability to provide a mechanism of discovery, for example a service directory or registry. Such extensions effectively become part of the overall infrastructure that is meant to support the implementation of a Service Oriented Architecture.
On the level of service, the discoverability principle can be referred to the design of an individual service so that it becomes as discoverable as possible – no matter whether the discoverability extension or product actually exists in the surrounding implementation environment. The reason behind this is that even if there is no need for a service registry owing to the fact that there is not enough of a service inventory to warrant the need for one, services should consistently be designed as resources that are highly discoverable in some fashion. By doing so, the evolutionary governance off those services can be better managed when the service portfolio increases in size, as each service will then be equipped with the metadata that is required to properly communicate its capabilities and meaning.
Service-Orientation and Interoperability
Interoperability refers to the process whereby people, systems, and data are connected. The word interoperability can be viewed in a broad way, or a more technical way. It may take in to account software procedures, but also social and political meaning. One definition of interoperability considers it as the ability of several systems or components to exchange data and to utilize the data that has been exchanged. In the field of telecommunications, interoperability has a twofold definition.
It is first thought of as the ability of forces, systems, or units to provide services while also accepting services from other systems, forces, or units, and to utilize services exchanged as a means of enabling them to effectively operate together. The other half of the definition of interoperability refers to the condition that is attained among electronics and communications systems or items of such equipment when services or data can be exchanged directly between them and their users. The amount of interoperability must be defined when referring to particular cases.
In the case of two-way radio, interoperability consists of three dimensions. One is devoted to scalable capacity; another to compatible communications paths, such as equipment, signaling, and compatible frequencies; and a third is devoted to radio system coverage or adequate signal strength.
Standardized Service Contract
Standardized service contracts are one of the key Service Oriented Architecture principles. They ensure that services that are in the same inventory of services are kept in compliance with contract design standards. The services in a Service Oriented Architecture are able to delineate their capabilities and overall purpose in the form of a service contract. The standardized service contract principle basically requires that specific considerations be taken in to account when a service’s public technical interface is being designed. It simultaneously assesses the nature and quantity of content that shall be published as part of the service’s official contract.
A lot of emphasis tends to be placed on particular components of service design. This includes the way that the services express their functionality, how policies are to be attached and asserted, as well as the way in which data types and models are to be defined.
A constant focus on ensuring the optimization of service contracts should be maintained. The service contract should also maintain granularity and be standardized in a way that ensures that endpoints established by services shall be governable, consistent, and reliable. A service contract is an attribute of service-oriented architecture that stipulates services in the form of a communications agreement that will be defined collectively by one or several service description documents.
