Why SOA is different

A few years ago, distributed object technology, in the guise of CORBA and COM+, was going to provide benefits of reuse. Prior to that, third and fourth generation languages such as C++ and Smalltalk (based on object technology) were to provide the same benefit. Even earlier, the same claims were made for structured programming. So why is SOA different?

Terminology

The use of terms such as services and processes allows business and IT to talk about items in the same way, improving communication, and reducing impedance mismatch between the two. The importance of this is greater than what it appears at first because it drives IT to build and structure its systems around the business rather than vice versa.

Interoperability

In the past, there have been competing platforms for the latest software development fad. This manifested itself as CORBA and COM+, Smalltalk and C++, Pascal and C. However, this time around, the standards are not based upon the physical implementation, but upon the service interfaces and wire protocols. In addition, these standards are generally text-based to avoid issues around conversion between binary forms. This allows services implemented in C# under Windows to inter-operate with Java or PL/SQL services running on Oracle SOA Suite under Windows, Linux, or Unix. The major players Oracle, Microsoft, IBM, SAP, and others have agreed on how to inter-operate together. This agreement has always been missing in the past.

Note

WS basic profile

There is an old IT joke that standards are great, there are so many to choose from! Fortunately, the SOA vendors have recognized this and have collaborated to create a basic profile, or collections of standards that focus on interoperability. This is known as WS basic profile and details the key web service standards that all vendors should implement to allow for interoperability. SOA Suite supports this basic profile as well as additional standards.

Extension and evolution

SOA recognizes that there are existing assets in the IT landscape and does not force these to be replaced, preferring instead to encapsulate and later extend these resources. SOA may be viewed as a boundary technology that reverses many of the earlier development trends. Instead of specifying how systems are built at the lowest level, it focuses on how services are described and how they inter-operate in a standards-based world.

Reuse in place

A final major distinguishing feature for SOA is the concept of reuse in place. Most reuse technologies in the past have focused on reuse through libraries, at best sharing a common implementation on a single machine through the use of dynamic link libraries. SOA focuses not only on reuse of the code functionality, but also upon the reuse of existing machine resources to execute that code. When a service is reused, the same physical servers with their associated memory and CPU are shared across a larger client base. This is good from the perspective of providing a consistent location to enforce code changes, security constraints, and logging policies, but it does mean that the performance of existing users may be impacted if care is not taken in how services are reused.

Note

Client responsibility in service contracts

As SOA is about reuse in place of existing machine resources as well as software resources, it is important that part of the service contract specifies the expected usage a client will make of a service. Imposing this constraint on the client is important for efficient sizing of the services being used by the client.

Terminology

The use of terms such as services and processes allows business and IT to talk about items in the same way, improving communication, and reducing impedance mismatch between the two. The importance of this is greater than what it appears at first because it drives IT to build and structure its systems around the business rather than vice versa.

Interoperability

In the past, there have been competing platforms for the latest software development fad. This manifested itself as CORBA and COM+, Smalltalk and C++, Pascal and C. However, this time around, the standards are not based upon the physical implementation, but upon the service interfaces and wire protocols. In addition, these standards are generally text-based to avoid issues around conversion between binary forms. This allows services implemented in C# under Windows to inter-operate with Java or PL/SQL services running on Oracle SOA Suite under Windows, Linux, or Unix. The major players Oracle, Microsoft, IBM, SAP, and others have agreed on how to inter-operate together. This agreement has always been missing in the past.

Note

WS basic profile

There is an old IT joke that standards are great, there are so many to choose from! Fortunately, the SOA vendors have recognized this and have collaborated to create a basic profile, or collections of standards that focus on interoperability. This is known as WS basic profile and details the key web service standards that all vendors should implement to allow for interoperability. SOA Suite supports this basic profile as well as additional standards.

Extension and evolution

SOA recognizes that there are existing assets in the IT landscape and does not force these to be replaced, preferring instead to encapsulate and later extend these resources. SOA may be viewed as a boundary technology that reverses many of the earlier development trends. Instead of specifying how systems are built at the lowest level, it focuses on how services are described and how they inter-operate in a standards-based world.

Reuse in place

A final major distinguishing feature for SOA is the concept of reuse in place. Most reuse technologies in the past have focused on reuse through libraries, at best sharing a common implementation on a single machine through the use of dynamic link libraries. SOA focuses not only on reuse of the code functionality, but also upon the reuse of existing machine resources to execute that code. When a service is reused, the same physical servers with their associated memory and CPU are shared across a larger client base. This is good from the perspective of providing a consistent location to enforce code changes, security constraints, and logging policies, but it does mean that the performance of existing users may be impacted if care is not taken in how services are reused.

Note

Client responsibility in service contracts

As SOA is about reuse in place of existing machine resources as well as software resources, it is important that part of the service contract specifies the expected usage a client will make of a service. Imposing this constraint on the client is important for efficient sizing of the services being used by the client.

Interoperability

In the past, there have been competing platforms for the latest software development fad. This manifested itself as CORBA and COM+, Smalltalk and C++, Pascal and C. However, this time around, the standards are not based upon the physical implementation, but upon the service interfaces and wire protocols. In addition, these standards are generally text-based to avoid issues around conversion between binary forms. This allows services implemented in C# under Windows to inter-operate with Java or PL/SQL services running on Oracle SOA Suite under Windows, Linux, or Unix. The major players Oracle, Microsoft, IBM, SAP, and others have agreed on how to inter-operate together. This agreement has always been missing in the past.

Note

WS basic profile

There is an old IT joke that standards are great, there are so many to choose from! Fortunately, the SOA vendors have recognized this and have collaborated to create a basic profile, or collections of standards that focus on interoperability. This is known as WS basic profile and details the key web service standards that all vendors should implement to allow for interoperability. SOA Suite supports this basic profile as well as additional standards.

Extension and evolution

SOA recognizes that there are existing assets in the IT landscape and does not force these to be replaced, preferring instead to encapsulate and later extend these resources. SOA may be viewed as a boundary technology that reverses many of the earlier development trends. Instead of specifying how systems are built at the lowest level, it focuses on how services are described and how they inter-operate in a standards-based world.

Reuse in place

A final major distinguishing feature for SOA is the concept of reuse in place. Most reuse technologies in the past have focused on reuse through libraries, at best sharing a common implementation on a single machine through the use of dynamic link libraries. SOA focuses not only on reuse of the code functionality, but also upon the reuse of existing machine resources to execute that code. When a service is reused, the same physical servers with their associated memory and CPU are shared across a larger client base. This is good from the perspective of providing a consistent location to enforce code changes, security constraints, and logging policies, but it does mean that the performance of existing users may be impacted if care is not taken in how services are reused.

Note

Client responsibility in service contracts

As SOA is about reuse in place of existing machine resources as well as software resources, it is important that part of the service contract specifies the expected usage a client will make of a service. Imposing this constraint on the client is important for efficient sizing of the services being used by the client.

Extension and evolution

SOA recognizes that there are existing assets in the IT landscape and does not force these to be replaced, preferring instead to encapsulate and later extend these resources. SOA may be viewed as a boundary technology that reverses many of the earlier development trends. Instead of specifying how systems are built at the lowest level, it focuses on how services are described and how they inter-operate in a standards-based world.

