article

In computing, the term Service-Oriented Architecture (SOA "es-ō-ā") expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementationChannabasavaiah, Holley and Tuggle, Migrating to a service-oriented architecture, IBM DeveloperWorks, 16 Dec 2003

Service Oriented Architecture was first proposed by Roy W. Schulte and Yefim V. Natis who were Gartner analysts. They specified SOA as "a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes." Roy W. Schulte and Yefim V. NatisService Oriented Architecture,Gartner, 12 April 1996

SOA is usually based on Web services standards (e.g., using SOAP or REST) that have gained broad industry acceptance. These standards (also referred to as Web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. However, one can implement SOA using any service-based technology.

SOA can also be regarded as a style of Information Systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services. These services inter-operate based on a formal definition (or contract, eg. WSDL) which is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA-compliant systems can therefore be independent of development technologies and platforms (such as Java, .NET etc). For example, services written in C# running on .Net platforms and services written in Java running on JEE platforms can both be consumed by a common composite application. In addition, applications running on either platform can consume services running on the other as Web services, which facilitates reuse.

SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services.

High-level languages such as BPEL and specifications such as WS-Coordination extend the service concept further by providing a method of defining and supporting orchestration of fine grained services into coarser grained business services, which in turn can be incorporated into workflows and business processes implemented in composite applications or portals.

SOA definitions

The OASIS SOA Reference Model group defines SOA as

Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

There are multiple definitions of SOA but currently only the OASIS group has created a formal definition with depth which can be applied to both the technology and business domains.

Though many definitions of SOA limit themselves to technology or just Web Services, it should be noted that this is predominantly pushed by technology vendors; in 2003 they talked just of Web Services, while in 2006 the talk is of events and process engines.

Why SOA?

Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to the changing market conditions. This style of architecture promotes reuse at the macro (service) level rather than micro levels (eg. Objects). It can also simplify interconnection to and usage of existing IT (legacy) assets.

In some respects, SOA can be considered an evolution in architecture, not a revolution. It captures many of best practices or actual use of the architectures that came before it. In communications systems, for example, there has been little development in recent years of solutions that use truly static bindings to talk to other equipment in the network, but by formally embracing an SOA approach, solutions are better positioned to stress the importance of well-defined, highly interoperable interfaces. This should greatly decrease integration costs and allow for much more dynamic solutions to be deployed.

SOA principles

The following guiding principles define the ground rules for development, maintenance, and usage of the SOAYvonne Balzer Improve your SOA project plans, IBM, 16 July 2004
  • Reuse, granularity, modularity, composability, componentization, and interoperability
  • Compliance to standards (both common and industry-specific)
  • Services identification and categorization, provisioning and delivery, and monitoring and tracking

The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:

  • Service Encapsulation
  • Service Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
  • Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents
  • Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
  • Service reusability - Logic is divided into services with the intention of promoting reuse
  • Service composability - Collections of services can be coordinated and assembled to form composite services
  • Service autonomy – Services have control over the logic they encapsulate
  • Service statelessness – Services minimize retaining information specific to an activity
  • Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanismsThomas Erl Serviceorientation.org - About the Principles, 2005-2006

In addition, the following factors should also be taken into account when defining a SOA implementation:

  • Life cycle management
  • Efficient use of system resources
  • Service maturity and performance

Service-oriented design and development

The modelling and design methodology for SOA applications has become known by the terms service-oriented analysis and design and SODA. The SOA functions as much as a software development framework as it does as a delivery framework. In order for a digital firm to incorporate SOA in their environment successfully, everyone needs to orient themselves to think in terms of services. Development of services and systems that use/reuse service requires a long-term commitment by both business sponsors and I.T. staff. A new paradigm the service model must be employed in all phases of planning, budgeting, tool selection, human resources and infrastructure purchase.

SOA is usually fronted by a client User-Interface (UI), which may also be a composite application, which end users see and interact with. See Client/SOA for a discussion of one such architecture. In general, SOA and services are "behind the scenes", not visible to users.

SOA and Web service protocols

Many people define service-oriented architecture as services exposed using the Web Services Protocol Stack . The base level of Web services standards relevant to SOA include the following:

  • XML - a markup language for describing data in message payloads in a document format
  • HTTP (or HTTPS) - request/response protocol between clients and servers used to transfer or convey information
  • SOAP - a protocol for exchanging XML-based messages over a computer network, normally using HTTP
  • Web Services Description Language (WSDL) - XML-based service description that describes the public interface, protocol bindings and message formats required to interact with a web service
  • Universal Description, Discovery, and Integration (UDDI) - An XML-based registry to publish service descriptions (WSDL) and allow their discovery

Note, however, that a system does not necessarily need to use any or all of these standards to be "service-oriented."

SOA, Web 2.0 and Mashups

Web 2.0 refers to a second generation of services available for people to collaborate and share information on the Internet. Web 2.0 applications use Web services and may include Ajax program interfaces, Web syndication, blogs and wikis. While there are no set standards for Web 2.0, it is characterised by building on the existing web server architecture and using services. Web 2.0 can therefore be regarded as displaying some SOA characteristicsDion Hinchcliffe Is Web 2.0 The Global SOA?], SOA Web Services Journal, 28 October 2005 . Mashups are also regarded by some as Web 2.0 applications. The term "enterprise mashup" has been coined to describe Web applications that combine content from more than one source into an integrated experience, which share many of the characteristics of Service-Oriented Business Applications (SOBAs), which are applications composed of services in a declarative manner. There is ongoing debate about "the collision of Web 2.0, mashups and SOA" with some stating that Web 2.0 applications are a realisation of SOA composite and business applications. Jason Bloomberg Mashups and SOBAs: Which is the Tail and Which is the Dog?, Zapthink

