Top 50 Oracle Service Bus Interview Questions You Must Prepare 19.Mar.2024

Oracle Service Bus provides intelligent message brokering between business services (such as enterprise services and databases) and service clients (such as presentation applications or other business services) through proxy services that you can configure using Oracle Service Bus development and run-time tooling. Proxy services are Oracle Service Bus definitions of intermediary Web services that Oracle Service Bus implements locally on Oracle WebLogic Server. With Oracle Service Bus message brokering, service clients exchange messages with an intermediary proxy service rather than working directly with a business service.

Oracle Service Bus lets you implement proxy services independently and configure them dynamically, as driven by your business needs, without requiring costly infrastructure development and re-deployment efforts. The configuration functions are separated from the management functions in Oracle Service Bus.

A proxy service can route messages to multiple business services; you can choose to configure a proxy service with an interface that is independent of the business services with which the proxy service communicates. In such cases, you can configure a proxy service message flow definition to route a message to the appropriate business service and map the message data into the format required by the business service interface.

Business services are Oracle Service Bus definitions of the enterprise services that exchange messages during business processes. A business service and its interface can be defined and configured using the Oracle Service Bus design-time tooling. To configure a business service, you must specify its interface, the type of trport it uses, its security requirements, and other characteristics.

A business service definition is similar to that of a proxy service, but it does not have pipelines (a message flow).

Oracle Service Bus performs dynamic message routing based on a message content, for cases when services or responses need to be directed to multiple destination service and in scenarios where different versions of a service have to be provisioned based upon business service requests. Dynamic routing is useful when business requirements dictate that certain conditions of a request define where it should be processed. For example, a financial institutions request for a credit report on a customer may use any of several credit services based on where the customer or organization resides.

In dynamic routing, a message is analyzed using conditional checks in conditional branching statements, to retrieve the value of a data element or multiple data elements that determine the routing logic. Different business service destinations are assigned to different value combinations resulting from this conditional check. The message is dynamically routed to one of multiple destination business services based on the data element value. Trformations may be applied to the response message going to one or more of these destinations depending on business-service requirements.

  • Avoid project renames. If projects need to be renamed, do so concurrently across development, QA, stage and production systems before the next deployment.
  • Operations on environment specific resources are best filtered out at import time. Administrators may define these resources (referenced in the import file) in the target system before starting the import process. Alternatively, new environment-specific resources may be deployed and customized for the environment after the import.
  • Operational resources controlled by the operator should not be impacted by the import. A naming convention or a dedicated folder could be used to identify such resources during import.
  • When the customization file contains the customizations of all project resources in a single file, apply customizations only to resources that are imported. An alternative is to preserve environment values on import and only apply customizations to resources that are added during import.
  • At export-time, the exporter needs to know if resources have been deleted, renamed, or moved; and if there have been project reorganizations of artifacts since the last export. If yes, complete deployment should be done. If no, the exporter can select only those resources that need to be exported and an incremental deployment can be done.

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.

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.

 JCA Binding resources in Oracle Service Bus let you create business and proxy services that interact with external services through Oracle SOA Suite JCA adapters. A JCA Binding is made up of a service WSDL and a corresponding .jca file created in Oracle JDeveloper.

SMTP Server resources specify the address of SMTP servers corresponding to E-mail destinations, port numbers, and, if required, authentication credentials. They are global resources that are used in Alert Destination resources across projects in an Oracle Service Bus domain.

WSS defines a framework for message confidentiality, integrity, and sender authentication for SOAP messages. Using WSS, Oracle Service Bus provides support for securing messages using digital signatures, encryption, or both. Though it is not a substitute for trport-level security, WSS is ideal for end-to-end message confidentiality and integrity.

It is more flexible than SSL since individual parts of the SOAP envelope can be signed, encrypted or both, while other parts are neither signed nor encrypted. This is a powerful feature when combined with the ability of Oracle Service Bus to make routing decisions and perform trformations on the data based on the message content. Oracle Service Bus currently supports WSS over HTTP/S and JMS.

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

Open a browser window and enter the following URL to open the Oracle Service Bus Console for the ServiceBusTutorial domain: http://localhost:7001/sbconsole

Log in if necessary with Oracle Service Bus Console the user name and password that you specified when you created the domain.