Reuse in place

A final major distinguishing feature for SOA is the concept of reuse in place. Most reuse technologies in the past have focused on reuse through libraries, at best sharing a common implementation on a single machine through the use of dynamic link libraries. SOA focuses not only on reuse of the code functionality, but also upon the reuse of existing machine resources to execute that code. When a service is reused, the same physical servers with their associated memory and CPU are shared across a larger client base. This is good from the perspective of providing a consistent location to enforce code changes, security constraints, and logging policies, but it does mean that the performance of existing users may be impacted if care is not taken in how services are reused.

Note

Client responsibility in service contracts

As SOA is about reuse in place of existing machine resources as well as software resources, it is important that part of the service contract specifies the expected usage a client will make of a service. Imposing this constraint on the client is important for efficient sizing of the services being used by the client.

Reuse in place

A final major distinguishing feature for SOA is the concept of reuse in place. Most reuse technologies in the past have focused on reuse through libraries, at best sharing a common implementation on a single machine through the use of dynamic link libraries. SOA focuses not only on reuse of the code functionality, but also upon the reuse of existing machine resources to execute that code. When a service is reused, the same physical servers with their associated memory and CPU are shared across a larger client base. This is good from the perspective of providing a consistent location to enforce code changes, security constraints, and logging policies, but it does mean that the performance of existing users may be impacted if care is not taken in how services are reused.

Note

Client responsibility in service contracts

As SOA is about reuse in place of existing machine resources as well as software resources, it is important that part of the service contract specifies the expected usage a client will make of a service. Imposing this constraint on the client is important for efficient sizing of the services being used by the client.

Service Component Architecture (SCA)

We have spoken a lot about service reuse and composing new services out of existing services, but we have yet to indicate how this may be done. The Service Component Architecture in SOA Suite is a standard that is used to define how services in a composite application are connected. It also defines how a service may interact with other services.

As can be seen in the preceding screenshot, an SCA composite consists of several different parts.

Component

A component represents a piece of business logic. It may be process logic, such as a BPEL process, routing logic, such as a mediator, or some other SOA Suite component. In the next section, we will discuss the components of the SOA Suite. SCA also supports writing custom components in Java or other languages, but we will not cover that in this book.

Service

A service represents the interface provided by a component or by the SCA Assembly itself. This is the interface to be used by clients of the assembly or component. A service that is available from outside the composite is referred to as an External Service.

Reference

A reference is a dependency on a service provided by another component, another SCA Assembly, or by some external entity such as a remote web service. References to services outside the composite are referred to as External References.

Wire

Services and references are joined together by wires. A wire indicates a dependency between components or between a component and an external entity.

Note

It is important to note that wires show dependencies and not flow of control. In the example, the Mediator component may call the FileWriteService before or after invoking BPEL, or it may not invoke it at all.

Composite.xml

An SCA Assembly is described in a file named composite.xml. The format of this file is defined by the SCA standard and consists of the elements identified in the preceding screenshot.

Properties

The components in the SCA may have properties associated with them that can be customized as part of the deployment of an SCA Assembly. These properties are also described in the composite.xml.

Component

A component represents a piece of business logic. It may be process logic, such as a BPEL process, routing logic, such as a mediator, or some other SOA Suite component. In the next section, we will discuss the components of the SOA Suite. SCA also supports writing custom components in Java or other languages, but we will not cover that in this book.

Service

A service represents the interface provided by a component or by the SCA Assembly itself. This is the interface to be used by clients of the assembly or component. A service that is available from outside the composite is referred to as an External Service.

Reference

A reference is a dependency on a service provided by another component, another SCA Assembly, or by some external entity such as a remote web service. References to services outside the composite are referred to as External References.

Wire

Services and references are joined together by wires. A wire indicates a dependency between components or between a component and an external entity.

Note

It is important to note that wires show dependencies and not flow of control. In the example, the Mediator component may call the FileWriteService before or after invoking BPEL, or it may not invoke it at all.

Composite.xml

An SCA Assembly is described in a file named composite.xml. The format of this file is defined by the SCA standard and consists of the elements identified in the preceding screenshot.

Properties

The components in the SCA may have properties associated with them that can be customized as part of the deployment of an SCA Assembly. These properties are also described in the composite.xml.

Service

A service represents the interface provided by a component or by the SCA Assembly itself. This is the interface to be used by clients of the assembly or component. A service that is available from outside the composite is referred to as an External Service.

Reference

A reference is a dependency on a service provided by another component, another SCA Assembly, or by some external entity such as a remote web service. References to services outside the composite are referred to as External References.

Wire

Services and references are joined together by wires. A wire indicates a dependency between components or between a component and an external entity.

Note

It is important to note that wires show dependencies and not flow of control. In the example, the Mediator component may call the FileWriteService before or after invoking BPEL, or it may not invoke it at all.

Composite.xml

An SCA Assembly is described in a file named composite.xml. The format of this file is defined by the SCA standard and consists of the elements identified in the preceding screenshot.

Properties

The components in the SCA may have properties associated with them that can be customized as part of the deployment of an SCA Assembly. These properties are also described in the composite.xml.

Reference

A reference is a dependency on a service provided by another component, another SCA Assembly, or by some external entity such as a remote web service. References to services outside the composite are referred to as External References.

Wire

Services and references are joined together by wires. A wire indicates a dependency between components or between a component and an external entity.

Note

It is important to note that wires show dependencies and not flow of control. In the example, the Mediator component may call the FileWriteService before or after invoking BPEL, or it may not invoke it at all.

Composite.xml

An SCA Assembly is described in a file named composite.xml. The format of this file is defined by the SCA standard and consists of the elements identified in the preceding screenshot.

Properties

The components in the SCA may have properties associated with them that can be customized as part of the deployment of an SCA Assembly. These properties are also described in the composite.xml.

Wire

Services and references are joined together by wires. A wire indicates a dependency between components or between a component and an external entity.

Note

It is important to note that wires show dependencies and not flow of control. In the example, the Mediator component may call the FileWriteService before or after invoking BPEL, or it may not invoke it at all.

Composite.xml

An SCA Assembly is described in a file named composite.xml. The format of this file is defined by the SCA standard and consists of the elements identified in the preceding screenshot.

Properties

The components in the SCA may have properties associated with them that can be customized as part of the deployment of an SCA Assembly. These properties are also described in the composite.xml.

Composite.xml

An SCA Assembly is described in a file named composite.xml. The format of this file is defined by the SCA standard and consists of the elements identified in the preceding screenshot.

Properties

The components in the SCA may have properties associated with them that can be customized as part of the deployment of an SCA Assembly. These properties are also described in the composite.xml.

Properties

The components in the SCA may have properties associated with them that can be customized as part of the deployment of an SCA Assembly. These properties are also described in the composite.xml.

SOA Suite components

SOA Suite has a number of component parts, some of which may be licensed separately.

Services and adapters

The most basic unit of service-oriented architecture is the service. This may be provided directly by a web service-enabled piece of code or it may be exposed by encapsulating an existing resource.

The only way to access a service is through its defined interface. This interface may actually be part of the service or it may be a wrapper that provides a standard-based service interface on top of a more implementation-specific interface. Accessing the service in a consistent fashion isolates the client of the service from any details of its physical implementation.

