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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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 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.

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.

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 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.

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.

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.

Within JDeveloper, an application is the main container for our work. It consists of a directory where all our application projects will be created.

So, before we can create our Echo SCA Assembly, we must create the application to which it will belong. Within the Applications Navigator tab in JDeveloper, click on the New Application… item.

This will launch the Create SOA Application dialog, as shown in the preceding screenshot.

Give the application an appropriate name like SoaSuiteBook11gChapter2.

We can specify the top-level directory in which we want to create our applications. By default, JDeveloper will set it to the following:

<JDEVELOPER_HOME>\ mywork\<Application Name>

Normally, we would specify a directory that's not under JDEVELOPER_HOME, as this makes it simpler to upgrade to future releases of JDeveloper.

In addition, you can specify an Application Template. For SOA projects, select SOA Application template, and click on the Next button.

Next, JDeveloper will prompt us for the details of a new SOA project.

We provide a name for our project such as EchoComposite and select the technologies we desire to be available in the project. In this case, we leave the default SOA technology selected. The project will be created in a directory that, by default, has the same name as the project and is located under the application directory. These settings can be changed.

Clicking on Next will give us the opportunity to configure our new composite by selecting some initial components. Select Composite With BPEL to create a new Assembly with a BPEL process, as shown in the next screenshot:

We have a number of different templates available to us. Apart from the Empty Composite template, they all populate the composite with an initial component. This may be a BPEL component, a Business Rule component, a Human Task, or a Mediator component. The Composite From Oracle BPA Blueprint is used to import a process from the Oracle BPA Suite and generate it as a BPEL component within the composite.

It is possible to create an Empty Composite and then add the components directly to the composite, so if you choose the wrong template and start working with it, you can always enhance it by adding more components. Even the Empty Composite is not really empty, as it includes all the initial files you need to start building your own composite.

Clicking Finish will launch the Create BPEL Process wizard, as shown in the following screenshot:

Replace the process with a sensible Name like EchoProcess and select a template of the type Synchronous BPEL Process and click OK. JDeveloper will create a skeleton BPEL Process and a corresponding WSDL that describes the web service implemented by our process. This process will be wrapped in an SCA Assembly.

If we look at the process that JDeveloper has created (as shown in the following screenshot), we can see that in the center is the process itself, which contains the activities to be carried out. At the moment, it just contains an initial activity for receiving a request and a corresponding activity for sending a response.

Either side of the process we have a swim lane containing Partner Links that represent either the caller of our process, as is the case with the echoprocess_client partner links, or services that our BPEL process calls out to. At the moment this is empty as we haven't defined any external references that we use within our BPEL process. Notice also that we don't currently have any content between receiving the call and replying; our process is empty and does nothing.

The Component Palette window (to the right of our process window in the preceding screenshot) lists all the BPEL Activities and Components that we can use within our process. To use any of these, we have to simply drag-and-drop them onto the appropriate place within our process.

If you click on the BPEL Services drop-down, you also have the option of selecting services which we use whenever we need to call out to an external system.

Getting back to our skeleton process, we can see that it consists of two activities; receiveInput and replyOutput. In addition it has two variables, inputVariable and outputVariable, which were created as part of our skeleton process.

The first activity is used to receive the initial request from the client invoking our BPEL process; when this request is received it will populate the variable inputVariable with the content of the request.

The last activity is used to send a response back to the client, and the content of this response will contain the content of outputVariable.

For the purpose of our simple EchoProcess we just need to copy the content of the input variable to the output variable.

Assigning values to variables

In BPEL, the <assign> activity is used to update the values of variables with new data. The <assign> activity typically consists of one or more copy operations. Each copy consists of a target variable, that is, the variable that you wish to assign a value to and a source, which can either be another variable or an XPath expression.

To insert an Assign activity, drag one from the Component Palette on to our BPEL process at the point just after the receiveInput activity, as shown in the following screenshot:

To configure the Assign activity, double-click on it to open up its configuration window. Click on the green cross to access a menu and select Copy Operation…, as shown in the next screenshot:

This will present us with the Create Copy Operation window, as shown in the following screenshot:

On the left-hand side, we specify the From variable, that is, where we want to copy from. For our process, we want to copy the content of our input variable to our output variable. So expand inputVariable and select /client:process/client:input, as shown in the preceding screenshot.

On the right-hand side, we specify the To variable, that is, where we want to copy to. So expand outputVariable and select /client:processResponse/client:result.

Once you've done this, click OK and then OK again to close the Assign window.

This completes our process, so click on the Save All icon (the fourth icon along, in the top-left-hand corner of JDeveloper) to save our work.

Our process is now ready to be deployed. Before doing this, make sure the SOA Suite is running and that within JDeveloper we have defined an Application Server connection (as described in the installation guide).

To deploy the process, right-click on our EchoComposite project and then select Deploy | EchoComposite | to MyApplicationServerConnection.

This will bring up the SOA Deployment Configuration Dialog. This dialog allows us to specify the target servers onto which we wish to deploy the composite. We may also specify a Revision ID for the composite to differentiate it from other deployed versions of the composite. If a revision with the same ID already exists, then it may be replaced by specifying the Overwrite any existing composites with the same revision ID option.

Clicking OK will begin the build and deployment of the composite. JDeveloper will open up a window below our process containing five tabs: Messages, Feedback, BPEL, Deployment, and SOA, to which it outputs the status of the deployment process.

During the build, the SOA tab will indicate if the build was successful, and assuming it was, then an Authorization Request window will pop up requesting credentials for the application server.

On completion of the build process, the Deployment tab should state Successfully deployed archive…., as shown in the following screenshot:

If you don't get this message, then check the log windows for details of the error and fix it accordingly.

Now that our process has been deployed, the next step is to run it. A simple way to do this is to initiate a test instance using the Enterprise Manager (EM) console, which is the web-based management console for SOA Suite.

To access the EM console, open up a browser and enter the following URL:

http://<hostname>:<port>/em

This will bring up the login screen for the EM console. Log in as weblogic. This will take us to the EM console dashboard, as shown in the following screenshot:

The Dashboard provides us with a summary report on the Fusion Middleware domain. On the left-hand side we have a list of management areas and on the right we have summaries of application deployments, including our EchoComposite under the SOA tab.

From here, click on the composite name, that is, EchoComposite. This will take us to the Dashboard screen for our composite. From here we can see the number of completed and currently executing composite instances.

At the top of the Dashboard there is a Test button that allows us to execute a composite test. Pressing this button brings up the Test Web Service page, as shown in the following screenshot:

When we created our process, JDeveloper automatically created a WSDL file which contained the single operation (that is, process). However, it's quite common to define processes that have multiple operations, as we will see later on in the book.

The Operation drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

When you select the operation to invoke, the console will generate an HTML form with a field for each element in the message payload of the operation (as defined by the WSDL for the process). Here we can enter into each field the value that we want to submit.

For operations with large message payloads it can be simpler to just enter the XML source. If you select the XML View drop-down list the console will replace the form with a free text area with a skeleton XML fragment into which we can insert the required values.

To execute a test instance of our composite, enter some text in the input field and click Test Web Service. This will cause the console to generate a SOAP message and use it to invoke our Echo process.

Upon successful execution of the process, our test page will be updated to show the result which displays the response returned by our process. Here we can see that the result element contains our original input string, as shown in the following screenshot:

If we expand the SOA and soa-infra items on the left-hand side of the page, we will arrive back at the dashboard for the EchoComposite. Clicking on a completed instance will give us a summary of the composite. From here we can see the components that make up our composite. In this case, the composite consists of a single BPEL process.

Clicking on the BPEL process takes us to an audit record of the instance. We can expand the tree view to see details of individual operations like the message sent by replyOutput.

Clicking on the Flow tab will display a graphical representation of the activities within the BPEL process.

Clicking on any of the activities in the audit trail will pop up a window displaying details of the actions performed by that activity. In the following screenshot, we can see details of the message sent by the replyOutput activity:

This completes development of our first BPEL process. The next step is to call it via the Mediator. This will give us the option of transforming the input into the format we desire and of routing to different components based on the input content.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

Within JDeveloper, an application is the main container for our work. It consists of a directory where all our application projects will be created.

So, before we can create our Echo SCA Assembly, we must create the application to which it will belong. Within the Applications Navigator tab in JDeveloper, click on the New Application… item.

This will launch the Create SOA Application dialog, as shown in the preceding screenshot.

Give the application an appropriate name like SoaSuiteBook11gChapter2.

We can specify the top-level directory in which we want to create our applications. By default, JDeveloper will set it to the following:

<JDEVELOPER_HOME>\ mywork\<Application Name>

Normally, we would specify a directory that's not under JDEVELOPER_HOME, as this makes it simpler to upgrade to future releases of JDeveloper.

In addition, you can specify an Application Template. For SOA projects, select SOA Application template, and click on the Next button.

Next, JDeveloper will prompt us for the details of a new SOA project.

We provide a name for our project such as EchoComposite and select the technologies we desire to be available in the project. In this case, we leave the default SOA technology selected. The project will be created in a directory that, by default, has the same name as the project and is located under the application directory. These settings can be changed.

Clicking on Next will give us the opportunity to configure our new composite by selecting some initial components. Select Composite With BPEL to create a new Assembly with a BPEL process, as shown in the next screenshot:

We have a number of different templates available to us. Apart from the Empty Composite template, they all populate the composite with an initial component. This may be a BPEL component, a Business Rule component, a Human Task, or a Mediator component. The Composite From Oracle BPA Blueprint is used to import a process from the Oracle BPA Suite and generate it as a BPEL component within the composite.

It is possible to create an Empty Composite and then add the components directly to the composite, so if you choose the wrong template and start working with it, you can always enhance it by adding more components. Even the Empty Composite is not really empty, as it includes all the initial files you need to start building your own composite.

Clicking Finish will launch the Create BPEL Process wizard, as shown in the following screenshot:

Replace the process with a sensible Name like EchoProcess and select a template of the type Synchronous BPEL Process and click OK. JDeveloper will create a skeleton BPEL Process and a corresponding WSDL that describes the web service implemented by our process. This process will be wrapped in an SCA Assembly.

If we look at the process that JDeveloper has created (as shown in the following screenshot), we can see that in the center is the process itself, which contains the activities to be carried out. At the moment, it just contains an initial activity for receiving a request and a corresponding activity for sending a response.

Either side of the process we have a swim lane containing Partner Links that represent either the caller of our process, as is the case with the echoprocess_client partner links, or services that our BPEL process calls out to. At the moment this is empty as we haven't defined any external references that we use within our BPEL process. Notice also that we don't currently have any content between receiving the call and replying; our process is empty and does nothing.

The Component Palette window (to the right of our process window in the preceding screenshot) lists all the BPEL Activities and Components that we can use within our process. To use any of these, we have to simply drag-and-drop them onto the appropriate place within our process.

If you click on the BPEL Services drop-down, you also have the option of selecting services which we use whenever we need to call out to an external system.

Getting back to our skeleton process, we can see that it consists of two activities; receiveInput and replyOutput. In addition it has two variables, inputVariable and outputVariable, which were created as part of our skeleton process.

The first activity is used to receive the initial request from the client invoking our BPEL process; when this request is received it will populate the variable inputVariable with the content of the request.

The last activity is used to send a response back to the client, and the content of this response will contain the content of outputVariable.

For the purpose of our simple EchoProcess we just need to copy the content of the input variable to the output variable.

Assigning values to variables

In BPEL, the <assign> activity is used to update the values of variables with new data. The <assign> activity typically consists of one or more copy operations. Each copy consists of a target variable, that is, the variable that you wish to assign a value to and a source, which can either be another variable or an XPath expression.

