What is the common practice for targeting Foreign Servers in Oracle WebLogic Server

Question

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

Answer 1

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!