Services are defined by a specific interface, usually specified in a Web Service Description Language (WSDL) file. A WSDL file specifies the operations supported by the service. Each operation describes the expected format of the input message and if a message is returned it also describes the format of that message. Services are often surfaced through adapters that take an existing piece of functionality and "adapt" it to the SOA world, so that it can interact with other SOA Suite components. An example of an adapter is the file adapter that allows a file to be read or written to. The act of reading or writing the file is encapsulated into a service interface. This service interface can then be used to receive service requests by reading a file or to create service requests by writing a file.

Out of the box, the SOA Suite includes licenses for the following adapters:

File adapter
FTP adapter
Database adapter
JMS adapter
MQ adapter
AQ adapter
Socket adapter
BAM adapter

The database adapter and the file adapter are explored in more detail in Chapter 3, Service-enabling Existing Systems, while the BAM adapter is discussed in Chapter 9, Building Real-time Dashboards. There is also support for other non-SOAP transports and styles such as plain HTTP, REST, and Java.

Services are the most important part of service-oriented architecture, and in this book, we focus on how to define their interfaces and how to best assemble services together to create composite services with a value beyond the functionality of a single atomic service.

ESB – service abstraction layer

To avoid service location and format dependencies, it is desirable to access services through an Enterprise Service Bus (ESB). This provides a layer of abstraction over the service and allows transformation of data between formats. The ESB is aware of the physical endpoint locations of services and acts to virtualize services.

Services may be viewed as being plugged into the Service Bus.

An Enterprise Service Bus is optimized for routing and transforming service requests between components. By abstracting the physical location of a service, an ESB allows services to be moved to different locations without impacting the clients of those services. The ability of an ESB to transform data from one format to another also allows for changes in service contracts to be accommodated without recoding client services. The Service Bus may also be used to validate that messages conform to interface contracts and to enrich messages by adding additional information to them as part of the message transformation process.

Oracle Service Bus and Oracle Mediator

Note that the SOA Suite contains both the Oracle Service Bus (formerly AquaLogic Service Bus, now known as OSB) and the Oracle Mediator. OSB provides more powerful service abstraction capabilities that will be explored in Chapter 4, Loosely-coupling Services. Beyond simple transformation, it can also perform other functions such as throttling of target services. It is also easier to modify service endpoints in the runtime environment with OSB.

The stated direction by Oracle is for the Oracle Service Bus to be the preferred ESB for interactions outside the SOA Suite. Interactions within the SOA Suite may sometimes be better dealt with by the Oracle Mediator component in the SOA Suite, but we believe that for most cases, the Oracle Service Bus will provide a better solution and so that is what we have focused on within this book. However, in the current release, the Oracle Service Bus only executes on the Oracle WebLogic platform. Therefore, when running SOA Suite on non-Oracle platforms, there are two choices:

Use only the Oracle Mediator
Run Oracle Service Bus on a WebLogic Server while running the rest of SOA Suite on the non-Oracle platform

Later releases of the SOA Suite will support Oracle Service Bus on non-Oracle platforms such as WebSphere.

Service orchestration – the BPEL process manager

In order to build composite services, that is, services constructed from other services, we need a layer that can orchestrate, or tie together, multiple services into a single larger service. Simple service orchestrations can be done within the Oracle Service Bus, but more complex orchestrations require additional functionality. These service orchestrations may be thought of as processes, some of which are low-level processes and others are high-level business processes.

Business Process Execution Language (BPEL) is the standard way to describe processes in the SOA world, a task often referred to as service orchestration. The BPEL process manager in SOA Suite includes support for the BPEL 1.1 standard, with most constructs from BPEL 2.0 also being supported. BPEL allows multiple services to be linked to each other as part of a single managed process. The processes may be short running (taking seconds and minutes) or long running (taking hours and days).

The BPEL standard says nothing about how people interact with it, but BPEL process manager includes a Human Workflow component that provides support for human interaction with processes.

The BPEL process manager may also be purchased as a standalone component, in which case, it ships with the Human Workflow support and the same adapters, as included in the SOA Suite.

We explore the BPEL process manager in more detail in Chapter 5, Using BPEL to Build Composite Services and Business Processes and Chapter 14, Error Handling. Human workflow is examined in Chapter 6, Adding in Human Workflow and Chapter 17, Workflow Patterns.

Oracle also packages the BPEL process manager with the Oracle Business Process Management (BPM) Suite. This package includes the former AquaLogic BPM product (acquired when BEA bought Fuego), now known as Oracle BPM. Oracle positions BPEL as a system-centric process engine with support for human workflow, while BPM is positioned as human-centric process engine with support for system interaction.

Rules

Business decision-making may be viewed as a service within SOA. A rules engine is the physical implementation of this service.

SOA Suite includes a powerful rules engine that allows key business decision logic to be abstracted out of individual services and managed in a single repository.

In Chapter 7, Using Business Rules to Define Decision Points and in Chapter 18, Using Business Rules to Implement Services, we investigate how to use the rules engine.

Security and monitoring

One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.

Enterprise Manager serves as a policy manager for security, providing a centralized service for policy enforcement points to obtain their policies. Policy enforcement points, termed interceptors in SOA Suite 11g, are responsible for applying security policy, ensuring that only requests that comply with the policy are accepted.

Security policy may also be applied through the Service Bus. Although policy management is done in the Service Bus rather than in the Enterprise Manager, the direction is for Oracle to have a common policy management in a future release.

Applying security policies is covered in Chapter 21, Defining Security and Management Policies.

Active monitoring – BAM

It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.

Business Activity Monitoring is part of the SOA Suite and provides a real-time view of processes and services data to end users. BAM is covered in Chapter 9, Building Real-time Dashboards.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Services and adapters

The most basic unit of service-oriented architecture is the service. This may be provided directly by a web service-enabled piece of code or it may be exposed by encapsulating an existing resource.

The only way to access a service is through its defined interface. This interface may actually be part of the service or it may be a wrapper that provides a standard-based service interface on top of a more implementation-specific interface. Accessing the service in a consistent fashion isolates the client of the service from any details of its physical implementation.

Services are defined by a specific interface, usually specified in a Web Service Description Language (WSDL) file. A WSDL file specifies the operations supported by the service. Each operation describes the expected format of the input message and if a message is returned it also describes the format of that message. Services are often surfaced through adapters that take an existing piece of functionality and "adapt" it to the SOA world, so that it can interact with other SOA Suite components. An example of an adapter is the file adapter that allows a file to be read or written to. The act of reading or writing the file is encapsulated into a service interface. This service interface can then be used to receive service requests by reading a file or to create service requests by writing a file.

Out of the box, the SOA Suite includes licenses for the following adapters:

File adapter
FTP adapter
Database adapter
JMS adapter
MQ adapter
AQ adapter
Socket adapter
BAM adapter

The database adapter and the file adapter are explored in more detail in Chapter 3, Service-enabling Existing Systems, while the BAM adapter is discussed in Chapter 9, Building Real-time Dashboards. There is also support for other non-SOAP transports and styles such as plain HTTP, REST, and Java.