Pipeline pairs are request and response pipelines. The request pipeline definition specifies the actions that Oracle Service Bus performs on request messages to the proxy service before invoking a business service or another proxy service. The response pipeline definition specifies the processing that Oracle Service Bus performs on responses from the business or proxy service that the proxy service invokes before returning a response to a client.

Each pipeline consists of a sequence of stages, each stage containing actions. However, a single service-level request pipeline might optionally branch out into operational pipelines (you can configure one default operational pipeline at most one per operation). The determination of the operation is done through user-selected criteria. The response processing starts with the relevant operation pipeline which then joins into a single service-level response pipeline.

A branch node allows processing to proceed down exactly one of several possible paths. Branching is driven by a simple lookup table with each branch tagged with a simple but unique string value. A variable in the message context is designated as the lookup variable for that node, and its value is used to determine which branch to follow. If no branch matches the value of the lookup variable, then a default branch is followed. The value of the lookup variable must be set before reaching the branch node. This approach ensures that exceptions do not occur within the branch node itself. A branch node may have several descendants in the message flow tree: one for each branch including the default branch.

The route node is used to perform request and response communication with another service. It represents the boundary between request and response processing for the proxy service, and therefore, cannot have any descendants in the message flow tree. When the route node dispatches a request message, request processing is considered finished. When the route node receives a response message, response processing begins.

The route node is very flexible in its specification and supports conditional routing as well as outbound and response trformations. It allows if structures and case structures to be combined (and nested) to define a single endpoint and operation to route the message.

 Trport-level security: applies security checks as part of establishing a connection between a client and a proxy service. The security requirements that you can impose through trport-level security depend on the protocol that you configure the proxy service to use. For information about configuring trport-level security for each supported protocol, see Configuring Trport-Level Security.

  • Custom Authentication: for message-level security and client-specified custom authentication credentials for inbound trport- and message-level requests. The custom authentication credentials can be in the form of a custom token, or a username and password.
  • Message-level security: for proxy services that are Web Services. This is part of the WS-Security specification. It applies security checks before processing a SOAP message or specific parts of a SOAP message.

Oracle Service Bus Console is a Web services management dashboard that allows you to monitor Web services and servers and perform service management tasks. The console enables you to perform operational tasks such as configuring proxy and business services, setting up security, managing resources, and capturing data for tracking or regulatory auditing. It provides views to monitor current state and health of the Oracle Service Bus environment by displaying detailed statistics about servers, services, and alerts. The Oracle Service Bus Console also enables you respond rapidly and effectively to changes in your service-oriented environment.

Oracle Service Bus provides the following types of security features:

  • Authentication 
  • Identity assertion
  • Authorization
  • Auditing
  • Credential mapping

In Oracle Service Bus, a message flow is the implementation of a proxy service. You configure the logic for the manipulation of messages using proxy service message flow definitions. This logic includes such activities as trformation, publishing, and reporting, which are implemented as individual actions within the stages of a pipeline.

Pipelines are one-way processing paths that include no branching. A pipeline is a named sequence of stages containing actions, representing a non-branching one-way processing path. It is used to specify the message flow for service requests and responses. A stage is a user-configured processing step. Messages fed into the pipelines are accompanied by a set of message context variables that contain the message contents. They can be accessed or modified by actions in the pipeline stages.

To support interoperability with heterogeneous end points, Oracle Service Bus lets service configurations control the content type, JMS type, and encoding used. It does not make assumptions about what the external client or service needs, but instead uses the service-definition information that has been configured for this purpose. Oracle Service Bus derives the content type for outbound messages from the service type and interface and uses the following specifications:

  • XML or SOAP (with or without a WSDL), the content type is text/XML
  • Messaging and the interface is MFL or binary, the content type is binary/octet-stream
  • Messaging and the interface is text, the content type is text/plain
  • Messaging and the interface is XML, the content type is text/XML.

The content type can be overridden in the outbound context variable ($outbound) for proxy services invoking a service, and in the inbound context variable ($inbound) for a proxy service response. Additionally, there is a JMS type (byte or text) which can be configured when the service is defined in the Administration Console. Encoding is also explicitly configured in the service definition for all outbound messages.

  • Development-only registry
  • Production-only registry
  • Development and production time registry
  • Registry per individual domain

