Home/ Questions/Q 4084360
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T18:25:48+00:00

We’re trying to come up with something approaching a simple and straight-forward model for

  • 0

We’re trying to come up with something approaching a simple and straight-forward model for targeting of JMS resources in WebLogic (fat chance, I know). Queues and Topics can easily and quite intuitively be mapped to JMS servers running on WebLogic servers, but Foreign Servers and the resources within them seem to be a bit more tricky.

In both WLS 10.0 and 10.3 Foreign Servers are, firstly, not defined next to JMS Servers but as members of a JMS Module. Secondly, they are targeted by default to the target of the JMS Module they are defined in, i.e. a WLS Cluster or WLS Server(s), unlike “non-foreign” resources which are targeted at JMS Servers via Subdeployments.

However, with Advanced Targeting it is also possible to target Foreign Servers at JMS Servers. This results in a model that is much more symmetrical with respect to foreign/”non-foreign” JMS resources.

Advanced Targeting http://dexter.xebialabs.com/Media/foreign_server_advanced_targeting.png

So, the questions are:

  1. Is there any reason beyond historical accident why Foreign Resource and “non-foreign” resource targeting is so different (foreign resources by default at a WLS Cluster or WLS Server(s) vs. non-foreign resources at JMS Servers)?
  2. Is there any common or best practice for targeting Foreign and non-foreign resources?
  3. Are there any reasons why one would not want to target Foreign Servers at JMS Servers via Subdeployments?

Thanks in advance!

Andrew Phillips

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    1) Foreign JMS servers used to be defined as a stand-alone component, similar to connectors, messaging bridges, etc. These components (historically) target application servers or clusters directly instead of an intermediary component like a JMS server.

    With the later releases, Oracle has tried to merge both the internal and foreign JMS under a universal umbrella. However, the target options were kept different. To provide flexibility with the JMS portion, sub-deployments were introduced. Oracle seems to have been extended sub-deployments to Foreign Servers for the sake of consistency, making things quite complicated/messy.

    I wouldn’t call it an accident since the newer releases keep conforming to this setup 🙂

    2) For applications deployed across clusters, you will need to have a single JMS module defined for the entire cluster inorder. Multiple definitions of your connection factory will skew the JMS load-balancing.

    Our best practices were centered around the standard of creating a single JMS Module per cluster (or app server if it wasn’t clustered) and then creating both the Foreign server and the weblogic JMS queues/connection factories within the same module. Also, having good naming conventions for your sub-deployments and JMS Modules goes a long way.

    3) Foreign servers (especially with IBM MQ) can have a lot of complex issues once you’re running >16 concurrent MDBs. We avoided the Foreign Server -> JMS Server -> Managed Server to cut down the additional layer of abstraction/complexity inorder to keep the configuration simpler. You also reduce the risk of your foreign server’s exceptions being masked by a cryptic JMS server exception (I don’t have any proof of this).

    A team mate once suggested that the Foreign Server -> Application Server setup was more performant but we had Oracle’s A-team confirm that it’s only a logical/aesthetic change and shouldn’t really matter.

    Hope that helps!

    • 0