In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems package functionality as interoperable services. A SOA infrastructure allows different applications to exchange data with one another.

Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies that underlie applications^[1]. SOA separates functions into distinct units, or services^[2], which developers make accessible over a network in order that users can combine and reuse them in the production of applications^[3]. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

SOA can be seen in a continuum, from older concepts of distributed computing^[2][3] and modular programming, through to current practices of mashups, SaaS, and Cloud Computing (which some see as the offspring of SOA ^[4]).

[edit] Description

[edit] Introduction

SOAs build applications out of software services. Services comprise intrinsically unassociated, loosely coupled units of functionality that have no calls to each other embedded in them. Each service implements one action, such as filling out an online application for an account, viewing an online bank-statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, they use defined protocols that describe how one or more services can "talk" to each other.

A software developer, software engineer, or business process expert associates individual SOA objects by using orchestration. In the process of orchestration, a software engineer or process engineer associates relatively large chunks of software functionality (services) in a non-hierarchical arrangement (in contrast to a class hierarchy) by using a special software tool that contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices that the designer can manage and the software system can consume and use at run-time.

SOA may be used for business applications, or in government and the military.^[5]

Underlying and enabling all of this requires metadata in sufficient detail to describe not only the characteristics of these services, but also the data that drives them. Programmers have made extensive use of XML in SOA to structure data that they wrap in a nearly exhaustive description-container. Analogously, WSDL typically describe the services themselves, while SOAP describes the communications protocols. Whether these description languages are the best possible for the job, and whether they will remain the favorites in the future, remains an open question. In the meantime^[update] SOA depends on data and services that are described using some implementation of metadata that should meet the following two criteria:

the metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity
the metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort

SOA's goal is to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the marginal cost of creating the n-th application is low, as all of the software required already exists to satisfy the requirements of other applications. Ideally, one requires only orchestration to produce a new application.

For this to operate, no interactions must exist between the chunks specified or within the chunks themselves. Instead, the interaction of services (all of them unassociated peers) is specified by humans in a relatively ad hoc way with the intent driven by newly emergent requirements. Thus the need for services as much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. Programmers develop the services themselves using traditional languages like Java, C#, C, C++ or COBOL.

SOA services feature loose coupling, in contrast to the functions that a linker binds together to form an executable, to a dynamically linked library or to an assembly. SOA services also run in "safe" wrappers such as Java or .NET, and other programming languages that manage memory allocation and reclamation, allow ad hoc and late binding, and provide some degree of indeterminate data typing.