Services are the most important part of service-oriented architecture, and in this book, we focus on how to define their interfaces and how to best assemble services together to create composite services with a value beyond the functionality of a single atomic service.

ESB – service abstraction layer

To avoid service location and format dependencies, it is desirable to access services through an Enterprise Service Bus (ESB). This provides a layer of abstraction over the service and allows transformation of data between formats. The ESB is aware of the physical endpoint locations of services and acts to virtualize services.

Services may be viewed as being plugged into the Service Bus.

An Enterprise Service Bus is optimized for routing and transforming service requests between components. By abstracting the physical location of a service, an ESB allows services to be moved to different locations without impacting the clients of those services. The ability of an ESB to transform data from one format to another also allows for changes in service contracts to be accommodated without recoding client services. The Service Bus may also be used to validate that messages conform to interface contracts and to enrich messages by adding additional information to them as part of the message transformation process.

Oracle Service Bus and Oracle Mediator

Note that the SOA Suite contains both the Oracle Service Bus (formerly AquaLogic Service Bus, now known as OSB) and the Oracle Mediator. OSB provides more powerful service abstraction capabilities that will be explored in Chapter 4, Loosely-coupling Services. Beyond simple transformation, it can also perform other functions such as throttling of target services. It is also easier to modify service endpoints in the runtime environment with OSB.

The stated direction by Oracle is for the Oracle Service Bus to be the preferred ESB for interactions outside the SOA Suite. Interactions within the SOA Suite may sometimes be better dealt with by the Oracle Mediator component in the SOA Suite, but we believe that for most cases, the Oracle Service Bus will provide a better solution and so that is what we have focused on within this book. However, in the current release, the Oracle Service Bus only executes on the Oracle WebLogic platform. Therefore, when running SOA Suite on non-Oracle platforms, there are two choices:

Use only the Oracle Mediator
Run Oracle Service Bus on a WebLogic Server while running the rest of SOA Suite on the non-Oracle platform

Later releases of the SOA Suite will support Oracle Service Bus on non-Oracle platforms such as WebSphere.

Service orchestration – the BPEL process manager

In order to build composite services, that is, services constructed from other services, we need a layer that can orchestrate, or tie together, multiple services into a single larger service. Simple service orchestrations can be done within the Oracle Service Bus, but more complex orchestrations require additional functionality. These service orchestrations may be thought of as processes, some of which are low-level processes and others are high-level business processes.

Business Process Execution Language (BPEL) is the standard way to describe processes in the SOA world, a task often referred to as service orchestration. The BPEL process manager in SOA Suite includes support for the BPEL 1.1 standard, with most constructs from BPEL 2.0 also being supported. BPEL allows multiple services to be linked to each other as part of a single managed process. The processes may be short running (taking seconds and minutes) or long running (taking hours and days).

The BPEL standard says nothing about how people interact with it, but BPEL process manager includes a Human Workflow component that provides support for human interaction with processes.

The BPEL process manager may also be purchased as a standalone component, in which case, it ships with the Human Workflow support and the same adapters, as included in the SOA Suite.

We explore the BPEL process manager in more detail in Chapter 5, Using BPEL to Build Composite Services and Business Processes and Chapter 14, Error Handling. Human workflow is examined in Chapter 6, Adding in Human Workflow and Chapter 17, Workflow Patterns.

Oracle also packages the BPEL process manager with the Oracle Business Process Management (BPM) Suite. This package includes the former AquaLogic BPM product (acquired when BEA bought Fuego), now known as Oracle BPM. Oracle positions BPEL as a system-centric process engine with support for human workflow, while BPM is positioned as human-centric process engine with support for system interaction.

Rules

Business decision-making may be viewed as a service within SOA. A rules engine is the physical implementation of this service.

SOA Suite includes a powerful rules engine that allows key business decision logic to be abstracted out of individual services and managed in a single repository.

In Chapter 7, Using Business Rules to Define Decision Points and in Chapter 18, Using Business Rules to Implement Services, we investigate how to use the rules engine.

Security and monitoring

One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.

Enterprise Manager serves as a policy manager for security, providing a centralized service for policy enforcement points to obtain their policies. Policy enforcement points, termed interceptors in SOA Suite 11g, are responsible for applying security policy, ensuring that only requests that comply with the policy are accepted.

Security policy may also be applied through the Service Bus. Although policy management is done in the Service Bus rather than in the Enterprise Manager, the direction is for Oracle to have a common policy management in a future release.

Applying security policies is covered in Chapter 21, Defining Security and Management Policies.

Active monitoring – BAM

It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.

Business Activity Monitoring is part of the SOA Suite and provides a real-time view of processes and services data to end users. BAM is covered in Chapter 9, Building Real-time Dashboards.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

ESB – service abstraction layer

To avoid service location and format dependencies, it is desirable to access services through an Enterprise Service Bus (ESB). This provides a layer of abstraction over the service and allows transformation of data between formats. The ESB is aware of the physical endpoint locations of services and acts to virtualize services.

Services may be viewed as being plugged into the Service Bus.

An Enterprise Service Bus is optimized for routing and transforming service requests between components. By abstracting the physical location of a service, an ESB allows services to be moved to different locations without impacting the clients of those services. The ability of an ESB to transform data from one format to another also allows for changes in service contracts to be accommodated without recoding client services. The Service Bus may also be used to validate that messages conform to interface contracts and to enrich messages by adding additional information to them as part of the message transformation process.

Oracle Service Bus and Oracle Mediator

Note that the SOA Suite contains both the Oracle Service Bus (formerly AquaLogic Service Bus, now known as OSB) and the Oracle Mediator. OSB provides more powerful service abstraction capabilities that will be explored in Chapter 4, Loosely-coupling Services. Beyond simple transformation, it can also perform other functions such as throttling of target services. It is also easier to modify service endpoints in the runtime environment with OSB.

The stated direction by Oracle is for the Oracle Service Bus to be the preferred ESB for interactions outside the SOA Suite. Interactions within the SOA Suite may sometimes be better dealt with by the Oracle Mediator component in the SOA Suite, but we believe that for most cases, the Oracle Service Bus will provide a better solution and so that is what we have focused on within this book. However, in the current release, the Oracle Service Bus only executes on the Oracle WebLogic platform. Therefore, when running SOA Suite on non-Oracle platforms, there are two choices:

Use only the Oracle Mediator
Run Oracle Service Bus on a WebLogic Server while running the rest of SOA Suite on the non-Oracle platform

Later releases of the SOA Suite will support Oracle Service Bus on non-Oracle platforms such as WebSphere.

Service orchestration – the BPEL process manager

In order to build composite services, that is, services constructed from other services, we need a layer that can orchestrate, or tie together, multiple services into a single larger service. Simple service orchestrations can be done within the Oracle Service Bus, but more complex orchestrations require additional functionality. These service orchestrations may be thought of as processes, some of which are low-level processes and others are high-level business processes.

Business Process Execution Language (BPEL) is the standard way to describe processes in the SOA world, a task often referred to as service orchestration. The BPEL process manager in SOA Suite includes support for the BPEL 1.1 standard, with most constructs from BPEL 2.0 also being supported. BPEL allows multiple services to be linked to each other as part of a single managed process. The processes may be short running (taking seconds and minutes) or long running (taking hours and days).

