Service Oriented Architecture

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

In computing, service-oriented architecture (SOA) provides a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as interoperable services: software modules provided as a service can be integrated or used by several organizations, even if their respective client systems are substantially different. An implementation of SOA is called a Service Oriented Architecture implementation. It is an attempt to develop yet another means for software module integration. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an 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 that users can combine and reuse them in the production of applications. 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 as a sort of continuum, as opposed to distributed computing or modular programming.

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.