IB's Java World

Parallel processing and aggregation in WebSphere Integration Developer 6.2

2009-06-11T09:37:00.023-05:00

When we integrate multiple applications using ESB, it is common requirement that we might need to call multiple services from a particular operation in our ESB application. And often, the calls are independent of other calls and in these cases it is expected that ESB layer call providers in an asynchronous manner to cut down the processing time. Although WebSphere Integration Developer came with mediation primitives for aggregating multiple responses, there was no (easy?) way that one could make asynchronous calls (parallel processing) and aggregate responses using Fan-Out/Fan-In and Service Invoke mediation primitives in WID 6.1.2 or prior versions (However, parallel processing and aggregation could be achieved using java code - using invokeAsync API - in Custom Mediation primitives). In these versions, one could only make multiple sync calls and aggregate responses using Fan-Out/Fan-In mediation primitives and Fan-Out/Fan-In provided a mechanism for looping.
Good news is that WID 6.2 has come up with features supporting parallel processing. Good thing about this is that if you are already using Fan-Out/Fan-In to make multiple sync calls using Service Invokes, it is very easy to change them to make async calls. Let’s see how to make service invokes run in asynchronous mode and aggregate responses of asynchronous calls within Fan-Out/Fan-In mediation primitives.
The following image shows my mediation flow implementation, where I have two Service Invoke mediation primitives enclosed within a set of Fan-Out/Fan-In primitives.

This is simple enough – out terminal of Fan-Out is connected to two Service Invokes – one calling an operation on ServiceA and other calling ServiceB. Fan-In aggregates response from both Service Invoke primitives. Let’s see the settings for Service Invoke mediation primitive to make asynchronous calls.

There is a new property added to Service Invoke named “Invocation Style”. You just need to select ‘Async’ from the drop down list to make Service Invoke make asynchronous call to the target provider. Also note that you need to set appropriate value to Async Timeout text box highlighted above. The response will be lost if this value set to a lower value that time taken by the service invoke to return response!
Let’s see settings for Fan-Out and Fan-In mediation primitives.

I have set Fan-Out out terminal to 'Fire once'. However, since I have wired the output terminal to two Service Invoke primitives, both providers are called and there are two responses to be aggregated. So in the properties window of Fan-In mediation primitive, I set a value 2 in “Fire output terminal when” text box. And this is the only option available when “Fire once” is selected in associated Fan-Out.
Let’s see another scenario, when you have an array of inputs, for example an array of ‘User’s to be created. In this case you might be calling same service multiple times – once for each element in array. In a similar case, you might be iterating through a set of inputs and calling different services based on a filter. In these cases the settings of Service Invoke primitives remain same. However, you need to set different properties for Fan-Out and Fan-In.

In Fan-Out primitive, I have specified a XPATH expression to iterate through the array of users. Out terminal will be fired for each User element in the input array. There are two radio buttons below this - these two are new properties of Fan-Out mediation primitive in WID 6.2. Please note that I have selected the radio button “Check for asynchronous responses after all messages have been fired”. This decides when to start collecting responses. And in properties of Fan-In, I have selected radio button “Fire output terminal when the associated Fan-Out primitive has iterated through all messages.” Alternatively you can set XPath expression to decide this or or set exact number of responses, if you know. In my case, out terminal is fired for each iteration as Fan-Out iterates through all messages, and corresponding responses are received.
Just a note - it seems that Fan-Out/Fan-In primitives in WID6.2 do not properly aggregate the responses from multiple synchronous calls, even though aggregation happens correctly for async calls. This was a working feature in WID 6.1.2, broken in WID 6.2 for some reason. There is a PMR for this and official fix should be available soon.

Using Axis WSDL2Java ant task to develop web service client

2009-05-26T20:32:00.029-05:00

In my previous post Developing web service client using WebSphere WSDL2Java ant task we have seen how to use WebSphere wsdl2java ant task to develop web service clients. In this post, let us examine how to generate client side java artifacts using Axis wsdl2java ant task and code a simple web service client.
To run axis wsdl2java, all we need is Apache Axis(JAX-RPC compliant web service engine) installed. We also need Apache Xerces2 (XML parser) installed for running the client. I have Axis v1.4 and Xerces 2.9.1 installed in my system.
I have deployed a tiny sample Web Service 'ServiceA' in a application server running locally for this purpose. We will use the WSDL of this web service to generate stubs. I have defined an simple request/response operation 'createUser' in this.
Following is how I used wsdl2java in this example, in it's simplest way.

<axis-wsdl2java
    output="${src-gen.dir}"
    verbose="true"
    url="${wsdl}"/>
</target>