As of 2008, increasing numbers of third-party software companies offer software services for a fee. In the future, SOA systems may consist of such third-party services combined with others created in-house. This has the potential to spread costs over many customers and customer uses, and promotes standardization both in and across industries. In particular, the travel industry now has a well-defined and documented set of both services and data, sufficient to allow any reasonably competent software engineer to create travel-agency software using entirely off-the-shelf software services(For more details, please visit http://www.opentravel.org/).^{[citation needed]} Other industries, such as the finance industry, have also started making significant progress in this direction.

SOA as an architecture relies on service-orientation as its fundamental design principle^[6]. If a service presents a simple interface that abstracts away its underlying complexity, users can access independent services without knowledge of the service's platform implementation^[7].

SOA relies on services exposing their functionality via interfaces that other applications and services can read to understand how to utilize those services.

Relative to typical practices of earlier attempts to promote software reuse via modularity of functions or by use of predefined groups of functions known as classes, SOA's atomic-level objects often end up 100 to 1,000 times larger.^{[citation needed]}

[edit] Requirements

In order to efficiently use a SOA, one must^{[citation needed]} meet the following requirements:

Interoperability between different systems and programming languages provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication is based on the concept of messages. Using messages across defined message channels decreases the complexity of the end application, thereby allowing the developer of the application to focus on true application functionality instead of the intricate needs of a communication protocol.
Desire to create a federation of resources. Establish and maintain data flow to a federated data warehouse. This allows new functionality developed to reference a common business format for each data element.

[edit] Principles

The following guiding principles define the ground rules for development, maintenance, and usage of the SOA^[8]:

Reuse, granularity, modularity, composability, componentization and interoperability
Standards compliance (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 – Many web services are consolidated to be used under the SOA. Often such services were not planned to be under SOA.
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 optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms^[9]
Service Relevance – Functionality is presented at a granularity recognized by the user as a meaningful service

The following references provide additional considerations for defining a SOA implementation:

SOA Reference Architecture provides a working design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.^[10]
Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information.

In addition, one might take the following factors into account when defining a SOA implementation:

efficient use of system resources
service maturity and performance
EAI Enterprise Application Integration

[edit] Web services approach

Web services can implement a service-oriented architecture. Web services make functional building-blocks accessible over standard Internet protocols independent of platforms and programming languages. These services can be new applications or just wrapped around existing legacy systems to make them network-enabled.

Each SOA building block can play one or both of two roles:

Service provider
The service provider creates a Web service and possibly publishes its interface and access information to the service registry. Each provider must decide which services to expose, how to make trade-offs between security and easy availability, how to price the services, or (if no charges apply) how to exploit them for other value. The provider also has to decide what category the service should be listed in for a given broker service and what sort of trading partner agreements are required to use the service. It registers what services are available within it, and lists all the potential service recipients. The implementer of the broker then decides the scope of the broker. Public brokers are available through the Internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet. Furthermore, the amount of the offered information has to be decided. Some brokers specialize in many listings. Others offer high levels of trust in the listed services. Some cover a broad landscape of services and others focus within an industry. There are also brokers that catalog other brokers. Depending on the business model, brokers can attempt to maximize look-up requests, number of listings or accuracy of the listings. The Universal Description Discovery and Integration (UDDI) specification defines a way to publish and discover information about Web services. Other service broker technologies include for example ebXML (Electronic Business using eXtensible Markup Language) and those based on the ISO/IEC 11179 Metadata Registry (MDR) standard.
Service requester
The service requester or Web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its Web services. Which service the service-requesters need, they have to take it into the Brokers, then bind it with respective service and then use it. They can access multiple services, if the service provides multiple services.

[edit] SOA and Web service protocols

This section does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed. (June 2006)

Implementors commonly build SOAs using Web services standards (for example, using SOAP) that have gained^[when?] 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. One can, however, implement SOA using any service-based technology, such as Jini, CORBA or REST.

[edit] Other SOA concepts

Architectures can operate independently of specific technologies^[3]. Designers can implement SOA using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, Web Services or WCF (Microsoft's implementation of Webservice forms a part of WCF). SOA can be implemented using one or more of these protocols and, for example, might use a file-system mechanism to communicate data conforming to a defined interface-specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

An evolution of SOA concepts into a more advanced architecture called SOA 2.0 is being adopted by many implementers of SOA.

Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall, 2005

SOA Meta Model, The Linthicum Group, 2007

Service-Oriented Modeling Framework (SOMF) Version 2.0

SOA enables the creation of applications that are built by combining loosely coupled and interoperable services^[11]. These services inter-operate based on a formal definition (or contract, e. g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET etc). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as Web services that facilitates reuse. Managed environments can also wrap COBOL legacy systems and present them as software services. This has extended the useful life of many core legacy systems indefinitely, no matter what language they originally used.

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-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine-grained services into more coarse-grained business services, which architects can in turn incorporate into workflows and business processes implemented in composite applications or portals^{[citation needed]}.

The use of Service Component Architecture (SCA) to implement SOA is a current area of research.

Service-oriented modeling ^[2] is a SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets. The Service-Oriented Modeling Framework (SOMF) is a work structure or "map" depicting the various components that contribute to a successful service-oriented modeling approach. It illustrates the major elements that identify the “what to do” aspects of a service development scheme. The model enables practitioners to craft a project plan and to identify the milestones of a service-oriented initiative. SOMF also provides a common modeling notation to address alignment between business and IT organizations.

SOMF is designed to address the following principles:

Business Traceability
Architectural Best-Practices Traceability
Technological Traceability
SOA Value Proposition
Software Assets Reuse
SOA Integration Strategies
Technological Abstraction and Generalization
Architectural Components Abstraction

[edit] SOA definitions

There are multiple definitions of SOA. The OASIS group^[12] and the Open Group^[13] have both created formal definitions.

OASIS defines SOA as the following:

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.

[edit] Service contract

A service contract needs^{[citation needed]} to have the following components:

Header

Name – Name of the service. Should indicate in general terms what it does, but not be the only definition
Version – The version of this service contract
Owner – The person/team in charge of the service
Responsibility assignment (RACI)

Responsible – The role/person/team responsible for the deliverables of this contract/service. All versions of the contract
Accountable – Ultimate Decision Maker in terms of this contract/service
Consulted – Who must be consulted before action is taken on this contract/service. This is two-way communication. These people have an impact on the decision or the execution of that decision.
Informed – Who must be informed that a decision or action is being taken. This is a one-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.

Type – This is the type of the service to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:

Presentation
Process
Business
Data
Integration

Functional

Functional Requirement (from Requirements Document) – Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished.
Service Operations – Methods, actions etc. Must be defined in terms of what part of the functionality it provides.
Invocation – Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple invocation paths for the same service. We may have the same functionality for an internal and some external clients, each with different invocation means and interfaces. Examples:

SOAP
REST
Events Triggers

Non-Functional

Security Constraints – Defines who can execute this service in terms of roles or individual partners etc. and which invocation mechanism they can invoke.
Quality of Service – Determines the allowable failure rate
Transactional – Is this capable of acting as part of a larger transaction and if so, how do we control that?
Service Level Agreement – Determines the amount of latency the service is allowed to have to perform its actions
Semantics – Dictates or defines the meaning of terms used in the description and interfaces of the service
Process – Describes the process, if any, of the contracted service

[edit] SOA and network management architecture

The principles of SOA are currently^[update] 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 M.3060 Principles for the Management Of Next Generation Networks recommendation from the ITU-T.

Tools for managing SOA infrastructure include:

[edit] Discussion

[edit] Benefits

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

In some respects, one can regard SOA as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures. In communications systems, for example, little development has taken place of solutions that use truly static bindings to talk to other equipment in the network. By formally embracing a SOA approach, such systems are better positioned to stress the importance of well-defined, highly inter-operable interfaces^[15].

Some^[who?] have questioned whether SOA is just a revival of modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s)^{[citation needed]}. SOA promotes the goal of separating users (consumers) from the service implementations. Services can therefore be run on various distributed platforms and be accessed across networks. This can also maximize reuse of services^{[citation needed]}.

SOA is an architectural and design discipline conceived to achieve the goals of increased interoperability (information exchange, reusability, and composability), increased federation (uniting resources and applications while maintaining their individual autonomy and self-governance), and increased business and technology domain alignment.

Service-Oriented Architecture (SOA) is an architectural approach (or style) for constructing complex software-intensive systems from a set of universally interconnected and interdependent building blocks, called services.

SOA realizes its business and IT benefits through utilizing an analysis and design methodology when creating services that ensures they are consistent with the architectural vision and roadmap, and adhere to principles of service-orientation. Arguments supporting the business and management aspects from SOA are outlined in various publications^[16].

A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" that are easy to produce and improve. Also services can be "mega-corporations" that are constructed as coordinated work of sub-ordinate services.

Services generally adhere to the following principles of service-orientation:

abstraction
autonomy
composability
discoverability
formal contract
loose coupling
reusability
statelessness

A mature rollout of SOA effectively defines the API of the organization.

Implementation of services should be treated as separate projects from the larger project for three reasons:

It promotes the concept to the business that services can be delivered quickly and independently from the larger and slower-moving projects common in the organization. The business starts understanding systems and simplified user interfaces calling on services. This advocates agility.
It promotes the decoupling of services from its consuming project. This encourages good design where the service is designed without knowing who its consumers are.
Documentation and test artifacts of the service are not embedded within the detail of the larger project. This is important when the service needs to be reused later.

An indirect benefit of SOA is dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation. The industry has never been exposed to this circumstance before.

If appropriate test data is defined in the organization, then when a service is being built, a corresponding stub is built that reacts to the test data. A full set of regression tests, scripts, data, and responses is also captured for the service. The service can be tested as a 'black box' using existing stubs corresponding to the services it calls. Test environments can be constructed where the primitive and out-of-scope services are stubs, while the remainder of the mesh are test deployments of full services. As each interface is fully documented, with its own full set of regression test documentation, it becomes simple to identify problems in test services. Testing evolves to merely validating that the test service operates according to its documentation, and in finding gaps in documentation and test cases of all services within the environment. Managing data state of idempotent services is the only complexity.

Examples may prove useful to aid in documenting a service to the level where it becomes useful. The documentation of some API's within the Java Community Process are good examples. As these are exhaustive, staff would typically use only important subsets. The 'ossjsa.pdf' file within JSR-89 is an example for such a file. JSR-89 Spec Download

[edit] Challenges in adopting SOA

One obvious and common challenge faced involves managing services metadata^{[citation needed]}. SOA-based environments can include many services that 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. This becomes even more complicated when these services are delivered by different organizations within the company or even different companies (partners, suppliers, etc). This creates huge trust issues across teams, and hence SOA Governance comes into picture.

Another challenge involves the lack of testing in SOA space. There are no sophisticated tools that provide testability of all headless services (including message and database services along with web services) in a typical architecture. Lack of horizontal trust requires that both producers and consumers test services on a continuous basis. SOA's main goal is to deliver Agility to Businesses. Therefore it is important to invest in a testing framework (build or buy) that would provide you with the visibility required to find the culprit in your architecture in no time. The Business Agility requires from SOA services to be controlled by the business goals and directives as defined in the Business Motivation Model (BMM)^[17].

Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer suffice when the capabilities of the application are exposed as services that can be used by other applications. That is, application-managed security is not the right model for securing services. A number of new technologies and standards are emerging to provide more appropriate models for security in SOA. See SOA Security entry for more information.

As SOA and the WS-* specifications practitioners constantly expand, update and refine their output, there is a shortage of skilled people to work on SOA-based systems, including the integration of services and construction of services infrastructure.

Interoperability becomes an important aspect of SOA implementations. The WS-I organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to enforce compatibility^[18]. Testing tools have been designed by WS-I to help assess whether web services are conformant with WS-I profile guidelines. Additionally, another charter has been established to work on the Reliable Secure Profile.

Significant vendor hype exists concerning SOA; this can create expectations that may not be fulfilled. Product stacks continue to evolve as early adopters test the development and runtime products with real-world problems. SOA does not guarantee reduced IT costs, improved systems agility or faster time-to-market. Successful SOA implementations may realize some or all of these benefits depending on the quality and relevance of the system architecture and design^[19] ^[20].

SOA efforts are routinely initiated by internal IT delivery organizations, and some of these improperly introduce concepts to the business so it remains misunderstood. The adoption starts meeting IT delivery needs instead of those of the business, so the result is an organization with superlative laptop provisioning services, instead of one that can quickly respond to market opportunities. Business Leadership also becomes convinced that the organization is executing on SOA well.

As one of the most important benefits of SOA is its ease of reuse. Therefore accountability and funding models must ultimately evolve within the organization. A business unit needs to be encouraged to create services that other units will use. Conversely, units must be encouraged to reuse services. This requires a few new governance components:

Each business unit creating services must have an appropriate support structure in place to deliver on its service level obligations, and to support enhancing existing services strictly for the benefit of others. This is typically quite foreign to business leaders.
Each business unit consuming services accepts the apparent risk of reusing services outside their own control, with the attendant external project dependancies, etc.
An innovative funding model is needed as incentive to drive these behaviors above. Business units normally pay the IT Organization to assist during projects, and then to operate the environment. Corporate incentives should discount these costs to service providers, and create internal revenue streams from consuming business units to the service provider. These streams should be less than the costs of a consumer simply building it the old-fashioned way. ----

[edit] Criticisms of SOA

Some criticisms^[21] of SOA depend on the assumption that SOA is just another term for Web Services. For example, some critics^[who?] claim SOA results in the addition of XML layers, introducing XML parsing and composition. In the absence of native or binary forms of Remote Procedure Call (RPC), applications could run slower and require more processing power, increasing costs. Most implementations do incur these overheads, but SOA can be implemented using technologies (for example, Java Business Integration (JBI)) that do not depend on remote procedure calls or translation through XML. At the same time, there are emerging, open-source XML parsing technologies, such as VTD-XML, and various XML-compatible binary formats that promise to significantly improve the SOA performance^[22][23][24].

Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. This constraint has the drawback that it could reduce the overall scalability of the service provider because it might need to remember the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.

Another concern is that WS-* standards and products are still evolving (e. g., transaction, security), and SOA can thus introduce new risks unless properly managed and estimated with additional budget and contingency for additional Proof of Concept work.

Some critics^[who?] feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc).

The ability to easily modify systems is sometimes omitted from IT system design. Many systems, including SOAs, hard-code the operations, goods and services of the organization, thus restricting their online service and business agility in the global marketplace.^{[citation needed]}

The next step in the design process covers the definition of a Service Delivery Platform (SDP) and its implementation. It is in the SDP design phase where one defines the business information models, identity management, products, content, devices, and the end user service characteristics, as well as how agile the system is so that it can deal with the evolution of the business and its customers.

[edit] Extensions

[edit] SOA, Web 2.0, and mashups

Web 2.0 refers to a "second generation" of Web sites, primarily distinguished by the ability of visitors to contribute information for collaboration and sharing. Web 2.0 applications often use REST-ful web services and commonly feature AJAX based user interfaces, utilizing Web syndication, blogs, and wikis. While there are no set standards for Web 2.0, it is characterized by building on the existing Web server architecture and using services. Web 2.0 can therefore be regarded as displaying some SOA characteristics^[25][26][27].

Some commentators^[who?] also regard mashups as Web 2.0 applications. The term Business Mashups has been coined to describe Web applications that combine content from more than one source into an integrated experience that share many of the characteristics of service-oriented business applications (SOBAs). SOBAs 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 realization of SOA composite and business applications^[28].

[edit] Web 2.0

Tim O'Reilly coined the term Web 2.0 to describe a perceived, quickly growing set of Web-based applications^[29]. A topic that has experienced extensive coverage involves the relationship between Web 2.0 and Service-Oriented Architectures (SOAs). SOA is considered as the philosophy of encapsulating application logic in services with a uniformly defined interface and making these publicly available via discovery mechanisms. The notion of complexity-hiding and reuse, but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies, SOA and Web 2.0, and their respective applications. Some argue Web 2.0 and SOA have significantly different elements and thus can not be regarded “parallel philosophies”, whereas others consider the two concepts as complementary and regard Web 2.0 as the global SOA^[30].

The philosophies of Web 2.0 and SOA serve different user needs and thus expose differences with respect to the design and also the technologies used in real-world applications. However, very recently^[update], numerous novel use-cases demonstrate the great potential of combining technologies and principles of both Web 2.0 and SOA^[31].

In an "Internet of Services", all people, machines, and goods will have access via the network infrastructure of tomorrow. The Internet will thus offer services for all areas of life and business, such as virtual insurance, online banking and music, and so on. Those services will require a complex services infrastructure including Service delivery platforms bringing together demand and supply. Building blocks for the Internet of Services are SOA, Web 2.0 and semantics on the technology side as well as novel business models, and approaches to systematic and community based innovation^[32].

Even though Oracle indicates that Gartner is coining a new term, Gartner analysts indicate that they call this advanced SOA and "whimsically" refer to it as SOA 2.0^[33]. Most of the major middleware vendors (e. g., webMethods, TIBCO Software, IBM, Sun Microsystems, and Oracle) have had some form of SOA 2.0 attributes for years.

However, some other industry commentators^[who?] have criticized attaching a version number ("2.0") to an application-architecture design-approach, while others^[who?] have stated that the "next generation" should apply to the evolution of SOA techniques from IT optimization to business development^[34].

[edit] Digital Nervous System

SOA implementations have been described as representing a piece of the larger vision known as the Digital Nervous System ^[35][36] or the Zero Latency Enterprise^[37]

Representational State Transfer

From Wikipedia, the free encyclopedia

Jump to: navigation, search

"REST" redirects here. For other uses, see Rest.

This article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (May 2009)

Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. As such, it is not just a method for building "web services." The terms "representational state transfer" and "REST" were introduced in 2000 in the doctoral dissertation of Roy Fielding,^[1] one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification.

In the strictest sense, REST refers to a collection of network architecture principles that outline how resources are defined and addressed. Usually, however, the term is more loosely to describe any simple interface that transmits domain-specific data over HTTP, without an additional messaging layer such as SOAP or session tracking via HTTP cookies. These two meanings can conflict and overlap.

It is possible to design a software system in accordance with Fielding's REST architectural style without using HTTP and without interacting with the World Wide Web.^[2] It is also possible to design simple XML+HTTP interfaces which do not conform to REST principles, and instead follow a model of remote procedure call. The difference between the uses of the term "REST" therefore causes some confusion in technical discussions.

Systems which follow Fielding's REST principles are often referred to as "RESTful".

[edit] Principles

Proponents of REST argue that the Web's scalability and growth are a direct result of a few key design principles:

Application state and functionality are abstracted into resources
Every resource is uniquely addressable using a universal syntax for use in hypermedia links
All resources share a uniform interface for the transfer of state between client and resource, consisting of

A constrained set of well-defined operations
A constrained set of content types, optionally supporting code on demand

A protocol which is:

Client-server
Stateless
Cacheable
Layered

Fielding describes REST's effect on scalability thus:

REST's client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries—proxies, gateways, and firewalls—to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.^[3]

[edit] REST's central principle: resources

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information). For example, a resource which is a circle may accept and return a representation which specifies a center point and radius, formatted in SVG, but may also accept and return a representation which specifies any three distinct points along the curve as a comma-separated list.

Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without "seeing past" its own request (referred to as "layering," another constraint of REST and a common principle in many other parts of information and networking architecture). Thus an application can interact with a resource by knowing two things: the identifier of the resource, and the action required—it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and the server actually holding the information. The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML, XML or JSON document of some kind, although it may be an image, plain text, or any other content.