The BPEL standard says nothing about how people interact with it, but BPEL process manager includes a Human Workflow component that provides support for human interaction with processes.

The BPEL process manager may also be purchased as a standalone component, in which case, it ships with the Human Workflow support and the same adapters, as included in the SOA Suite.

We explore the BPEL process manager in more detail in Chapter 5, Using BPEL to Build Composite Services and Business Processes and Chapter 14, Error Handling. Human workflow is examined in Chapter 6, Adding in Human Workflow and Chapter 17, Workflow Patterns.

Oracle also packages the BPEL process manager with the Oracle Business Process Management (BPM) Suite. This package includes the former AquaLogic BPM product (acquired when BEA bought Fuego), now known as Oracle BPM. Oracle positions BPEL as a system-centric process engine with support for human workflow, while BPM is positioned as human-centric process engine with support for system interaction.

Rules

Business decision-making may be viewed as a service within SOA. A rules engine is the physical implementation of this service.

SOA Suite includes a powerful rules engine that allows key business decision logic to be abstracted out of individual services and managed in a single repository.

In Chapter 7, Using Business Rules to Define Decision Points and in Chapter 18, Using Business Rules to Implement Services, we investigate how to use the rules engine.

Security and monitoring

One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.

Enterprise Manager serves as a policy manager for security, providing a centralized service for policy enforcement points to obtain their policies. Policy enforcement points, termed interceptors in SOA Suite 11g, are responsible for applying security policy, ensuring that only requests that comply with the policy are accepted.

Security policy may also be applied through the Service Bus. Although policy management is done in the Service Bus rather than in the Enterprise Manager, the direction is for Oracle to have a common policy management in a future release.

Applying security policies is covered in Chapter 21, Defining Security and Management Policies.

Active monitoring – BAM

It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.

Business Activity Monitoring is part of the SOA Suite and provides a real-time view of processes and services data to end users. BAM is covered in Chapter 9, Building Real-time Dashboards.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Oracle Service Bus and Oracle Mediator

Note that the SOA Suite contains both the Oracle Service Bus (formerly AquaLogic Service Bus, now known as OSB) and the Oracle Mediator. OSB provides more powerful service abstraction capabilities that will be explored in Chapter 4, Loosely-coupling Services. Beyond simple transformation, it can also perform other functions such as throttling of target services. It is also easier to modify service endpoints in the runtime environment with OSB.

The stated direction by Oracle is for the Oracle Service Bus to be the preferred ESB for interactions outside the SOA Suite. Interactions within the SOA Suite may sometimes be better dealt with by the Oracle Mediator component in the SOA Suite, but we believe that for most cases, the Oracle Service Bus will provide a better solution and so that is what we have focused on within this book. However, in the current release, the Oracle Service Bus only executes on the Oracle WebLogic platform. Therefore, when running SOA Suite on non-Oracle platforms, there are two choices:

Use only the Oracle Mediator
Run Oracle Service Bus on a WebLogic Server while running the rest of SOA Suite on the non-Oracle platform

Later releases of the SOA Suite will support Oracle Service Bus on non-Oracle platforms such as WebSphere.

Service orchestration – the BPEL process manager

In order to build composite services, that is, services constructed from other services, we need a layer that can orchestrate, or tie together, multiple services into a single larger service. Simple service orchestrations can be done within the Oracle Service Bus, but more complex orchestrations require additional functionality. These service orchestrations may be thought of as processes, some of which are low-level processes and others are high-level business processes.

Business Process Execution Language (BPEL) is the standard way to describe processes in the SOA world, a task often referred to as service orchestration. The BPEL process manager in SOA Suite includes support for the BPEL 1.1 standard, with most constructs from BPEL 2.0 also being supported. BPEL allows multiple services to be linked to each other as part of a single managed process. The processes may be short running (taking seconds and minutes) or long running (taking hours and days).

The BPEL standard says nothing about how people interact with it, but BPEL process manager includes a Human Workflow component that provides support for human interaction with processes.

The BPEL process manager may also be purchased as a standalone component, in which case, it ships with the Human Workflow support and the same adapters, as included in the SOA Suite.

We explore the BPEL process manager in more detail in Chapter 5, Using BPEL to Build Composite Services and Business Processes and Chapter 14, Error Handling. Human workflow is examined in Chapter 6, Adding in Human Workflow and Chapter 17, Workflow Patterns.

Oracle also packages the BPEL process manager with the Oracle Business Process Management (BPM) Suite. This package includes the former AquaLogic BPM product (acquired when BEA bought Fuego), now known as Oracle BPM. Oracle positions BPEL as a system-centric process engine with support for human workflow, while BPM is positioned as human-centric process engine with support for system interaction.

Rules

Business decision-making may be viewed as a service within SOA. A rules engine is the physical implementation of this service.

SOA Suite includes a powerful rules engine that allows key business decision logic to be abstracted out of individual services and managed in a single repository.

In Chapter 7, Using Business Rules to Define Decision Points and in Chapter 18, Using Business Rules to Implement Services, we investigate how to use the rules engine.

Security and monitoring

One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.

Enterprise Manager serves as a policy manager for security, providing a centralized service for policy enforcement points to obtain their policies. Policy enforcement points, termed interceptors in SOA Suite 11g, are responsible for applying security policy, ensuring that only requests that comply with the policy are accepted.

Security policy may also be applied through the Service Bus. Although policy management is done in the Service Bus rather than in the Enterprise Manager, the direction is for Oracle to have a common policy management in a future release.

Applying security policies is covered in Chapter 21, Defining Security and Management Policies.

Active monitoring – BAM

It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.

Business Activity Monitoring is part of the SOA Suite and provides a real-time view of processes and services data to end users. BAM is covered in Chapter 9, Building Real-time Dashboards.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Service orchestration – the BPEL process manager

In order to build composite services, that is, services constructed from other services, we need a layer that can orchestrate, or tie together, multiple services into a single larger service. Simple service orchestrations can be done within the Oracle Service Bus, but more complex orchestrations require additional functionality. These service orchestrations may be thought of as processes, some of which are low-level processes and others are high-level business processes.

Business Process Execution Language (BPEL) is the standard way to describe processes in the SOA world, a task often referred to as service orchestration. The BPEL process manager in SOA Suite includes support for the BPEL 1.1 standard, with most constructs from BPEL 2.0 also being supported. BPEL allows multiple services to be linked to each other as part of a single managed process. The processes may be short running (taking seconds and minutes) or long running (taking hours and days).

The BPEL standard says nothing about how people interact with it, but BPEL process manager includes a Human Workflow component that provides support for human interaction with processes.

The BPEL process manager may also be purchased as a standalone component, in which case, it ships with the Human Workflow support and the same adapters, as included in the SOA Suite.

We explore the BPEL process manager in more detail in Chapter 5, Using BPEL to Build Composite Services and Business Processes and Chapter 14, Error Handling. Human workflow is examined in Chapter 6, Adding in Human Workflow and Chapter 17, Workflow Patterns.

Oracle also packages the BPEL process manager with the Oracle Business Process Management (BPM) Suite. This package includes the former AquaLogic BPM product (acquired when BEA bought Fuego), now known as Oracle BPM. Oracle positions BPEL as a system-centric process engine with support for human workflow, while BPM is positioned as human-centric process engine with support for system interaction.

