Service-oriented architecture
From Wikipedia, the free encyclopedia
 | It has been suggested that Service-Oriented Architecture Types be merged into this article or section. (Discuss) Proposed since April 2010. |
| It has been suggested that Service Oriented Architecture Fundamentals be merged into this article or section. (Discuss) Proposed since April 2011. |
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page.
|
| Programming paradigms |
|---|
|
In software engineering, a Service-Oriented Architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures) that can be reused for different purposes. SOA design principles are used during the phases of systems development and integration.
SOA also generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well-understood, well-defined interface to access them. XML is often used for interfacing with SOA services, though this is not required. JSON is also becoming increasingly common.
SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation.
Service orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services,[1] which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.[2]
SOA can be seen in a continuum, from older concepts of distributed computing[1][3] and modular programming, through SOA, and on to current practices of mashups, SaaS, and Cloud Computing (which some see as the offspring of SOA [4]).
Contents[hide] |
[edit]Description
[edit]Overview
The SOA implementations rely on a mesh of software services. Services comprise 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, or viewing an online bank statement, or placing an online booking or airline ticket order. Rather than services embedding calls to each other in their source code, they use defined protocols that describe how services pass and parse messages using description metadata.
SOA developers associate individual SOA objects by using orchestration. In the process of orchestration the developer associates software functionality (the services) in a non-hierarchical arrangement using a software tool that contains a complete list of all available services, their characteristics, and the means to build an application utilizing these sources.
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, the Web Services Description Language (WSDL) typically describes the services themselves, while the SOAP protocol describes the communications protocols. Whether these description languages are the best possible for the job, and whether they will become/remain the favorites in the future, remain open questions. As of 2008 SOA depends on data and services that are described by 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. For example, metadata could be used by other applications, like a catalogue, to perform autodiscovery of services without modifying the functional contract of a service.
- The metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort.
SOA aims 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, humans specify the interaction of services (all of them unassociated peers) 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#, Visual Basic, COBOL, or PHP.
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 in 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[original research?] 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.[5] 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]
[edit]Requirements
In order to efficiently use a SOA, the architecture must meet the following requirements:
- Interoperability among different systems and programming languages that provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication depends 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 database system. 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 first published research of service orientation from an industry perspective was provided by Thomas Erl of SOA Systems Inc. who defined eight specific service-orientation principles common to all primary SOA platforms. These principles were published in “Service-Oriented Architecture: Concepts, Technology, and Design”, on the www.soaprinciples.com research site, and in the September 2005 edition of the Web Services Journal (see Service-orientation).
- Standardized service contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
- Service loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
- Service abstraction – Beyond descriptions 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 autonomy – Services have control over the logic they encapsulate.
- Service granularity – A design consideration to provide optimal scope and right granular level of the business functionality in a service operation.
- Service statelessness - Services minimize resource consumption by deferring the management of state information when necessary
- Service discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
- Service composability – Services are effective composition participants, regardless of the size and complexity of the composition.