[edit] Claimed benefits

Many of the statements below refer to REST in the specific context of Web Services, as opposed to SOAP. REST was originally defined in Fielding's dissertation in the context of information and media access. Fielding did not originally contrast REST with RPC.

Some benefits with REST:

Provides improved response time and reduced server load due to its support for the caching of representations
Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
Provides equivalent functionality when compared to alternative approaches to communication
Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:

The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

One benefit that's obvious with regards to web based applications is that a RESTful implementation allows a user to bookmark specific "queries" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this "representation" of a path or entry point into an application state becomes highly portable.

[edit] RESTful example: the World Wide Web

The World Wide Web is the key example of RESTful design. Much of it conforms to REST principles. The Web consists of the Hypertext Transfer Protocol (HTTP), content types including the Hypertext Markup Language (HTML), and other Internet technologies such as the Domain Name System (DNS).

HTML can include JavaScript and applets to support code on demand, and has implicit support for hyperlinks.

HTTP has a uniform interface for accessing resources, which consists of URIs, methods, status codes, headers, and content distinguished by MIME type.

The most important HTTP methods are POST, GET, PUT and DELETE. These are often respectively associated with the CREATE, READ, UPDATE, DELETE (CRUD) operations associated with database technologies:^[4]

The following table associates several common HTTP verbs with similar database operations, however the meaning of the HTTP verbs do not correspond directly with a single database operation. For example, an HTTP PUT is used to set the value of a resource and may result in either a creation or replacement as needed.