Rules

Business decision-making may be viewed as a service within SOA. A rules engine is the physical implementation of this service.

SOA Suite includes a powerful rules engine that allows key business decision logic to be abstracted out of individual services and managed in a single repository.

In Chapter 7, Using Business Rules to Define Decision Points and in Chapter 18, Using Business Rules to Implement Services, we investigate how to use the rules engine.

Security and monitoring

One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.

Enterprise Manager serves as a policy manager for security, providing a centralized service for policy enforcement points to obtain their policies. Policy enforcement points, termed interceptors in SOA Suite 11g, are responsible for applying security policy, ensuring that only requests that comply with the policy are accepted.

Security policy may also be applied through the Service Bus. Although policy management is done in the Service Bus rather than in the Enterprise Manager, the direction is for Oracle to have a common policy management in a future release.

Applying security policies is covered in Chapter 21, Defining Security and Management Policies.

Active monitoring – BAM

It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.

Business Activity Monitoring is part of the SOA Suite and provides a real-time view of processes and services data to end users. BAM is covered in Chapter 9, Building Real-time Dashboards.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Rules

Business decision-making may be viewed as a service within SOA. A rules engine is the physical implementation of this service.

SOA Suite includes a powerful rules engine that allows key business decision logic to be abstracted out of individual services and managed in a single repository.

In Chapter 7, Using Business Rules to Define Decision Points and in Chapter 18, Using Business Rules to Implement Services, we investigate how to use the rules engine.

Security and monitoring

One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.

Enterprise Manager serves as a policy manager for security, providing a centralized service for policy enforcement points to obtain their policies. Policy enforcement points, termed interceptors in SOA Suite 11g, are responsible for applying security policy, ensuring that only requests that comply with the policy are accepted.

Security policy may also be applied through the Service Bus. Although policy management is done in the Service Bus rather than in the Enterprise Manager, the direction is for Oracle to have a common policy management in a future release.

Applying security policies is covered in Chapter 21, Defining Security and Management Policies.

Active monitoring – BAM

It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.

Business Activity Monitoring is part of the SOA Suite and provides a real-time view of processes and services data to end users. BAM is covered in Chapter 9, Building Real-time Dashboards.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Security and monitoring

One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.

Enterprise Manager serves as a policy manager for security, providing a centralized service for policy enforcement points to obtain their policies. Policy enforcement points, termed interceptors in SOA Suite 11g, are responsible for applying security policy, ensuring that only requests that comply with the policy are accepted.

Security policy may also be applied through the Service Bus. Although policy management is done in the Service Bus rather than in the Enterprise Manager, the direction is for Oracle to have a common policy management in a future release.

Applying security policies is covered in Chapter 21, Defining Security and Management Policies.

Active monitoring – BAM

It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.

Business Activity Monitoring is part of the SOA Suite and provides a real-time view of processes and services data to end users. BAM is covered in Chapter 9, Building Real-time Dashboards.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Active monitoring – BAM

It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.

Business Activity Monitoring is part of the SOA Suite and provides a real-time view of processes and services data to end users. BAM is covered in Chapter 9, Building Real-time Dashboards.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Business to Business – B2B

Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Complex Event Processing – CEP

As our services execute, we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events, on the other hand, often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time-based and series-based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA Suite that requires a complementary but different approach to the other SOA components.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

Event delivery network

Even the loose-coupling provided by a Service Bus is not always enough. We often wish to just publish events and let any interested parties be notified of the event. A new feature of SOA Suite 11g is the event delivery network, which allows events to be published without the publisher being aware of the target or targets. Subscribers can request to be notified of particular events, filtering them based on event domain, event type, and event content. We cover the event delivery network in Chapter 8, Using Business Events.

SOA Suite architecture

We will now examine how Oracle SOA Suite provides the services identified previously.

Top level

The SOA Suite is built on top of a Java Enterprise Edition (Java EE) infrastructure. Although SOA Suite is certified with several different Java EE servers, including IBM WebSphere, it will most commonly be used with the Oracle WebLogic server. The Oracle WebLogic Server (WLS) will probably always be the first available Java EE platform for SOA Suite and is the only platform that will be provided bundled with the SOA Suite to simplify installation. For the rest of this book, we will assume that you are running SOA Suite on the Oracle WebLogic server. If there are any significant differences when running on non-Oracle application servers, we will highlight them in the text.

In addition to a Java EE application server, the SOA Suite also requires a database. The SOA Suite is designed to run against any SQL database, but certification for non-Oracle databases has been slow in coming. The database is used to maintain configuration information and also records of runtime interactions. Oracle Database XE can be used with the SOA Suite, but it is not recommended for production deployments as it is not a supported configuration.

Component view

In a previous section, we examined the individual components of the SOA Suite and here we show them in context with the Java EE container and the database. Note that CEP does not run in an application server and OSB runs in a separate container to the other SOA Suite components.

All the services are executed within the context of the Java EE container, even though they may use that container in different ways. BPEL listens for events and updates processes based upon those events. Adapters typically make use of the Java EE containers connector architecture (JCA) to provide connectivity and notifications. Policy interceptors act as filters. Note that the Oracle Service Bus (OSB) is only available when the application server is a WebLogic server.

Implementation view

Oracle has put a lot of effort into making SOA Suite consistent in its use of underlying services. A number of lower-level services are reused consistently across components.

A Portability Layer provides an interface between the SOA Suite and the specifics of the JEE platform that hosts it.

At the lowest level, connectivity services, such as SCA, JCA adapters, JMS, and Web Service Framework, are shared by higher-level components.

A Service Layer exposes higher-level functions. The BPEL process manager is implemented by a combination of a BPEL engine and access to the Human Workflow engine. Rules is another shared service that is available to BPEL or other components.

A recursive example

The SOA Suite architecture is a good example of service-oriented design principles being applied. Common services have been identified and extracted to be shared across many components. The high-level services such as BPEL and ESB share some common services such as transformation and adapter services running on a standard Java EE container.

Top level

The SOA Suite is built on top of a Java Enterprise Edition (Java EE) infrastructure. Although SOA Suite is certified with several different Java EE servers, including IBM WebSphere, it will most commonly be used with the Oracle WebLogic server. The Oracle WebLogic Server (WLS) will probably always be the first available Java EE platform for SOA Suite and is the only platform that will be provided bundled with the SOA Suite to simplify installation. For the rest of this book, we will assume that you are running SOA Suite on the Oracle WebLogic server. If there are any significant differences when running on non-Oracle application servers, we will highlight them in the text.

In addition to a Java EE application server, the SOA Suite also requires a database. The SOA Suite is designed to run against any SQL database, but certification for non-Oracle databases has been slow in coming. The database is used to maintain configuration information and also records of runtime interactions. Oracle Database XE can be used with the SOA Suite, but it is not recommended for production deployments as it is not a supported configuration.

Component view

In a previous section, we examined the individual components of the SOA Suite and here we show them in context with the Java EE container and the database. Note that CEP does not run in an application server and OSB runs in a separate container to the other SOA Suite components.