Oracle Service Bus provides the capability for incoming or outgoing messages to be validated against a WSDL or XML schema with a validation action. This action can occur at any time within the message flow and ensures that the incoming or outgoing message is in the format expected by the destination services consumer or provider. Messages that fail validation can log the failure or create an error. In the latter case, an error stage can be used to apply alternative actions.

Message validation can be used for service versioning to validate messages against different versions of a schema or WSDL. This is to ensure the message is routed to the proper version of the service end point, or to check whether trformation must be applied prior to sending the message.

A security role is an identity that can be dynamically conferred upon a user or group based on conditions that are evaluated at runtime.

The following is a list of default roles to which Oracle Service Bus users can be assigned:

  • IntegrationAdmin
  • IntegrationDeployer
  • IntegrationMonitor
  • IntegrationOperator

Oracle Service Bus provides the following examples:

Routing a Loan Application : A primary mortgage company uses Oracle Service Bus to route loan applications to appropriate business services based on the interest rate requested by the customer. An application containing a request for a rate less than 5% requires management approval and is routed to an appropriate business service for processing.

All other loan applications are routed to another business service for processing. The target business service responds, indicating whether the loan application is approved or rejected.

Trforming a Loan Application : A primary mortgage company uses Oracle Service Bus to identify and re-route loan applications that are easy to sell to secondary mortgage companies. A loan application with a principal request of $25,000,000.00 can be sold to a secondary mortgage company. For such a loan application, a Web service lookup is performed to retrieve the customer's credit rating. The credit rating information is added to the loan application and the application is then forwarded to the secondary mortgage company's Web service to be processed. All other loan applications are routed to another business service for processing. The target business service responds indicating whether the loan application is approved or rejected.

Validating a Loan Application : A primary mortgage company uses Oracle Service Bus to route loan applications to appropriate business services and to validate the loan applications. When an application is invalid (due to missing or incorrect data), an error message is returned to the client and the error is reported in the Oracle Service Bus Console.

A complete application is routed to a selected business service for review. If approved, the business service returns a message indicating whether the loan is accepted or rejected.

  •  Organize business services associated with a particular UDDI registry in a specific folder to make it easy to identify these resources during import.
  • Use the same UDDI server resource name in all systems using that UDDI registry. When there is a separate development and production UDDI registry, use the same resource name for the development and production instances of the UDDI registry. This ensures that references to the server by services are automatically resolved during import.
  • The same service in development and production may not have the same keys when two registries are used. However, the recommended approach is to preserve the same keys.
  • Create a new UDDI service with the new shape when the shape of a business service changes.

Customization files are XML files and you can open these files in any editor and substitute the required environment values. In addition, you can search for specific environment values (that are not complex XML types) in Oracle Service Bus Console or in a customization file and replace them with the new values. You can fine-tune the scope of the search by filtering these environment values based on variable type or project.

An Administrator uses customization files to make changes to environment values as well as to change references within resources. Customization files can include customizations for all the environment values found in the selected resources, including complex environment values types defined inside the EnvValueTypes class. In addition, it includes a reference customization type for changing resource references inside resources with dependencies.

The customization schema (Customization.xsd) which describes the customization types is available at the following location in your Oracle Service Bus installation:

BEA_HOME modulescom.bea.common.configfwk_1.2.0.0.jar

You can create sample customization files from Oracle Service Bus Console. The scope of a customization file can be a project or individual resources in a project.

The created sample customization file may be used as a starting point for making desired modifications by specifying the actual values for an environment during the export or import process.

Oracle Service Bus allows you to manage Web services and deliver authentic message brokering through the configuration of proxy services in the Oracle Service Bus design-time environment. The underlying concepts of Oracle Service Bus are briefly described in this section. Oracle Service Bus manages the routing and trformation of messages in an enterprise system to promote seamless application integration.

Oracle Service Bus is a market-leading enterprise service bus built from the ground up for Service Oriented Architecture (SOA) life cycle management. It provides foundation capabilities for service discovery and intermediation, rapid service provisioning and deployment, and governance. This service-infrastructure software adheres to the SOA principles of building coarse-grained, loosely coupled, and standards-based services, creating a neutral container in which business functions may connect service consumers and back-end business services, regardless of underlying infrastructure.

You can start Oracle Service Bus using one of the following methods: On Windows systems, from the Windows Start menu in the Oracle WebLogic > User Projects group, or running startWebLogic.cmd in the new domain.

On UNIX systems, run startWebLogic.sh from the root of the new domain.

