Service Oriented Architecture: What Is SOA? Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.

Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services. A service: Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)

Is self-contained May be composed of other services Is a black box to consumers of the service An architectural style is the combination of distinctive features in which architecture is performed or expressed. Overview of SOA The principle of service-orientation can apply throughout the enterprise architecture, but is most commonly applied to the organization of the software that supports the enterprise's business operations. With SOA, this software is organized as a set of software services. The services are supported by an infrastructure that, together with the services, improves information flow within the enterprise and between the enterprise and external enterprises.

Overview of a Service-Oriented Architecture The software services are used by the enterprises business operations. This frequently involves a human-computer interface, often implemented as a web interface using portals, etc., but it may also involve other interfaces, such as machine interfaces for process control. Specific sets of business processes, services, and interfaces are created in the context of a supporting infrastructure as service-based solutions. Each solution solves a particular business problem. The business operations themselves may be organized on the service-oriented principle. Indeed, there are many people who believe that the greatest benefits of SOA are obtained when it is applied to the business architecture. The infrastructure provides the execution environment for the software services. This includes the basic operating system and networking, and also includes specific support for software services, such as message passing and service discovery.

The infrastructure is managed via human-computer interfaces by technical staff who are responsible for all aspects of operating the enterprises IT, including its availability, performance, and security. A major benefit of SOA is that it delivers enterprise agility, by enabling rapid development and modification of the software that supports the business processes. The infrastructure can provide for this by including facilities such as business-oriented scripting languages and model-driven implementation tools. These facilities support not only the creation of new software services, but also the modification and replacement of existing ones: the whole service lifecycle. They are used via human-computer interfaces by development staff. The infrastructure also provides for storage of enterprise information. SOA can enable easier flow of information within and between enterprises. The information is not locked up in specific services, as it often is in the so-called silo applications of earlier architecture styles, but is available to all the software services that need it. Service-orientation may extend to the design of the infrastructure, and many people advocate this, but it is not essential to service-oriented software architecture.

Introduction to Service-Oriented Architecture

Changing markets, increasing competitive pressures and evolving customer needs are placing greater pressure on IT to deliver greater flexibility and speed. Today, every organization is faced with the need to predict change in a global business environment, to rapidly respond to competitors, and to best exploit organizational assets for growth. In response to these challenges, leading companies are adopting service-oriented architecture (SOA) as a means of delivering on these requirements by overcoming the complexity of their application and IT environments. SOA provides an enterprise architecture that supports building connected enterprise applications to provide solutions to business problems. SOA facilitates the development of enterprise applications as modular business Web services that can be easily integrated and reused, creating a truly flexible, adaptable IT infrastructure. You can move and reconfigure pieces, turning your systems into the IT equivalent of Lego blocks. The components of Oracle SOA Suite benefit from common capabilities, including a single deployment, management, and tooling model, end-to-end security, and unified metadata management. Oracle SOA Suite is unique in that it provides the following set of integrated capabilities:

Advances:

Messaging Service discovery Orchestration Web services management and security Business rules Events framework Business activity monitoring

Interoperability: SOA, and the industry standards underpinning it, enable existing siloed applications to interoperate seamlessly and in an easier-to-maintain manner than any traditional EAI solution. Increased reuse: Once legacy systems and applications are service enabled, these services can be reused, which results in reduced ongoing development costs and results in reduced time to market. Further, business processes built as an orchestration of services can also be exposed as services, further increasing reuse. More agile business processes: SOA reduces the gap between the business process model and implementation. This enables changes to business processes already implemented as orchestrations of services to be easily captured and implemented. Improved visibility: SOA can give improved business visibility by enabling business capabilities exposed as services, and the status of in-flight business processes automated with business activity monitoring, to be rapidly integrated into service-enabled enterprise portals, aiding business decision-making. Reduced maintenance costs: SOA development encourages duplicated overlapping business capabilities (services) that span multiple applications and systems to be consolidated into a small number of shared services. SOA development enables elimination of redundant services and reduces the cost of maintaining systems by providing a single point of change for application logic. Further, SOA gives IT the means to gradually phase out legacy systems and applications, while

minimizing disruption to the applications that are built on or are integrated with them using SOA principles. This process frees up funds for new projects.

Compliance and governance: By realizing better and more standardized operational procedures, SOA provides the basis for a comprehensive security solution, and enables better visibility into business operations and exception conditions.

Introduction to Oracle SOA Suite Components