All the services are executed within the context of the Java EE container, even though they may use that container in different ways. BPEL listens for events and updates processes based upon those events. Adapters typically make use of the Java EE containers connector architecture (JCA) to provide connectivity and notifications. Policy interceptors act as filters. Note that the Oracle Service Bus (OSB) is only available when the application server is a WebLogic server.

Implementation view

Oracle has put a lot of effort into making SOA Suite consistent in its use of underlying services. A number of lower-level services are reused consistently across components.

A Portability Layer provides an interface between the SOA Suite and the specifics of the JEE platform that hosts it.

At the lowest level, connectivity services, such as SCA, JCA adapters, JMS, and Web Service Framework, are shared by higher-level components.

A Service Layer exposes higher-level functions. The BPEL process manager is implemented by a combination of a BPEL engine and access to the Human Workflow engine. Rules is another shared service that is available to BPEL or other components.

A recursive example

The SOA Suite architecture is a good example of service-oriented design principles being applied. Common services have been identified and extracted to be shared across many components. The high-level services such as BPEL and ESB share some common services such as transformation and adapter services running on a standard Java EE container.

Component view

In a previous section, we examined the individual components of the SOA Suite and here we show them in context with the Java EE container and the database. Note that CEP does not run in an application server and OSB runs in a separate container to the other SOA Suite components.

All the services are executed within the context of the Java EE container, even though they may use that container in different ways. BPEL listens for events and updates processes based upon those events. Adapters typically make use of the Java EE containers connector architecture (JCA) to provide connectivity and notifications. Policy interceptors act as filters. Note that the Oracle Service Bus (OSB) is only available when the application server is a WebLogic server.

Implementation view

Oracle has put a lot of effort into making SOA Suite consistent in its use of underlying services. A number of lower-level services are reused consistently across components.

A Portability Layer provides an interface between the SOA Suite and the specifics of the JEE platform that hosts it.

At the lowest level, connectivity services, such as SCA, JCA adapters, JMS, and Web Service Framework, are shared by higher-level components.

A Service Layer exposes higher-level functions. The BPEL process manager is implemented by a combination of a BPEL engine and access to the Human Workflow engine. Rules is another shared service that is available to BPEL or other components.

A recursive example

The SOA Suite architecture is a good example of service-oriented design principles being applied. Common services have been identified and extracted to be shared across many components. The high-level services such as BPEL and ESB share some common services such as transformation and adapter services running on a standard Java EE container.

Implementation view

Oracle has put a lot of effort into making SOA Suite consistent in its use of underlying services. A number of lower-level services are reused consistently across components.

A Portability Layer provides an interface between the SOA Suite and the specifics of the JEE platform that hosts it.

At the lowest level, connectivity services, such as SCA, JCA adapters, JMS, and Web Service Framework, are shared by higher-level components.

A Service Layer exposes higher-level functions. The BPEL process manager is implemented by a combination of a BPEL engine and access to the Human Workflow engine. Rules is another shared service that is available to BPEL or other components.

A recursive example

The SOA Suite architecture is a good example of service-oriented design principles being applied. Common services have been identified and extracted to be shared across many components. The high-level services such as BPEL and ESB share some common services such as transformation and adapter services running on a standard Java EE container.

A recursive example

The SOA Suite architecture is a good example of service-oriented design principles being applied. Common services have been identified and extracted to be shared across many components. The high-level services such as BPEL and ESB share some common services such as transformation and adapter services running on a standard Java EE container.

JDeveloper

Everything we have spoken of so far has been related to the executable or runtime environment. Specialist tools are required to take advantage of this environment. It is possible to manually craft the assemblies and descriptors required to build a SOA Suite application, but it is not a practical proposition. Fortunately, Oracle provides JDeveloper free of charge to allow developers to build SOA Suite applications.

JDeveloper is actually a separate tool, but it has been developed in conjunction with SOA Suite so that virtually all facilities of SOA Suite are accessible through JDeveloper. One exception to this is the Oracle Service Bus, which in the current release does not have support in JDeveloper but instead has a different tool named WebLogic Workspace Studio. Although JDeveloper started life as a Java development tool, many users now never touch the Java side of JDeveloper, doing all their work in the SOA Suite components.

JDeveloper may be characterized as a model-based, wizard-driven development environment. Re-entrant wizards are used to guide the construction of many artifacts of the SOA Suite, including adapters and transformation.

JDeveloper has a consistent view that the code is also the model, so that graphical views are always in synchronization with the underlying code. It is possible to exercise some functionality of SOA Suite using the Eclipse platform, but to get full value out of the SOA Suite it is really necessary to use JDeveloper. The Eclipse platform does, however, provide the basis for the Service Bus designer, the Workspace Studio. There are some aspects of development that may be supported in both tools, but are easier in one than the other.

Other components

We have now touched on all the major components of the SOA Suite. There are, however, a few items that are either of a more limited interest or are outside the SOA Suite, but closely related to it.

Service repository and registry

Oracle has a service repository and registry product that is integrated with the SOA Suite but separate from it. The repository acts as a central repository for all SOA artifacts and can be used to support both developers and deployers in tracking dependencies between components both deployed and in development. The repository can publish SOA artifacts such as service definitions and locations to the service registry. The Oracle Service registry may be used to categorize and index services created. Users may then browse the registry to locate services. The service registry may also be used as a runtime location service for service endpoints.

BPA Suite

The Oracle BPA Suite is targeted at business process analysts who want a powerful repository-based tool to model their business processes. The BPA Suite is not an easy product to learn, and like all modeling tools, there is a price to pay for the descriptive power available. The fact of interest to SOA Suite developers is the ability for the BPA Suite and SOA Suite to exchange process models. Processes created in the BPA Suite may be exported to the SOA Suite for concrete implementation. Simulation of processes in the BPA Suite may be used as a useful guide for process improvement.

Links between the BPA Suite and the SOA Suite are growing stronger over time, and this provides a valuable bridge between business analysts and IT architects.

The BPM Suite

The Business Process Management Suite is focused on modeling and execution of business processes. As mentioned, it includes BPEL process manager to provide strong system-centric support for business processes, but the primary focus of the Suite is on modeling and executing processes in the BPM designer and BPM server. BPM server and BPEL process manager are converging on a single shared service implementation.

Portals and WebCenter

The SOA Suite has no real end-user interface outside the human workflow service. Frontends may be built using JDeveloper directly or they may be crafted as part of Oracle Portal, Oracle WebCenter, or another Portal or frontend builder. A number of portlets are provided to expose views of SOA Suite to end users through the portal. These are principally related to human workflow, but also include some views onto the BPEL process status. Portals can also take advantage of WSDL interfaces to provide a user interface onto services exposed by the SOA Suite.

Enterprise manager SOA management pack

Oracle's preferred management framework is Oracle Enterprise Manager. This is provided as a base set of functionality with a large number of management packs, which provide additional functionality. The SOA management pack extends Enterprise Manager to provide monitoring and management of artifacts within the SOA Suite.

Service repository and registry

Oracle has a service repository and registry product that is integrated with the SOA Suite but separate from it. The repository acts as a central repository for all SOA artifacts and can be used to support both developers and deployers in tracking dependencies between components both deployed and in development. The repository can publish SOA artifacts such as service definitions and locations to the service registry. The Oracle Service registry may be used to categorize and index services created. Users may then browse the registry to locate services. The service registry may also be used as a runtime location service for service endpoints.