To insert an Assign activity, drag one from the Component Palette on to our BPEL process at the point just after the receiveInput activity, as shown in the following screenshot:

To configure the Assign activity, double-click on it to open up its configuration window. Click on the green cross to access a menu and select Copy Operation…, as shown in the next screenshot:

This will present us with the Create Copy Operation window, as shown in the following screenshot:

On the left-hand side, we specify the From variable, that is, where we want to copy from. For our process, we want to copy the content of our input variable to our output variable. So expand inputVariable and select /client:process/client:input, as shown in the preceding screenshot.

On the right-hand side, we specify the To variable, that is, where we want to copy to. So expand outputVariable and select /client:processResponse/client:result.

Once you've done this, click OK and then OK again to close the Assign window.

This completes our process, so click on the Save All icon (the fourth icon along, in the top-left-hand corner of JDeveloper) to save our work.

Our process is now ready to be deployed. Before doing this, make sure the SOA Suite is running and that within JDeveloper we have defined an Application Server connection (as described in the installation guide).

To deploy the process, right-click on our EchoComposite project and then select Deploy | EchoComposite | to MyApplicationServerConnection.

This will bring up the SOA Deployment Configuration Dialog. This dialog allows us to specify the target servers onto which we wish to deploy the composite. We may also specify a Revision ID for the composite to differentiate it from other deployed versions of the composite. If a revision with the same ID already exists, then it may be replaced by specifying the Overwrite any existing composites with the same revision ID option.

Clicking OK will begin the build and deployment of the composite. JDeveloper will open up a window below our process containing five tabs: Messages, Feedback, BPEL, Deployment, and SOA, to which it outputs the status of the deployment process.

During the build, the SOA tab will indicate if the build was successful, and assuming it was, then an Authorization Request window will pop up requesting credentials for the application server.

On completion of the build process, the Deployment tab should state Successfully deployed archive…., as shown in the following screenshot:

If you don't get this message, then check the log windows for details of the error and fix it accordingly.

Now that our process has been deployed, the next step is to run it. A simple way to do this is to initiate a test instance using the Enterprise Manager (EM) console, which is the web-based management console for SOA Suite.

To access the EM console, open up a browser and enter the following URL:

http://<hostname>:<port>/em

This will bring up the login screen for the EM console. Log in as weblogic. This will take us to the EM console dashboard, as shown in the following screenshot:

The Dashboard provides us with a summary report on the Fusion Middleware domain. On the left-hand side we have a list of management areas and on the right we have summaries of application deployments, including our EchoComposite under the SOA tab.

From here, click on the composite name, that is, EchoComposite. This will take us to the Dashboard screen for our composite. From here we can see the number of completed and currently executing composite instances.

At the top of the Dashboard there is a Test button that allows us to execute a composite test. Pressing this button brings up the Test Web Service page, as shown in the following screenshot:

When we created our process, JDeveloper automatically created a WSDL file which contained the single operation (that is, process). However, it's quite common to define processes that have multiple operations, as we will see later on in the book.

The Operation drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

When you select the operation to invoke, the console will generate an HTML form with a field for each element in the message payload of the operation (as defined by the WSDL for the process). Here we can enter into each field the value that we want to submit.

For operations with large message payloads it can be simpler to just enter the XML source. If you select the XML View drop-down list the console will replace the form with a free text area with a skeleton XML fragment into which we can insert the required values.

To execute a test instance of our composite, enter some text in the input field and click Test Web Service. This will cause the console to generate a SOAP message and use it to invoke our Echo process.

Upon successful execution of the process, our test page will be updated to show the result which displays the response returned by our process. Here we can see that the result element contains our original input string, as shown in the following screenshot:

If we expand the SOA and soa-infra items on the left-hand side of the page, we will arrive back at the dashboard for the EchoComposite. Clicking on a completed instance will give us a summary of the composite. From here we can see the components that make up our composite. In this case, the composite consists of a single BPEL process.

Clicking on the BPEL process takes us to an audit record of the instance. We can expand the tree view to see details of individual operations like the message sent by replyOutput.

Clicking on the Flow tab will display a graphical representation of the activities within the BPEL process.

Clicking on any of the activities in the audit trail will pop up a window displaying details of the actions performed by that activity. In the following screenshot, we can see details of the message sent by the replyOutput activity:

This completes development of our first BPEL process. The next step is to call it via the Mediator. This will give us the option of transforming the input into the format we desire and of routing to different components based on the input content.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

We provide a name for our project such as EchoComposite and select the technologies we desire to be available in the project. In this case, we leave the default SOA technology selected. The project will be created in a directory that, by default, has the same name as the project and is located under the application directory. These settings can be changed.

Clicking on Next will give us the opportunity to configure our new composite by selecting some initial components. Select Composite With BPEL to create a new Assembly with a BPEL process, as shown in the next screenshot:

We have a number of different templates available to us. Apart from the Empty Composite template, they all populate the composite with an initial component. This may be a BPEL component, a Business Rule component, a Human Task, or a Mediator component. The Composite From Oracle BPA Blueprint is used to import a process from the Oracle BPA Suite and generate it as a BPEL component within the composite.

It is possible to create an Empty Composite and then add the components directly to the composite, so if you choose the wrong template and start working with it, you can always enhance it by adding more components. Even the Empty Composite is not really empty, as it includes all the initial files you need to start building your own composite.

Clicking Finish will launch the Create BPEL Process wizard, as shown in the following screenshot:

Replace the process with a sensible Name like EchoProcess and select a template of the type Synchronous BPEL Process and click OK. JDeveloper will create a skeleton BPEL Process and a corresponding WSDL that describes the web service implemented by our process. This process will be wrapped in an SCA Assembly.

If we look at the process that JDeveloper has created (as shown in the following screenshot), we can see that in the center is the process itself, which contains the activities to be carried out. At the moment, it just contains an initial activity for receiving a request and a corresponding activity for sending a response.

Either side of the process we have a swim lane containing Partner Links that represent either the caller of our process, as is the case with the echoprocess_client partner links, or services that our BPEL process calls out to. At the moment this is empty as we haven't defined any external references that we use within our BPEL process. Notice also that we don't currently have any content between receiving the call and replying; our process is empty and does nothing.

The Component Palette window (to the right of our process window in the preceding screenshot) lists all the BPEL Activities and Components that we can use within our process. To use any of these, we have to simply drag-and-drop them onto the appropriate place within our process.

If you click on the BPEL Services drop-down, you also have the option of selecting services which we use whenever we need to call out to an external system.

Getting back to our skeleton process, we can see that it consists of two activities; receiveInput and replyOutput. In addition it has two variables, inputVariable and outputVariable, which were created as part of our skeleton process.

The first activity is used to receive the initial request from the client invoking our BPEL process; when this request is received it will populate the variable inputVariable with the content of the request.

The last activity is used to send a response back to the client, and the content of this response will contain the content of outputVariable.

For the purpose of our simple EchoProcess we just need to copy the content of the input variable to the output variable.

Assigning values to variables

In BPEL, the <assign> activity is used to update the values of variables with new data. The <assign> activity typically consists of one or more copy operations. Each copy consists of a target variable, that is, the variable that you wish to assign a value to and a source, which can either be another variable or an XPath expression.

To insert an Assign activity, drag one from the Component Palette on to our BPEL process at the point just after the receiveInput activity, as shown in the following screenshot:

To configure the Assign activity, double-click on it to open up its configuration window. Click on the green cross to access a menu and select Copy Operation…, as shown in the next screenshot:

This will present us with the Create Copy Operation window, as shown in the following screenshot:

On the left-hand side, we specify the From variable, that is, where we want to copy from. For our process, we want to copy the content of our input variable to our output variable. So expand inputVariable and select /client:process/client:input, as shown in the preceding screenshot.

On the right-hand side, we specify the To variable, that is, where we want to copy to. So expand outputVariable and select /client:processResponse/client:result.

Once you've done this, click OK and then OK again to close the Assign window.

This completes our process, so click on the Save All icon (the fourth icon along, in the top-left-hand corner of JDeveloper) to save our work.

Our process is now ready to be deployed. Before doing this, make sure the SOA Suite is running and that within JDeveloper we have defined an Application Server connection (as described in the installation guide).

To deploy the process, right-click on our EchoComposite project and then select Deploy | EchoComposite | to MyApplicationServerConnection.

This will bring up the SOA Deployment Configuration Dialog. This dialog allows us to specify the target servers onto which we wish to deploy the composite. We may also specify a Revision ID for the composite to differentiate it from other deployed versions of the composite. If a revision with the same ID already exists, then it may be replaced by specifying the Overwrite any existing composites with the same revision ID option.

Clicking OK will begin the build and deployment of the composite. JDeveloper will open up a window below our process containing five tabs: Messages, Feedback, BPEL, Deployment, and SOA, to which it outputs the status of the deployment process.

During the build, the SOA tab will indicate if the build was successful, and assuming it was, then an Authorization Request window will pop up requesting credentials for the application server.

On completion of the build process, the Deployment tab should state Successfully deployed archive…., as shown in the following screenshot:

If you don't get this message, then check the log windows for details of the error and fix it accordingly.

Now that our process has been deployed, the next step is to run it. A simple way to do this is to initiate a test instance using the Enterprise Manager (EM) console, which is the web-based management console for SOA Suite.

To access the EM console, open up a browser and enter the following URL:

http://<hostname>:<port>/em

This will bring up the login screen for the EM console. Log in as weblogic. This will take us to the EM console dashboard, as shown in the following screenshot:

The Dashboard provides us with a summary report on the Fusion Middleware domain. On the left-hand side we have a list of management areas and on the right we have summaries of application deployments, including our EchoComposite under the SOA tab.

From here, click on the composite name, that is, EchoComposite. This will take us to the Dashboard screen for our composite. From here we can see the number of completed and currently executing composite instances.

At the top of the Dashboard there is a Test button that allows us to execute a composite test. Pressing this button brings up the Test Web Service page, as shown in the following screenshot:

When we created our process, JDeveloper automatically created a WSDL file which contained the single operation (that is, process). However, it's quite common to define processes that have multiple operations, as we will see later on in the book.

The Operation drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

When you select the operation to invoke, the console will generate an HTML form with a field for each element in the message payload of the operation (as defined by the WSDL for the process). Here we can enter into each field the value that we want to submit.

For operations with large message payloads it can be simpler to just enter the XML source. If you select the XML View drop-down list the console will replace the form with a free text area with a skeleton XML fragment into which we can insert the required values.

To execute a test instance of our composite, enter some text in the input field and click Test Web Service. This will cause the console to generate a SOAP message and use it to invoke our Echo process.

Upon successful execution of the process, our test page will be updated to show the result which displays the response returned by our process. Here we can see that the result element contains our original input string, as shown in the following screenshot:

If we expand the SOA and soa-infra items on the left-hand side of the page, we will arrive back at the dashboard for the EchoComposite. Clicking on a completed instance will give us a summary of the composite. From here we can see the components that make up our composite. In this case, the composite consists of a single BPEL process.

Clicking on the BPEL process takes us to an audit record of the instance. We can expand the tree view to see details of individual operations like the message sent by replyOutput.

Clicking on the Flow tab will display a graphical representation of the activities within the BPEL process.

Clicking on any of the activities in the audit trail will pop up a window displaying details of the actions performed by that activity. In the following screenshot, we can see details of the message sent by the replyOutput activity:

This completes development of our first BPEL process. The next step is to call it via the Mediator. This will give us the option of transforming the input into the format we desire and of routing to different components based on the input content.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

