The primary goal of service-oriented architecture (SOA) is to align the business world with the world of information technology (IT) in a way that makes both more effective. SOA is about the business results that can be achieved from having better alignment between the business and IT.
SOA starts from the premise that all businesses have a business design. A business design describes how that business works — the processes that it performs; the organizational structure of the people and finances within that business; the business’ near-term and long-term goals and objectives; the economic and market influences that affect how that business achieves its goals; the rules and policies that condition how the business operates.
Most businesses have a written form of their high level business plan — the high level definition that states the business’ purpose. Few businesses, however, have a written form of their business design. Many of those who have documented their business design have trouble keeping their design up to date with what they actually practice. Business processes evolve as businesses respond to shifts in the marketplace, regulations, or product innovations; this evolution usually happens without reflecting those changes in the formal design of the business.
However, even if the business design has not been documented, or even if what is documented is now obsolete, there is nonetheless a business design in effect. A fundamental premise of SOA is that if the business design can be transcribed and maintained there is a potential for leveraging that captured design information.
Even if the business design is not used to communicate between the business and IT organizations, it can nonetheless be a valuable tool to help businesses understand what they are doing and how. Beyond that, however, the business design becomes an essential tool in communicating requirements between the business and the IT organization. The business can identify those elements of the design that should be automated and what within that design should be performed by people, creating a blueprint of the information systems that are created to support that automation.
By deriving the information system design from the business design you can more easily drive changes into the information system at the rate and pace of change in the business design. Furthermore, the information system can be used as a catalyst for change in the business design. It is from this correspondence that SOA delivers on the promise of more flexible businesses through more flexible IT.
This correspondence is represented as the SOA Lifecycle, in which the business process is modeled, assembled, deployed and monitored in an iterative manner. This transforms the information system from being one of merely a “cost of doing business” to a fundamental tool for enabling a business to be more competitive, profitable and responsive to changes in the marketplace.
To achieve this synergism between the business and IT domains we need to employ a number of capabilities:
A formalism and language for capturing the business design
A methodology for translating the business design into a set of information system artefacts to implement that design
An infrastructure for hosting those implementation artefacts that is as flexible to changes in its marketplace as the business itself needs to be
A place for retaining the correlation between the business design and the information system that can be used to identify and fix failures in executing on the goals and constraints of the business design
A means by which we can manage the system to ensure those goals are met.
These capabilities improve the flow of the business process through SOA Lifecycle iterations.
What is a “Service” in Service-Oriented Architecture?
We refer to the practice of deriving an information system design from a business design as service-oriented architecture. The business process and the tasks from which it is composed can be collectively thought of roughly as services. Thus, the business design is essentially a composition of services and the policies and conditions that must be applied to their use which form the information system design.
However, there remains the question of “what is a service?” Is it a function within an application? Are all application functions services? Does SOA include system services? Coming up with a single, mathematically precise definition that applies universally to all situations can be hugely complicated. In practice, such precision is not necessary to achieving value and success from SOA.
An underlying premise in the application of SOA to information technology is the principle of loose coupling — that is, avoiding or at least encapsulating temporal, technological and organizational constraints in the information system design. This same principle applies also to the definition of service — the rules used to define services in one context may not be applicable in another. What is important is that whatever definition we arrive at, it should originate from the primary concerns and constraints of that context. As a generalization, a service is a repeatable task within a business process. So, if you can identify your business processes, and within that, the set of tasks that you perform within the process, then you can claim that the tasks are services and the business process is a composition of services.
However, note that certain tasks can be decomposed into business processes in their own right. The order-entry process includes, among other things, a task to confirm availability of the items being ordered. The confirm-availability task is itself a business process that includes, for example, the tasks of checking the on-hand inventory, verifying the supply pipeline, and possibly creating a background request and determining its availability. Thus, business processes are themselves services; there is a principle of recursive decomposition implied in the term service. If taken far enough we could easily claim that everything is a service. This, obviously, is not useful — at some point treating everything as a service would yield an incredibly inefficient over-generalization of the problem space. You should exercise this principle of recursive decomposition only to the extent that you legitimately need flexibility within your business design.
From this definition of service, service-orientation is a way of integrating your business as a set of linked services. If you can define the services in each of your vertical and horizontal lines-of-business, you can begin to link those LOBs by composing their services into larger business processes. Likewise, you can decompose the main services of your LOBs into a set of more basic services that can then be easily recomposed either to change LOB processes, or to interlink your LOBs at a lower level of their capabilities. Similarly, you can use the same principles of composition to create links with your business partners to both automate those relationships and to gain more efficiency from them. One consequence of service orientation is flexibility: you gain the ability to iteratively optimize your business design, unhampered by inflexible IT structures.
A service-oriented architecture, then, is an architectural style for creating an Enterprise IT Architecture that exploits the principles of service-orientation to achieve a tighter relationship between the business and the information systems that support the busines.
Refrence :
Building Composite Applications
by Juan R. Rodriguez et al
