Explore topic-wise InterviewSolutions in .

EJBs can be invoked as Web SERVICES by first registering a Business SERVICE with EJB transport and then getting the WSDL from the Business Service.

EJBs can be invoked as Web Services by first registering a Business Service with EJB transport and then getting the WSDL from the Business Service.

YES, by USING the BEA XQUERY METHOD execute-sql

Yes, by using the BEA XQuery method execute-sql

Invoke the BUSINESS SERVICES and xquery (for DB) REPRESENTING the DIFFERENT EIS in the REQUEST pipeline.

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

Use an XA JMS CONNECTION FACTORY in the jms URL.

Use an XA JMS Connection factory in the jms url.

They are the CONTAINERS for actions. A STAGE is the SMALLEST GROUP to have its error handling

They are the containers for actions. A stage is the smallest group to have its error handling

USE the SKIP ACTION.

Use the Skip action.

By USING the REPLY ACTION.

By using the Reply action.

For, LET, Order By, Where and Return are keywords for WRITING XQUERY Expressions. FLWOR stands for these key WORDS .

For, Let, Order By, Where and Return are keywords for writing XQuery Expressions. FLWOR stands for these key words .

By using the local-name() Xpath function 

EXAMPLE:

For the Xml node REQUEST XMLNS:ns0=blah blah>ABC local-name function will RETURN Request.

By using the local-name() Xpath function 

example:

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

It will RESULT into XML ELEMENT ABC.

It will result into xml element abc.

By doing DATA VALIDATION before INVOKING the CORE XQUERY functions/constructs.

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

By USING the CONCAT XQUERY FUNCTION

By using the concat xquery function

By USING the normalize-space XQUERY FUNCTION

By using the normalize-space xquery function

By USING the for EXPRESSION.

By using the for expression.

By USING the TRUE() FUNCTION.

By using the true() function.

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. Transformations may be applied to the response message going to one or more of these destinations depending on business-service requirements.

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. Transformations may be applied to the response message going to one or more of these destinations depending on business-service requirements.

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 transformation capabilities. This routing capability allows loose coupling of SOA endpoints and is particularly useful and allows service enrichment and reuse by combining transformation and routing FUNCTIONS.

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 transformation capabilities. This routing capability allows loose coupling of SOA endpoints and is particularly useful and allows service enrichment and reuse by combining transformation and routing functions.

An error handler is a pipeline that allows various actions such as logging, transformation, 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 transfers 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; transformation errors occur if Oracle Service BUS is unable to successfully transform 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.

An error handler is a pipeline that allows various actions such as logging, transformation, 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:

Errors can occur during message flow processing for various reasons. For example, security errors occur if a username is not correctly validated or authorized; transformation errors occur if Oracle Service Bus is unable to successfully transform 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.

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 transformation must be applied PRIOR to sending the message.

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 transformation must be applied prior to sending the message.

Oracle Service Bus provides robust and flexible ERROR handling for configured SERVICES. It can handle ERRORS in the following ways:

• Testing WHETHER an assertion is true and sending a reply with failure in the request or response pipeline.
• Configuring the service to catch and handle the error at multiple levels including the stage, route node, pipeline, or service levels. The level configured to catch the error depends on the service behavior desired.
• Letting the DEFAULT system error handler handle the error.

Oracle Service Bus provides robust and flexible error handling for configured services. It can handle errors in the following ways:

Message MANIPULATION is a KIND of transformation 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 TRANSFORM 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.

Message manipulation is a kind of transformation 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 transform a message through content manipulation are as follows:

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.

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.

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.

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:

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.

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 transformations. It allows if structures and case structures to be combined (and nested) to define a single endpoint and operation to route the message.

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 transformations. It allows if structures and case structures to be combined (and nested) to define a single endpoint and operation to route the message.

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

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

A pipeline is a named sequence of STAGES, representing a non-branching one-way processing PATH. It is USED to specify the message flow for service requests and responses.

Pipelines FALL into one of the following three CATEGORIES:

