(For more resources on BPEL, SOA and Oracle see here.)
If we want our SOA architecture to be highly fexible and agile, we have to ensure loose coupling between different components. As service interfaces and endpoint addresses change over time, we have to remove all point-to-point connections between service providers and service consumers by introducing an intermediate layer—Enterprise Service Bus (ESB). ESB is a key component of every mature SOA architecture and provides several important functionalities, such as message routing, transformation between message types and protocols, the use of adapters, and so on. Another important requirement for providing fexibility is service-reuse. This can be achieved through the use of UDDI (Universal Description, Discovery and Integration) compliant service registry, which enables us to publish and discover services. Using service registry we can also implement dynamic endpoint lookup, so that service consumers retrieve actual service endpoint address from registry in runtime.
Oracle Service Bus architecture and features
ESB provides means to manage connections, control the communication between services, supervise the services and their SLAs (Service Level Agreements), and much more. The importance of the ESB often becomes visible after the frst development iteration of SOA composite application has taken place. For example, when a service requires a change in its interface or payload, the ESB can provide the transformation capabilities to mask the differences to existing service consumers. ESB can also mask the location of services, making it easy to migrate services to different servers. There are plenty other scenarios, where ESB is important.
In this article, we will look at the Oracle Service Bus (OSB). OSB presents a communication backbone for transport and routing of messages across an enterprise. It is designed for high-throughput and reliable message delivery to a variety of service providers and consumers. It supports XML as a native data type, however, other data types are also supported. As an intermediary, it processes incoming service request messages, executes the routing logic and transforms these messages if needed. It can also transform between different transport protocols (HTTP, JMS, File, FTP, and so on.). Service response messages follow the inverse path. The message processing is specifed in the message fow defnition of a proxy service.
OSB provides some functionalities that are similar to the functionalities of the Mediator component within the SOA Composite, such as routing, validation, fltering, and transformation. The major difference is that the Mediator is a mediation component that is meant to work within the SOA Composite and is deployed within a SOA composition application. The OSB on the other hand is a standalone service bus. In addition to providing the communication backbone for all SOA (and non-SOA) applications, OSB mission is to shield application developers from changes in the service endpoints and to prevent those systems from being overloaded with requests from upstream applications.
In addition to the Oracle Service Bus, we can also use the Mediator service component, which also provides mediation capabilities, but only within SOA composite applications. On the other hand, OSB is used for inter-application communication.
The following figure shows the functional architecture of Oracle Service Bus (OSB). We can see that OSB can be categorized into four functional layers:
- Messaging layer: Provides support to reliably connect any service by leveraging standards, such as HTTP/SOAP, WS-I, WS-Security, WS-Policy, WS-Addressing, SOAP v1.1, SOAP v1.2, EJB, RMI, and so on. It even supports the creation of custom transports using the Custom Transport Software Development Kit (SDK).
- Security layer: Provides security at all levels: Transport Security (SSL), Message Security (WS-Policy, WS-Security, and so on), Console Security (SSO and role based access) and Policy (leverages WS-Security and WS-Policy).
- Composition layer: Provides confguration-driven composition environment. We can use either the Eclipse plug-in environment or web-based Oracle Service Bus Console. We can model message fows that contain content-based routing, message validation, and exception handling. We can also use message transformations (XSLT, XQuery), service callouts (POJO, Web Services), and a test browser. Automatic synchronization with UDDI registries is also supported.
- Management layer: Provides a unifed dashboard for service monitoring and management. We can defne and monitor Service Level Agreements (SLAs), alerts on operation metrics and message pipelines, and view reports.
Proxy services and business services
OSB uses a specifc terminology of proxy and business services. The objective of OSB is to route message between business services and service consumers through proxy services.
Proxy services are generic intermediary web services that implement the mediation logic and are hosted locally on OSB. Proxy services route messages to business services and are exposed to service consumers. A proxy service is confgured by specifying its interface, type of transport, and its associated message processing logic. Message fow defnitions are used to defne the proxy service message handling capabilities.
Business services describe the enterprise services that exchange messages with business processes and which we want to virtualize using the OSB. The defnition of a business service is similar to that of a proxy service, however, the business services does not have a message fow defnition.
Message fow modeling
Message fows are used to defne message processing logic of proxy services. Message fow modeling includes defning a sequence of activities, where activities are individual actions, such as transformations, reporting, publishing and exception management. Message fow modeling can be performed using a visual development environment (Eclipse or Oracle Service Bus Console). Message fow defnitions are defned using components, such as pipelines, branch nodes and route nodes, as shown in the following fgure:
A pipeline is a sequence of stages, representing a one-way processing path. It is used to specify message fow for service requests and responses. If a service defnes more operations, a pipeline might optionally branch into operational pipelines. There are three types of pipelines:
- Request pipelines are used to specify the request path of the message flow
- Response pipelines are used to specify the response path of a message flow
- Error pipelines are used as error handlers.
Request and response pipelines are paired together as pipeline pairs. Branch nodes are used as exclusive switches, where the processing can follow one of the branches. A variable in the message context is used as a lookup variable to determine which branch to follow.
Route nodes are used to communicate with another service (in most cases a business service). They cannot have any descendants in the message fow. When the route node sends the request message, the request processing is fnished. On the other side, when it receives a response message, the response processing begins.
Each pipeline is a sequence of stages that contain user-defned message processing actions. We can choose between a variety of supported actions, such as Publish, Service Callout, For Each, If... Then..., Raise Error, Reply, Resume, Skip, Delete, Insert, Replace, Validate, Alert, Log, Report, and more. Later in this article, we will show you how to use a pipeline on the Travel Approval process. However, let us frst look at the Oracle Service Registry, which we will use together with the OSB.
(For more resources on BPEL, SOA and Oracle see here.)
Oracle Service Registry
Oracle Service Registry (OSR) is a fully V3-compliant implementation of UDDI (Universal Description, Discovery and Integration), and one of the key components of Oracle SOA Suite 11g. It allows us to publish and discover services and service providers, and manage metadata about services (security, transport, or quality service) using taxonomies. Therefore, it plays an important role when trying to improve visibility and promote service reuse. It is also important in the scope of SOA governance.
Service registry is very important for various reasons. It provides a central place where all service defnitions are stored. This becomes important when the number of services (including BPEL processes) grows. It helps to maintain overview of services. Service registry also provides a central place where developers can search for existing services. This improves service reuse, which is one of the most important aspects of SOA. Of course, service registry also provides means to publish services for other developers to discover and reuse.
In addition to reuse, service registry can also be helpful when we need to migrate services from one server to the other. This can happen because of various reasons, but one of the most common reasons is the migration between the development, test, and production environments. Service registry is also helpful when we need to version services and manage changes. With service registry we can also develop more loosely-coupled composite applications, because we do not need to hard-code the service URLs. Rather, the application will resolve URLs at run-time. In all cases, service registry is often used together with the ESB. We will not discuss all OSR details in this article. We will demonstrate how to publish a service, how to export/import resources between OSB and OSR, how to browse the OSR using JDeveloper, and how to enable dynamic endpoint lookup in a SOA composite application.
Logging into Oracle Service Registry
To log into Oracle Registry Control, we have to open web browser and access the following URL: http://host_name:port/application_name/uddi/web, where host_name is the name of the host on which OSR is installed, application_name is name of the application (default name is registry), and port is a number that is set during installation process.
OSR provides two web consoles: Registry Control and Business Service Control. Registry Control provides an interface that is based on the UDDI specifcation and is useful for developers familiar with business entities and tModels. Business Service Control on the other hand provides a simpler interface for less-technical users unfamiliar with tModels and other UDDI stuff. We can publish and discover services using both. In this article, we will show how to use Registry Control Console. We click on the Login link in the upper-right corner. The Registry Control home page opens, as shown in the following screenshot:
Publishing a business entity
Before publishing the EmployeeTravelStatus service, we have to publish a business entity (service provider). This is because the UDDI data model requires a business entity for each service, which is represented by a tModel. We click on the Publish link and then press the Add business button. We name the business entity Packt Publishing. We can also add a description and enter custom business key.
We click on the Add business button and then Save changes.
Publishing a business service
Back on the Publish page, we expand the Businesses folder, right-click the Packt Publishing business entity, and select Publish WSDL.
The Publish WSDL document page opens. We enter the WSDL location (URI) of the EmployeeTravelStatus service and click Publish.
The Publish summary page opens. We can review the entities that have been published to the OSR. We click OK.
In the above article we have covered:
- Oracle Service Bus architecture and features
- Publishing services to OSR
- BPEL4People [Article]
- Bussiness Processes in BPEL [Article]
- Human Interactions in BPEL [Article]
- Web Services, SOA, and WS-BPEL Technologies [Article]
- SOA—Service Oriented Architecture [Article]
- Oracle Web Services Manager: Authentication and Authorization [Article]