HTTP	CRUD
POST	Create
GET	Read
PUT	Update, Create
DELETE	Delete

Some "RESTful" services will extend the POST method to include the operations of updating and deleting by including additional arguments (e.g. method=delete,method=update). However, in doing so the service is moving the "operation" out of HTTP and inside the request data (similar to a RPC style or SOAP web service). The HTTP standard states that POST is intended to create "a new subordinate of the resource identified"^[5]. While the PUT operation is intended to create a new resource "stored under the supplied Request-URI" based on the enclosed entity in the request and in the case that the supplied Request-URI exists, "the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server" (i.e. update the resource)^[6].

HTTP separates the notions of a web server and a web browser. This allows the implementation of each to vary from the other based on the client-server principle. When used RESTfully, HTTP is stateless. Each message contains all the information necessary to understand the request when combined with state at the resource. As a result, neither the client nor the server needs to remember any communication state between messages. Any state retained by the server must be modeled as a resource.

The statelessness constraint can be violated in HTTP using cookies to maintain sessions. Fielding notes the risks of privacy leaks and security complications which often arise through the use of cookies, and the confusions and bugs which can result from interactions between cookies and the "back" button in a browser.

HTTP provides mechanisms to control caching, and permits a conversation between web browser and web cache to occur using the same mechanisms as between web browser and web server. No layer can access any conversation other than the one it is immediately involved with.