To create the request and response paths, request and response pipelines are paired together and organized into a single-rooted tree structure. A branch node allows these pipeline pairs to be executed conditionally, and route nodes at the ends of the branches perform the request and response dispatching. A pipeline tree chains together instance of the following top-level components:

  • pipeline pair node
  • branch node
  • route node or echo node.

A pipeline pair node ties together a single request and a single response pipeline into one top-level element. Only the request pipeline is executed during request processing, and only the response pipeline is executed when reversing the path for response processing.

Development-Only Registry : The simplest deployment of UDDI is having a single development (design) time registry where the resources are both published and discovered. This registry is used for governance using approval control. However, you can also have separate design time publish registry and discovery registry. After the design time publish registry is approved, it can be promoted to the discovery registry.

Production-Only Registry : In this production time registry topology, a single production UDDI registry contains all the production business services and proxy services, and their locations (URL). The production registry can be used to discover all production services. However, you can also have separate production time publish registry and discovery registry. After the production time publish registry is approved, it can be promoted to the production discovery registry.

Typically, proxy services are automatically published to the publish registry. If the approval step in UDDI results in a reject of the service, the UDDI approver manually notifies the developer and the developer has to make the appropriate changes and re-export the services through the stage and production systems.

Development and Production Registry : An alternative approach is to have a separate development and production UDDI registry. In this topology, the approval step can take place in the development registry. So, the extra development UDDI registry ensures that approvals are done earlier in the cycle.

Registry per Individual Domain : Sometimes, the proxy service does a dynamic search of the UDDI registry with a POJO callout to select the service meeting the desired search criteria and retrieve the URL for dynamic routing. In this scenario, a dummy service is defined in Oracle Service Bus with a dummy URL and the URL is dynamically replaced with the actual value after the lookup. In this scenario, a UDDI registry is needed for each environment. Also, the dummy business service in Oracle Service Bus is not linked to any UDDI service.

There is an impact on performance and availability in this scenario. So, the preferred approach is to enable automatic synchronization of a business service into Oracle Service Bus with a routing table XQuery resource that can be used for dynamic routing.

By using the local-name() Xpath function 

example:

For the Xml node Request xmlns:ns0=blah blah>abc local-name function will return Request.

As part of deployment, environment values in resources in source systems must be changed as part of the export process or the import process to reflect the values that are application in the target system.

Environment values are certain pre-defined fields in the configuration data whose values are very likely to change when you move your configuration from one domain to another (for example, from test to production). Environment values represent entities such as URLs, URIs, file and directory names, server names, e-mails, and such. Also, environment values can be found in Alert Destinations, proxy services, business services, SMTP Server and JNDI Provider resources, and UDDI Registry entries.

Certain environment values are complex XML objects that cannot be found and replaced using the Find and Replace option from Oracle Service Bus Console. However, you can still set these environment values directly by using the ALSBConfigurationMBean from a script. For detailed information about ALSBConfigurationMBean, see the Javadocs for Oracle Service Bus Classes. In addition to setting them through the API, you can set complex type environment values using customization files.

Oracle Service Bus mediates service request and response messages between disparate heterogeneous service endpoints and intelligently routes messages between them. Content-based routing is a mediation capability supported by Oracle Service Bus based on conditional message processing and trformation capabilities. This routing capability allows loose coupling of SOA endpoints and is particularly useful and allows service enrichment and reuse by combining trformation and routing functions.

Outbound security secures communication between a proxy service and a business service. Most of the tasks involve configuring proxy services to comply with the trport-level or message-level security requirements that business services specify. If a business service requires the use of PKI technology for digital signatures, or SSL authentication, a service key provider is created, which provides private keys paired with certificates.

An error handler is a pipeline that allows various actions such as logging, trformation, and publishing to be performed to handle errors appropriately. If an error occurs within a stage a sequence of steps are executed. This sequence of steps constitutes an error pipeline for that stage.

The error pipeline allows you to handle the error in the following ways:

  • Publish the original message to an alternate endpoint
  • Formulate an error response message to be returned to the invoker of the proxy service
  • Log the message
  • Continue processing the message through the pipeline after modifying the context
  • Raise an exception. Raising an exception trfers control to the next higher scoped error pipeline.

