Basic SOA architecture

Basic SOA architecture

Now let's take a look at some more complex, technical subjects, such as the role of the enterprise service bus (ESB), business processes, their choreography, and the role of Web services.

What constitutes a basic SOA architecture?

A basic SOA architecture is composed of a service provider, service, and an optional service directory. Application-to-application messaging is used in the information exchange.

The similarity between this 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 , the basic scenario is as follows: First the service provider creates a service and decides to expose it and publish it. Publishing is done by posting the service information on the service directory. On the other side, a service requester, in need of a certain service, 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 fulfill the business need.

Figure 1. Basic SOA architecture

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 services for consumers

Back to top

What's 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 providers and service consumers.

Below are the detailed roles of the ESB:

• Provides an integration infrastructure consistent with the 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

Back to top

What's 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.
• Provide faster tooling support, which speeds the implementation of SOA.

Back to top

What is choreography? How does it fit in the SOA big picture?

Business service choreography is concerned with the development and of business flow logic, independent from underlying services and business logic. This means that the process choreography cares about the sequence of events and how the events are related, but it doesn't care about the events themselves. This separation of concerns between process and services provides flexibility to easily change the processes without changing the core services. This follows the loose-coupling aim of SOA.

To describe business processes, an emerging standard, BPEL4WS, was created. BPEL4WS is layered over Web services standards. The compatibility of such standards enables processes to call underlying services and partner services in an open standards-based infrastructure.

A process that's defined in the BPEL4WS is composed of:

• The activities, which are the individual business steps within the process. The activities can be basic or formed of other activities (structured).
• Partner links, which specify external entities that interact with the process, or vice versa, using WSDL interfaces.
• Variables that store messages passed between activities, thus, representing state.
• Correlation sets, used to correlate multiple service requests or response messages with the same business process instance.
• Fault handlers to deal with exceptional situations that can occur when a business process runs.
• Event handlers, which receive and process messages in parallel to the normal process.
• Compensation handlers, which specify the compensation logic to undo an activity or more when an exception happens.

Human tasks

Business choreography also provides support for human tasks, which are components involving human intervention either with a service or with another person. An example is managerial approval on travel requests or handling a customer request by an individual.

The types of human tasks are:

• Participating tasks: These are initiated by the system (process), which requires a human response to continue . The system initiates the task and an individual from the candidate executers claims the task and executes it. Then she provides the output back to the system, notifying it of its completion. An example for this is a travel reimbursement process awaiting manager approval.

  Figure 2. Participating task members and interactions
  

• Originating tasks: As their name signifies, these are initiated by a person through a user interface. They target a system; a person creates an originating task and starts it; and a request is sent to the system to run the services that are needed. As soon as the system finishes executing, a notification is sent to the initiator. An example of such a task is the initiation of a travel reimbursement process by an employee.

  Figure 3. Originating task members and interactions
  

• Purely human tasks: These are, like originating human tasks, created and started by a person. And, like participating human tasks, they target another person who then claims and completes the task. Purely human tasks don't interact with business processes or other Web services. They're not automated tasks, yet they pass through the same cycle of assignment and notifications.

  Figure 4. Purely human task members and interactions
  

It's logical that human tasks can take much more time than automated tasks, which raises another question: Can processes afford the interruption and wait time caused by human tasks? The answer is yes. And to get into more detail, let's tackle the subject of business process types.

Business process types

Business processes can be either long-running or micro-flow:

• Long running processes are interruptible and can also run in several transactions. They can wait for external stimuli, like those resulting from the use of human tasks. A rule of thumb is that if a process contains a human task, then the process must be long running. Long-running processes can also contain both synchronous and asynchronous services. Long-running processes store each intermediate process state to be forward-recoverable.
• Micro-flows run in a single thread without interruption. They are also called noninterruptible business processes. Micro-flows run in only one transaction, are short in duration, and consist of synchronous services only.

Back to top

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.

Figure 5. The four stages of the SOA life cycle

Let's break these down:

Model stage

The phase includes business analysis and requirements gathering, which are then followed by ing and optimizing the business process. The 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, IBM CICS® applications, and so on)—that are needed in the ed processes are wrapped as services, while nonexisting 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 reliably running the mission-critical processes, and at the same time providing flexibility to make updates dynamically in case of change.

Manage stage

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

 Source:
https://www6.software.ibm.com/developerworks/education/ws-soa-ibmcertified/section5.html