JMS based JAXWS-Webservices using pure JEE stack on JBoss EAP 7 – Tutorial Part II – Infrastructure Setup

In this chapter we will have a close look at the infrastructure setup in particualar preparing JNDI resources for IBM Websphere MQ and configurating JBoss:

Defining JNDI Objects


Prerequisition for this configuration step is a properly set up IBM Websphere MQ environment!


Instead of hardcoding physical endpoints in the WSDL, we define JNDI names which reference the proper objects. So we need to do two things, to enable JBoss to be our JNDI provider

  1. create file which contains bindings between JNDI names and JNDI objects
  2. configure JBoss to use file and provide the references

For the first step we use the IBM Websphere MQ Explorer

mqexplorer.png

OR the command line tool to create a file system context (serivce provider class com.sun.jndi.fscontext.RefFSContextFactory), which must contain JNDI binding information for

  • a connectionFactory (here: MQConnectionFactory)
  • at least one Queue or Topic (here: Queue tst.q1)

This will result in a .binding file which is used for step 2 – tell JBoss to provide an external context. Therefore we use the existing naming module. The following snippet show the necessary configuration in JBoss’ central standalone.xml

<server xmlns="urn:jboss:domain:4.1">
    <extensions>
    <!-- activate naming subsystem -->
    <extension module="org.jboss.as.naming"/>
    </extensions>
    <system-properties>
        <!-- path to directory containing .binding file -->
        <property name="jndi.config.file" value="file:/C:/Temp/bnd"/>
    </system-properties>
        <subsystem xmlns="urn:jboss:domain:naming:2.0">
            <bindings>
                <external-context name="java:jboss/exported/jms" module="com.sun.jndi" class="javax.naming.directory.InitialDirContext" cache="false">
                    <environment>
                        <property name="java.naming.factory.initial" value="com.sun.jndi.fscontext.RefFSContextFactory"/>
                        <property name="java.naming.provider.url" value="${jndi.config.file}"/>
                    </environment>
                </external-context>
            </bindings>
            <remote-naming/>
        </subsystem>

The JNDI binding file is provided as external context under the JNDI namespace jms in scope java:jboss/exported – this scope enables, that the JNDI resources are also available for remote access (e.g. via http-remoting).

Also note the module attribute – this refers to the JBoss module, which contains the implementation of the JNDI provider class (see module dependencies). More information about the JBoss naming subsystem can be found here.

Module dependencies

JBoss provides an OSGi container to manage dependencies between modules. A module represents a deployable entity (jar, war, ear) as well as the provided libraries which are hereby bundled in functional groups (e.g. logging, ejb, cxf etc.). Further information can be found in the JBoss documentation here and here.

We will use this mechanism to provide the necessary IBM Websphere MQ and Sun JNDI libs to our service. This approach is recommended for every shared library cause it enables you to centrally manage your dependencies (e.g. for version updates), significantly decreases the deployment package and thus speeds up the startup delay.

The following picture shows the JBoss EAP 7 folder structure. Custom modules can be stored as siblings to system beneath the modules folder, which contains all provided server modules. We will use the file hierarchy com / ibm / mq where the lowest folders represent the slot, whereby main is default. Slot can be conceived as version, so as you can see we have the websphere mq lib module in version 7 (main) and version 8 (v8) provided parallel by the JBoss container.

ordnerstruktur_komplett.png

The second relevant part of the module is the module.xml configuration file. Here all necessary information is wired together. For additional configuration of modules please refer to the JBoss doc.

<!-- slot can be omitted if default (main) -->
<module xmlns="urn:jboss:module:1.3" name="com.ibm.mq" slot="v8">
	<resources>
		<resource-root path="com.ibm.mq.headers.jar"/>
		<resource-root path="com.ibm.mq.jar"/>
		<resource-root path="com.ibm.mq.jmqi.jar"/>
		<resource-root path="com.ibm.mq.pcf.jar"/>
		<resource-root path="com.ibm.mqjms.jar"/>
		<resource-root path="connector.jar"/>
		<resource-root path="dhbcore.jar"/>
		<resource-root path="jta.jar"/>
	</resources>
	<dependencies>
        <module name="javaee.api" export="true" />
	</dependencies>
</module>

For this tutorial we also need a second custom module which contains the Sun filesystem context JNDI provider implementation. We will need this dependency for retrieving the JNDI references of queue connection factory and destinations defined in the section above. The module files are located under sun / jndi / main

<module xmlns="urn:jboss:module:1.3" name="com.sun.jndi">
    <resources>
        <resource-root path="fscontext.jar"/>
		<resource-root path="providerutil.jar"/>
    </resources>
	<dependencies>
        <module name="javaee.api" export="true" />
	</dependencies>
</module>

The next post will show in detail how to write the service code and wire the things together.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s