- 서비스 지향 아키텍처(서비스 기반 아키텍처)
A service-oriented architecture (SOA) is a group of services that communicate with each other. The process of communication involves either simple data-passing between a service provider and service consumers, or a more complicated system of two or more service providers. Intercommunication implies the need for some means of connecting two or more services to each other.
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.
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 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. 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. 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.
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
from wikipedia