SOA 2.0 or Advanced SOA

Oracle is talking up SOA 2.0 as "the next-generation version of SOA" combining service-oriented architecture and Event Driven Architecture, and categorizing the first iteration of SOA as client-server drivenPaul Krill Make way for SOA 2.0, InfoWorld , May 17, 2006 . Even though Oracle indicates that Gartner is coining a new term, Gartner analysts indicate that they call this advanced SOA and it is 'whimsically' referred to as SOA 2.0.Yefim Natis & Roy Schulte Advanced SOA for Advanced Enterprise Projects, Gartner, July 13, 2006 Most of the pure-play middleware vendors (i.e. webMethods and Tibco) have had SOA 2.0 attributes for years. SOA 2.0 can therefore be regarded as marketing and evangelism rather than a new "way of doing things".

However, other industry commentators have criticized attaching a version number to an architecture, while others have stated that the "next generation" should apply to the evolution of SOA techniques from IT optimization to business developmentJoe McKendrick Anti-SOA 2.0 petition nears 400, ZDNet.com, June 29, 2006 .

What are the challenges faced in SOA adoption?

One obvious and common challenge faced is managing services metadata. SOA-based environments can include many services which exchange messages to perform tasks. Depending on the design, a single application may generate millions of messages. Managing and providing information on how services interact is a complicated task.

Another challenge is providing appropriate levels of security. Applications which consume services, particularly those external to company firewalls, are more visible to external parties than traditional monolithic proprietary applications. The flexibility and reach of SOA can compromise security; the WS-Security suite of specifications is being developed to provide appropriate security .

As SOA and the WS-* specifications are constantly being expanded, updated and refined, there is a shortage of skilled people to work on SOA based systems, including the integration of services and construction of services infrastructure.

There is significant vendor hype concerning SOA that can create expectations that may not be fulfilled. SOA does not guarantee reduced IT costs, improved systems agility or faster time to market. Successful SOA implementations may realise some or all of these benefits depending on the quality and relevance of the system architecture and design.

SOA and business architecture

One area where SOA has been gaining ground is in its power as a mechanism for defining business services and operating models and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business. The purpose of using SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. Within this area, the first SOA technical method was announced in 2004 (see Service-oriented Modeling and Architecture (SOMA)). Since then, efforts have been made to move towards greater standardization and the involvement of business objectives, particularly within the OASIS standards group and specifically the SOA Adoption Blueprints group. All of these approaches take a fundamentally structured approach to SOA, focusing on the Services and Architecture elements and leaving implementation to the more technically focused standards.

SOA and network management architecture

The principles of SOA are currently being applied to the field of network management. Examples of Service-Oriented network management architectures are TS 188 001 NGN Management OSS Architecture from ETSI, and the recently published M.3060 Principles for the Management Of Next Generation Networks recommendation from the ITU-T.

Products

SOA is not a product, rather an architectural style. Several vendors offer products which can form the basis of or enable SOA, particularly Enterprise Service Bus (ESB) products. ESBs provide infrastructure that can be purchased, implemented and leveraged for SOA-based systems. See the list of SOA related products for an overview and ideas.

Literature

References

See also

Footnotes

  • An alternative view, particularly after initial deployments, is that SOAs properly ought not dictate physical implementation, so the formal definition should not include "network." High performance SOAs may not be viable deployed to distributed nodes on a network, and separate nodes for every (or most) services could be prohibitively expensive.

External links

Articles

Web services | Enterprise application integration | Information technology

Serviceorienteret arkitektur | Serviceorientierte Architektur | Arquitectura orientada a servicios | Service Oriented Architecture | Service-oriented architecture | Service-oriëntatie | サービス指向アーキテクチャ | Service-oriented architecture | SOA | Сервисно-ориентированная архитектура | SOA

 

This article is licensed under the GNU Free Documentation License. It uses material from the "Service-oriented architecture".

Home Page • arts • business • computers • games • health • hospitals • home • kids & teens • news • physicians • recreation• reference • regional • science • shopping • society • sports • world