We’ll use JMS instead of HTTP to incorporate secure SOAP communication in this method. The only distinction is that both your request and response will be queued. By using JMS persistence for XA/QoS, the request cannot be lost this way. The client will ingest the answer after it has been published in the queue. Get this Oracle service bus training available online that would assist you to make your career path in Oracle Services.
We’ll use an OSB project with a proxy server built on a WSDL and synchronous request/response operation for this method. Instead of using HTTP, the SOAP message will be transmitted through JMS. To build a test client, JDeveloper will be used:
Let’s start with an overview of JMS transport before we get into this process. It also explains how to use JMA in your services and how to customize it. The blog also covers functionality and principles related to WebLogic JMS and Oracle Service Bus, and also WebSphere MQ interoperability and Oracle Service Bus.
JMS Interoperability Overview
The central Java API for developing and deploying J2EE Web services is the Java API for XML-Remote Procedure Call (JAX-RPC). JAX-RPC provides a simple and secure platform for designing Web services applications by abstracting the complexities of mapping between Java types and XML types, and also the lower-level details of handling XML SOAP messages from the client. Through having two models of programming, JAX-RPC implements a process call paradigm:
- A blueprint for building stateless EJB modules or Web services endpoints using Java classes on the server-side.
- A model for creating Java clients that communicate with Web services using local objects on the client-side.
The use of interoperability and SOAP with other Web Services developed with other technology is required by JAX-RPC. If the business logic is already performed by a Java class or a stateless session EJB then using JAX-RPC, J2EE allows you to show it as a service.
JMS transport is supported by all service forms of Oracle Service Bus which are defined in Section 2.2, “Working with Business Services.” and Section 2.3, “Working with Proxy Services” proxy services and business services must be designed to use JMS transport.
JMS for Oracle WebLogic Server details can be found at:
- Oracle Fusion Middleware Programming JMS for Oracle WebLogic Server has a section called “Managing Your Applications”.
- In the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help choose “Configure JMS Servers”
Request-Response Messaging (Asynchronous)
The below are the various types of messaging:
- Flow in one-way
- Request-response that is synchronous
- Request-response that is asynchronous
JMS messaging, on the other hand, is either one-way flow or request-response that is asynchronous. JMS-based request-response messaging that is asynchronous is another choice to HTTP or HTTPS-based messaging (S).
The below are some of the benefits of using request-response messaging that is asynchronous:
- When waiting for a response, the thread of a request is not interrupted. This eliminates management of a thread problem that can arise when a large number of restricting invocations of request-response are sent. HTTP(S) and HTTP, on the other hand, have a mode of operation that isn’t blocked.
- Since HTTP is less reliable than messaging, it can be used to:
- Persisted on the hard drive
- When a service is unavailable, a queue is created.
- The message will be re-delivered if the server finds an error or refuses to process it.
The request-response messages that are asynchronous could be the easiest way to communicate with certain mainframes if you’re using IBM WebSphere MQ. Based on the request-response pattern used by JMS you use, the asynchronous service must echo the correlation ID or the message ID. An ID format is employed by Oracle Service Bus that is relevant with IBM WebSphere MQ and is focused on MQ native interface services. See Section 30.9, “Message ID and Correlation ID Patterns for JMS Request/Response.” for more details.
The inbound and outbound transports handle asynchronous request-response messages. There is no differentiation in the flow of a message between HTTP request-response and JMS request-response, except the $outbound and $inbound transport-related data.
Asynchronous and synchronous requests and responses can be bridged by Oracle Service Bus. For instance, HTTP may be used to call a proxy server, which then connects to a business service of JMS request-response. This is known as synchronous-to-asynchronous service switching.
Transport with SOAP-JMS
Since SOAP is transport-agnostic, you should use JMS rather than HTTP for SOAP transport. Enterprise consumers, in particular, need SOAP JMS transport. JMS request-response SOAP messages are supported by Oracle Service Bus. Oracle WebLogic Server SOAP-based clients and utility interoperability is supported by Oracle Service Bus.
JMS is even a method for ensuring that messages are delivered reliably.
Oracle WebLogic Server interoperability
While configuring an Oracle WebLogic Server’s service with JMS binding, apply this SOAP-JMS URI format:
jms://host:port/contextURI/serviceName?URI=destJndiName
The URI must have the following format while you configure the Oracle Service Bus’s service:
jms://host:port/connection_factory/jndi_destination
The same “jndi_destination” is used in both formats. The JNDI name of an active QueueConnectionFactory in the target Oracle WebLogic Server must be used as the “jndi_destination”.
Before using Oracle Service Bus to send a request to Oracle WebLogic Server services, You must use the value “/contextURI/serviceName” as a JMS property for the URI within the outbound variable’s message flow ($outbound). This property is set using the Transport Headers action.
View “Inbound and Outbound Variables” in the Oracle Fusion Middleware Administrator’s Guide for Oracle Service Bus for more detail on setting $outbound.
The URI property is ignored when a Web services client of an Oracle WebLogic Server calls a proxy service of an Oracle Service Bus. It can be passed along to a called process using the Transport Headers action’s pass-through options. See Section 2.4.32, “Adding and Configuring Transport Headers Actions in Message Flows.” for further details.
Only request-response services of an Oracle WebLogic that run on version 9.2 or later can be called by Oracle Service Bus. It can, however, use JMS services that are one-way.
Cross-Domain JMS Calls Response Queues Configuration
Ensure that each Managed Server requestor has its response queue while configuring the response queue for cross-domain JMS calls.
Domains, JMS Servers, and WebLogic Naming Guidelines
If you’re dealing with several domains, make sure the setup meets the following specifications:
- The domain names and instances of the Oracle WebLogic Server are all distinct.
- The names of WebLogic JMS servers are unique across domains.
- When using a file store of a JMS for permanent messages, the name of the file store of the JMS should be different across domains.
The below are the rules for naming JMS Servers:
- In the same namespace, you can’t get two names for the JMS server. If this is the case, Oracle Service Bus will be unable to decide to which JMS server messages should be sent as they are sent to a destination.
- Duplicate JMS Server names in different domains aren’t a challenge if you’re using Store and Forward (SAF).
- When using the “ReplyTo” feature in cross-domain interaction, duplicate names of a JMS server may be a challenge. Instead of being returned to the domain that sent the original message, the “ReplyTo” message sent from a provided domain is returned to the same JMS server domain that sent the message.
To get more details on configuring and managing WebLogic JMS, see the following links:
- “Oracle Fusion Middleware Programming JMS for Oracle WebLogic Server” has a section called “Managing Your Applications”
- Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help has a section called “Configure JMS Servers.”
Service Specifications with JMS Type
When configuring message flows, Oracle Service Bus helps you to monitor the type of content, JMS type, and encoding used to enable interoperability with heterogeneous endpoints. For non-Java messages, the type of JMS may be text or byte. See “Content Types, JMS Type, and Encoding” in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help for more detail.
SOAP Fault Messages Defined by the WSDL
The WebLogic clientgen tool produces a “java.lang.Exception” subclass for the fault type of XML when consuming a WSDL that explicitly specifies a fault. When the JAX-RPC stack of an Oracle WebLogic Server examines a response message of a SOAP and decides that it includes a fault of a SOAP, it attempts to map the fault to a Java class generated by clientgen.
The clientgen tool produces a Java class “com.bea.test.TheFaultType” that extends “java.lang.Exception” if a WSDL includes the meanings shown in the following listing. While calling the relevant service stub method, a JAX-RPC client will catch “com.bea.test.TheFaultType.”
Example: Sample WSDL Definitions
<definitions … xmlns:s0=”http://www.oracle.com/test/”>
…
<types>
<xsd:schema targetNamespace=”http://www.oracle.com/test/”>
…
<xsd:complexType name=”theFaultType”>
<xsd:sequence>
<xsd:element name=”ID” type=”xsd:int” />
<xsd:element name=”message” type=”xsd:string” />
</xsd:sequence>
</xsd:complexType>
<xsd:element name=”theFault” type=”theFaultType” />
</xsd:schema>
</types>
…
<message name=”theFaultMessage”>
<part element=”s0:theFaultPart” name=”theFault” />
</message>
…
<binding …>
<operation …>
<soap:operation soapAction=”…” style=”document” />
<input …>
…
</input>
<output …>
…
</output>
<fault …>
<soap:fault name=”theFaultPart” use=”literal” />
</fault>
</operation>
</binding>
…
</definitions>
So the correct exception is thrown by the JAX-RPC stack if the SOAP message has a fault in the correct format. If the fault is created inside the message flow of an Oracle Service Bus, then you should:
1. Substitute the $body variable for the node with the below SOAP sample:
Example: Sample SOAP
<soap-env:Body>
<soap-env:Fault>
<faultcode
xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>soap:Server</faultcode>
<faultstring>Some literal string</faultstring>
<detail>
<test:theFault>
<test:ID>Any user defined code</test:Id>
<test:message>A specific literal message</test:message>
</test:theFault>
</detail>
</soap-env:Fault>
</soap-env:Body>
Where:
- The namespace’s system prefix is “soap-env”. http://schemas.xmlsoap.org/soap/envelope/
- The namespace’s prefix is “test”.
You must declare the prefix “test” if Oracle Service Bus is not already aware of it.
2. Setup a failure-based reply action.
Configure Reply Actions in the Oracle Service Bus Administration Console for more detail. see Section 2.4.22, “Adding and Configuring Reply Actions in Message Flows.”
Client-side artifacts are generated using the clientgen tool like the stubs of JAX-RPC, required to call a Web Service. “Oracle Fusion Middleware WebLogic Web Services Reference for Oracle WebLogic Server” has a section called “Ant Task Reference”.
WebSphere MQ Interoperability
The WebSphere MQ JMS interface connects Oracle Service Bus to WebSphere MQ. Oracle Service Bus is a JMS client for WebSphere MQ.
There are two ways for WebSphere MQ to access the Oracle Service Bus:
- The WebSphere MQ front-end, Oracle Service Bus, accepts service requests from other applications and transforms them into WebSphere MQ requests.
- WebSphere MQ uses Oracle Service Bus to transfer messages to other applications.
See Section 33.9.1, “Using the WebSphere MQ JMS Interface.” for more detail.
Conclusion:
Oracle Service Bus 11g is a scalable SOA integration network that provides a high-volume, mission-critical SOA environment with a reliable, standards-based infrastructure. It is intended to connect, mediate, and handle interactions through an enterprise-wide service network between heterogeneous services, legacy systems, packed solutions, and multiple Enterprise Service Bus (ESB) instances. Oracle Service Bus serves as the basis for SOA communications and is a key component of the Oracle SOA Suite.
Author Bio
I am VarshaDutta Dusa, Working as a Senior Digital Marketing professional & Content writer in HKR Trainings. Having good experience in handling technical content writing and aspires to learn new things to grow professionally. I am expertise in delivering content on the market demanding technologies like Oracle Service Bus Course, SQL Server DBA Course, Elasticsearch Course, Jmeter, Kibana, ServiceNow HR Service Management etc.