HTML links only produce HTTP GET requests, and HTML forms allow GET and POST methods. The other HTTP methods mentioned here are not available in HTML 4.01 or XHTML 1.0.^[7] WebDAV makes use of other HTTP verbs in a web context. For this reason some "RESTful" services will overload the POST method to make it perform the operation updating (PUT) and deleting (DELETE) a resource.

[edit] RESTful web services

A RESTful web service is a simple web service implemented using HTTP and the principles of REST. Such a web service can be thought about as a collection of resources. The definition of such a web service can be thought of as comprising three aspects:

The URI for the web service such as http://example.com/resources/cars
The MIME type of the data supported by the web service. This is often JSON , XML or YAML but can be any other valid MIME type.
The set of operations supported by the web service using HTTP methods (e.g. POST, GET, PUT or DELETE).

Members of the collection are addressed by ID using URIs of the form <baseURI>/<ID>. The ID can be any unique identifier. For example if a RESTful web service representing a collection of cars for sale might have the URI http://example.com/resources/cars. If the service uses the car registration number as the ID then a particular car might be present in the collection as http://example.com/resources/cars/yxz123.

The following table shows how the HTTP verbs are typically used to implement a web service.

RESTful Web Service HTTP methods
Resource	GET	PUT	POST	DELETE
Collection URI such as `http://example.com/resources/cars/`	List the members of the collection. For example list all the cars for sale.	Not generally used. Meaning defined as replace the entire collection with another entire collection.	Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is typically returned by this operation.	Not generally used. Meaning defined as delete the entire collection.
Member URI such as `http://example.com/resources/cars/yxz123`	Retrieve the addressed member of the collection	Update the addressed member of the collection or create it with a defined ID.	Not generally used.	Delete the addressed member of the collection.