We have a number of different templates available to us. Apart from the Empty Composite template, they all populate the composite with an initial component. This may be a BPEL component, a Business Rule component, a Human Task, or a Mediator component. The Composite From Oracle BPA Blueprint is used to import a process from the Oracle BPA Suite and generate it as a BPEL component within the composite.

It is possible to create an Empty Composite and then add the components directly to the composite, so if you choose the wrong template and start working with it, you can always enhance it by adding more components. Even the Empty Composite is not really empty, as it includes all the initial files you need to start building your own composite.

Clicking Finish will launch the Create BPEL Process wizard, as shown in the following screenshot:

Replace the process with a sensible Name like EchoProcess and select a template of the type Synchronous BPEL Process and click OK. JDeveloper will create a skeleton BPEL Process and a corresponding WSDL that describes the web service implemented by our process. This process will be wrapped in an SCA Assembly.

If we look at the process that JDeveloper has created (as shown in the following screenshot), we can see that in the center is the process itself, which contains the activities to be carried out. At the moment, it just contains an initial activity for receiving a request and a corresponding activity for sending a response.

Either side of the process we have a swim lane containing Partner Links that represent either the caller of our process, as is the case with the echoprocess_client partner links, or services that our BPEL process calls out to. At the moment this is empty as we haven't defined any external references that we use within our BPEL process. Notice also that we don't currently have any content between receiving the call and replying; our process is empty and does nothing.

The Component Palette window (to the right of our process window in the preceding screenshot) lists all the BPEL Activities and Components that we can use within our process. To use any of these, we have to simply drag-and-drop them onto the appropriate place within our process.

If you click on the BPEL Services drop-down, you also have the option of selecting services which we use whenever we need to call out to an external system.

Getting back to our skeleton process, we can see that it consists of two activities; receiveInput and replyOutput. In addition it has two variables, inputVariable and outputVariable, which were created as part of our skeleton process.

The first activity is used to receive the initial request from the client invoking our BPEL process; when this request is received it will populate the variable inputVariable with the content of the request.

The last activity is used to send a response back to the client, and the content of this response will contain the content of outputVariable.

For the purpose of our simple EchoProcess we just need to copy the content of the input variable to the output variable.

Assigning values to variables

In BPEL, the <assign> activity is used to update the values of variables with new data. The <assign> activity typically consists of one or more copy operations. Each copy consists of a target variable, that is, the variable that you wish to assign a value to and a source, which can either be another variable or an XPath expression.

To insert an Assign activity, drag one from the Component Palette on to our BPEL process at the point just after the receiveInput activity, as shown in the following screenshot:

To configure the Assign activity, double-click on it to open up its configuration window. Click on the green cross to access a menu and select Copy Operation…, as shown in the next screenshot:

This will present us with the Create Copy Operation window, as shown in the following screenshot:

On the left-hand side, we specify the From variable, that is, where we want to copy from. For our process, we want to copy the content of our input variable to our output variable. So expand inputVariable and select /client:process/client:input, as shown in the preceding screenshot.

On the right-hand side, we specify the To variable, that is, where we want to copy to. So expand outputVariable and select /client:processResponse/client:result.

Once you've done this, click OK and then OK again to close the Assign window.

This completes our process, so click on the Save All icon (the fourth icon along, in the top-left-hand corner of JDeveloper) to save our work.

Our process is now ready to be deployed. Before doing this, make sure the SOA Suite is running and that within JDeveloper we have defined an Application Server connection (as described in the installation guide).

To deploy the process, right-click on our EchoComposite project and then select Deploy | EchoComposite | to MyApplicationServerConnection.

This will bring up the SOA Deployment Configuration Dialog. This dialog allows us to specify the target servers onto which we wish to deploy the composite. We may also specify a Revision ID for the composite to differentiate it from other deployed versions of the composite. If a revision with the same ID already exists, then it may be replaced by specifying the Overwrite any existing composites with the same revision ID option.

Clicking OK will begin the build and deployment of the composite. JDeveloper will open up a window below our process containing five tabs: Messages, Feedback, BPEL, Deployment, and SOA, to which it outputs the status of the deployment process.

During the build, the SOA tab will indicate if the build was successful, and assuming it was, then an Authorization Request window will pop up requesting credentials for the application server.

On completion of the build process, the Deployment tab should state Successfully deployed archive…., as shown in the following screenshot:

If you don't get this message, then check the log windows for details of the error and fix it accordingly.

Now that our process has been deployed, the next step is to run it. A simple way to do this is to initiate a test instance using the Enterprise Manager (EM) console, which is the web-based management console for SOA Suite.

To access the EM console, open up a browser and enter the following URL:

http://<hostname>:<port>/em

This will bring up the login screen for the EM console. Log in as weblogic. This will take us to the EM console dashboard, as shown in the following screenshot:

The Dashboard provides us with a summary report on the Fusion Middleware domain. On the left-hand side we have a list of management areas and on the right we have summaries of application deployments, including our EchoComposite under the SOA tab.

From here, click on the composite name, that is, EchoComposite. This will take us to the Dashboard screen for our composite. From here we can see the number of completed and currently executing composite instances.

At the top of the Dashboard there is a Test button that allows us to execute a composite test. Pressing this button brings up the Test Web Service page, as shown in the following screenshot:

When we created our process, JDeveloper automatically created a WSDL file which contained the single operation (that is, process). However, it's quite common to define processes that have multiple operations, as we will see later on in the book.

The Operation drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

When you select the operation to invoke, the console will generate an HTML form with a field for each element in the message payload of the operation (as defined by the WSDL for the process). Here we can enter into each field the value that we want to submit.

For operations with large message payloads it can be simpler to just enter the XML source. If you select the XML View drop-down list the console will replace the form with a free text area with a skeleton XML fragment into which we can insert the required values.

To execute a test instance of our composite, enter some text in the input field and click Test Web Service. This will cause the console to generate a SOAP message and use it to invoke our Echo process.

Upon successful execution of the process, our test page will be updated to show the result which displays the response returned by our process. Here we can see that the result element contains our original input string, as shown in the following screenshot:

If we expand the SOA and soa-infra items on the left-hand side of the page, we will arrive back at the dashboard for the EchoComposite. Clicking on a completed instance will give us a summary of the composite. From here we can see the components that make up our composite. In this case, the composite consists of a single BPEL process.

Clicking on the BPEL process takes us to an audit record of the instance. We can expand the tree view to see details of individual operations like the message sent by replyOutput.

Clicking on the Flow tab will display a graphical representation of the activities within the BPEL process.

Clicking on any of the activities in the audit trail will pop up a window displaying details of the actions performed by that activity. In the following screenshot, we can see details of the message sent by the replyOutput activity:

This completes development of our first BPEL process. The next step is to call it via the Mediator. This will give us the option of transforming the input into the format we desire and of routing to different components based on the input content.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

Clicking Finish will launch the Create BPEL Process wizard, as shown in the following screenshot:

Replace the process with a sensible Name like EchoProcess and select a template of the type Synchronous BPEL Process and click OK. JDeveloper will create a skeleton BPEL Process and a corresponding WSDL that describes the web service implemented by our process. This process will be wrapped in an SCA Assembly.

If we look at the process that JDeveloper has created (as shown in the following screenshot), we can see that in the center is the process itself, which contains the activities to be carried out. At the moment, it just contains an initial activity for receiving a request and a corresponding activity for sending a response.

Either side of the process we have a swim lane containing Partner Links that represent either the caller of our process, as is the case with the echoprocess_client partner links, or services that our BPEL process calls out to. At the moment this is empty as we haven't defined any external references that we use within our BPEL process. Notice also that we don't currently have any content between receiving the call and replying; our process is empty and does nothing.

The Component Palette window (to the right of our process window in the preceding screenshot) lists all the BPEL Activities and Components that we can use within our process. To use any of these, we have to simply drag-and-drop them onto the appropriate place within our process.

If you click on the BPEL Services drop-down, you also have the option of selecting services which we use whenever we need to call out to an external system.

Getting back to our skeleton process, we can see that it consists of two activities; receiveInput and replyOutput. In addition it has two variables, inputVariable and outputVariable, which were created as part of our skeleton process.

The first activity is used to receive the initial request from the client invoking our BPEL process; when this request is received it will populate the variable inputVariable with the content of the request.

The last activity is used to send a response back to the client, and the content of this response will contain the content of outputVariable.

For the purpose of our simple EchoProcess we just need to copy the content of the input variable to the output variable.

Assigning values to variables

In BPEL, the <assign> activity is used to update the values of variables with new data. The <assign> activity typically consists of one or more copy operations. Each copy consists of a target variable, that is, the variable that you wish to assign a value to and a source, which can either be another variable or an XPath expression.

To insert an Assign activity, drag one from the Component Palette on to our BPEL process at the point just after the receiveInput activity, as shown in the following screenshot:

To configure the Assign activity, double-click on it to open up its configuration window. Click on the green cross to access a menu and select Copy Operation…, as shown in the next screenshot:

This will present us with the Create Copy Operation window, as shown in the following screenshot:

On the left-hand side, we specify the From variable, that is, where we want to copy from. For our process, we want to copy the content of our input variable to our output variable. So expand inputVariable and select /client:process/client:input, as shown in the preceding screenshot.

On the right-hand side, we specify the To variable, that is, where we want to copy to. So expand outputVariable and select /client:processResponse/client:result.

Once you've done this, click OK and then OK again to close the Assign window.

This completes our process, so click on the Save All icon (the fourth icon along, in the top-left-hand corner of JDeveloper) to save our work.

Our process is now ready to be deployed. Before doing this, make sure the SOA Suite is running and that within JDeveloper we have defined an Application Server connection (as described in the installation guide).

To deploy the process, right-click on our EchoComposite project and then select Deploy | EchoComposite | to MyApplicationServerConnection.

This will bring up the SOA Deployment Configuration Dialog. This dialog allows us to specify the target servers onto which we wish to deploy the composite. We may also specify a Revision ID for the composite to differentiate it from other deployed versions of the composite. If a revision with the same ID already exists, then it may be replaced by specifying the Overwrite any existing composites with the same revision ID option.

Clicking OK will begin the build and deployment of the composite. JDeveloper will open up a window below our process containing five tabs: Messages, Feedback, BPEL, Deployment, and SOA, to which it outputs the status of the deployment process.

During the build, the SOA tab will indicate if the build was successful, and assuming it was, then an Authorization Request window will pop up requesting credentials for the application server.

On completion of the build process, the Deployment tab should state Successfully deployed archive…., as shown in the following screenshot:

If you don't get this message, then check the log windows for details of the error and fix it accordingly.

Now that our process has been deployed, the next step is to run it. A simple way to do this is to initiate a test instance using the Enterprise Manager (EM) console, which is the web-based management console for SOA Suite.

To access the EM console, open up a browser and enter the following URL:

http://<hostname>:<port>/em

This will bring up the login screen for the EM console. Log in as weblogic. This will take us to the EM console dashboard, as shown in the following screenshot:

The Dashboard provides us with a summary report on the Fusion Middleware domain. On the left-hand side we have a list of management areas and on the right we have summaries of application deployments, including our EchoComposite under the SOA tab.

From here, click on the composite name, that is, EchoComposite. This will take us to the Dashboard screen for our composite. From here we can see the number of completed and currently executing composite instances.

At the top of the Dashboard there is a Test button that allows us to execute a composite test. Pressing this button brings up the Test Web Service page, as shown in the following screenshot:

When we created our process, JDeveloper automatically created a WSDL file which contained the single operation (that is, process). However, it's quite common to define processes that have multiple operations, as we will see later on in the book.