The generated java files will be placed under folder represented by the output attribute. In my case I have assigned property 'src-gen.dir', which points the folder named src-gen under basedir. Attribute 'url' represents the WSDL on which we are running wsdl2java. It can be URL (like http://host:port/.../ServiceA.wsdl) or the path to the WSDL file in local file system. In this example, I have placed the WSDL file directly under the basedir, so the value of wsdl ant property is just 'ServiceA.wsdl'. Even though we can use the wsdl's URL in wsdl ant task, it becomes little tricky when the WSDL URL is HTTPS (URL with HTTPS protocol, like https://host:port/.../ServiceA.wsdl). In one of my previous post Running Axis WSDL2Java on HTTPS WSDL I have posted some info I had collected about this. If we are generating the client code frequently, it's better to use the WSDL URL to generate client code reflecting changes in web service, which is the ideal way. Otherwise it is better to copy the WSDL to local file system and run wsdl2java.
WSDL2Java ant task has many more advanced options, for example, mapping namespace to a package structure of your choice (by default package structure is derived from namespace), so that the generated classes arranged in this package structure, like given below. Please read more by going through Axis documentations.

<axis-wsdl2java
    output="${src-gen.dir}"
    verbose="true"
    url="${wsdl}" >
  <mapping
    namespace="http://servicea.test.ws.ibswings.com"
    package="com.ibswings.ws.test" />
</axis-wsdl2java>

In my example ant build script, I have called wsdl2java from a target viz. gen. Before we call wsdl2java, we need to provide ant with task definition for this, unless the jar containing these classes are placed under ant's lib folder, to be loaded while starting up. I have loaded the ant tasks like given below.

<taskdef resource="axis-tasks.properties" classpathref="axis.classpath" />

Classpath reference 'axis.classpath' loads all the required jars from the lib direct of Axis installation folder, for loading wsdl2java ant task. Axis is installed under C:\Dev\Installed\axis-1_4 in my computer, and an ant property 'axis.home' points to this folder.

<path id="axis.classpath">
  <fileset dir="${axis.home}/lib">
    <include name="**/*.jar" />
  </fileset>
</path>

I have coded a simple java client program to test the web service, using the generated stubs. Here is the code.

package com.ibswings.ws.test.servicea;

public class Main {

    public static void main(String ... args) {

        try {
            ServiceAImpl proxy = new ServiceAPortServiceLocator().getServiceAPort();
            proxy.createUser(null);
        } catch (Exception exp) {
            exp.printStackTrace();
        }
    }
}

To compile all the generated and above java code, I have defined a ant target named build as shown below.

<target name="build" depends="gen">
  <javac srcdir="${src.dir}"
      destdir="${build.dir}"
      classpathref="axis.classpath"
      debug="on">
    <src path="${src-gen.dir}"/>
  </javac>
</target>

And finally a target to run the client:

<target name="run">
    <java classname="com.ibswings.ws.test.servicea.Main" classpathref="master.classpath"/>
</target>

Here is the complete ant script which has all targets needed from generating java stubs from wsdl, compile and finally to run the client.

<project name="axis" default="run">

  <property name="axis.home" value="C:\Dev\Installed\axis-1_4"/>
  <property name="xerces.home" value="C:\Dev\Installed\xerces-2_9_1"/>
  <property name="src-gen.dir" value="src"/>
  <property name="src.dir" value="src"/>
  <property name="build.dir" value="build"/>
  <property name="wsdl" value="ServiceA.wsdl"/>

  <path id="axis.classpath">
    <fileset dir="${axis.home}/lib">
      <include name="**/*.jar" />
    </fileset>
  </path>

  <path id="master.classpath">
    <pathelement path="${build.dir}"/>
    <path refid="axis.classpath"/>
    <fileset dir="${xerces.home}">
      <include name="xercesImpl.jar"/>
    </fileset>
  </path>

  <taskdef resource="axis-tasks.properties" classpathref="axis.classpath" />

  <target name="init">
    <mkdir dir="${build.dir}"/>
    <mkdir dir="${src-gen.dir}"/>

    <delete includeemptydirs="true">
      <fileset dir="${build.dir}" includes="**/*.*"/>
    </delete>

    <delete includeemptydirs="true">
      <fileset dir="${src-gen.dir}" includes="**/*.*"/>
    </delete>
  </target>
  
  <target name="gen" depends="init">
  <axis-wsdl2java
    output="${src-gen.dir}"
    verbose="true"
    url="${wsdl}" >
    </axis-wsdl2java>
  </target>
  
  <target name="build" depends="gen">
    <javac srcdir="${src.dir}"
         destdir="${build.dir}"
         classpathref="axis.classpath"
         debug="on">
      <src path="${src-gen.dir}"/>
    </javac>
  </target>
  
  <target name="run">
    <java classname="com.ibswings.ws.test.servicea.Main" classpathref="master.classpath"/>
  </target>

</project>

Developing web service client using WebSphere WSDL2Java ant task

2009-04-20T15:38:00.019-05:00

Clients for web services can be easily generated/coded any eclipse (or eclipse based) or any other modern IDEs for java development. All we need is a WSDL or URL pointing a WSDL. However, very often we are required to automate the process of generating client side java stubs (artifacts) using the build tool like Apache ant. Most of the web service engines/tools come bundled with ant tasks for generating java artifacts. In the following section we will see how to generate client side stubs using WebSphere WSDL2Java ant task and code a sample java web service client.
The foremost thing we need is the structure of "wsdl2java" ant task to generate the java client stubs. Here is the call to WebSphere wsdl2java ant task to generate client classes:

<wsdl2java url="${local.wsdl}"
    output="${src-gen.dir}"
    role="client"
    container="none"
    introspect="false"
    genjava="true"
    verbose="true">
</wsdl2java>

This is pretty simple. local.wsdl ant property points the the WSDL file (in local file system) of the Web Service for which I need to code the client. I have placed the WSDL under a folder wsdl (wsdl\ServiceA.wsdl) under the current directory (basedir, in ant term) from where I am running the ant command. Another property "src-gen.dir" the directory where the generated java files are placed. I am keeping these file in a separated directory, than the java files I coded to make the actual web service call, just for the convenience of managing/deleting these generated files.
As you are aware, to make wsdl2java task available to ant, we have two options. Either we have to place the jar containing this class in the ant's lib folder so that ant loads the tasks in start up, or explicitly load the task in ant build script it self. I have opted for the second option. Here is the taskdef for loading the wsdl2java task:

<taskdef name="wsdl2java" classname="com.ibm.websphere.ant.tasks.WSDL2Java">
  <classpath refid="taskdefs.classpath">
</taskdef>

This is self explanatory. The actual class containing the definition of wsdl2java is "com.ibm.websphere.ant.tasks.WSDL2Java". This class in bundled in the jar "ws_runtime.jar" which is available one of the folders under your WAS/RAD installation folder. In my case it is "${WAS_HOME}\runtimes\bi_v61\deploytool\itp\plugins\com.ibm.websphere.v61_6.1.200\ws_runtime.jar". I refer the top level installation folder using a property "WAS_HOME". I am using WID (WebSphere Integration Developer) tool locally, so my WAS_HOME is the top level installation folder of WID - "C:\Program Files\ibm\WID61". You will need to change this accordingly for the WebSphere development environment like RAD that you are using. So the class path definition for this task goes like:

<path id="taskdefs.classpath">
  <pathelement location="${WAS_HOME}\runtimes\bi_v61\deploytool\itp\plugins\com.ibm.websphere.v61_6.1.200\ws_runtime.jar">
</path>

I have added the call to wsdl2java under target "gen". The target definition is:

<target name="gen" depends="init">
  <wsdl2java url="${local.wsdl}"
    output="${src-gen.dir}"
    role="client"
    container="none"
    introspect="false"
    genjava="true"
    verbose="true">
  </wsdl2java>
</target>

Running this "gen" taget from ant generates all the client java classes we need to make a call to the web service "ServiceA" to the directory "src-gen" in my case!
I have coded a simple client java class for making the call to the Web Service using the generated stubs and placed it under the folder src. So I have two source folders namely src and src-gen with java source files to compile. By the way, following is the simple java code calling the web service from my client java class "com.ibswings.test.Main":

package com.ibswings.test;
import com.ibswings.ws.test.servicea.ServiceAImpl;
import com.ibswings.ws.test.servicea.ServiceAPortServiceLocator;
import com.ibswings.ws.test.servicea.User;

public class Main {

   public static void main(String ... args) {

        try {
             ServiceAImpl proxy = new ServiceAPortServiceLocator().getServiceAPort();
             System.out.println("Created User: " + proxy.createUser(new User()).isSuccess());
        } catch (Exception exp) {
             exp.printStackTrace();
        }
   }
}

Here is the ant target for compiling the java source files:

<target name="build" depends="gen">
  <javac srcdir="${src.dir}"
      destdir="${build.dir}"
      classpathref="master.classpath"
      debug="on">
    <src path="${src-gen.dir}">
  </javac>
</target>

To compile the java classes we need some jar files, which are again under some of the WebSphere's installation folder. I have added these jars under classpath definition "master.classpath" like:

<path id="master.classpath">
  <pathelement path="${build.dir}">
  <path refid="taskdefs.classpath">
  <pathelement location="${WAS_HOME}\runtimes\base_v61_stub\runtimes\com.ibm.ws.webservices.thinclient_6.1.0.jar">
  <pathelement location="${WAS_HOME}\runtimes\base_v61_stub\java\jre\lib\xml.jar">
</path>

In this case, I have given the exact path names of the jar files. However, in your case these jars might be in different directories, depending on the IDE/WebSphere environment you are using. Please search for these jars in your filesystem under WAS_HOME and replace the paths accordingly. Optionally, you can use <fileset> ant type to load the jars like:

<path id="master.classpath">
  <pathelement path="${build.dir}">
  <path refid="taskdefs.classpath">

  <fileset dir="${WAS_HOME}\runtimes">
      <include name="**/com.ibm.ws.webservices.thinclient_6.1.0.jar">
      <include name="**/xml.jar">
  </fileset>

</path>

However, ant might take a while to search these jars and load these, slowing your build process. I would suggest you to find the exact path for jars.
Finally, I have added a target for running my client. Here is the ant script:

<target name="run">
  <java classname="com.ibswings.test.Main" classpathref="master.classpath">
</target>

Here is the my complete build script (build.xml):

<project name="webserviceclient" default="build">

<property name="WAS_HOME" value="C:\Program Files\ibm\WID61">
<property name="local.wsdl" value="wsdl\ServiceA.wsdl">
<property name="src-gen.dir" value="src-gen">
<property name="src.dir" value="src">
<property name="build.dir" value="build">

<path id="taskdefs.classpath">
  <pathelement location="${WAS_HOME}\runtimes\bi_v61\deploytool\itp\plugins\com.ibm.websphere.v61_6.1.200\ws_runtime.jar">
</path>

<taskdef name="wsdl2java" classname="com.ibm.websphere.ant.tasks.WSDL2Java">
  <classpath refid="taskdefs.classpath">
</taskdef>

<path id="master.classpath">
  <pathelement path="${build.dir}">
  <path refid="taskdefs.classpath">
  <pathelement location="${WAS_HOME}\runtimes\base_v61_stub\runtimes\com.ibm.ws.webservices.thinclient_6.1.0.jar">
  <pathelement location="${WAS_HOME}\runtimes\base_v61_stub\java\jre\lib\xml.jar">
</path>

<target name="init">
  <mkdir dir="${build.dir}">
  <mkdir dir="${src-gen.dir}">

  <delete includeemptydirs="true">
    <fileset dir="${build.dir}" includes="**/*.*">
  </delete>

  <delete includeemptydirs="true">
    <fileset dir="${src-gen.dir}" includes="**/*.*">
  </delete>
</target>

<target name="gen" depends="init">
  <wsdl2java url="${local.wsdl}"
    output="${src-gen.dir}"
    role="client"
    container="none"
    introspect="false"
    genjava="true"
    verbose="true">
  </wsdl2java>
</target>

<target name="build" depends="gen">
  <javac srcdir="${src.dir}"
      destdir="${build.dir}"
      classpathref="master.classpath"
      debug="on">
    <src path="${src-gen.dir}">
  </javac>
</target>

<target name="run">
  <java classname="com.ibswings.test.Main" classpathref="master.classpath">
</target>

</project>

One final and most important thing - you cannot run ant targets defined above with the ant executable that you have downloaded and installed from apache website! You need to run these using the "ws_ant" (ws_ant.bat in Windows and ws_ant.sh in UNIX) command line utility that comes bundled with webbphere. This is typically available under "<ws_home>\runtimes\bi_vxx\bin\" folder (C:\Program Files\ibm\WID61\runtimes\bi_v61\bin\ws_ant.bat in my case).
The command run "gen" target defined above, I run following command:

"C:\Program Files\ibm\WID61\runtimes\bi_v61\bin\ws_ant.bat" gen

To build target above generates the (Depends on 'gen') java artifacts and them compiles all java files (including the client Main.java I coded). 'build' target is also the default target of my ant project. The ant command to build is:

"C:\Program Files\ibm\WID61\runtimes\bi_v61\bin\ws_ant.bat" build

or simply

"C:\Program Files\ibm\WID61\runtimes\bi_v61\bin\ws_ant.bat"

That's it.. It's that easy to use WebSphere wsdl2java.
Please note that, to run the client, I need to have the actual webservice "ServiceA" running somwhere (locally, per my Main.java) ... Which I have not mentioned here, since that is sort of out of scope!
I have used wsdl1java in simplest way possible in this example. WSDL2Java has many more options. Please read more about WebSphere ant tasks at WebSphere info center. For example, http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp.

Log4J configuration – controlling logging to multiple loggers

2009-03-10T12:50:00.001-05:00

I recently happened to read a blog about Apache Lo44J java logging API where the blogger mentioned that there is no clean good document/tutorial about using log4j, considering the fact that it is one of the most widely used open source java API. I felt that it is true to some extent, when I had to look for some help regarding a logging issue I encountered. Especially, I could not find one authentic manual/tutorial explaining the log4j configuration.

My requirement was to control the logging of messages to multiple appenders (targets) with different log priority. For example, I wanted to a log message to write log only to file if priority is debug but wanted to write to both console and log file if priority is set to info or above. With the help of some blogs and log4j javadocs, I found ways to do this. In this blog, I am explaining what I understood, assuming that it might help others looking for this info.

I used XML configuration for configuring log4j in my project, so I will use same in this article. I assume that you (reader of this blog) have basic understanding of Log4J configuration, if not please read this short manual at apache. I expect you to understand Log4J terms like Logger, Log Level and the XML tags like <category>, <appender>, <layout> etc., those appear in log4j configuration.

Note: wherever I mention “logger” (starting with lower case l), I referelement <category> in log4j configuration xml. I mean <root> wherever I mention root logger and tag <appender> wherever I mention “appender”.

As I mentioned above, my requirement was to log messages to multiple appenders (targets), console and a file, But I wanted to all messages (any level – level DEBUG or above) logged to file and only messages with log level ERROR or higher to the console. Following is my log4j.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

</layout>

</appender>

</layout>

</appender>

<appender-ref ref="FILE"/>

</category>

<root>

<appender-ref ref="CONSOLE"/>

</root>

</log4j:configuration>

A simple class I used to test this:

package com.ibswings.loggertest;

import org.apache.log4j.Logger;

public class Test {

public static void main(String[] args) {

new Test();

}

public Test() {

Logger logger = Logger.getLogger(getClass());

logger.debug("Debug Message");

logger.info("Info Message");

logger.error("Error Message");

}

I was expecting this to print all three messages from code to be printed to the log TestLogFile.log and only error message to be printed to console, since I have set ‘error’ priority in <root>. However I noticed that all messages are printed to both log file and console like:

2009-03-07 19:32:00,893 DEBUG Test.java:14 - Debug Message

2009-03-07 19:32:00,893 INFO Test.java:15 - Info Message

2009-03-07 19:32:00,893 ERROR Test.java:16 - Error Message

Let’s look into this in detail. By default, when a message is logged, the message will go to the first logger () whose names closely matches the name of the Logger instance you created in Java code. From there, it is directed to the next matching logger up in the logger hierarchy until root logger. In each of these loggers, output is sent to all appenders indentified by definitions. In the above example, I had created logger in my code like:

Logger logger = Logger.getLogger(getClass());

Actually, this is equivalent of

Logger logger = Logger.getLogger(“com.ibswings.loggertest.Test”);

When following line is executed,

logger.debug("Debug Message");

The closest matching logger defined in config is <category name="com.ibswings". This logs output to TestLogFile.log through appender named “FILE” (Note that if I had a logger defined in log4j.xml with name "com.ibswings.loggertest", that would have been the first logger to get the message). Message directed to root logger from here, since there is no other logger matching the name in between. And, message is printed out to standard out by CONSOLE appender. Also, when message is logged by root, it is logged with priority of message it received it from previous logger. Hence all messages are printed to console in this case, even though we have set error priority in root. The priority set in root has two uses – first, it is the default priority of all other loggers without priorities set. Second, all messages which are only received by root logger (i.e. messages with no matching loggers in log4j.xml) will have this default priority enabled. In following section, let’s see how we can avoid duplicating messages in both log file and console.

How to log only my messages to log file and others to console?

As I mentioned above, output from each logger is directed to next logger above in the logger hierarchy, till root logger. To set behavior off, we need use “addictivity” attribute in . If addictivity is set to “false” in a particular logger, output will not be sent to next logger up in the hierarchy. Or, output is sent from logger to logger, until it reaches a logger (of course, before root) in which addictivity is set to false. By default (when not specified) addivity is set to true. That’s how in the previous case messages are printed to both file and console. Let’s use this in out log4j.xml to stop messages from printing in console.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

</layout>

</appender>

</layout>

</appender>

<appender-ref ref="FILE"/>

</category>

<root>

<appender-ref ref="CONSOLE"/>

</root>

</log4j:configuration>

With this log4j.xml, all messages from the code are logged to file only. Since we set additivity="false" in the first logger, output is not directed to root logger. In this case, other Logger instances with name not matching “com.ibswings” and any System.out.printxx() calls go to console. In the following section, let’s see how to send all messages from our java code to file and some selected messages (based on priority) to console.

How to log all my messages to log file and selected (based on priority) my messages to console?

Coming to my original requirement, I want to send all my messages (printed from my java code) to log file. Also, I want to send all error messages from my code to console also. At the same time, I want to see all other messages (from other Logger instances and SOP calls) in console.

To achieve this, let’s assume we add appender-ref to console in our first logger. Now question is how to send only error messages, since whatever priority we set to in logger is applicable to all appenders. The solution is to use “Threshold” parameter in appender definition. If we specify a particular priority in appender using threshold, only messages with priority equal of higher to priority specified in ‘threshold’ are printed to the target. However, in this case, we cannot set ‘threshold’ to error in CONSOLE appender, since we need to print all messages (any level) not covered by our logger to console, in root logger. Let’s create a new appender CONSOLE_1 to log messages to console. The configuration is given below.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

</layout>

</appender>

</layout>

</appender>

</layout>

</appender>

<appender-ref ref="FILE"/>

<appender-ref ref="CONSOLE_1"/>

</category>

<root>

<appender-ref ref="CONSOLE"/>

</root>

</log4j:configuration>

When I ran my test, I see all message logged to file and error message printed in console. Also, all other messages with any level and SOPs printed to console, since we have appender CONSOLE referenced in root logger. In following section, let’s see how to all my messages and all other error messages, only to log file. Following is the log4j.xml we can use to achieve this.

How to log all my messages and all other error messages, only to log file?

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

</layout>

</appender>

</layout>

</appender>

<appender-ref ref="FILE"/>

</category>

<root>

<appender-ref ref="FILE"/>

<!--

<appender-ref ref="CONSOLE"/>

-->

</root>

</log4j:configuration>

Note that I have commented appender-ref CONSOLE in root logger. With this log4j.xml, all messages logged from my java code are printed to log file. At the same time any other message with priority error is also printed to log file. All these will be logged only to the log file, not to console. However, we will still see SOPs in the logger (if we use this in an Application server, we will see lot of such messages in console/standard out or error log files).

Running Axis WSDL2Java on HTTPS WSDL

2008-12-18T20:15:00.002-06:00

If you are getting SSL related exception while using WSDL2Java on a HTTPS WSDL (URL with HTTPS protocol) like “javax.net.ssl.SSLHandshakeException: … unable to find valid certification path to requested target”, you have to add the certificate of the host in your URL to the java’s keystore.

The above exception might occur only when you use the WSDL url (eg. https://myhost.com:443/TestWS/Test.wsdl) to generate the java files using Axis WSDL2Java ant tasks. Easiest option would be to download the WSDL on to your local file system and using it to generate java files using WSDL2Java. However, to run the client in standalone mode, you still need to add the certificate to the JRE’s keystore.

Follow the steps given above to import the certificate onto the JRE's keystore. First, we need to export the certificate from the browser to a file.

If you are using IE, here is how you can do so:

Access URL with https protocol (example: service WSDL location (Ex. https://foo.com/bar?wsdl) on the browser.
Internet explorer will prompt a security alert. Select the "View Certificate" button.
Navigate to the tab "Details". Select the "Copy to File.." button.
Certificate Export Wizard will be displayed. Select "NEXT" button.
The option "DER encoded binary X.509 (.CER) will be by default selected. Select "Next".
Place the file where it suits you better.
Select "Next". The "Completing Certificate Export Wizard" will be displayed. Select "Finish". The will be a pop-up saying "The export was successful".

If you are using Mozilla Firefox,

Open the URL in the browser. Click on the lock icon on the bottom right hand side corner of statusbar of browser window.
Click on view certificate. Go to ‘Details’ tab in opened dialog.
Click on Export button to save the file.
Place the file where it suits you better.

Following are the steps to import the certificate signature to JRE keystore:

Move the certificate file to your %JAVA_HOME%/jre/lib/security folder.
In ant you can use command ant –diagnostics to find out java installation folder by using java.home system property.
Make a backup copy of file named “cacerts” (the keystore) which is under %JAVA_HOME%/jre/lib/security.
Open a command prompt and change directory (cd) to %JAVA_HOME%/jre/lib/security.
Run following command:
keytool -importcert -trustcacerts -keystore cacerts -storepass changeit -alias "<aliasname>" –file <cert file>
Type in ‘yes’. (prompt appears for untrusted certificates)
Run following command to verify:
keytool -keystore cacerts -storepass changeit -list -alias "<aliasname>"

After importing certificate to keystore, if you are getting the exception with message “CertificateException: No name matching <host name> found” when you are running Axis WSDL2Java ant task, make sure that you give the same alias name as the common name (CN) of the certificate while adding the cert to keystore. Also make sure that you have the WSLD URLs host name maches certificate’s CN. In this case, Certificate CN, Alias and the hostname in WSDL should all match.
To know the CN of certificate, see details of certificate in browser or use keytool –list command given int step 9 above. The text in the first line before the first comma in the output of keytool –list command is the CN.

You can delete certificates added to keystore using keytool –deletecert command and add them back with alias as CN of certificate.
Sample command to delete certificate from keystore:
JAVA_HOME\jre\lib\security> keytool -delete -keystore cacerts -storepass changeit -alias "<aliasname>"

Integrating WebSphere MQ 6 with BEA Weblogic Server 10 using Weblogic Server's Foreign (JMS) Server feature.

2008-02-17T12:59:00.001-06:00

This article (in fact you may call this a set of instructions) shows you how to configure Foreign (JMS) Server in BEA WebLogic 10 Server to receive/send messages from/to queues in WebSphere MQ.

What we need:

You must have following software installed in your system:

WebSphere MQ 6
BEA Weblogic 10
JDK 1.5 or above. (This comes bundled with Weblogic)

I assume you know compile and deploy message driven beans in Weblogic.

What we going to do:

Create a queue manager and two local queues namely MQSenderQueue and MQReceiverQueue in Websphere MQ, one for sending a message to our MDB at Weblogic and other one for receiving messages from Weblogic. Create and configure JMS Foreign Server, Destinations and Connection Factories.
Code and deploy a MDB in Weblogic and automatically receive messages from MQ MQSenderQueue and place it at a second MQ queue MQReceiverQueue using Weblogic Foreign JSM Server features.

For testing:

Put a test message to MQSenderQueue at MQ.
Monitor Weblogic console to see if it has received and sent the message again to MQ.
See the message received at the MQReceiverQueue at MQ.

Creating queue managers, queues and connection factories in WebSphere MQ:

Creating queue manage

Click on Start -> Program Files -> IBM WebSphere MQ -> WebSphere MQ Explorer to open WebSphere MQ Explorer. Optionally execute C:\Program Files\ibm\WebSphere MQ\bin strmqcfg.exe to run explorer.

Image #1: WebSphere MQ Explorer

On the left hand side WebSphere MQ Explorer – Navigator pane, click on 'IBM WebSphere MQ' node to expand that, if it is not expanded already.

To create a queue manager, right click on the ‘Queue Managers’ node and select New -> Queue Manager.
In the opened window, enter name “MQTest” in the name textbox and keep clicking Next-> and finally click Finish.

Now you have created a MQ queue manager namely “MQTest”. A node “MQTest” must appear under node “Queue Managers” now as shown below:

Image #2: Create queue manager in MQ

Image #3: Create queue manager in MQ

Image #4: View queue manager in MQ

Creating WebSphere MQ local queues

Now let us create MQ queues. As I mentioned above, we are going to create two queues. We will be using one of them to put a test message which is to be received by our MDB at BEA Weblogic and the other one is used by our MDB to put message the message back into second MQ queue, so that we can see the same message again in MQ, but in the second MQ queue.

We are going to create two local queues using MQ explorer.

1. To create our first local MQ queue, right click on Queues node under “MQTest” queue manager. Select New -> Local Queue.

Image #5: Create local queue in MQ

2. Enter name for our first local MQ queue “MQSenderQueue” as shown below. Click “Next” and finally “Finish”. This is the queue we will be using to put our test message.

Image #6: Create local queue in MQ

3. Repeat the above two steps to create another local queue “MQReceiverQueue”. Note the naming I followed here – used a prefix MQ to avoid the confusions since we use similar JNDI names in Weblogic also.

Optionally, you may create MQ queue manager and local queues using command prompt. Open a command prompt (CMD) and CD to C:\Program Files\ibm\WebSphere MQ\bin.

Create the queue manager: crtmqm MQTest.
Start the queue manager: strmqm MQTest.
Create queues in the queue manager:

 runmqsc MQTest
  DEFINE QLOCAL(MQSenderQueue)
  DEFINE QLOCAL(MQReceiverQueue)
 end

Please note that I haven’t tried this option, so I am not sure how it works.

Creating JNDI Context and Connection factories

Next, create a simple file-based JNDI context and configure the JMS objects in that JNDI namespace. These JNDI objects are used by applications running in WebSphere Application Server Community Edition to connect to the WebSphere MQ queue manager. For this exercise, WebLogic and WebSphere MQ should be on the same machine.

The setting is for file-based JNDI. Create the directory C:\MQ-JNDI before continuing with the next step. Under new folder C:\MQ-JNDI, create a file mq-jndi.properties with the following contents:

INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
PROVIDER_URL=file:/C:/MQ-JNDI
SECURITY_AUTHENTICATION=none

Next open a command prompt, cd to C:\MQ-JNDI, create the QueueConnectionFactory and Queue objects by executing the command:

“C:\Program Files\IBM\WebSphere MQ\Java\bin\JMSAdmin.bat” -cfg mq-jndi.properties

You should see this prompt, where you can configure the JNDI objects:

InitCtx>

At the prompt, copy and paste all five lines of following commands together and press Enter.

def xaqcf(MQSenderQCF) qmgr(MQTest)
def xaqcf(MQReceiverQCF) qmgr(MQTest)
def q(MQSenderQueue) qmgr(MQTest) queue(MQSenderQueue)
def q(MQReceiverQueue) qmgr(MQTest) queue(MQReceiverQueue)
end

You should see a message like “Stopping Websphere MQ classes for Java(tm) Message Service Administration” after you press Enter after the last line “end”.
With that, we now have MQ queues ready (see following image). Next task is to create a MDB in EJB 3 and deploy it in BEA Weblogic 10.

Image #7: MQ explorer showing queue manager and local queues.

Configuring Foreign JSM Server in BEA Weblogic Server:

Before starting your Weblogic Server you have to ensure that certain MQ related jar files are in your Weblogic Server’s classpath. Easiest way to do this is to copy following jars from “C:\Program Files\ibm\WebSphere MQ\Java\lib” folder to your Weblogic domain’s lib (C:\bea\user_projects\domains\RnD\lib in my case) folder, from where Weblogic loads them up while starting.

com.ibm.mq.jar
com.ibm.mqjms.jar
commonservices.jar
dhbcore.jar
fscontext.jar

Create JMS Module

Once jars are in Weblogic Server’s class path, start your Weblogic server and login to Weblogic admin console. To start with, click ‘Lock & Edit’ button.
Expand Services -> Messaging on LHS menu and click JMS Modules link.
Click on “New” button on RHS

Image #8: Configuring JMS module

Type in a name “MQIntegrationTest” in the Name text box and press Next.

Image #9: Configuring JMS module

Select the Target server (in my case it was AdminServer) as shown below, press Next and finally Finish. Click on “Activate Changes” button on LHS.

Image #10: Creating JMS module

Create JMS Foreign Server

Click on Lock & Edit again.
Select Services -> Messaging -> JMS Modules as you did earlier, and click on newly created module “MQIntegrationTest”. Click New button.
Select “Foreign Server” radio button and click “Next”.

Image #11: Creating JMS foreign server

Enter “MQTestForeignServer” in the Name text box, click Next button. In this page you can see that the target server is selected already. Click Finish.

Image #12: Creating JMS foreign server

Image #13: Creating JMS foreign server

Activate changes by clicking “Activate Changes” button.

Click Lock & Edit again.
Open the newly created Foreign JMS server byt clicking Services -> Messaging -> JMS Modules -> MQIntegrationTest -> MQTestForeignServer.

Under the General tab under Configuration, type in following details:

JNDI Initial Context Factory: com.sun.jndi.fscontext.RefFSContextFactory
JNDI Connection URL: file:/C:/MQ-JNDI

Click “Save”.

Image #14: Configure JMS foreign server

Creating Destinations
Click on Destinations link in the Configuration tab at the top and click New

Image #15: Create Destinations

Type in following:

Name: ReceiverDetails
Local JNDI Name: jms/WLReceiverQueue
Remote JNDI Name: MQSenderQueue

Note that the Remote JNDI Name must match the name of the queue you created in WebSphere MQ broker.
Click OK.

Image #16: Configure Destination

Repeat the above to create another Destination with following details:

Name: ReplyDetails
Local JNDI Name: jms/WLReplyQueue
Remote JNDI Name: MQReceiverQueue

Now you can see two Destinations created:

Image #17: Newly created Destinations

Creating Destinations
Let’s create two Connection Factories for above queues.
Click on Connection Factories (next to Destinations) and click New

Image #18: Create connection factories

Enter following details in “Create a New Foreign JMS Connection Factory” page.

Name: ReceiverCF
Local JNDI Name: jms/WLReceiverQCF
Remote JNDI Name: MQSenderQCF

Again, the remote JNDI name must match on you have given to MQ connection factory.
Click Ok.

Image #19: Create connection factory

Repeat the above steps to create one more connection factory for our ReplyQueue:

Name: ReplyCF
Local JNDI Name: jms/WLReplyQCF
Remote JNDI Name: MQReceiverQCF

With that, you can see two Connection Factories created for our Foreign JMS Server like shown below:

Image #20: Connection factories

Click on “Activate Changes” to activate changes. With that you are done with creating and configuring Foreign JMS Server. The only thing pending before we test is to code and deploy our MDB.

Creating MDB and deploying it.

Here is the MDB code:

/*
* File: TestMDB.java
* Copyright (c) 2007-2008 ibswings.com. All rights reserved.
*/
package com.ibswings.ejb3.mdb;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.annotation.Resource;
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.QueueConnection;
import javax.jms.QueueSender;
import javax.jms.QueueSession;
import javax.jms.Session;
import javax.jms.TextMessage;

/**
* Class: TestMDB
*
* @author Ishwara Varnasi
* @date Feb 17, 2008
*/
@MessageDriven(name = "TestMDB", mappedName = "jms/WLReceiverQueue",
activationConfig = {@ActivationConfigProperty(
propertyName = "destinationType",
propertyValue = "javax.jms.Queue")}
)
public class TestMDB implements MessageListener {

public void onMessage(Message msg) {
System.out.println("\n=========================================");
System.out.println("=> Message received!");

if (msg instanceof TextMessage) {

try {
System.out.println("=> Message: "
+ ((TextMessage) msg).getText());
} catch (JMSException e) {
e.printStackTrace();
}
}

// Place the message on to the reply queue (WLReplyQueue)
putMessage(msg);
System.out.println("=========================================");
}

@Resource(name = "WLReplyQueue", mappedName = "jms/WLReplyQueue")
private javax.jms.Queue queue;
@Resource(name = "WLReplyQCF", mappedName = "jms/WLReplyQCF")
private javax.jms.QueueConnectionFactory tcf;

public void putMessage(javax.jms.Message msg) {
System.out.println("=> Placing message on WLReplyQueue...");
QueueConnection queueConnection = null;
QueueSession queueSession = null;
QueueSender queueSender = null;

try {
queueConnection = tcf.createQueueConnection();
queueSession = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
queueSender = queueSession.createSender(queue);
queueSender.send(msg);
System.out.println("=> Message sent!");

} catch (Exception e) {
System.out.println("Exception: ");
e.printStackTrace();

if (e instanceof JMSException) {
((JMSException) e).getLinkedException().printStackTrace();
}

} finally {

try {
System.out.println("=> Closing Connection");
queueSession.close();
queueConnection.close();
} catch (Exception e) {
System.out.println("Exception: ");
e.printStackTrace();

if (e instanceof JMSException) {
((JMSException) e).getLinkedException().printStackTrace();
}
}
}
}

@PostConstruct
public void postCreate() {
System.out.println("Bean Created");
}

@PreDestroy
public void preDestroy() {
System.out.println("Bean Destroyed");
}
}

The above code is for a simple message driven bean. It receives messages from MQSenderQueue and onMessage() prints out the content of text message received. Next it places the message back to the WLReplyQue. Note that in the code we never directly place message on to MQ queue. We are actually placing the message to a MQ queue namely MQReceiverQueue using Foreign JMS Server and local Weblogic JNDI name WLReplyQue.
Since we are using EJB 3, we actually do not need an ejb-jar.xml since we are using annotaions. However, to make it work on Weblogic 10, we still need a weblogic-ejb-jar.xml. Somehow I couldn’t get it working without this. Also note that I am using an older (90) schema for weblogic-ejb-jar.xml. Following is the content of Weblogic-ejb-jar.xml:

<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90"
j2ee="http://java.sun.com/xml/ns/j2ee"
xsi="http://www.w3.org/2001/XMLSchema-instance"
schemalocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">

<weblogic-enterprise-bean>
<ejb-name>TestMDB</ejb-name>
<message-driven-descriptor>
<destination-jndi-name>
jms/WLReceiverQueue
</destination-jndi-name>
<connection-factory-jndi-name>
jms/WLReceiverQCF
</connection-factory-jndi-name>
</message-driven-descriptor>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>

Create EJB jar and deploy it in Weblogic Server. You need to restart Weblogic instance if you do any changes in MQ to reflect that in Weblogic. We are all set to test now!

Testing

Open WebSphere MQ explorer, click on MQTest (our queue manager) -> Queues. On the RHS table, right click on MQSenderQueue and select “Put test message” in the popup menu. Type in a test message, say, “Hello MQ-Weblogic World!”, click “Put Message” and close.

Image #21: Put a test message for testng.

Go to your Weblogic Servers’ output console and you will see the message. Outputs look like:

=========================================
=> Message received!
=> Message: Hello MQ-Weblogic World!
=> Placing message on WLReplyQueue...
=> Message sent!
=> Closing Connection
=========================================

Now go to MQ explorer and check messages in the second queue – MQReceiverQueue – you should be able to see this message.

Image #22: Queues with messages.

This article is inspired by an article by Sanjay M Kesavan at
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0604_kesavan/0604_kesavan.html
I would like thank Mr. Kesavan, author of above wonderful article.

That’s it. You may send your feedbacks to me on ivarnasi@gmail.com.