^[8]

[edit] REST versus RPC

The statements below refer to REST in the context of Web Services, specifically as opposed to SOAP. Note that Fielding's dissertation presents REST in the context of information and media access, not web services. It does not contrast REST to RPC, although it does contrast RPC to HTTP (which is used to illustrate an implementation of REST).

REST

Resources—Commands are defined in simple terms: resources to be retrieved, stored / get, set—difficult to do many joins

RPC

Commands—Commands are defined in methods with varying complexity: depending on "standard"—easier to hide complex things behind a method

REST

Nouns—Exchanging resources and concepts

RPC

Verbs—Exchanging methods

REST Triangle of nouns, verbs, and content types.

A RESTful web application requires a different design approach from an RPC application.

An RPC application is exposed as one or more network objects, each with an often unique set of functions which can be invoked. Before a client communicates with the application it must have knowledge of the object identity in order to locate it and must also have knowledge of the object type in order to communicate with it.

RESTful design constrains the aspects of a resource which define its interface (the verbs and content types). This leads to the definition of fewer types on the network than an RPC-based application but more resource identifiers (nouns). REST design seeks to define a set of resources with which clients can interact uniformly, and to provide hyperlinks between resources which clients can navigate without requiring knowledge of the whole resource set. Server-provided forms can also be used in a RESTful environment to describe how clients should construct a URL in order to navigate to a particular resource.

[edit] Example

An RPC application might define operations such as the following:

getUser()

addUser()

removeUser()

updateUser()

getLocation()

addLocation()

removeLocation()

updateLocation()

listUsers()

listLocations()

findLocation()

findUser()

Client code to access this application may look something like this:

exampleAppObject = new ExampleApp('example.com:1234')

exampleAppObject.removeUser('001')

With REST, on the other hand, the emphasis is on the diversity of resources, or nouns; for example, a REST application might define the following resources

http://example.com/users/

http://example.com/users/{user} (one for each user - where {user} is either the user name or the user id)

http://example.com/findUserForm

http://example.com/locations/

http://example.com/locations/{location} (one for each location - where {location} is the location name or the location id)

http://example.com/findLocationForm

Client code to access this application may look something like this:

userResource = new Resource('http://example.com/users/001')

userResource.delete()

Each resource has its own identifier noun. Clients start at a single resource such as the user resource which represents themselves, and navigate to location resources and other user resources. Clients work with each resource through standard operations, such as GET to download a copy of the resource's representation, PUT to paste a changed copy over the top of the original, or DELETE to remove the data or state associated with the resource. POST is sometimes used interchangeably with PUT, but can also be seen as a "paste after" rather than a "paste over" request. POST is generally used for actions with side-effects, such as requesting the creation of a purchase order, or adding some data to a collection. Note how each object has its own URL and can easily be cached, copied, and bookmarked.