Errors can occur during message flow processing for various reasons. For example, security errors occur if a username is not correctly validated or authorized; trformation errors occur if Oracle Service Bus is unable to successfully trform or validate a message; a routing error is raised if a routing service is unavailable, and so on. Typically, these errors originate from a specific stage, route node or from the proxy service, as this is where most of the message flow logic is implemented.

Each stage can have a sequence of steps to execute if an error occurs in that stage. This sequence of steps constitute an error pipeline for that stage. In addition, an error pipeline can be defined for a pipeline (request or response) or for an entire proxy service. The lowest scoped error pipeline that exists is invoked on an error.

Invoke the Business Services and xquery (for DB) representing the different EIS in the request pipeline.

Oracle Service Bus accommodates multiple messaging paradigms and supports the following types of communication:

  • Synchronous request/response
  • Asynchronous publish one-one
  • Asynchronous publish one-many
  • Asynchronous request/response (synchronous-to-asynchronous bridging).

In sync-async bridging, a synchronous client issues a request to an asynchronous provider. For this pattern, Oracle Service Bus provides the capability to publish a message on one JMS queue and configure a second JMS queue for the response, with a timeout value for listening for the response. This type of service appears as a synchronous service to the service consumer. Using asynchronous request/response messages has these advantages: 

  • No blocking by the request thread, removing thread management issues that can occur when numerous blocking request/response invocations are made.
  • More reliable messaging

Web Services Policy (WS-Policy) is a standards-based framework for defining a Web services security constraints and requirements. It expresses security constraints and requirements in a collection of XML statements called policies, each of which contains one or more assertions. In Oracle Service Bus, WS-Policy assertions are used to specify a Web services requirements for digital signatures and encryption, along with the security algorithms and authentication mechanisms that it requires.

WS-Policy policies may be included directly in a WSDL document or included by reference, and a WSDL document may import other WSDL documents that contain or refer to WS-Policy policies. An XML file that contains these policies can be used by multiple proxy services or business services.

The WebLogic Web Services runtime environment recognizes two types of WS-Policy statements:

  •  Concrete WS-Policy statements: specify the security tokens that are used for authentication, encryption, and digital signatures. These WS-Policy statements are created if the type of authentication required (such as using X.509 or SAML tokens), multiple private key and certificate pairs from the keystore used for encryption and digital signatures, are known at run-time.
  •  Abstract WS-Policy statements: that do not specify security tokens.

A JAR (Java ARchive) is a zipped file that contains a set of Java classes. It is used to store compiled Java classes and associated metadata that can constitute a program. A JAR acts like a callable program library for Java code elements (so that a single compilation link provides access to multiple elements, rather than requiring bindings for each element individually).

JAR files can be registered as reusable Oracle Service Bus resources. They are used in Java callout actions that provide a Java exit mechanism, EJB-based business services, and Tuxedo-based business services.

Message manipulation is a kind of trformation in which the contents of a message, rather than its whole structure, are manipulated to make the message compatible with the destination service. This is performed by adding, replacing or removing actions to the request or response pipelines of the message flow. The different actions available to trform a message through content manipulation are as follows:

  • Insert : Inserts a data element into the message. This insertion may occur anywhere within the message context as specified during configuration.
  • Delete : Deletes a data element in the message. This is used when the target destination does not expect a specific data element in the message.
  • Replace : Replaces a series of text within the message with a different series. This can be used, for example, to replace the namespace of a message.

The typical unit of deployment is called a project. There are two types of project deployment: 

  • Complete - The entire project is deployed
  • Incremental - Only changes to the project since the last deployment or some explicitly selected subset of resources are deployed.

Incremental deployment is additive  only new and updated resources are deployed on the target system. Note that any resource that is deleted in the project is not deleted from the target system. However, deleted project resources are also deleted from the target system during a complete project deployment.

Note: This behavior may be customized at import time. For example, alert destinations are defined in the production system by the production system operator, but these alerts do not exist in the development system. In such a scenario, you may not want to delete these alert destinations when you do a complete deployment of the project.

All messages sent to and received by the proxy service are defined internally in the proxy service by a set of properties that holds the message data and meta-data related to that message. This set of properties is known as the Message Context (context) and is implemented using Context Variables. It is defined by an XML schema. Each Context Variable relates to a different property. Some Context Variables are predefined and others are user defined. The heart of the proxy service is the Message context. For a complete description of the Message Context and context variables used in the message flow.