Oracle SOA Suite provides a comprehensive suite of components for developing, securing, and monitoring service-oriented architecture (SOA). Service components (BPEL process, business rule, human task, and mediator) are the building blocks that you use to construct an SOA composite application. The Service Infrastructure provides the internal message transport infrastructure capabilities for connecting service components and enabling data flow. Service engines for the components process the message information received from the Service Infrastructure. See SOA Composite Application Architecture for more information about service components. Oracle Business Activity Monitoring consumes data transported over the Service Infrastructure, providing powerful business insight capabilities. The following components comprise an Oracle SOA Suite installation:

Service Infrastructure Oracle Mediator Oracle Adapters Business Events and Events Delivery Network Oracle Metadata Repository Oracle Business Rules Oracle WSM Policy Manager Oracle BPEL Process Manager Human Workflow Oracle Business Activity Monitoring Oracle User Messaging Service Oracle B2B Oracle JDeveloper Oracle Enterprise Manager

The following components are included with Oracle SOA Suite, but available as a separate download:

Oracle Service Bus Oracle Complex Event Processing

Both the Oracle Service Bus and the Service Infrastructure share common components, including Oracle Adapters, Oracle Metadat a Repository, and the UDDI registry. The UDDI registry is available with the Oracle Service Registry, which is a separately licensable component. See Oracle Service Registry for more information. In addition, several separately licensable products interoperate with Oracle SOA Suite components. See Interoperability with Other Oracle Products for more information.

Oracle Adapters
Oracle Adapters use JCA technology to connect external systems to the Oracle SOA Suite. Oracle SOA Suite provides the following technology adapters to integrate with transport protocols, data stores, and messaging middleware:

BAM FTP Java Messaging Service (JMS) Advanced Queuing (AQ) Files Message Queuing (MQ) Series

Oracle BPEL Process Manager

Oracle BPEL Process Manager provides the standard for assembling a set of discrete services into an end-to-end process flow, radically reducing the cost and complexity of process integration initiatives. Oracle BPEL Process Manager enables you to orchestrate synchronous and asynchronous services into end-to-end BPEL process flows. You integrate BPEL processes with external services (known as partner links). You also integrate technology adapters and services, such as human tasks, transformations, notifications, and business rules within the process.

Life Cycle of an SOA Composite Application

The basic life cycle of an SOA composite application is as follows: 1. 2. 3. 4. Use Oracle JDeveloper to design an SOA composite application with various SOA components. Package the composite application for deployment. Deploy the SOA composite application to the SOA Infrastructure. The SOA Infrastructure is a Java EE-compliant application running in Oracle WebLogic Server. The application manages composites and their life cycle, service engines, and binding components. Use Oracle Enterprise Manager Fusion Middleware Control to monitor and manage the composite application for a farm's SOA infrastructure.

SOA Composite Application Architecture

An SOA composite is an assembly of services, service components, and references designed and deployed together in a single application. Wiring between the service, service component, and reference enable message communication. The composite processes the information described in the messages. The graphic provides an example of a composite that includes a mediator service component and a BPEL service component, an inbound service binding component, and an outbound reference binding component. Service Components Service components are the building blocks of an SOA composite application. Each service component is hosted in its own service engine container. Messages sent to the service engine are targeted at specific service components. For example, a message targeted for a BPEL process is sent to the BPEL service engine. Service engines process the message information received from the . The following service components are available. There is a corresponding service engine of the same name for each service component. All service engines can interact together in a single composite.

BPEL process For process orchestration and storage of synchronous or asynchronous process. You design a business process that integrates a series of business activities and services into an end-to-end process flow.

Business rules For designing a business decision based on rules.

Human task For modeling a workflow that describes the tasks for users or groups to perform as part of an endto-end business process flow.

Mediator For routing events (messages) between different components.

Services Services provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. These capabilities are used for contacting the SOA composite application components. The binding connectivity of the service describes the protocols that can communicate with the service, for example, SOAP/HTTP or a JCA adapter. References References enable messages to be sent from the SOA composite application to external services in the outside world.

Wires Wires enable you to graphically connect the following components in a single SOA composite application for message communication:

Services to service components Service components to other service components Service components to reference

What Are Composite Applications?

A composite application is a collection of software assets that have been assembled to provide a business capability. These assets are artifacts that can be deployed independently, enable composition, and leverage specific platform capabilities.