[edit] Uniform interfaces in REST and RPC

The uniform interface allows clients to access data from a range of resources without special code to deal with each one, so long as it is actually uniform. The content returned from a user resource could be the globally standard and RESTful HTML, a less RESTful industry standard representation such as UserML, or an unRESTful application-specific data format. Which content is returned can be negotiated at request time. The content could even be a combination of these representations: HTML can be marked up with microformats which have general or industry-specific appeal, and these microformats can be extended with application-specific information.

Uniform interfaces reduce the cost of client software by ensuring it is only written once, rather than once per application it has to deal with. Both REST and RPC designs may try to maximise the uniformity of the interface they expose by conforming to industry or global standards. In the RPC model these standards are primarily in the form of standard type definitions and standard choreography. In REST it is primarily the choice of standard content types and verbs which controls uniformity.

[edit] Public implementations

It is possible to claim an enormous number of RESTful applications on the Web (just about everything accessible through an HTTP GET request or updateable through HTTP POST). Taken more narrowly, in its sense as an alternative to both Web Services generally and the RPC style specifically, REST can be found in a number of places on the public Web:

The "blogosphere"—the universe of weblogs—is mostly REST-based, since it involves downloading XML files (in RSS or Atom format) which contain lists of links to other resources;
The Atom Publishing Protocol for publishing to blogs is considered a canonical RESTful protocol;
Various websites and web applications offer REST-like developer interfaces to data (e.g. Flickr, Twitter or Amazon S3).

Note that WSDL version 2.0 now offers support for binding to all the HTTP request methods (not only GET and POST as in version 1.1).^[9]

[edit] False or weak forms

Some interfaces referred to as being "RESTful" do not intentionally respect REST's architectural constraints. REST advocate Mark Baker uses the term "accidentally RESTful"^[10] to describe interfaces that partially follow REST's architectural constraints. For example, Flickr's interface can be considered RESTful in its use of standalone GET operations, but it does not attempt to support the full range of a REST interface. Other interfaces that use HTTP to tunnel function calls or which offer a "POX/HTTP" (Plain Old XML over HTTP) endpoint are also sometimes referred to as "REST" interfaces.^{[citation needed]}

[edit] Implementation challenges

Implementation is hampered by limited support for HTTP PUT and DELETE in popular development platforms. For example, in the LAMP platform, support for PUT must be added as a module. Web searches offer few examples of how to implement updating database-driven content using PUT. For example, it is nontrivial to create a PHP script to update http://example.com/thing/1 with a PUT message when /thing.php will serve a GET request with XML generated from a database. Most published patterns for updating entities use the POST method.

[edit] Outside of the Web

Just as much of the web can be seen as RESTful or nearly RESTful, a number of existing protocols and architectures have RESTful characteristics. Software which may interact with a number of different kinds of objects or devices can do so by virtue of a uniform, agreed interface. Many of these uniform interfaces follow document-oriented REST patterns rather than object-oriented patterns [should expand on and thus clarify this distinction]:

[edit] Modbus

Modbus is a protocol which allows memory ranges within PLCs to be addressed. Ranges can be written and read effectively as PUT and GET operations.

[edit] JavaBeans

JavaBeans and other systems which perform property-based editing follow the PUT and GET model of the REST architectural style. Rather than write object-specific editor code, the code is written once and can interact with various object types. Resources in this model are defined by the combination of an object identifier and a property name.

[edit] SNMP

The SNMP protocol and its object model, which predate the Web, share some characteristics with RESTful systems. A strict verb discipline follows from the protocol's small operator set, and the 'resources' are addressed with a uniform global scheme of Object Identifiers. Most interaction occurs in client-server fashion, and the clients and servers (called managers and agents respectively) can be deployed and evolved independently. Each request-response pair can be understood in isolation.

However, movement through the space of Object identifiers is not assisted by hyperlinks, nor is it considered as traversal through states in a state machine. Rather, the manager uses prior knowledge of the Management Information Bases supported by this particular agent to request or change the information it is interested in. SNMP is focused on providing data about known elements of a device or entity in a LAN or limited-access WAN scope, rather than issues of Internet scaling and links between independently authored content.

[edit] CMIP

The CMIP protocol was designed to allow the control of network resources by presenting their manageable characteristics as object graphs. The objects have parent-child relationships which are identified using distinguished names and attributes which are read and modified by a set of CRUD operations. The notable non-restful aspect of CMIP is the M_ACTION operation although wherever possible, MIB designers would typically endeavour to represent controllable and stateful aspects of network equipment through attributes

Representational State Transfer

From Wikipedia, the free encyclopedia

Jump to: navigation, search

"REST" redirects here. For other uses, see Rest.

This article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (May 2009)

