Introduction to SOA and Web services for IT
The exact origin of the SOA style of design is unknown. Gartner Group used the term service-oriented architectures in 1997 when describing an architectural principle in order to enable CORBA and DCOM programming model coexistence in the enterprise. The Object Management Group designed CORBA as a set of services. Still, no undisputable inventor of SOA has emerged. The absence of a clear creator of the SOA design style may be attributed to the natural maturing of architectural styles. The computing industry has seen an evolution of design styles for over forty years.
Regardless of the exact origin, SOA as a design style has existed for some time and has benefited from the lessons learned of its predecessor design styles. Design styles are built upon a set of principles that govern its use. These principles are the characteristics that provide the intrinsic behavior for the style of design. Systems that adhere to a style of design are expected to exhibit the principles of that design style, realizing the benefits offered by these principles. The principles of the SOA design style, also known as design characteristics, are:
- Loose coupling
- Separation of concerns
- Single implementation
By designing solutions that follow the SOA style of design, these solutions can expect to benefit from these principles. Even though designing solutions for the sake of using a modern style of design might seem interesting, real business value must be realized to justify its use. The SOA style of design offers companies several benefits:
- Increased business responsiveness and agility
- Ability to transcend organizational boundaries
- Reduces product development cycle times
- Exposes commodities in business processes
Along with the benefits to the business community, the information technology (IT) community can benefit from the SOA style of design, as well. SOA can provide the following benefits to the IT community:
- Build services once and use often
- Services are built by contract
- Promotes process consistency
- Allows for localization of function and standardization of cross-cutting concerns
- Standardizes integration and reduces solution complexity
With the understanding of the principles of the SOA style of design and the benefits to the business and IT communities, an IT architect is able to determine the applicability of SOA as a design style when designing a solution.
Recently, Web services has popularized the term SOA. The computing industry often uses the terms Web services and SOA interchangeably when describing either a design style or an implementation technology. It is important to know that Web services is not the SOA, but rather, a technology that follows the SOA style of design. SOA and its underlying principles have existed longer than Web services. Only recently has the Web services SOA gained so much attention. This is due in part to the significant industry support for Web services from organizations like IBM, Microsoft, BEA, Oracle, Hewlett Packard, and others. In the remainder of this module, the definition and attributes of SOA will be identified.
Although stated earlier, it is worth repeating that the proliferation of Web services, or rather a large-scale deployment of Web services, does not move an organization closer to an SOA. SOA requires planning and introduction of some new processes and technologies over time in the area of services management. It also requires an understanding of SOA and what constitutes a service.
Explaining SOA to the business executive
Imagine the following scenario.
You are an IT architect working on a project within the organization when suddenly one of the non-technical business executives takes you aside. The executive is starting to see the phrase service-oriented architecture (SOA) more and more in the news and hearing it bantered about by the IT group. Since this appears to be more than a passing thought, the executive asks you the typical business person's most-often asked questions:
- What is it?
- Why do you need it?
- What does it do for you?
- What will be relinquished if you don't have it?
The executive sounds somewhat frustrated and asks if this is the next bright idea from the IT industry and wants to know what the IT group is doing about it.
How do you anSWer these questions? This module answers these questions and more.
Service-oriented architecture defined: What is it?
Service orientation is the integration of applications and information sources through the exchange of information based on common semantics or a vocabulary used to define the structure of information exchange. Service orientation enables loose coupling of service providers and service consumers, as there is no information to be shared initially between the two parties.
Service-oriented architecture is an architectural style, design style, and a design principle for application development and integration. SOA promotes business process orchestration of the enterprise-level business services using a distributed model consisting of disparate organizational, customer, supplier, and partner systems.
SOA is composed of a service provider, service requester, or the service consumer and an optional service directory, which together are leveraged to deliver services using application-to-application messaging for information exchange. The service provider creates a service and publishes descriptive information about the service in the service directory. The service requester queries the descriptive information in the service directory to locate the service and also gathers information about the service and the service provider. The service requester accesses the service hosted in the service provider infrastructure and, in turn, realizes the business value of leveraging the service.
Each element of a service-oriented architecture is described below:
- A service is a unit of work done by a service provider to achieve desired end results for a service consumer.
- Service provider systems are the providers of services accessible by well-defined and published interfaces.
- Service requester systems are the consumer of services accessible by well-defined and published interfaces.
- Service directory is a well-known directory of available services.
- Services are created and published by service providers and are made available on a suitable infrastructure for access by the service consumers.
- Service descriptions are created by the service provider and are published to the service registry for access by the service consumer.
- Security and management are part of the overall SOA framework.
SOA is an architectural style intended to achieve loose coupling among interacting software assets or applications. The SOA framework is considered to be an evolutionary step in the future of application design and development. SOA enables the modeling of business problems in terms of discrete services, which can be securely interfaced and integrated with other applications over the Internet or other suitable network infrastructure.
The relationships between processes, services, and components are described by looking at each item. These relationships are illustrated below. Building systems using heterogeneous network-addressable software components is what SOA is about.
- Business processes get business value from things, such as software assets, for example, applications.
- Services describe what things do but represent a fundamental shift in thinking from the traditional approach of creating things.
- Components are what things are, not what things do.
- Deployment units or software artifacts are how things are constructed and deployed.
The graphic below illustrates the relationship between business processes and services. Simply stated, this means a business process comprises one or more business services. The business services are choreographed in a manner to fulfill a business process. Business services in turn implement one or more components that may or may not be implemented as a group. For example, an application can provide a service. Components are a collection of software artifacts or deployment units that are constructed for deployment on one or more nodes, such as platforms.
Service relationship to component
Service-oriented architecture is a natural evolutionary step from the object-oriented (OO), procedural, and data-centric approaches adopted for solution implementation until now. In fact, when creating the SOA system, individual services are typically implemented using one or more of these technologies.
Services are built from components that represent software artifacts or deployment units that are deployed on a platform.
Therefore, SOA is a way of designing software systems to provide services to either user applications or other services. SOA describes the components of the system and the interaction between the components. A well-defined, robust service layer is a key component of SOA.
The service layer and the components used to physically implement the service are illustrated.
The figure illustrates the service layer and the relationship between a services layer, its components, and the business processes that consume the services. Both consumer and provider are illustrated in the figure.
Some key observations from this view are that processes or other services consume services. Components may easily lend themselves to service identification and exposure while others may require re-engineering or the use of wrapping technology to invoke a component as a service. Understanding the SOA
SOA can be understood by examining three items:
- SOA building blocks
- SOA characteristics
- SOA design considerations
The SOA building blocks are the inherent components and the essential ingredients of SOA. The characteristics are the features of the SOA, and the design rules are the guidelines and the best practices for designing and building services in an SOA.
Understanding a service-oriented architecture
Understanding the SOA (continued)
SOA building blocks include the following:
- Business level services — Services are defined as business-level services that map closely to the real-world activities and business functions.
- Infrastructure level services — Services are defined as infrastructure-level services that do not contain business logic, but are necessary for the management of business-level services
- Services management — Service management is a critical component of service-oriented architecture based solutions, where services are consumed and used in a collaborative way in a trusted or non-trusted environment. Services management provides both business process management of services (monitoring, metering, SLA, and QoS) and usage management of services (for example, routing, prioritization, and transformation). This also includes utilities that might be necessary for reporting or profile management.
- Security — Security provides authentication of service consumers (that is, applications and users) based on message authentication standards such as SAML and WS-Security. Authorization or access control of services and operations based on consumer entitlements that are also part of security.
- Service directory — Service directory provides a registry function for the discovery of services and a Web-based interface for administration, auditing, access control management, publication, and search.
SOA characteristics include:
- Loosely coupled — Uses a well-defined interface designed to expose business functions and data, but also to hide underlying implementation details from service requesters
- Shared services — Allows individual software assets to become building blocks that can be reused in developing other applications (application assembly)
- Federated control — Federated and policy-based security, management, and deployment
- Standards based — Leverages open standards to represent software assets as services (for example, XML, SOAP, WSDL, and others)
"SOA design considerations are essential to the design of a service."
(Using Service-Oriented Architecture and Component Based Development to Build Web Service Applications. A. Brown, S. Johnston, and K. Kelly, Rational Software Corporation White Paper, 2002.) Each of the characteristics can be traced back to one or more SOA principles that provide integrity to the principles and the characteristics. These include:
Service-oriented architecture: Why do you need it?
- Coarse grain — The level of granularity is a statement of functional richness for a service. The more coarse grained a service is, the richer the function offered by the service. Although coarse grained is desired, services can be fine grained if there is business justification. The key to granularity is the reuse potential.
- Interface-based design — Interface-based design allows for the development of a service that is independent of the implementation platform, language, and logic.
- Discoverable — The ability for a service requester to discover a service provider is critical for the wide adoption of SOA design. If no one knows that a service exists, it is unlikely that the service will ever get utilized.
- Single instance — The single instance characteristic helps reinforce the notion that only one implementation of a service should be running. Again, this is usually the best practice-based design consideration; although, there may be cases where a particular design suggests a different approach to service instances.
- Separation of concern — The importance of separation when programming in complex environments is described by E.E. Dijkstra in his book, A Discipline of Programming. (A Discipline of Programming, E.E. Dijkstra, Prentice Hall, Englewood Cliffs, NJ, 1976.) The separation of concern principle allows for a cleaner handling of the complexity, as well as a means to achieve adaptability and scalability of software systems. A major benefit of an SOA design is the separation of concerns to reduce the complexity of today’s enterprise systems.
- Asynchronous — Asynchronous communication is not required, but is consistent with the other service characteristics such as coarse-grained services and loose coupling. It would be completely legitimate to design an SOA solution that used synchronous styles of computing and still achieve coarse-grained services and loose coupling. Asynchronous communication offers the benefit of scaling through asynchronous behavior and queuing techniques.
- Stateless — Services neither remember the last thing they were asked to do, nor care what the next service is. Services are not dependent on the context or state of other services. This is not to suggest that a service cannot maintain state. However, the suggestion is that a best practices approach to developing services would be based on a stateless design.
The combination of SOA and Web services is very close to being just what companies have been looking for in order to:
Service-oriented architecture: What does it do for you?
- Realize IT’s long-promised potential
- Justify IT expenses and capital outlays
- Provide non-technical people a clear understanding of what IT does, how they do it, and their intrinsic value
Service-oriented architecture: What will be relinquished if you don't have it?
- Saves money, time, and people
- Eliminates frustrations with IT
- Justifies IT investments
- Provides business executives with a clear understanding of what IT does and its value
- Eliminates IT’s 6-6 answer; that is, the project will take 6 months and cost 6 figures
- Provides a business and competitive differentiator
It is very likely that business transactions will be significantly easier with an SOA. An SOA could be the difference between the success and failure of the next:
- Department, intra-company, or inter-company merger
- Product or service rollout
- Business partner, customer, or supplier addition
- Geographical expansion
- Competitive onslaught
A service-oriented architecture consists of a small set of simple and ubiquitous interfaces to all participating software assets. These interfaces are encoded with only generic semantics. These interfaces also should be universally available to all interested and authorized providers and consumers. Descriptive messages constrained by an extensible schema are delivered through the interfaces. None, or only minimal, system behavior is prescribed by these messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.
The fundamental rules governing an SOA are:
- The messages exchanged between participating systems must be descriptive, rather than instructive, because the software system providing the service is responsible for solving any problems. Descriptive messages provide information about the service and the associated inputs and outputs. The providers are responsible for the how to; hence, the need for instructive messages does not exist.
- The vocabulary and the structure of the messages must be understood by all parties. This common understanding by all parties demands limiting the vocabulary and structure of messages but is a necessity for efficient communication.
- The message structure should be extensible.
An SOA may define a mechanism that enables a requester application to dynamically discover an application providing the requested service. The SOA introduces a set of concepts and ideas that are not evident in the traditional models. These concepts include:
- Component view of business services that can provide delivery of strategic business needs that require flexibility, value-add, and cost-effectiveness.
- Emphasis on the service operational management element based on services-based infrastructure.
- A business component implementation of service mediation and brokering.
- Enterprise view of business components, a sharp contrast to the traditional application functions that were tuned toward independent line-of-business business process requirements.