The Operation drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

When you select the operation to invoke, the console will generate an HTML form with a field for each element in the message payload of the operation (as defined by the WSDL for the process). Here we can enter into each field the value that we want to submit.

For operations with large message payloads it can be simpler to just enter the XML source. If you select the XML View drop-down list the console will replace the form with a free text area with a skeleton XML fragment into which we can insert the required values.

To execute a test instance of our composite, enter some text in the input field and click Test Web Service. This will cause the console to generate a SOAP message and use it to invoke our Echo process.

Upon successful execution of the process, our test page will be updated to show the result which displays the response returned by our process. Here we can see that the result element contains our original input string, as shown in the following screenshot:

If we expand the SOA and soa-infra items on the left-hand side of the page, we will arrive back at the dashboard for the EchoComposite. Clicking on a completed instance will give us a summary of the composite. From here we can see the components that make up our composite. In this case, the composite consists of a single BPEL process.

Clicking on the BPEL process takes us to an audit record of the instance. We can expand the tree view to see details of individual operations like the message sent by replyOutput.

Clicking on the Flow tab will display a graphical representation of the activities within the BPEL process.

Clicking on any of the activities in the audit trail will pop up a window displaying details of the actions performed by that activity. In the following screenshot, we can see details of the message sent by the replyOutput activity:

This completes development of our first BPEL process. The next step is to call it via the Mediator. This will give us the option of transforming the input into the format we desire and of routing to different components based on the input content.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

This completes our process, so click on the Save All icon (the fourth icon along, in the top-left-hand corner of JDeveloper) to save our work.

Our process is now ready to be deployed. Before doing this, make sure the SOA Suite is running and that within JDeveloper we have defined an Application Server connection (as described in the installation guide).

To deploy the process, right-click on our EchoComposite project and then select Deploy | EchoComposite | to MyApplicationServerConnection.

This will bring up the SOA Deployment Configuration Dialog. This dialog allows us to specify the target servers onto which we wish to deploy the composite. We may also specify a Revision ID for the composite to differentiate it from other deployed versions of the composite. If a revision with the same ID already exists, then it may be replaced by specifying the Overwrite any existing composites with the same revision ID option.

Clicking OK will begin the build and deployment of the composite. JDeveloper will open up a window below our process containing five tabs: Messages, Feedback, BPEL, Deployment, and SOA, to which it outputs the status of the deployment process.

During the build, the SOA tab will indicate if the build was successful, and assuming it was, then an Authorization Request window will pop up requesting credentials for the application server.

On completion of the build process, the Deployment tab should state Successfully deployed archive…., as shown in the following screenshot:

If you don't get this message, then check the log windows for details of the error and fix it accordingly.

Now that our process has been deployed, the next step is to run it. A simple way to do this is to initiate a test instance using the Enterprise Manager (EM) console, which is the web-based management console for SOA Suite.

To access the EM console, open up a browser and enter the following URL:

http://<hostname>:<port>/em

This will bring up the login screen for the EM console. Log in as weblogic. This will take us to the EM console dashboard, as shown in the following screenshot:

The Dashboard provides us with a summary report on the Fusion Middleware domain. On the left-hand side we have a list of management areas and on the right we have summaries of application deployments, including our EchoComposite under the SOA tab.

From here, click on the composite name, that is, EchoComposite. This will take us to the Dashboard screen for our composite. From here we can see the number of completed and currently executing composite instances.

At the top of the Dashboard there is a Test button that allows us to execute a composite test. Pressing this button brings up the Test Web Service page, as shown in the following screenshot:

When we created our process, JDeveloper automatically created a WSDL file which contained the single operation (that is, process). However, it's quite common to define processes that have multiple operations, as we will see later on in the book.

The Operation drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

When you select the operation to invoke, the console will generate an HTML form with a field for each element in the message payload of the operation (as defined by the WSDL for the process). Here we can enter into each field the value that we want to submit.

For operations with large message payloads it can be simpler to just enter the XML source. If you select the XML View drop-down list the console will replace the form with a free text area with a skeleton XML fragment into which we can insert the required values.

To execute a test instance of our composite, enter some text in the input field and click Test Web Service. This will cause the console to generate a SOAP message and use it to invoke our Echo process.

Upon successful execution of the process, our test page will be updated to show the result which displays the response returned by our process. Here we can see that the result element contains our original input string, as shown in the following screenshot:

If we expand the SOA and soa-infra items on the left-hand side of the page, we will arrive back at the dashboard for the EchoComposite. Clicking on a completed instance will give us a summary of the composite. From here we can see the components that make up our composite. In this case, the composite consists of a single BPEL process.

Clicking on the BPEL process takes us to an audit record of the instance. We can expand the tree view to see details of individual operations like the message sent by replyOutput.

Clicking on the Flow tab will display a graphical representation of the activities within the BPEL process.

Clicking on any of the activities in the audit trail will pop up a window displaying details of the actions performed by that activity. In the following screenshot, we can see details of the message sent by the replyOutput activity:

This completes development of our first BPEL process. The next step is to call it via the Mediator. This will give us the option of transforming the input into the format we desire and of routing to different components based on the input content.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

This completes our process, so click on the Save All icon (the fourth icon along, in the top-left-hand corner of JDeveloper) to save our work.

Our process is now ready to be deployed. Before doing this, make sure the SOA Suite is running and that within JDeveloper we have defined an Application Server connection (as described in the installation guide).

To deploy the process, right-click on our EchoComposite project and then select Deploy | EchoComposite | to MyApplicationServerConnection.

This will bring up the SOA Deployment Configuration Dialog. This dialog allows us to specify the target servers onto which we wish to deploy the composite. We may also specify a Revision ID for the composite to differentiate it from other deployed versions of the composite. If a revision with the same ID already exists, then it may be replaced by specifying the Overwrite any existing composites with the same revision ID option.

Clicking OK will begin the build and deployment of the composite. JDeveloper will open up a window below our process containing five tabs: Messages, Feedback, BPEL, Deployment, and SOA, to which it outputs the status of the deployment process.

During the build, the SOA tab will indicate if the build was successful, and assuming it was, then an Authorization Request window will pop up requesting credentials for the application server.

On completion of the build process, the Deployment tab should state Successfully deployed archive…., as shown in the following screenshot:

If you don't get this message, then check the log windows for details of the error and fix it accordingly.

Now that our process has been deployed, the next step is to run it. A simple way to do this is to initiate a test instance using the Enterprise Manager (EM) console, which is the web-based management console for SOA Suite.

To access the EM console, open up a browser and enter the following URL:

http://<hostname>:<port>/em

This will bring up the login screen for the EM console. Log in as weblogic. This will take us to the EM console dashboard, as shown in the following screenshot:

The Dashboard provides us with a summary report on the Fusion Middleware domain. On the left-hand side we have a list of management areas and on the right we have summaries of application deployments, including our EchoComposite under the SOA tab.

From here, click on the composite name, that is, EchoComposite. This will take us to the Dashboard screen for our composite. From here we can see the number of completed and currently executing composite instances.

At the top of the Dashboard there is a Test button that allows us to execute a composite test. Pressing this button brings up the Test Web Service page, as shown in the following screenshot:

When we created our process, JDeveloper automatically created a WSDL file which contained the single operation (that is, process). However, it's quite common to define processes that have multiple operations, as we will see later on in the book.

The Operation drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

When you select the operation to invoke, the console will generate an HTML form with a field for each element in the message payload of the operation (as defined by the WSDL for the process). Here we can enter into each field the value that we want to submit.

For operations with large message payloads it can be simpler to just enter the XML source. If you select the XML View drop-down list the console will replace the form with a free text area with a skeleton XML fragment into which we can insert the required values.

To execute a test instance of our composite, enter some text in the input field and click Test Web Service. This will cause the console to generate a SOAP message and use it to invoke our Echo process.

Upon successful execution of the process, our test page will be updated to show the result which displays the response returned by our process. Here we can see that the result element contains our original input string, as shown in the following screenshot:

If we expand the SOA and soa-infra items on the left-hand side of the page, we will arrive back at the dashboard for the EchoComposite. Clicking on a completed instance will give us a summary of the composite. From here we can see the components that make up our composite. In this case, the composite consists of a single BPEL process.

Clicking on the BPEL process takes us to an audit record of the instance. We can expand the tree view to see details of individual operations like the message sent by replyOutput.

Clicking on the Flow tab will display a graphical representation of the activities within the BPEL process.

Clicking on any of the activities in the audit trail will pop up a window displaying details of the actions performed by that activity. In the following screenshot, we can see details of the message sent by the replyOutput activity:

This completes development of our first BPEL process. The next step is to call it via the Mediator. This will give us the option of transforming the input into the format we desire and of routing to different components based on the input content.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

Now that our process has been deployed, the next step is to run it. A simple way to do this is to initiate a test instance using the Enterprise Manager (EM) console, which is the web-based management console for SOA Suite.

To access the EM console, open up a browser and enter the following URL:

http://<hostname>:<port>/em

This will bring up the login screen for the EM console. Log in as weblogic. This will take us to the EM console dashboard, as shown in the following screenshot:

The Dashboard provides us with a summary report on the Fusion Middleware domain. On the left-hand side we have a list of management areas and on the right we have summaries of application deployments, including our EchoComposite under the SOA tab.

From here, click on the composite name, that is, EchoComposite. This will take us to the Dashboard screen for our composite. From here we can see the number of completed and currently executing composite instances.

At the top of the Dashboard there is a Test button that allows us to execute a composite test. Pressing this button brings up the Test Web Service page, as shown in the following screenshot:

When we created our process, JDeveloper automatically created a WSDL file which contained the single operation (that is, process). However, it's quite common to define processes that have multiple operations, as we will see later on in the book.

The Operation drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

When you select the operation to invoke, the console will generate an HTML form with a field for each element in the message payload of the operation (as defined by the WSDL for the process). Here we can enter into each field the value that we want to submit.

For operations with large message payloads it can be simpler to just enter the XML source. If you select the XML View drop-down list the console will replace the form with a free text area with a skeleton XML fragment into which we can insert the required values.

To execute a test instance of our composite, enter some text in the input field and click Test Web Service. This will cause the console to generate a SOAP message and use it to invoke our Echo process.

Upon successful execution of the process, our test page will be updated to show the result which displays the response returned by our process. Here we can see that the result element contains our original input string, as shown in the following screenshot:

If we expand the SOA and soa-infra items on the left-hand side of the page, we will arrive back at the dashboard for the EchoComposite. Clicking on a completed instance will give us a summary of the composite. From here we can see the components that make up our composite. In this case, the composite consists of a single BPEL process.

Clicking on the BPEL process takes us to an audit record of the instance. We can expand the tree view to see details of individual operations like the message sent by replyOutput.

Clicking on the Flow tab will display a graphical representation of the activities within the BPEL process.

Clicking on any of the activities in the audit trail will pop up a window displaying details of the actions performed by that activity. In the following screenshot, we can see details of the message sent by the replyOutput activity:

This completes development of our first BPEL process. The next step is to call it via the Mediator. This will give us the option of transforming the input into the format we desire and of routing to different components based on the input content.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

By selecting the composite.xml tab in JDeveloper, we can see the outline of the Assembly that we have created for the BPEL process. We can add a Mediator to this by dragging it from the Component Palette.

Dragging the Mediator Component will cause a dialog to be displayed requesting a Name and Template for the Mediator.

If we select the Define Interface Later template, then we can click OK to add a Mediator to our Assembly. Defining the interface later will allow us to define the interface by wiring it to a service. Note that the types of interface templates are the same as the ones we saw for our BPEL process.