Systems which follow Fielding's REST principles are often referred to as "RESTful".

[edit] Principles

Proponents of REST argue that the Web's scalability and growth are a direct result of a few key design principles:

Application state and functionality are abstracted into resources
Every resource is uniquely addressable using a universal syntax for use in hypermedia links
All resources share a uniform interface for the transfer of state between client and resource, consisting of

A constrained set of well-defined operations
A constrained set of content types, optionally supporting code on demand

A protocol which is:

Client-server
Stateless
Cacheable
Layered

Fielding describes REST's effect on scalability thus:

[edit] REST's central principle: resources

[edit] Claimed benefits

Some benefits with REST:

Provides improved response time and reduced server load due to its support for the caching of representations
Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
Provides equivalent functionality when compared to alternative approaches to communication
Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:

The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

[edit] RESTful example: the World Wide Web

HTML can include JavaScript and applets to support code on demand, and has implicit support for hyperlinks.

HTTP has a uniform interface for accessing resources, which consists of URIs, methods, status codes, headers, and content distinguished by MIME type.

HTTP	CRUD
POST	Create
GET	Read
PUT	Update, Create
DELETE	Delete

[edit] RESTful web services

The URI for the web service such as http://example.com/resources/cars
The MIME type of the data supported by the web service. This is often JSON , XML or YAML but can be any other valid MIME type.
The set of operations supported by the web service using HTTP methods (e.g. POST, GET, PUT or DELETE).

Members of the collection are addressed by ID using URIs of the form <baseURI>/<ID>. The ID can be any unique identifier. For example if a RESTful web service representing a collection of cars for sale might have the URI http://example.com/resources/cars. If the service uses the car registration number as the ID then a particular car might be present in the collection as http://example.com/resources/cars/yxz123.

The following table shows how the HTTP verbs are typically used to implement a web service.

RESTful Web Service HTTP methods
Resource	GET	PUT	POST	DELETE
Collection URI such as http://example.com/resources/cars/	List the members of the collection. For example list all the cars for sale.	Not generally used. Meaning defined as replace the entire collection with another entire collection.	Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is typically returned by this operation.	Not generally used. Meaning defined as delete the entire collection.
Member URI such as http://example.com/resources/cars/yxz123	Retrieve the addressed member of the collection	Update the addressed member of the collection or create it with a defined ID.	Not generally used.	Delete the addressed member of the collection.

^[8]

[edit] REST versus RPC

REST

Resources—Commands are defined in simple terms: resources to be retrieved, stored / get, set—difficult to do many joins

RPC

Commands—Commands are defined in methods with varying complexity: depending on "standard"—easier to hide complex things behind a method

REST

Nouns—Exchanging resources and concepts

RPC

Verbs—Exchanging methods

REST Triangle of nouns, verbs, and content types.

A RESTful web application requires a different design approach from an RPC application.

[edit] Example

An RPC application might define operations such as the following:

getUser()

addUser()

removeUser()

updateUser()

getLocation()

addLocation()

removeLocation()

updateLocation()

listUsers()

listLocations()

findLocation()

findUser()

Client code to access this application may look something like this:

exampleAppObject = new ExampleApp('example.com:1234')

exampleAppObject.removeUser('001')

With REST, on the other hand, the emphasis is on the diversity of resources, or nouns; for example, a REST application might define the following resources

http://example.com/users/

http://example.com/users/{user} (one for each user - where {user} is either the user name or the user id)

http://example.com/findUserForm

http://example.com/locations/

http://example.com/locations/{location} (one for each location - where {location} is the location name or the location id)

http://example.com/findLocationForm

Client code to access this application may look something like this:

userResource = new Resource('http://example.com/users/001')

userResource.delete()

[edit] Uniform interfaces in REST and RPC

[edit] Public implementations

The "blogosphere"—the universe of weblogs—is mostly REST-based, since it involves downloading XML files (in RSS or Atom format) which contain lists of links to other resources;
The Atom Publishing Protocol for publishing to blogs is considered a canonical RESTful protocol;
Various websites and web applications offer REST-like developer interfaces to data (e.g. Flickr, Twitter or Amazon S3).

Note that WSDL version 2.0 now offers support for binding to all the HTTP request methods (not only GET and POST as in version 1.1).^[9]

[edit] False or weak forms

[edit] Implementation challenges

Implementation is hampered by limited support for HTTP PUT and DELETE in popular development platforms. For example, in the LAMP platform, support for PUT must be added as a module. Web searches offer few examples of how to implement updating database-driven content using PUT. For example, it is nontrivial to create a PHP script to update http://example.com/thing/1 with a PUT message when /thing.php will serve a GET request with XML generated from a database. Most published patterns for updating entities use the POST method.

[edit] Outside of the Web

[edit] Modbus

Modbus is a protocol which allows memory ranges within PLCs to be addressed. Ranges can be written and read effectively as PUT and GET operations.

[edit] JavaBeans

[edit] SNMP

[edit] CMIP