BPA Suite

The Oracle BPA Suite is targeted at business process analysts who want a powerful repository-based tool to model their business processes. The BPA Suite is not an easy product to learn, and like all modeling tools, there is a price to pay for the descriptive power available. The fact of interest to SOA Suite developers is the ability for the BPA Suite and SOA Suite to exchange process models. Processes created in the BPA Suite may be exported to the SOA Suite for concrete implementation. Simulation of processes in the BPA Suite may be used as a useful guide for process improvement.

Links between the BPA Suite and the SOA Suite are growing stronger over time, and this provides a valuable bridge between business analysts and IT architects.

The BPM Suite

The Business Process Management Suite is focused on modeling and execution of business processes. As mentioned, it includes BPEL process manager to provide strong system-centric support for business processes, but the primary focus of the Suite is on modeling and executing processes in the BPM designer and BPM server. BPM server and BPEL process manager are converging on a single shared service implementation.

Portals and WebCenter

The SOA Suite has no real end-user interface outside the human workflow service. Frontends may be built using JDeveloper directly or they may be crafted as part of Oracle Portal, Oracle WebCenter, or another Portal or frontend builder. A number of portlets are provided to expose views of SOA Suite to end users through the portal. These are principally related to human workflow, but also include some views onto the BPEL process status. Portals can also take advantage of WSDL interfaces to provide a user interface onto services exposed by the SOA Suite.

Enterprise manager SOA management pack

Oracle's preferred management framework is Oracle Enterprise Manager. This is provided as a base set of functionality with a large number of management packs, which provide additional functionality. The SOA management pack extends Enterprise Manager to provide monitoring and management of artifacts within the SOA Suite.

BPA Suite

The Oracle BPA Suite is targeted at business process analysts who want a powerful repository-based tool to model their business processes. The BPA Suite is not an easy product to learn, and like all modeling tools, there is a price to pay for the descriptive power available. The fact of interest to SOA Suite developers is the ability for the BPA Suite and SOA Suite to exchange process models. Processes created in the BPA Suite may be exported to the SOA Suite for concrete implementation. Simulation of processes in the BPA Suite may be used as a useful guide for process improvement.

Links between the BPA Suite and the SOA Suite are growing stronger over time, and this provides a valuable bridge between business analysts and IT architects.

The BPM Suite

The Business Process Management Suite is focused on modeling and execution of business processes. As mentioned, it includes BPEL process manager to provide strong system-centric support for business processes, but the primary focus of the Suite is on modeling and executing processes in the BPM designer and BPM server. BPM server and BPEL process manager are converging on a single shared service implementation.

Portals and WebCenter

The SOA Suite has no real end-user interface outside the human workflow service. Frontends may be built using JDeveloper directly or they may be crafted as part of Oracle Portal, Oracle WebCenter, or another Portal or frontend builder. A number of portlets are provided to expose views of SOA Suite to end users through the portal. These are principally related to human workflow, but also include some views onto the BPEL process status. Portals can also take advantage of WSDL interfaces to provide a user interface onto services exposed by the SOA Suite.

Enterprise manager SOA management pack

Oracle's preferred management framework is Oracle Enterprise Manager. This is provided as a base set of functionality with a large number of management packs, which provide additional functionality. The SOA management pack extends Enterprise Manager to provide monitoring and management of artifacts within the SOA Suite.

The BPM Suite

The Business Process Management Suite is focused on modeling and execution of business processes. As mentioned, it includes BPEL process manager to provide strong system-centric support for business processes, but the primary focus of the Suite is on modeling and executing processes in the BPM designer and BPM server. BPM server and BPEL process manager are converging on a single shared service implementation.

Portals and WebCenter

The SOA Suite has no real end-user interface outside the human workflow service. Frontends may be built using JDeveloper directly or they may be crafted as part of Oracle Portal, Oracle WebCenter, or another Portal or frontend builder. A number of portlets are provided to expose views of SOA Suite to end users through the portal. These are principally related to human workflow, but also include some views onto the BPEL process status. Portals can also take advantage of WSDL interfaces to provide a user interface onto services exposed by the SOA Suite.

Enterprise manager SOA management pack

Oracle's preferred management framework is Oracle Enterprise Manager. This is provided as a base set of functionality with a large number of management packs, which provide additional functionality. The SOA management pack extends Enterprise Manager to provide monitoring and management of artifacts within the SOA Suite.

Portals and WebCenter

The SOA Suite has no real end-user interface outside the human workflow service. Frontends may be built using JDeveloper directly or they may be crafted as part of Oracle Portal, Oracle WebCenter, or another Portal or frontend builder. A number of portlets are provided to expose views of SOA Suite to end users through the portal. These are principally related to human workflow, but also include some views onto the BPEL process status. Portals can also take advantage of WSDL interfaces to provide a user interface onto services exposed by the SOA Suite.

Enterprise manager SOA management pack

Oracle's preferred management framework is Oracle Enterprise Manager. This is provided as a base set of functionality with a large number of management packs, which provide additional functionality. The SOA management pack extends Enterprise Manager to provide monitoring and management of artifacts within the SOA Suite.

Enterprise manager SOA management pack

Oracle's preferred management framework is Oracle Enterprise Manager. This is provided as a base set of functionality with a large number of management packs, which provide additional functionality. The SOA management pack extends Enterprise Manager to provide monitoring and management of artifacts within the SOA Suite.

Summary

As we have seen, there are a lot of components to the SOA Suite, and even though Oracle has done a lot to provide consistent usage patterns, there is still a lot to learn about each component. The rest of this book takes a solution-oriented approach to the SOA Suite rather than a component approach. We will examine the individual components in the context of the role they serve and how they are used to enable service-oriented architecture.

You're reading from Oracle SOA Suite 11g R1 Developer's Guide Service-Oriented Architecture (SOA) is made easily accessible thanks to this comprehensive guide. With a logically structured approach, it gives you the expertise to start using the Oracle SOA suite in real-world applications.

Table of Contents (5) Chapters

Chapter 1. Introduction to Oracle SOA Suite

Service-oriented architecture in short

Service

Tip

Note

Orientation

Note

Architecture

Tip

Note

Why SOA is different

Terminology

Interoperability

Note

Extension and evolution

Reuse in place

Note

Terminology

Interoperability

Note

Extension and evolution

Reuse in place

Note

Interoperability

Note

Extension and evolution

Reuse in place

Note

Extension and evolution

Reuse in place

Note

Reuse in place

Note

Service Component Architecture (SCA)

Component

Service

Reference

Wire

Note

Composite.xml

Properties

Component

Service

Reference

Wire

Note

Composite.xml

Properties

Service

Reference

Wire

Note

Composite.xml

Properties

Reference

Wire

Note

Composite.xml

Properties

Wire

Note

Composite.xml

Properties

Composite.xml

Properties

Properties

SOA Suite components

Services and adapters

ESB – service abstraction layer

Oracle Service Bus and Oracle Mediator

Service orchestration – the BPEL process manager

Rules

Security and monitoring

Active monitoring – BAM

Business to Business – B2B

Complex Event Processing – CEP

Event delivery network

Services and adapters