Tuesday, August 18, 2015

Third Party Queue Connection using Foreign JMS Server in OSB/SOA

Hi,

There are cases where we need to establish third party JMS connection. To achieve that in ESB, we can use JMS Bridges, which creates a reliable connection oriented link to any weblogic JMS queue or to other Third Party Queue. One other way to establish the same is using Foreign JMS Server.

There are other ways listed below
Q. What tools are available for integrating with remote JMS providers?
A. The following table summarizes the tools available for integrating with remote JMS providers:
Method
Automatic Enlistment
JMS Resource Pooling
Direct use of the remote provider's JMS client
Yes for a WebLogic server provider. Other providers must perform enlistment programmatically.
No. Can be done programmatically.
Messaging Bridge
Yes
N/A
Foreign JMS Server Definition
No. To get automatic enlistment, use in conjunction with a JMS resource reference or MDB.
No. To get resource pooling, use in conjunction with a JMS resource reference or MDB.
JMS Resource Reference
Yes
Yes
Message Driven EJBs
Yes
Yes


Both of the messaging bridge and the foreign JMS server allow you to receive/send messages via a WLS server to a JMS destination that is running on a remote WLS server/cluster/domain or a 3rd party messaging product.


Conceptual Diagram


So when to use what ?

Q. When should I use a messaging bridge?
A. Typically, messaging bridges are used to provide store-and-forward high availability design requirements. A messaging bridge is configured to consume from a sender's local destination and forward it to the sender's actual target remote destination. This provides high availability because the sender is still able to send messages to its local destination even when the target remote destination is unreachable. When a remote destination is not reachable, the local destination automatically begins to store messages until the bridge is able to forward them to the target destination when the target becomes available again.

Q. When should I avoid using a messaging bridge?
A. Other methods are preferred in the following situations:
  • Receiving from a remote destination—use a message driven EJB or implement a client consumer directly.
  • Sending messages to a local destination—send directly to the local destination.
  • Environment with low tolerance for message latency. Messaging Bridges increase latency and may lower throughput. Messaging bridges increase latency for messages as they introduce an extra destination in the message path and may lower throughput because they forward messages using a single thread.


Q. When is it best to use a Foreign JMS Server Definition?
A. For this release, a Foreign JMS Server definition conveniently moves JMS JNDI parameters into one central place. You can share one definition between EJBs, servlets, and messaging bridges. You can change a definition without recompiling or changing deployment descriptors. They are especially useful for:
  • Any message driven EJB (MDB) where it is desirable to administer standard JMS communication properties via configuration rather than hard code them into the application's EJB deployment descriptors. This applies even if the MDB's source destination isn't remote.
  • Any MDB that has a destination remote to the cluster. This simplifies deployment descriptor configuration and enhances administrative control.
  • Any EJB or servlet that sends or receives from a remote destination.
  • Enabling resource references to refer to remote JMS providers. 

Here it is how you can configure it.

https://docs.oracle.com/cd/E57014_01/wls/WLACH/taskhelp/jms_modules/foreign_servers/ConfigureForeignServers.html


If you are connecting it to a third party queue, you need to have their JMS libraries in weblogic lib. For MQ it comes by default.

Now to use the JMS Server resource reference in OSB or in SOA, you can use it normally as you do for internal weblogic Queue push and pop.

In OSB, you can skip giving the host:port and jms:///ConnectionFactoryJNDI/QueueJNDI will work.

In SOA, you can configure JMS Adapter with  Connection factory location details and refer to the Queue while designing your process and it will work as it does for local queue.

Thanks









No comments:

Post a Comment