Figure 5. High-level representation of a composite application In the past, an enterprise's software assets were usually a set of independent business applications that were monolithic and poorly integrated with each other. However, to get the business benefits of composition, an enterprise must treat its software assets in a more granular manner, and different tiers of architecture will require different kinds of assets, such as presentation assets, application assets, and data assets. For example, a Web service might be an application asset, an OLAP cube might be a data asset, and a particular data-entry screen might be a presentation asset. An inventory of software assets by itself does not enable composite applications. This requires a platform with capabilities for compositionthat is, a platform that provides the ability to deploy assets separately from each other, and in combination with each other. In other words, these assets must be components, and the platform must providecontainers. Containers provided by the platform must be of different types, which map to the different tiers in the architecture. Enterprise architectures are usually decomposed into three tiers: presentation, application (or business logic), and data. So, the platform must provide containers for these. However the three-tier architecture assumes structured business processes and data, where all requirements are made known during the process of designing and building the system. By their very nature, composite applications presume that composition of solutions can occur after assets have been built and deployed, and so need to account explicitly for people-to-people interactions between information workers that are essential to get any business process complete. Usually, these interactions are not captured by structured processes or traditional business applications, and therefore it is critical to add a fourth tierthe productivity tierto account for these human interactions. This is shown in Figure 6.

Figure 6. The four tiers of a composite application (Click on the picture for a larger image) Traditional discussions around the architecture of business applications tend to focus on the application tier as being the connection between people and data. Typically, however, the application tier contains structured business logic, and this holds for discussions around Service-Oriented Architectures (SOAs), EnterpriseService Buses (ESBs), Service-Component Architectures (SCAs), or most other architectural perspectives in the industry todayincluding first-generation discussions around composite applications. However, building a composite application requires a mind-set that not only is the productivity tier a critical element of the stack, but also contains the most business value.

What Does a Composite Application Look Like?

A figurative representation of a composite application is shown in Figure 7, which shows a very abstract representation of an enterprise solution, deconstructed along the lines of Figure 6. At the top are information workers, who access business information and documents through portals that are role-specific views into the enterprise. They create specific documents during the course of business activities, and these activities are part of larger business processes. These processes coordinate the activities of people and systems. The activities of systems are controlled through process-specific business rules that invoke back-end LOB applications and resources through service interfaces. The activities of people plug into the process through events that are raised when documents that are specific to the process are created or modified. Then business rules are applied to the content of those documents, to extract information, transform it, and transfer it to the next stage of the process.

Figure 7. Deconstructing an enterprise application Today, most LOB applications are a collection of resources, hard-coded business processes, and inflexible user interfaces. However, based on the previous section, it is clear that enterprise solutions must be broken down into a collection of granular assets that can be assembled into composite applications. A high-level approach for doing this to any business process is listed in Table 1, and subsequent chapters will elaborate upon these steps:

Decompose the solution for a business process into software assets corresponding to the elements shown in Table 1.

Package all assets corresponding to a given business process into a "process pack" for redistribution and deployment. This would contain metadata and software components, as well as solution templates that combine them. The process pack would also contain service-interface definitions that would enable connections to other IT systems. These connections would be enabled by implementing the service interfaces, for example, to connect to LOB applications and data. The goal is to be able to layer a standardized business process easily onto any heterogeneous IT landscape. Deploy the process pack onto a platform that provides containers for the types of assets into which the solution has been decomposed. The platform should provide capabilities for rapid customization, personalization, reconfiguration, and assembly of assets. Connect the assets within the process pack to existing LOB systems and other enterprise resources by implementing the services interfaces. These connections could be made using Web services technologies, other kinds of custom adapters, or potentially even Internet protocols like RSS.

Table 1. List of application assets for composition

Documents Workflows Business activities Business rules Schemas Interfaces to connect to back-end systems (Web service APIs)

UI screens Data connections Authorizations Reports Metrics

Expected Benefits of Composition, and How to Achieve Them

Deployment of enterprise applications should be tied to business benefits in the Triple-A sense (agility, adaptability, alignment). These benefits must be demonstrated from two perspectives:

Solution-provider perspective (or Development perspective)This is the perspective of the organization that builds an enterprise application. This might be an Independent Software Vendor (ISV), a Systems Integrator (SI), or even an in-house IT department. The solution-provider perspective is concerned primarily with benefits gained in activities relating to designing, implementing, and deploying enterprise applications. Solution-consumer perspective (or User perspective)This is the perspective of the organization that uses an enterprise application. Typically, this is the business unit that commissioned the enterprise application. The solution-consumer perspective is concerned primarily with benefits gained by the business after the solution has gone into production.

The benefits of composition that can be reasonably expected in each of these two perspectives are listed here, along with some high-level best practices to achieve these expected benefits.

Alignment
Composition must promote alignment among key stakeholders. This could be internal alignment (align different groups within the enterprise) or external alignment (align with suppliers, customers, and partners).

Solution-provider perspective: Solutions should align existing IT assets with the needs of business owners. Solution-consumer perspective: It should be easy to assemble composite applications that align groups within a company, and also across organizational boundaries. Frequently, this will require applications that support cross-functional processes and enable collaboration.