Introduction
One can define a service-oriented architecture (SOA) as a group of services that communicate with each other. The process of communication involves either simple data-passing or two or more services coordinating some activity. 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 units of functionality that have no calls to each other embedded in them. They typically implement functionality most humans would recognize as a service, 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 which describe how one or more services can "talk to" each other. This architecture then relies on a business process expert to page link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.
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.
An application designer or engineer 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 which contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices which the designer can manage and the software system can consume and use at run-time.
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 which 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 which meets the following two criteria:
the metadata must come in a form which software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity
the metadata must also come in a form which system designers can understand and manage with a reasonable expenditure of cost and effort
SOA has the goal of allowing users to string together fairly large chunks of functionality to form ad hoc applications which 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 zero, 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 More Read
http://en.wikipediawiki/Service-oriented_architecture
