A basic SOA architecture is composed of a service provider, service and an optical service directory. Application-to-application messaging is used in the information exchange. The similarity between this model and that of straight web services is very visible, with WSDL being the invocation contract stored in a service directory where it can be queried and fetched via UDDI. Web services are actually a realization of SOA at its most basic level.

In this model, the basic scenario is as follows: First the service provider creates a service and decides to expose it and publishing is done by posting the service information on the service directory.

On other side, a service requester, in need of a certain, searches the service directory for one that meets the necessary criteria. Upon finding one and using the information available on the service directory, the service requester is able to directly contact the service provider in the correct way to fulfil the business need.

Here are some definitions of terms used in this section:

*Service provider: provider of services whose invocation contract and location are published.

*Service consumer: consumer of services matching his or her business need found in a service directory

*service directory: Directory for publishing and listing available service for consumers

The role played by an ESB in an SOA:

An ESB plays an important role in an SOA. At the base of its roles, it represents the backbone and infrastructure capable of connecting service provider’s service consumers. Below are the detailed roles of the ESB:

• Provides an integration infrastructure consistent with principles of SOA:

• Enforces the use of explicit implementation – independent interfaces to define services with loose coupling

• Uses communication protocols that stress location transparency and interoperability

• Promotes the definition of services that encapsulate reusable business functionalities

*Provides the means to manage the service infrastructure

*operates in the distributed, heterogeneous environment because it:

• Supports synchronous and asynchronous communication

• Uses standard interfaces and standard protocols

• Centralizes control and distributes processing

• Supports mediation to formulate the request /response as needed between different parties without the need of change in any

• Applies security and QOS to the soa project

The role of web services in SOA:

Although web services came before SOA, they represent the answer and realization of the SOA question seeking the need for interoperability between systems and platforms. This helped get SOA up and running quickly because it already had a supporting technology to satisfy its needs. It’s clear now that web services represent the cornerstone of the SOA and its recommended technology for interoperability.

Web services are the cornerstone of SOA because they:

• Enforce standards and ,thus ,promote compatibility and portability

• Are cross-platform and cross-language

• Are widely supported, making SOA relatively easy to adopt

• Are message-oriented

• Provided faster tooling support ,which speeds the implementation of SOA

The SOA life cycle and its different stages

SOA is characterized by a dynamic life cycle. Inherent in it is the possibility of continuous improvement of the processes ,which associated with the loose coupling enforced with the SOA, allows processes to improve as easily as disassembling and reassembling the building blocks (services in this case)without rework. This improves time to market and alignment of business and IT.

A famous diagram of the SOA life cycle includes the four interconnected hexagonal figures representing the four stages of SOA .as visible in the diagram in figure 5, the four stages form a closed loop, representing the continuous cycle of monitoring and improvement. Lets break this technique:

Model stage

• The model phase includes business analysis and requirements gathering, which are then followed by modelling and optimizing the business process. The model helps lay a common understanding of the process, its objectives, and outcomes. It also makes sure that the design meets the business requirement and provides a baseline to measure the performance later on.

Assemble stage

• During this phase, existing assets- such as enterprise resource planning (ERP), financial systems-that are needed in the modelled processes are wrapped as services, while non-existent needed functionalities are implemented and tested. After all services are available they can be orchestrated to implement the business process.

Deploy Stage

• During the deployment phase, the runtime environment can be configured to meet the required quality-of-service levels and security requirements. The environment can be scaled and optimized to be capable of reliability running the mission critical processes, and at the same time providing flexibility to make updates dynamically in case change.

Manage Stage

• During this phase, several aspects are managed and monitored, such as service assets, service availability and response times, and version control over services. An important role in this phase is monitoring key performance indicators of the processes. This helps to prevent or isolate and diagnose problems in real time as well as provide feedback on business process performance and bottlenecks to help improve it. This feedback is sent to the model phase, the first step, helping improve the process.