We want to have the Mediator use the same interface as the BPEL process. To rewire the composite to use a Mediator, we first delete the line joining the EchoProcess in the Exposed Services swimlane to the BPEL process by right-clicking on the line and selecting Delete.

We can now wire the EchoProcess service to the input of the Mediator by clicking on the chevron in the top-right corner of the exposed service and dragging it onto the connection point on the left-hand side of the Mediator.

Now wire the Mediator to the BPEL process by dragging the yellow arrow on the Mediator onto the blue chevron on the BPEL process.

We have now configured the Mediator to accept the same interface as the BPEL process and wired the Mediator to forward all messages onto the BPEL process. The default behavior of the Mediator, if it has no explicit rules, is to route the input request to the outbound request and then route the response, if any, from the target to the client.

We can now deploy and test the Assembly containing the Mediator in the same way that we deployed and tested the Assembly containing the BPEL process.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

In preparation for this, we will need the URL for the WSDL of our process. To obtain this, from the EM Dashboard, click on the EchoComposite Assembly, and then the connector icon to the right of the Settings button. This will display a link for the WSDL location and Endpoint, as shown in the following screenshot:

If you click on this link, the EM console will open a window showing details of the WSDL. Make a note of the WSDL location as we will need this in a moment.

Ensure that the Oracle Service Bus has started and then open up the Service Bus Console. Either do this from the Programs menu in Windows, select Oracle Weblogic | User Projects | OSB | Oracle Service Bus Admin Console

Or alternatively, open up a browser, and enter the following URL:

http://<hostname>:<port>/sbconsole

Where hostname represents the name of the machine on which OSB is running and port represents the port number. So if OSB is running on your local machine using the default port, enter the following URL in your browser:

http://localhost:7001/sbconsole

This will bring up the login screen for the Service Bus Console, log in as weblogic. By default, the OSB Console will display the Dashboard view, which provides a summary of the overall health of the system.

Looking at the console, we can see that it is divided into three distinct areas. The Change Center in the top-left-hand corner, which we will cover in a moment. Also on the left, below the Change Center, is the navigation bar which we use to navigate our way round the console.

The navigation bar is divided into the following sections: Operations, Resource Browser, Project Explorer, Security Configuration, and System Administration. Clicking on the appropriate section will expand that part of the navigation bar and allow you to access any of its sub-sections and their corresponding menu items.

Clicking on any of the menu items will display the appropriate page within the main window of the console. In the previous diagram we looked at the Dashboard view, under Monitoring, which is part of the Operations section.

Before we can create a new project, or make any configuration changes through the console, we must create a new change session. A Change Session allows us to specify a series of changes as a single unit of work. These changes won't come into effect until we activate a session. At any point we can discard our changes, which will cause OSB to roll back those changes and exit our session.

While making changes through a session, other users can also be making changes under separate sessions. If users create changes that conflict with changes in other sessions, then the Service Bus will flag that as a conflict in the Change Center and neither user will be able to commit their changes until those conflicts have been resolved.

To create a new change session, click on Create in the Change Center. This will update the Change Center to indicate that we are in a session and the user who owns that session. As we are logged in as weblogic, it will be updated to show weblogic session, as shown in the following screenshot:

In addition, you will see that the options available to us in the Change Center have changed to Activate, Discard, and Exit.

Before we can create our Echo proxy service, we must create an OSB project in which to place our resources. Typical resources include WSDL, XSD schemas, XSLT, and XQuery as well as Proxy and Business Services.

Resources can be created directly within our top-level project folder, or we can define a folder structure within our project into which we can place our resources.

The Project Explorer is where we create and manage all of this. Click on the Project Explorer section within the navigation bar. This will bring up the Projects view, as shown in the following screenshot:

Here we can see a list of all projects defined in OSB, which at this stage just includes the default project. From here we can also create a new project. Enter a project name, for example Chapter02, as shown in the preceding screenshot, and then click Add Project. This will create a new project and update our list of projects to reflect this.

Creating the project folders

Click on the project name will take us to the Project View, as shown in the screenshot on the next page.

We can see that this splits into three sections. The first section provides some basic details about the project including any references to or from artifacts in other projects as well as an optional description.

The second section lists any folders within the current project folder and provides the option to create additional folders within the project.

The final section lists any resource contained within this folder and provides the option to create additional resource.

We are going to create the project folders BusinessService, ProxyService, and WSDL, into which we will place our various resources. To create the first of these, in the Folders section, enter BusinessService as the folder name (circled in the preceding screenshot) and click on Add Folder. This will create a new folder and updates the list of folders to reflect this.

Once created, follow the same process to create the remaining folders; your list of folders will now look as shown in the preceding screenshot.

Before we can create either our proxy or business service, we need to define the WSDL on which the service will be based. For this, we are going to use the WSDL of our Echo BPEL process that we created earlier in this chapter.

Before importing the WSDL, we need to ensure that we are in the right folder within our project. To do this, click on the WSDL folder in our Folders list. On doing this the project view will be updated to show us the content of this folder, which is currently empty. In addition, the project summary section of our project view will be updated to show that we are now within the WSDL folder, as circled in the following screenshot:

If we look at the Project Explorer in the navigation bar, we can see that it has been updated to show our location within the projects structure. By clicking on any project or folder in here, the console will take us to the project view for that location.

Importing a WSDL

To import the Echo WSDL into our project, click on the drop-down list next to Create Resource in the Resources section, and select Resources from URL, as shown in the following screenshot:

This will bring up the page for loading resources from a URL, which is shown in the following screenshot:

Note

A WSDL can also be imported from the filesystem by selecting the WSDL option from the Create Resource drop-down list.

In the URL/Path, enter the URL for our Echo WSDL. This is the WSDL location we made a note of earlier (in the WSDL tab for the Echo process in the BPEL console) and should look like the following:

http://<hostname>:<port>/orabpel/default/Echo/1.0/Echo?wsdl

Enter an appropriate value for the Resource Name(for example Echo), select a Resource Type as WSDL, and click on Next.

This will bring up the Load Resources window, which will list the resources that OSB is ready to import.

You will notice that in addition to the actual WSDL file, it will also list the Echo.xsd. This is because the Echo.wsdl contains the following import statement:

<wsdl:types>
  <schema>
    <import namespace=
            "http://xmlns.oracle.com/SOASuiteBook11gChapter2_jws
/EchoComposite/EchoProcess"
            schemaLocation=
            "http://axreynol-us.us.oracle.com:8001/soa-infra/services/default/EchoComposite/echoprocess_client_ep?XSD=xsd/EchoProcess.xsd"/>
  </schema>
</wsdl:types>

This imports the Echo XML schema, which defines the input and output message of our Echo service. This schema was automatically generated by JDeveloper when we created our Echo process. In order to use our WSDL, we will need to import this schema as well. Because of the unusual URL for the XML Schema, the Service Bus generates its own unique name for the schema.

Click Import, the OSB console will confirm that the resources have been successfully imported and provide the option to Load Another resource, as shown in the following screenshot:

Click on the WSDL folder within the project explorer to return to its project view. This will be updated to include our imported resources, as shown in the following screenshot:

We are now ready to create our Echo business service. Click on the Business Service folder within the Project Explorer to go to the project view for this folder.

In the Resources section, click on the drop-down list next to Create Resource and select Business Service. This will bring up the General Configuration page for creating a business service, as shown in the following screenshot:

Here we specify the name of our business service (that is, EchoBS) and an optional description. Next we need to specify the Service Type, as we are creating our service based on a WSDL select WSDL Web Service.

Next, click the Browse button. This will launch a window from where we can select the WSDL for the Business Service, as shown on the next page:

By default, this window will list all WSDL resources that are defined to the Service Bus, though you can restrict the list by defining the search criteria.

In our case, we just have the Echo WSDL, so we click on this. We will now be prompted to select a WSDL definition, as shown in the following screenshot:

Here we need to select which binding or port definition we wish to use for our Business Service, select EchoProcess_pt and click Submit. Bindings provide an abstract interface and do not specify the physical endpoint, requiring additional configuration later. Ports have a physical endpoint and so require no additional configuration.

This will return us to the General Configuration screen with the Service Type updated to show the details of the selected WSDL and port, as shown in the following screenshot:

Then, click on Next. This will take us to the Transport Configuration page, as shown in the following screenshot. Here we need to specify how the business service is to invoke an external service.

As we based our business service on the EchoPort definition, the transport settings are already preconfigured, based on the content of our WSDL file.

From here, click on Last. This will take us to a summary page of our business service. Click on Save to create our business service.

This will return us to the project view on the Business Service folder and display the message The Service EchoBS was created successfully. If we examine the Resources section, we should see that it now contains our newly created business service.

We are now ready to create our Echo proxy service. Click on the Proxy Service folder within the Project Explorer to go to the project view for this folder.

In the Resources section, click on the drop-down list next to Create Resource and select Proxy Service. This will bring up the General Configuration page for creating a proxy service, as shown in the following screenshot:

You will notice that this looks very similar to the general configuration screen for a business service. So as before, enter the name of our service (that is, Echo) and an optional description.

Next, we need to specify the Service Type. We could do this in exactly the same way as we did for our business service and base it on the Echo WSDL. However, this time we are going to base it on our EchoBS business service. We will see why in a moment.

For the Service Type, select Business Service, as shown in the screenshot, and click Browse…. This will launch the Select Business Service window from where we can search for and select the business service that we want to base our proxy service on.

By default, this window will list all the business services defined to the Service Bus, though you can restrict the list by defining the search criteria.

In our case, we just have the EchoBS, so select this, and click on Submit. This will return us to the General Configuration screen with Service Type updated, as shown in the following screenshot:

From here, click Last. This will take us to a summary page of our proxy service. Click Save to create our proxy service.

This will return us to the project view on the Proxy Service folder and display the message The Service Echo was created successfully.

If we examine the Resources section of our project view, we should see that it now contains our newly created proxy service as shown in the following screenshot:

Creating message flow

Once we have created our proxy service, the next step is to specify how it should handle requests. This is defined in the message flow of the proxy service.

The message flow defines the actions that the proxy service should perform when a request is received such as validating the payload, transforming, or enriching it before routing it to the appropriate business service.

Within the resource section of our project view, click on the Edit Message Flow icon, as circled in the preceding image. This will take us to the Edit Message Flow window, where we can view and edit the message flow of our proxy service, as shown in the following screenshot:

Looking at this, we can see that Echo already invokes the route node RouteTo_EchoBS.

Click on this and select Edit Route(as shown in the preceding screenshot). This will take us to the Edit Stage Configuration window, as shown in the following screenshot:

Here we can see that it's already configured to route requests to the EchoBS business service.

Normally, when we create a proxy service we have to specify the message flow from scratch. However, when we created our Echo proxy service we based it on the EchoBS business service (as opposed to a WSDL). Because of this, the Service Bus has automatically configured the message flow to route requests to EchoBS.

As a result, our message flow is already predefined for us, so click Cancel, and then Cancel again to return to our project view.

Activating the Echo proxy service

We now have a completed proxy service; all that remains is to commit our work. Within the Change Center click Activate.

This will bring up the Activate Session, as shown in the following screenshot:

Before activating a session, it's good practice to give a description of the changes that we've made, just in case we need to roll them back later. So enter an appropriate description and then click on Submit, as shown in the preceding screenshot:

Assuming everything is okay, this will activate our changes, and the console will be updated to list our configuration changes, as shown in the following screenshot:

If you make a mistake and want to undo the changes you have activated, then you can click on the undo icon (circled in the preceding screenshot), and if you change your mind, you can revert the undo.