Predefined context variables contain information about the message, trport headers, security principals, metadata for the current proxy service, and metadata for the primary routing and publish services invoked by the proxy service. You typically use an XQuery expression to manipulate context variables in a message flow. You can also modify context variables using trformation and in-place update actions.

The message-related context variables $header, $body, and $attachments represent the canonical format of the message in the message flow. These are wrapper variables that contain the SOAP header elements, the SOAP body element, and the MIME attachments, respectively. The context gives the impression that all messages are SOAP messages, and non-SOAP messages are mapped to this paradigm.

In the case of attachments, $attachments contains the following for each attachment:

  • attachment, if the attachment is XML
  • a reference XML, if the attachment is binary
  • text, if the attachment is text

Oracle Service Bus provides a service callout action that offers greater flexibility for more sophisticated message flows. Service Callouts are message processing request actions from one message flow, that invoke other services registered within Oracle Service Bus. This action is generally used in response to decisions made in complex dynamic-routing processing, or to perform message enrichment.

The service callout action is used inside a message flow routing stage, to call on the destination service to perform some action on the message. The destination service returns a response to the message flow, which gets assigned to a local variable. The variable may be used within the current message flow for conditional branching.

Service callouts allow custom Java code to be invoked from within proxy services. Oracle Service Bus supports a Java exit mechanism via a Java Callout action that allows call out to a Plain Old Java Object (POJO). Static methods can be accessed from any POJO. The POJO and its parameters are visible in the Oracle Service Bus Administration Console at design time; the parameters can be mapped to message context variables.

By doing data validation before invoking the core xquery functions/constructs.

Universal Description, Discovery and Integration (UDDI) registries are used in an enterprise to share Web 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 version 3.0-compliant registry.

Oracle Service Bus defines proxy services and business services in terms of two WSDL entities:

  • The abstract WSDL interface, which defines the operations in that interface and the types of message parts in the operation signature
  • The binding WSDL interface, which defines the binding of the message parts to the message (packaging), and the binding of the message to the trport 

WSDLs can be imported into the WSDL repository using the Oracle Service Bus Administration Console. The Oracle Service Bus Administration Console can also be used to resolve the references in the WSDLs, to ensure all schemas and WSDLs are linked correctly. After WSDLs are stored in the repository, they are available for use when adding proxy services and business services. Oracle Service Bus uses its own representation of the interface for messaging services.

Trformation maps describe the mapping between two disparate data types of different source and destination services. Oracle Service Bus supports data mapping using either XQuery or the eXtensible Stylesheet Language Trformation (XSLT) standard. In addition, MFL described data is automatically converted to the equivalent XML for trformation with XQuery or XSLT. The resulting XML is automatically converted to MFL if the target service requires it.

Export, import and environmental customizations may be done by a deployer, operator or Administrator depending on the system and depending on the enterprises policy.

Export from the development system is typically done by a deployer. The Administrator, operator, or deployer may be responsible for exporting and importing resources from the stage system to the production system.

Exporting and importing resources can be done using Oracle Service Bus Console or via a script or program (which can be written by a developer).

If an operator is responsible for exporting resources from a system, a pre-defined automated script or program can be executed to export either the complete project or specific resources in the project. Similarly, if an operator is responsible for importing resources into a system, a pre-defined automated script or program can be executed to do the import.

A single service level request pipeline in a stage might optionally branch out into operational pipelines (at most one per operation, and optionally a default operational pipeline). The operation is determined by user-selected criteria. The response processing starts with the relevant operation pipeline which then merges into a single service-level response pipeline. The following figure shows an example of operation pipelines in a proxy service.

For one-way operations, the response pipeline is executed with an empty message. This permits a response to be constructed for the proxy service, enabling bridging between request/response and one-way operations. The bridging mechanism me that proxy service input can be one-way while its output is request/response or vice versa. The proxy service either absorbs the response from the invoked service or generates one for the client. Actions in the response flow may also be used to do post processing on the message after it has been routed to the business service or the proxy service.

Oracle Service Bus supports the following message formats:

  • E-mail with or without attachments
  • JMS with headers
  • MFL (Message Format Language)
  • Raw Data. (Raw data is opaque non-XML data with no known schema (no MFL file)
  • Text
  • SOAP and SOAP with attachments (SOAP described or not described by a WSDL)
  • XML and XML with attachments (XML described or not described by a WSDL or a schema)