This chapter discusses the service configuration and resource organization capabilities provided by Oracle Service Bus. It highlights features that support service discovery and change management. This section is intended for IT deployment specialists who are responsible for configuring services in an SOA.
This chapter includes the following sections:
Oracle Service Bus has a robust resource configuration and organization framework for creating, organizing and configuring resources and ensuring semantic integrity between resource dependencies. It provides features to rapidly test, deploy, and, reverse resource configuration updates if required.
Oracle Service Bus has a built-in Project Explorer that allows logical grouping of Oracle Service Bus entities, allowing developers and administrators to better organize related parts of large development projects. For more information, see "Working with Projects, Folders, and Resources" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Oracle Service Bus resources can be organized into separate projects. Projects are non-hierarchical, disjointed, top-level grouping constructs. All resources (such as services, WS-Policies, WSDLs, XQuery transformations, etc.) reside in exactly one non-overlapping project.
Resources can be created directly under a project or be further organized into folders. Folders may be created inside projects or inside other folders and are similar to directories in a file system, with the project level being the root directory. Descriptions can be added to all projects and folders to further enhance navigation. Figure 4-1 shows the project and folder views in the Oracle Service Bus Administration Console.
Resources can be moved between projects or folders and can be renamed. Any Oracle Service Bus resource, project or folder can be cloned to create a copy of that resource with the specified target identity. Cloning a project or folder copies all artifacts in the project or folder to a different location.
Resources that are located in one project can reference and use resources that are defined in other projects. Dependencies are preserved when resources are renamed and moved. All references to a renamed or moved resource are automatically adjusted. An additional capability of the Project Explorer is the ability to track which resources outside the current folder are referenced by resources residing in it. Viewing these references gives both the location of the referenced resource (in the format of <project name>/<folder name>/<resource name>) and the type of resource referenced. For more information about referenced resources, see Section 4.2.5, "Tracking Dependencies."
Oracle Service Bus provides a number of capabilities to organize large numbers of resources in the resource cache. The resources in the Oracle Service Bus resource cache include WSDLs, XML Schemas, XQueries, XSLTs, MFLs, WS-Policies, Business Services, and Proxy Services. Oracle Service Bus relies on user-configured metadata for resources and services to determine how to process messages.
Oracle Service Bus is focused on supporting a set of trusted IT department specialists who manage the resources and services in the resource cache on behalf of the organizations they represent. All such users are defined as integration administrators or integration deployers and have full permissions to modify all the resources in the resource cache. Integration monitor users have full read access to the resource cache but cannot modify any resources. Typically, they are users who search or browse for resources or services. Integration operator users have full read access to the resource cache and can only change the operational characteristics of the services.
For more information about Oracle Service Bus users and roles, see "Security Configuration" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
This section describes change management in Oracle Service Bus.
One of the most important features of Oracle Service Bus is the Change Center, which is key to making configuration changes inside the service bus. The Change Center has the unique ability to lock its current configuration while changes are being made. This lets the service bus continue to receive and process requests for services while configuration changes are being made in the Oracle Service Bus Administration Console.
Additionally, changes being made to the configuration will not affect the current configuration until they are "activated." Once this is done, the changes go live instantly and Oracle Service Bus immediately uses the new configuration.
Under heavy load conditions, request messages may fail if they arrive while a proxy service pipeline is in the process of being activated. Once the proxy service pipeline activation is complete, new requests are processed normally.
If activated changes cause unpredictable, undesirable events, the Change Center also provides the capability to undo any changes made for any session. Task Details provides information on which resource was changed, who changed it, and when. An entire session or individual changes within a session can be rolled back, enabling Oracle Service Bus to roll the affected configurations back to the prior state.
For more information on Change Center, see "Using the Change Center" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Before you make modifications to resources in Oracle Service Bus, you must create a session. All modifications are made using the Oracle Service Bus Administration Console in a given session.
A session can be considered a sandbox environment in which changes are kept private to the user making those changes. In other words, they are not visible to other concurrent users making modifications. Modifications made in a session are not deployed in the server until the session is activated. Only one session can be active at any time and should only log into the Oracle Service Bus Administration Console through one browser.
To compare a resource modified in a given session against the resource that is already deployed to run time, you can temporarily exit the session, view the deployed resource, then reenter the session and view the changed resource. All resources are visible in the session. The view of all resources in a session is called the session view—it is a merged view of the unmodified deployed resources and the resources modified in the current session. Therefore, the session view at any point in time shows the configuration state if the session is activated at that point in time. The view of resources outside any session is the view of the deployed resources.
All individual session modifications, individual session activations, and undo operations for a session are performed in transactions to prevent data loss in the event of a failure. Sessions are persistent and long running—the restart of a server does not result in the loss of active sessions. This means that you can modify the configuration in a single session over a period of days (during which time the server can be stopped and restarted) if necessary. Each user has their own session, and can work in it independently without the need to lock other users out of the system.
You cannot activate a session if another user is already in the process of activating their session. If another user is activating a session when you try to activate your session, the Activate button will be disabled and you will have to wait until the other session is activated before you can activate your session. In certain circumstances, the Activate button may not be disabled if you did not refresh the page or if you are directly using MBeans. In this case, you will time out after a short while.
Administrators have permissions to access other user's sessions and view ongoing changes, make updates in those sessions, or discard them.
For more information, see "Using the Change Center" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Sessions use an optimistic scheme for conflicts. When you activate a session, the changes you made to resources in that session become visible immediately in other sessions. If you deploy a changed resource that is open in another user's active session, the other user's session receives a message in the Change Center indicating that the deployed resource has changed in the run time since the user started modifications. The user of the active session can then:
Discard the changes to the resource in the current session. That is, refresh the resource in the session with the newly deployed resource.
Activate the current session, which results in the resource in the run time being overwritten with the current session's changes. This is the default behavior.
For more information, see "Using the Change Center" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
The system keeps a log of all users who activated a session along with any resource modified by the session and when it was modified. This provides the enterprise with auditing and tracking facilities in addition to a history of changes made to a particular resource or project. The log is visible in the Change Center in the Oracle Service Bus Administration Console.
A crucial part of managing a large number of resources is establishing and exploring dependencies between resources. For example, it is useful to identify the WSDL that a service implements, or the XQueries used by a message flow configuration. Oracle Service Bus provides this capability by automatically tracking the references between resources and creating a graph of the dependencies. In both session views and deployed views, the Oracle Service Bus Administration Console displays for a given resource:
The resources that it references
The resources that it is referenced by
Also, for each project and folder, the Oracle Service Bus Administration Console displays other resources outside the project or folder that reference resources in the selected project or folder. The Oracle Service Bus Administration Console also displays the resources that a given project or folder references. This aids dependency tracking—you can easily navigate the dependency graph in the Oracle Service Bus Administration Console by clicking on the names of the referenced resources.
You can use this functionality to identify the dependencies between departmental projects or between departmental projects and corporate-wide shared projects in the resource cache.
Dependencies are preserved when resources are renamed and moved. All references to a renamed or moved resource are automatically adjusted.
Oracle Service Bus protects the integrity of all resources in the session view. You can view a list of all current validation errors for all resources in the session view by clicking the View Conflicts link in the Change Center. Changes to a referenced resource can cause validation errors in any resources that reference it.
Oracle Service Bus allows you to create resources with most semantic errors. However, all such errors must be fixed before a session can be committed.
There are certain classes of validation errors that are never allowed. If you attempt to update a resource that has one of these disallowed validation errors, your update will fail. For example, where your configuration requires an XQuery, you cannot enter arbitrary text in place of the XQuery. If you try to do this, your update fails. The XQuery and XPath editors in the Oracle Service Bus Administration Console provide a facility to validate your expressions. Click Validate to validate your XQuery and XPath expressions at design time. This reduces the possibility of run-time errors as a result of invalid configurations.
You can undo tasks that you have performed in your Oracle Service Bus configuration during your current session, and you can undo session activations outside of a session.
If you are working in a session, you can view a list of the modifications you have made in the session by accessing View Changes in the Change Center. You can undo specific tasks in the Change Center. An undo operation can result in objects becoming semantically invalid. For example, if a WSDL operation name change is undone, the proxy service routing to that operation on the service that uses that WSDL is semantically invalid. These validation errors are displayed immediately in the Change Center when you click the View Conflicts link.
Although you can undo tasks in any order (provided that individual undo operations result in valid data), the resulting configuration may be different depending on the order of undo. The undo operation sets the value of the resource to the value it had before the change to that resource. If the task being undone was one that created an object, there is no previous state to which an object can be returned—in other words, no object existed before this task was performed. Effectively, the undo operation deletes the new object from the session. In this case, errors occur for the objects that reference the one being deleted. You can view such errors on the View Conflicts page in the Change Center.
When you are not working in a session, you can view a list of session activations by accessing View Changes in the Change Center. You can undo a session activation in the Change Center. When you undo a session, the session activation is undone and all the operations performed in the session are lost. The system does not allow you to undo a session activation if an error in the run time configuration would result from the undo operation.
For example, if you attempt to undo a deployment that removes an object that is being referenced by another object, that undo operation is disallowed. For more information, see "Undoing Tasks" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
This section describes Oracle Service Bus service discovery features through Universal Description, Discovery and Integration (UDDI).
UDDI registries are used in an enterprise to share Web services. Using UDDI services helps companies organize and catalog these Web services for sharing and reuse in the enterprise or with trusted external partners.
A UDDI registry service for Web services is defined by the UDDI specification available at
UDDI registries are based on this specification, which provides details on how to publish and locate information about Web services using UDDI. The specification does not define run-time aspects of the services (it is only a directory of the services). UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose.
Publishing a service to a registry requires knowledge of the service type and the data structure representing that service in the registry. A registry entry has certain properties associated with it and these property types are defined when the registry is created. You can publish your service to a registry and make it available for other organizations to discover and use.
Proxy services developed in Oracle Service Bus can be published to a UDDI registry. Oracle Service Bus can interact with any UDDI 3.0 compliant registry including Oracle Service Registry.
UDDI offers several benefits to IT managers at both design time and run time, including increasing code reuse. UDDI also provides benefits to developers, including the following:
UDDI improves infrastructure management by publishing information about proxy services to the registry and categorizes the services for discovery. Thus growing a portfolio of services making it easier to understand and manage relationships among services, component versioning, and dependencies.
UDDI services can be imported from a registry to configure the parameters required to invoke the Web service and the necessary transport and security protocols.
UDDI promotes the use of standards-based Web services and business services development in business applications and provides a link to a library of resources for Web services developers. This decreasing the development life cycle and improves productivity. It also increases the prospect of interoperability between business applications by sharing standards-based resources.
UDDI provides a user friendly interface for searching and discovering Web services. You can search on criteria specified by you.
Oracle Service Registry
Oracle Service Registry is a version 3 compliant UDDI registry certified to work with Oracle Service Bus. It is not provided with Oracle Service Bus.
For information about Oracle Service Registry, see the Oracle Service Registry product documentation.
The Oracle Service Bus Administration Console makes the Oracle Service Registry or any version 3 UDDI-compliant registry accessible and easy to use. In working with UDDI, Oracle Service Bus promotes the re-use of standards based Web services. In this way, Oracle Service Bus resources can be searched for and discovered and used by a wide and distributed audience. Web services and UDDI are all built on a set of standards, so re-use promotes the use of acceptable, tested Web services and application development standards across the enterprise. The Web services and interfaces can be catalogued by type, function, or classification so that they can be discovered and managed more easily.
Permissions in Oracle Service Registry were developed so that administrators can manage users' permissions in Oracle Service Registry and create views into the registry, specific to the needs of the different user types. User permissions set in Oracle Service Bus govern access to the registries, their content, and the functionality available to you.
You can use the Oracle Service Bus Administration Console to publish proxy services to Oracle Service Registry. You can publish all proxy services to a UDDI registry—this includes the following service types: WSDL, Messaging, Any SOAP, and Any XML. For information on how to publish proxy services to a UDDI registry, see "Publishing Proxy Services to a UDDI Registry" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
You can import services from the registry as Oracle Service Bus business services. The service types supported are WSDL services with SOAP over HTTP binding and Oracle Service Bus proxy services (used primarily in multi-domain deployments). For information on how to import business services to Oracle Service Bus, see "Importing Business Services from a UDDI Registry" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Service definitions in Oracle Service Bus can be automatically synchronized (both ways) with those in UDDI. Services can be automatically published to a UDDI registry after they are created or changed within Oracle Service Bus and business service definitions can be imported from UDDI and automatically updated when the original service is changed in UDDI. Alternatively, you can configure the Oracle Service Bus Administration Console to prompt you for approval for synchronization when a service changes in the UDDI registry. For more information, see "Configuring UDDI Registries" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
"UDDI" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus
Technical Notes can be found at the following URL:
http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm. Specifically, see Using WSDL in a UDDI Registry.
UDDI product and development tool information is available on the OASIS UDDI Solutions page at
The UDDI specifications, which are available at
These specifications define:
SOAP APIs that applications use to query and to publish information to a UDDI registry
XML Schema schemas of the registry data model and the SOAP message formats
WSDL definitions of the SOAP APIs
UDDI registry definitions (tModels) of various identifier and category systems that can be used to identify and categorize UDDI registrations
Technical notes and best practice documents that help you deploy and use UDDI registries effectively are available on the OASIS UDDI Web site at