OSB allows you to undo any of your previous sessions as long as it doesn't result in an error in the runtime configuration of the Service Bus.

Testing our proxy service

All that's left is to test our proxy service. A simple way to do this is to initiate a test instance using the Service Bus test console.

To do this, we need to navigate back to the definition of our proxy service, rather than do this via the Project Explorer. We will use the Resource Browser. This provides a way to view all resources based on their type.

Click on the Resource Browser section within the navigation bar. By default, it will list all proxy services defined to the Service Bus, as shown in the following screenshot:

We can then filter this list further by specifying the appropriate search criteria.

Click on the Launch Test Console icon for the Echo proxy service (circled in the preceding screenshot). This will launch the test console shown on the next page.

The Available Operations drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

By default, the options Direct Call and Include Tracing are selected within the Test Configuration section; keep these selected as they enable us to trace the state of a message as it passes through the proxy service.

The Request Document section allows us to specify the SOAP Header and the Payload for our service. By default, these will contain a skeleton XML fragment based on the WSDL definition of the selected operation with default values for each field.

To execute a test instance of our service, modify the text in the <echo:input> element, as we have in the following screen shot, and click Execute. This will cause the console to generate a request message and use it to invoke our Echo proxy service.

Upon successful execution of the proxy, the test console will be updated to show the response returned. Here we can see that the result element contains our original initial input string, as shown in the following screenshot:

We can examine the state of our message as it passed through the proxy service by expanding the Invocation Trace, as we have in the following screenshot:

In addition, if you log back into the EM console, you should be able to see the Assembly instance that was invoked by the Service Bus.

Ensure that the Oracle Service Bus has started and then open up the Service Bus Console. Either do this from the Programs menu in Windows, select Oracle Weblogic | User Projects | OSB | Oracle Service Bus Admin Console

Or alternatively, open up a browser, and enter the following URL:

http://<hostname>:<port>/sbconsole

Where hostname represents the name of the machine on which OSB is running and port represents the port number. So if OSB is running on your local machine using the default port, enter the following URL in your browser:

http://localhost:7001/sbconsole

This will bring up the login screen for the Service Bus Console, log in as weblogic. By default, the OSB Console will display the Dashboard view, which provides a summary of the overall health of the system.

Looking at the console, we can see that it is divided into three distinct areas. The Change Center in the top-left-hand corner, which we will cover in a moment. Also on the left, below the Change Center, is the navigation bar which we use to navigate our way round the console.

The navigation bar is divided into the following sections: Operations, Resource Browser, Project Explorer, Security Configuration, and System Administration. Clicking on the appropriate section will expand that part of the navigation bar and allow you to access any of its sub-sections and their corresponding menu items.

Clicking on any of the menu items will display the appropriate page within the main window of the console. In the previous diagram we looked at the Dashboard view, under Monitoring, which is part of the Operations section.

Before we can create a new project, or make any configuration changes through the console, we must create a new change session. A Change Session allows us to specify a series of changes as a single unit of work. These changes won't come into effect until we activate a session. At any point we can discard our changes, which will cause OSB to roll back those changes and exit our session.

While making changes through a session, other users can also be making changes under separate sessions. If users create changes that conflict with changes in other sessions, then the Service Bus will flag that as a conflict in the Change Center and neither user will be able to commit their changes until those conflicts have been resolved.

To create a new change session, click on Create in the Change Center. This will update the Change Center to indicate that we are in a session and the user who owns that session. As we are logged in as weblogic, it will be updated to show weblogic session, as shown in the following screenshot:

In addition, you will see that the options available to us in the Change Center have changed to Activate, Discard, and Exit.

Before we can create our Echo proxy service, we must create an OSB project in which to place our resources. Typical resources include WSDL, XSD schemas, XSLT, and XQuery as well as Proxy and Business Services.

Resources can be created directly within our top-level project folder, or we can define a folder structure within our project into which we can place our resources.

The Project Explorer is where we create and manage all of this. Click on the Project Explorer section within the navigation bar. This will bring up the Projects view, as shown in the following screenshot:

Here we can see a list of all projects defined in OSB, which at this stage just includes the default project. From here we can also create a new project. Enter a project name, for example Chapter02, as shown in the preceding screenshot, and then click Add Project. This will create a new project and update our list of projects to reflect this.

Creating the project folders

Click on the project name will take us to the Project View, as shown in the screenshot on the next page.

We can see that this splits into three sections. The first section provides some basic details about the project including any references to or from artifacts in other projects as well as an optional description.

The second section lists any folders within the current project folder and provides the option to create additional folders within the project.

The final section lists any resource contained within this folder and provides the option to create additional resource.

We are going to create the project folders BusinessService, ProxyService, and WSDL, into which we will place our various resources. To create the first of these, in the Folders section, enter BusinessService as the folder name (circled in the preceding screenshot) and click on Add Folder. This will create a new folder and updates the list of folders to reflect this.

Once created, follow the same process to create the remaining folders; your list of folders will now look as shown in the preceding screenshot.

Before we can create either our proxy or business service, we need to define the WSDL on which the service will be based. For this, we are going to use the WSDL of our Echo BPEL process that we created earlier in this chapter.

Before importing the WSDL, we need to ensure that we are in the right folder within our project. To do this, click on the WSDL folder in our Folders list. On doing this the project view will be updated to show us the content of this folder, which is currently empty. In addition, the project summary section of our project view will be updated to show that we are now within the WSDL folder, as circled in the following screenshot:

If we look at the Project Explorer in the navigation bar, we can see that it has been updated to show our location within the projects structure. By clicking on any project or folder in here, the console will take us to the project view for that location.

Importing a WSDL

To import the Echo WSDL into our project, click on the drop-down list next to Create Resource in the Resources section, and select Resources from URL, as shown in the following screenshot:

This will bring up the page for loading resources from a URL, which is shown in the following screenshot:

Note

A WSDL can also be imported from the filesystem by selecting the WSDL option from the Create Resource drop-down list.

In the URL/Path, enter the URL for our Echo WSDL. This is the WSDL location we made a note of earlier (in the WSDL tab for the Echo process in the BPEL console) and should look like the following:

http://<hostname>:<port>/orabpel/default/Echo/1.0/Echo?wsdl

Enter an appropriate value for the Resource Name(for example Echo), select a Resource Type as WSDL, and click on Next.

This will bring up the Load Resources window, which will list the resources that OSB is ready to import.

You will notice that in addition to the actual WSDL file, it will also list the Echo.xsd. This is because the Echo.wsdl contains the following import statement:

<wsdl:types>
  <schema>
    <import namespace=
            "http://xmlns.oracle.com/SOASuiteBook11gChapter2_jws
/EchoComposite/EchoProcess"
            schemaLocation=
            "http://axreynol-us.us.oracle.com:8001/soa-infra/services/default/EchoComposite/echoprocess_client_ep?XSD=xsd/EchoProcess.xsd"/>
  </schema>
</wsdl:types>

This imports the Echo XML schema, which defines the input and output message of our Echo service. This schema was automatically generated by JDeveloper when we created our Echo process. In order to use our WSDL, we will need to import this schema as well. Because of the unusual URL for the XML Schema, the Service Bus generates its own unique name for the schema.

Click Import, the OSB console will confirm that the resources have been successfully imported and provide the option to Load Another resource, as shown in the following screenshot:

Click on the WSDL folder within the project explorer to return to its project view. This will be updated to include our imported resources, as shown in the following screenshot:

We are now ready to create our Echo business service. Click on the Business Service folder within the Project Explorer to go to the project view for this folder.

In the Resources section, click on the drop-down list next to Create Resource and select Business Service. This will bring up the General Configuration page for creating a business service, as shown in the following screenshot:

Here we specify the name of our business service (that is, EchoBS) and an optional description. Next we need to specify the Service Type, as we are creating our service based on a WSDL select WSDL Web Service.

Next, click the Browse button. This will launch a window from where we can select the WSDL for the Business Service, as shown on the next page:

By default, this window will list all WSDL resources that are defined to the Service Bus, though you can restrict the list by defining the search criteria.

In our case, we just have the Echo WSDL, so we click on this. We will now be prompted to select a WSDL definition, as shown in the following screenshot:

Here we need to select which binding or port definition we wish to use for our Business Service, select EchoProcess_pt and click Submit. Bindings provide an abstract interface and do not specify the physical endpoint, requiring additional configuration later. Ports have a physical endpoint and so require no additional configuration.

This will return us to the General Configuration screen with the Service Type updated to show the details of the selected WSDL and port, as shown in the following screenshot:

Then, click on Next. This will take us to the Transport Configuration page, as shown in the following screenshot. Here we need to specify how the business service is to invoke an external service.

As we based our business service on the EchoPort definition, the transport settings are already preconfigured, based on the content of our WSDL file.

From here, click on Last. This will take us to a summary page of our business service. Click on Save to create our business service.

This will return us to the project view on the Business Service folder and display the message The Service EchoBS was created successfully. If we examine the Resources section, we should see that it now contains our newly created business service.

We are now ready to create our Echo proxy service. Click on the Proxy Service folder within the Project Explorer to go to the project view for this folder.

In the Resources section, click on the drop-down list next to Create Resource and select Proxy Service. This will bring up the General Configuration page for creating a proxy service, as shown in the following screenshot:

You will notice that this looks very similar to the general configuration screen for a business service. So as before, enter the name of our service (that is, Echo) and an optional description.

Next, we need to specify the Service Type. We could do this in exactly the same way as we did for our business service and base it on the Echo WSDL. However, this time we are going to base it on our EchoBS business service. We will see why in a moment.

For the Service Type, select Business Service, as shown in the screenshot, and click Browse…. This will launch the Select Business Service window from where we can search for and select the business service that we want to base our proxy service on.

By default, this window will list all the business services defined to the Service Bus, though you can restrict the list by defining the search criteria.

In our case, we just have the EchoBS, so select this, and click on Submit. This will return us to the General Configuration screen with Service Type updated, as shown in the following screenshot:

From here, click Last. This will take us to a summary page of our proxy service. Click Save to create our proxy service.

This will return us to the project view on the Proxy Service folder and display the message The Service Echo was created successfully.

If we examine the Resources section of our project view, we should see that it now contains our newly created proxy service as shown in the following screenshot:

Creating message flow

Once we have created our proxy service, the next step is to specify how it should handle requests. This is defined in the message flow of the proxy service.

The message flow defines the actions that the proxy service should perform when a request is received such as validating the payload, transforming, or enriching it before routing it to the appropriate business service.

Within the resource section of our project view, click on the Edit Message Flow icon, as circled in the preceding image. This will take us to the Edit Message Flow window, where we can view and edit the message flow of our proxy service, as shown in the following screenshot:

Looking at this, we can see that Echo already invokes the route node RouteTo_EchoBS.

Click on this and select Edit Route(as shown in the preceding screenshot). This will take us to the Edit Stage Configuration window, as shown in the following screenshot:

Here we can see that it's already configured to route requests to the EchoBS business service.

Normally, when we create a proxy service we have to specify the message flow from scratch. However, when we created our Echo proxy service we based it on the EchoBS business service (as opposed to a WSDL). Because of this, the Service Bus has automatically configured the message flow to route requests to EchoBS.

As a result, our message flow is already predefined for us, so click Cancel, and then Cancel again to return to our project view.

Activating the Echo proxy service

We now have a completed proxy service; all that remains is to commit our work. Within the Change Center click Activate.

This will bring up the Activate Session, as shown in the following screenshot:

Before activating a session, it's good practice to give a description of the changes that we've made, just in case we need to roll them back later. So enter an appropriate description and then click on Submit, as shown in the preceding screenshot:

Assuming everything is okay, this will activate our changes, and the console will be updated to list our configuration changes, as shown in the following screenshot:

If you make a mistake and want to undo the changes you have activated, then you can click on the undo icon (circled in the preceding screenshot), and if you change your mind, you can revert the undo.

OSB allows you to undo any of your previous sessions as long as it doesn't result in an error in the runtime configuration of the Service Bus.

Testing our proxy service

All that's left is to test our proxy service. A simple way to do this is to initiate a test instance using the Service Bus test console.

To do this, we need to navigate back to the definition of our proxy service, rather than do this via the Project Explorer. We will use the Resource Browser. This provides a way to view all resources based on their type.

Click on the Resource Browser section within the navigation bar. By default, it will list all proxy services defined to the Service Bus, as shown in the following screenshot:

We can then filter this list further by specifying the appropriate search criteria.

Click on the Launch Test Console icon for the Echo proxy service (circled in the preceding screenshot). This will launch the test console shown on the next page.

The Available Operations drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

By default, the options Direct Call and Include Tracing are selected within the Test Configuration section; keep these selected as they enable us to trace the state of a message as it passes through the proxy service.

The Request Document section allows us to specify the SOAP Header and the Payload for our service. By default, these will contain a skeleton XML fragment based on the WSDL definition of the selected operation with default values for each field.

To execute a test instance of our service, modify the text in the <echo:input> element, as we have in the following screen shot, and click Execute. This will cause the console to generate a request message and use it to invoke our Echo proxy service.

Upon successful execution of the proxy, the test console will be updated to show the response returned. Here we can see that the result element contains our original initial input string, as shown in the following screenshot:

We can examine the state of our message as it passed through the proxy service by expanding the Invocation Trace, as we have in the following screenshot:

In addition, if you log back into the EM console, you should be able to see the Assembly instance that was invoked by the Service Bus.

Before we can create a new project, or make any configuration changes through the console, we must create a new change session. A Change Session allows us to specify a series of changes as a single unit of work. These changes won't come into effect until we activate a session. At any point we can discard our changes, which will cause OSB to roll back those changes and exit our session.

While making changes through a session, other users can also be making changes under separate sessions. If users create changes that conflict with changes in other sessions, then the Service Bus will flag that as a conflict in the Change Center and neither user will be able to commit their changes until those conflicts have been resolved.

To create a new change session, click on Create in the Change Center. This will update the Change Center to indicate that we are in a session and the user who owns that session. As we are logged in as weblogic, it will be updated to show weblogic session, as shown in the following screenshot:

In addition, you will see that the options available to us in the Change Center have changed to Activate, Discard, and Exit.

Before we can create our Echo proxy service, we must create an OSB project in which to place our resources. Typical resources include WSDL, XSD schemas, XSLT, and XQuery as well as Proxy and Business Services.

Resources can be created directly within our top-level project folder, or we can define a folder structure within our project into which we can place our resources.

The Project Explorer is where we create and manage all of this. Click on the Project Explorer section within the navigation bar. This will bring up the Projects view, as shown in the following screenshot:

Here we can see a list of all projects defined in OSB, which at this stage just includes the default project. From here we can also create a new project. Enter a project name, for example Chapter02, as shown in the preceding screenshot, and then click Add Project. This will create a new project and update our list of projects to reflect this.

Creating the project folders

Click on the project name will take us to the Project View, as shown in the screenshot on the next page.

We can see that this splits into three sections. The first section provides some basic details about the project including any references to or from artifacts in other projects as well as an optional description.

The second section lists any folders within the current project folder and provides the option to create additional folders within the project.

The final section lists any resource contained within this folder and provides the option to create additional resource.

We are going to create the project folders BusinessService, ProxyService, and WSDL, into which we will place our various resources. To create the first of these, in the Folders section, enter BusinessService as the folder name (circled in the preceding screenshot) and click on Add Folder. This will create a new folder and updates the list of folders to reflect this.

Once created, follow the same process to create the remaining folders; your list of folders will now look as shown in the preceding screenshot.

Before we can create either our proxy or business service, we need to define the WSDL on which the service will be based. For this, we are going to use the WSDL of our Echo BPEL process that we created earlier in this chapter.

Before importing the WSDL, we need to ensure that we are in the right folder within our project. To do this, click on the WSDL folder in our Folders list. On doing this the project view will be updated to show us the content of this folder, which is currently empty. In addition, the project summary section of our project view will be updated to show that we are now within the WSDL folder, as circled in the following screenshot:

If we look at the Project Explorer in the navigation bar, we can see that it has been updated to show our location within the projects structure. By clicking on any project or folder in here, the console will take us to the project view for that location.

Importing a WSDL

To import the Echo WSDL into our project, click on the drop-down list next to Create Resource in the Resources section, and select Resources from URL, as shown in the following screenshot:

This will bring up the page for loading resources from a URL, which is shown in the following screenshot:

Note

A WSDL can also be imported from the filesystem by selecting the WSDL option from the Create Resource drop-down list.

In the URL/Path, enter the URL for our Echo WSDL. This is the WSDL location we made a note of earlier (in the WSDL tab for the Echo process in the BPEL console) and should look like the following:

http://<hostname>:<port>/orabpel/default/Echo/1.0/Echo?wsdl

Enter an appropriate value for the Resource Name(for example Echo), select a Resource Type as WSDL, and click on Next.

This will bring up the Load Resources window, which will list the resources that OSB is ready to import.

You will notice that in addition to the actual WSDL file, it will also list the Echo.xsd. This is because the Echo.wsdl contains the following import statement:

<wsdl:types>
  <schema>
    <import namespace=
            "http://xmlns.oracle.com/SOASuiteBook11gChapter2_jws
/EchoComposite/EchoProcess"
            schemaLocation=
            "http://axreynol-us.us.oracle.com:8001/soa-infra/services/default/EchoComposite/echoprocess_client_ep?XSD=xsd/EchoProcess.xsd"/>
  </schema>
</wsdl:types>

This imports the Echo XML schema, which defines the input and output message of our Echo service. This schema was automatically generated by JDeveloper when we created our Echo process. In order to use our WSDL, we will need to import this schema as well. Because of the unusual URL for the XML Schema, the Service Bus generates its own unique name for the schema.

Click Import, the OSB console will confirm that the resources have been successfully imported and provide the option to Load Another resource, as shown in the following screenshot:

Click on the WSDL folder within the project explorer to return to its project view. This will be updated to include our imported resources, as shown in the following screenshot:

We are now ready to create our Echo business service. Click on the Business Service folder within the Project Explorer to go to the project view for this folder.

In the Resources section, click on the drop-down list next to Create Resource and select Business Service. This will bring up the General Configuration page for creating a business service, as shown in the following screenshot:

Here we specify the name of our business service (that is, EchoBS) and an optional description. Next we need to specify the Service Type, as we are creating our service based on a WSDL select WSDL Web Service.

Next, click the Browse button. This will launch a window from where we can select the WSDL for the Business Service, as shown on the next page:

By default, this window will list all WSDL resources that are defined to the Service Bus, though you can restrict the list by defining the search criteria.

In our case, we just have the Echo WSDL, so we click on this. We will now be prompted to select a WSDL definition, as shown in the following screenshot:

Here we need to select which binding or port definition we wish to use for our Business Service, select EchoProcess_pt and click Submit. Bindings provide an abstract interface and do not specify the physical endpoint, requiring additional configuration later. Ports have a physical endpoint and so require no additional configuration.

This will return us to the General Configuration screen with the Service Type updated to show the details of the selected WSDL and port, as shown in the following screenshot:

Then, click on Next. This will take us to the Transport Configuration page, as shown in the following screenshot. Here we need to specify how the business service is to invoke an external service.

As we based our business service on the EchoPort definition, the transport settings are already preconfigured, based on the content of our WSDL file.

From here, click on Last. This will take us to a summary page of our business service. Click on Save to create our business service.

This will return us to the project view on the Business Service folder and display the message The Service EchoBS was created successfully. If we examine the Resources section, we should see that it now contains our newly created business service.

We are now ready to create our Echo proxy service. Click on the Proxy Service folder within the Project Explorer to go to the project view for this folder.

In the Resources section, click on the drop-down list next to Create Resource and select Proxy Service. This will bring up the General Configuration page for creating a proxy service, as shown in the following screenshot:

You will notice that this looks very similar to the general configuration screen for a business service. So as before, enter the name of our service (that is, Echo) and an optional description.

Next, we need to specify the Service Type. We could do this in exactly the same way as we did for our business service and base it on the Echo WSDL. However, this time we are going to base it on our EchoBS business service. We will see why in a moment.

For the Service Type, select Business Service, as shown in the screenshot, and click Browse…. This will launch the Select Business Service window from where we can search for and select the business service that we want to base our proxy service on.

By default, this window will list all the business services defined to the Service Bus, though you can restrict the list by defining the search criteria.

In our case, we just have the EchoBS, so select this, and click on Submit. This will return us to the General Configuration screen with Service Type updated, as shown in the following screenshot:

From here, click Last. This will take us to a summary page of our proxy service. Click Save to create our proxy service.

This will return us to the project view on the Proxy Service folder and display the message The Service Echo was created successfully.

If we examine the Resources section of our project view, we should see that it now contains our newly created proxy service as shown in the following screenshot:

Creating message flow

Once we have created our proxy service, the next step is to specify how it should handle requests. This is defined in the message flow of the proxy service.

The message flow defines the actions that the proxy service should perform when a request is received such as validating the payload, transforming, or enriching it before routing it to the appropriate business service.

Within the resource section of our project view, click on the Edit Message Flow icon, as circled in the preceding image. This will take us to the Edit Message Flow window, where we can view and edit the message flow of our proxy service, as shown in the following screenshot:

Looking at this, we can see that Echo already invokes the route node RouteTo_EchoBS.

Click on this and select Edit Route(as shown in the preceding screenshot). This will take us to the Edit Stage Configuration window, as shown in the following screenshot:

Here we can see that it's already configured to route requests to the EchoBS business service.

Normally, when we create a proxy service we have to specify the message flow from scratch. However, when we created our Echo proxy service we based it on the EchoBS business service (as opposed to a WSDL). Because of this, the Service Bus has automatically configured the message flow to route requests to EchoBS.

As a result, our message flow is already predefined for us, so click Cancel, and then Cancel again to return to our project view.

Activating the Echo proxy service

We now have a completed proxy service; all that remains is to commit our work. Within the Change Center click Activate.

This will bring up the Activate Session, as shown in the following screenshot:

Before activating a session, it's good practice to give a description of the changes that we've made, just in case we need to roll them back later. So enter an appropriate description and then click on Submit, as shown in the preceding screenshot:

Assuming everything is okay, this will activate our changes, and the console will be updated to list our configuration changes, as shown in the following screenshot:

If you make a mistake and want to undo the changes you have activated, then you can click on the undo icon (circled in the preceding screenshot), and if you change your mind, you can revert the undo.

OSB allows you to undo any of your previous sessions as long as it doesn't result in an error in the runtime configuration of the Service Bus.

Testing our proxy service

All that's left is to test our proxy service. A simple way to do this is to initiate a test instance using the Service Bus test console.

To do this, we need to navigate back to the definition of our proxy service, rather than do this via the Project Explorer. We will use the Resource Browser. This provides a way to view all resources based on their type.

Click on the Resource Browser section within the navigation bar. By default, it will list all proxy services defined to the Service Bus, as shown in the following screenshot:

We can then filter this list further by specifying the appropriate search criteria.

