Service-oriented architecture (SOA) is a way of designing a software system to provide services to either end-user applications or other services through published and discoverable interfaces. In many cases, services provide a better way to expose discrete business functions and therefore an excellent way to develop applications that support business processes. Service-Oriented Architecture is also descried as an approach to implement applications based on the use of ‘services’.
In Service-Oriented Architecture applications must be developed as independent sets of interacting services offering well-defined interfaces to their potential users. The service can take the form of a web service. Web service enables services to be based on standards such as HTTP, XML and SOAP. The application which consumes web services can pick supplier’s functionalities, independently of where they are located on the network, or of the technologies and databases used.
SOA helps businesses respond more quickly and cost-effectively to changing market conditions. This style of architecture promotes reuse at the service level rather than the class level. SOA increase interoperability (information exchange), reusability, composability, and increase globalization through uniting resources.
There are some specific terms used to define elements within Web services, as shown in the following Figure:
Service: A logical entity; the contract defined by one or more published interfaces.
Service provider: The software entity that implements a service specification. 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.
Service requestor: The software entity that calls a service provider. Traditionally, this is termed a “client”.
Service locator: A specific kind of service provider that acts as a registry and allows for the lookup of service provider interfaces and service locations.
Service broker: The service broker is responsible for making the Web service interface and implementation access information available to any potential service requester. The Universal Description Discovery and Integration (UDDI) (6) specification defines a way to publish and discover information about Web services.

Service Technology.
Next subsection describes the principles affect SOA design for service layer.
|
| Principles affecting SOA design for service layer. |
The following are principles affecting SOA design for service layer:
Interface-based design: Services implement separately defined interfaces. The benefit is that multiple services can implement a common interface and a service can implement multiple interfaces.
Discoverable: Services should be discoverable and has a contract for consumers to use to request service.
Single instance: Each service is a single, always running instance that a number of clients communicate with.
Loosely coupled: Services are connected to other services and clients using standard, decoupled message-based methods such as XML document exchanges.
Asynchronous: In general, services use an asynchronous message passing approach; however, this is not required. Sometimes services may use synchronous message passing.
Some of these principles, such as interface-based design and discoverability, are also used in component-based development. The sum total of these attributes that differentiate a service-based application from an application developed using component architectures
| Component and services,commons and differences. |
Components and services are common in some features which may confuse about the terms and what they mean. Both service and component designs are interface-based design. A component is a piece of compiled code that can be assembled with other components to build applications. Components can easily be reused within the same application or across different applications. Components are usually associated with the OOP paradigm.
A service is implemented by one or more components and is a higher-level aggregation than a component. Component reuse works well in homogeneous environments while SOA establishes reuse in heterogeneous environments. This can be achieved by aggregating one or more components into a service and making them accessible using open standards. The following Figure shows mixing CBSD and SOA in software design.

Mixing Component Based and SOA in software design |
|