• Request Pipelines: used for processing the request path of the message flow
• Response Pipelines: used for processing the response path of the message flow
• Error Pipelines: used as error handlers

A pipeline is a named sequence of stages, representing a non-branching one-way processing path. It is used to specify the message flow for service requests and responses.

Pipelines fall into one of the following three categories:

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.

UDDI also provides benefits to developers, including the following:

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.

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.

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 transport-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 transformations on the data based on the message content. Oracle Service Bus currently supports WSS over HTTP/S and JMS.

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 transport-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 transformations on the data based on the message content. Oracle Service Bus currently supports WSS over HTTP/S and JMS.

Oracle Service Bus supports transport-level CONFIDENTIALITY, message integrity, and client authentication for one-way requests or request/response TRANSACTIONS (from clients to Oracle Service Bus) over HTTPS. It allows HTTP(S) PROXY services or business services to be configured to require one of the FOLLOWING types of client authentication:

• BASIC (username/password) client authentication
• CLIENT CERT (two-way SSL) client authentication
• No client authentication

When a proxy service is activated, Oracle Service Bus generates and deploys a thin Web application. Oracle Service Bus relies on Oracle WebLogic Server for server-side SSL support, including session management, client certificate validation and authentication, trust management and server SSL key/certificate manipulation. 

Transport security for transports other than HTTP is supported in Oracle Service Bus as follows: 

• For the E-mail and FTP transports, security is provided using credentials to connect to a FTP or E-mail server.
• For the file transport, security is provided using a LOGIN control to the machine on which the files are located.

Oracle Service Bus supports transport-level confidentiality, message integrity, and client authentication for one-way requests or request/response transactions (from clients to Oracle Service Bus) over HTTPS. It allows HTTP(S) proxy services or business services to be configured to require one of the following types of client authentication:

When a proxy service is activated, Oracle Service Bus generates and deploys a thin Web application. Oracle Service Bus relies on Oracle WebLogic Server for server-side SSL support, including session management, client certificate validation and authentication, trust management and server SSL key/certificate manipulation. 

Transport security for transports other than HTTP is supported in Oracle Service Bus as follows: 

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

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:

OUTBOUND security secures COMMUNICATION between a proxy service and a business service. Most of the tasks involve configuring proxy services to comply with the transport-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.

Outbound security secures communication between a proxy service and a business service. Most of the tasks involve configuring proxy services to comply with the transport-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.

 Transport-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 transport-level security depend on the protocol that you configure the proxy service to use. For information about configuring transport-level security for each supported protocol, see Configuring Transport-Level Security.

• CUSTOM Authentication: for message-level security and client-specified custom authentication credentials for inbound transport- 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.

 Transport-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 transport-level security depend on the protocol that you configure the proxy service to use. For information about configuring transport-level security for each supported protocol, see Configuring Transport-Level Security.

Oracle Service BUS PROVIDES the following types of security features:

• Authentication 
• Identity assertion
• Authorization
• Auditing
• CREDENTIAL mapping

Oracle Service Bus provides the following types of security features:

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.

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:

 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.

 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.

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.

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:

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.

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, transport 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 transformation 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

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, transport 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 transformation 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:

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)

Oracle Service Bus supports the following message formats:

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

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

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: 

Transformation 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 Transformation (XSLT) standard. In addition, MFL DESCRIBED data is automatically converted to the equivalent XML for transformation with XQuery or XSLT. The resulting XML is automatically converted to MFL if the target service REQUIRES it.

Transformation 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 Transformation (XSLT) standard. In addition, MFL described data is automatically converted to the equivalent XML for transformation with XQuery or XSLT. The resulting XML is automatically converted to MFL if the target service requires it.

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.

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.

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 transport 

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.

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

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.

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

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.

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.

• DEVELOPMENT-only REGISTRY
• Production-only registry
• Development and production time registry
• Registry PER INDIVIDUAL DOMAIN

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

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.

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.

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.

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.

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.

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.