Click on the Launch Test Console icon for the Echo proxy service (circled in the preceding screenshot). This will launch the test console shown on the next page.

The Available Operations drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

By default, the options Direct Call and Include Tracing are selected within the Test Configuration section; keep these selected as they enable us to trace the state of a message as it passes through the proxy service.

The Request Document section allows us to specify the SOAP Header and the Payload for our service. By default, these will contain a skeleton XML fragment based on the WSDL definition of the selected operation with default values for each field.

To execute a test instance of our service, modify the text in the <echo:input> element, as we have in the following screen shot, and click Execute. This will cause the console to generate a request message and use it to invoke our Echo proxy service.

Upon successful execution of the proxy, the test console will be updated to show the response returned. Here we can see that the result element contains our original initial input string, as shown in the following screenshot:

We can examine the state of our message as it passed through the proxy service by expanding the Invocation Trace, as we have in the following screenshot:

In addition, if you log back into the EM console, you should be able to see the Assembly instance that was invoked by the Service Bus.

Before we can create our Echo proxy service, we must create an OSB project in which to place our resources. Typical resources include WSDL, XSD schemas, XSLT, and XQuery as well as Proxy and Business Services.

Resources can be created directly within our top-level project folder, or we can define a folder structure within our project into which we can place our resources.

The Project Explorer is where we create and manage all of this. Click on the Project Explorer section within the navigation bar. This will bring up the Projects view, as shown in the following screenshot:

Here we can see a list of all projects defined in OSB, which at this stage just includes the default project. From here we can also create a new project. Enter a project name, for example Chapter02, as shown in the preceding screenshot, and then click Add Project. This will create a new project and update our list of projects to reflect this.

Creating the project folders

Click on the project name will take us to the Project View, as shown in the screenshot on the next page.

We can see that this splits into three sections. The first section provides some basic details about the project including any references to or from artifacts in other projects as well as an optional description.

The second section lists any folders within the current project folder and provides the option to create additional folders within the project.

The final section lists any resource contained within this folder and provides the option to create additional resource.

We are going to create the project folders BusinessService, ProxyService, and WSDL, into which we will place our various resources. To create the first of these, in the Folders section, enter BusinessService as the folder name (circled in the preceding screenshot) and click on Add Folder. This will create a new folder and updates the list of folders to reflect this.

Once created, follow the same process to create the remaining folders; your list of folders will now look as shown in the preceding screenshot.

Before we can create either our proxy or business service, we need to define the WSDL on which the service will be based. For this, we are going to use the WSDL of our Echo BPEL process that we created earlier in this chapter.

Before importing the WSDL, we need to ensure that we are in the right folder within our project. To do this, click on the WSDL folder in our Folders list. On doing this the project view will be updated to show us the content of this folder, which is currently empty. In addition, the project summary section of our project view will be updated to show that we are now within the WSDL folder, as circled in the following screenshot:

If we look at the Project Explorer in the navigation bar, we can see that it has been updated to show our location within the projects structure. By clicking on any project or folder in here, the console will take us to the project view for that location.

Importing a WSDL

To import the Echo WSDL into our project, click on the drop-down list next to Create Resource in the Resources section, and select Resources from URL, as shown in the following screenshot:

This will bring up the page for loading resources from a URL, which is shown in the following screenshot:

Note

A WSDL can also be imported from the filesystem by selecting the WSDL option from the Create Resource drop-down list.

In the URL/Path, enter the URL for our Echo WSDL. This is the WSDL location we made a note of earlier (in the WSDL tab for the Echo process in the BPEL console) and should look like the following:

http://<hostname>:<port>/orabpel/default/Echo/1.0/Echo?wsdl

Enter an appropriate value for the Resource Name(for example Echo), select a Resource Type as WSDL, and click on Next.

This will bring up the Load Resources window, which will list the resources that OSB is ready to import.

You will notice that in addition to the actual WSDL file, it will also list the Echo.xsd. This is because the Echo.wsdl contains the following import statement:

<wsdl:types>
  <schema>
    <import namespace=
            "http://xmlns.oracle.com/SOASuiteBook11gChapter2_jws
/EchoComposite/EchoProcess"
            schemaLocation=
            "http://axreynol-us.us.oracle.com:8001/soa-infra/services/default/EchoComposite/echoprocess_client_ep?XSD=xsd/EchoProcess.xsd"/>
  </schema>
</wsdl:types>

This imports the Echo XML schema, which defines the input and output message of our Echo service. This schema was automatically generated by JDeveloper when we created our Echo process. In order to use our WSDL, we will need to import this schema as well. Because of the unusual URL for the XML Schema, the Service Bus generates its own unique name for the schema.

Click Import, the OSB console will confirm that the resources have been successfully imported and provide the option to Load Another resource, as shown in the following screenshot:

Click on the WSDL folder within the project explorer to return to its project view. This will be updated to include our imported resources, as shown in the following screenshot:

We are now ready to create our Echo business service. Click on the Business Service folder within the Project Explorer to go to the project view for this folder.

In the Resources section, click on the drop-down list next to Create Resource and select Business Service. This will bring up the General Configuration page for creating a business service, as shown in the following screenshot:

Here we specify the name of our business service (that is, EchoBS) and an optional description. Next we need to specify the Service Type, as we are creating our service based on a WSDL select WSDL Web Service.

Next, click the Browse button. This will launch a window from where we can select the WSDL for the Business Service, as shown on the next page:

By default, this window will list all WSDL resources that are defined to the Service Bus, though you can restrict the list by defining the search criteria.

In our case, we just have the Echo WSDL, so we click on this. We will now be prompted to select a WSDL definition, as shown in the following screenshot:

Here we need to select which binding or port definition we wish to use for our Business Service, select EchoProcess_pt and click Submit. Bindings provide an abstract interface and do not specify the physical endpoint, requiring additional configuration later. Ports have a physical endpoint and so require no additional configuration.

This will return us to the General Configuration screen with the Service Type updated to show the details of the selected WSDL and port, as shown in the following screenshot:

Then, click on Next. This will take us to the Transport Configuration page, as shown in the following screenshot. Here we need to specify how the business service is to invoke an external service.

As we based our business service on the EchoPort definition, the transport settings are already preconfigured, based on the content of our WSDL file.

From here, click on Last. This will take us to a summary page of our business service. Click on Save to create our business service.

This will return us to the project view on the Business Service folder and display the message The Service EchoBS was created successfully. If we examine the Resources section, we should see that it now contains our newly created business service.

We are now ready to create our Echo proxy service. Click on the Proxy Service folder within the Project Explorer to go to the project view for this folder.

In the Resources section, click on the drop-down list next to Create Resource and select Proxy Service. This will bring up the General Configuration page for creating a proxy service, as shown in the following screenshot:

You will notice that this looks very similar to the general configuration screen for a business service. So as before, enter the name of our service (that is, Echo) and an optional description.

Next, we need to specify the Service Type. We could do this in exactly the same way as we did for our business service and base it on the Echo WSDL. However, this time we are going to base it on our EchoBS business service. We will see why in a moment.

For the Service Type, select Business Service, as shown in the screenshot, and click Browse…. This will launch the Select Business Service window from where we can search for and select the business service that we want to base our proxy service on.

By default, this window will list all the business services defined to the Service Bus, though you can restrict the list by defining the search criteria.

In our case, we just have the EchoBS, so select this, and click on Submit. This will return us to the General Configuration screen with Service Type updated, as shown in the following screenshot:

From here, click Last. This will take us to a summary page of our proxy service. Click Save to create our proxy service.

This will return us to the project view on the Proxy Service folder and display the message The Service Echo was created successfully.

If we examine the Resources section of our project view, we should see that it now contains our newly created proxy service as shown in the following screenshot:

Creating message flow

Once we have created our proxy service, the next step is to specify how it should handle requests. This is defined in the message flow of the proxy service.

The message flow defines the actions that the proxy service should perform when a request is received such as validating the payload, transforming, or enriching it before routing it to the appropriate business service.

Within the resource section of our project view, click on the Edit Message Flow icon, as circled in the preceding image. This will take us to the Edit Message Flow window, where we can view and edit the message flow of our proxy service, as shown in the following screenshot:

Looking at this, we can see that Echo already invokes the route node RouteTo_EchoBS.

Click on this and select Edit Route(as shown in the preceding screenshot). This will take us to the Edit Stage Configuration window, as shown in the following screenshot:

Here we can see that it's already configured to route requests to the EchoBS business service.

Normally, when we create a proxy service we have to specify the message flow from scratch. However, when we created our Echo proxy service we based it on the EchoBS business service (as opposed to a WSDL). Because of this, the Service Bus has automatically configured the message flow to route requests to EchoBS.

As a result, our message flow is already predefined for us, so click Cancel, and then Cancel again to return to our project view.

Activating the Echo proxy service

We now have a completed proxy service; all that remains is to commit our work. Within the Change Center click Activate.

This will bring up the Activate Session, as shown in the following screenshot:

Before activating a session, it's good practice to give a description of the changes that we've made, just in case we need to roll them back later. So enter an appropriate description and then click on Submit, as shown in the preceding screenshot:

Assuming everything is okay, this will activate our changes, and the console will be updated to list our configuration changes, as shown in the following screenshot:

If you make a mistake and want to undo the changes you have activated, then you can click on the undo icon (circled in the preceding screenshot), and if you change your mind, you can revert the undo.

OSB allows you to undo any of your previous sessions as long as it doesn't result in an error in the runtime configuration of the Service Bus.

Testing our proxy service

All that's left is to test our proxy service. A simple way to do this is to initiate a test instance using the Service Bus test console.

To do this, we need to navigate back to the definition of our proxy service, rather than do this via the Project Explorer. We will use the Resource Browser. This provides a way to view all resources based on their type.

Click on the Resource Browser section within the navigation bar. By default, it will list all proxy services defined to the Service Bus, as shown in the following screenshot:

We can then filter this list further by specifying the appropriate search criteria.

Click on the Launch Test Console icon for the Echo proxy service (circled in the preceding screenshot). This will launch the test console shown on the next page.

The Available Operations drop-down list allows us to specify which operation we want to invoke. In our case, it's automatically defaulted to process.

By default, the options Direct Call and Include Tracing are selected within the Test Configuration section; keep these selected as they enable us to trace the state of a message as it passes through the proxy service.

The Request Document section allows us to specify the SOAP Header and the Payload for our service. By default, these will contain a skeleton XML fragment based on the WSDL definition of the selected operation with default values for each field.

To execute a test instance of our service, modify the text in the <echo:input> element, as we have in the following screen shot, and click Execute. This will cause the console to generate a request message and use it to invoke our Echo proxy service.

Upon successful execution of the proxy, the test console will be updated to show the response returned. Here we can see that the result element contains our original initial input string, as shown in the following screenshot:

We can examine the state of our message as it passed through the proxy service by expanding the Invocation Trace, as we have in the following screenshot:

In addition, if you log back into the EM console, you should be able to see the Assembly instance that was invoked by the Service Bus.

Before we can create either our proxy or business service, we need to define the WSDL on which the service will be based. For this, we are going to use the WSDL of our Echo BPEL process that we created earlier in this chapter.

Before importing the WSDL, we need to ensure that we are in the right folder within our project. To do this, click on the WSDL folder in our Folders list. On doing this the project view will be updated to show us the content of this folder, which is currently empty. In addition, the project summary section of our project view will be updated to show that we are now within the WSDL folder, as circled in the following screenshot:

If we look at the Project Explorer in the navigation bar, we can see that it has been updated to show our location within the projects structure. By clicking on any project or folder in here, the console will take us to the project view for that location.