Configuring JMS in WAS could be quite confusing due to large number of settings and configuration resources (destination, queue/topic, connection factory, activation spec).

One of the most confusing aspects of this configuration is the quality of service (QOS) settings that deal with message reliability.

These settings can be configured using SIB destination:

And/or connection factory:

The reliability is also influenced by the JMS APIs used by the application code ( MessageProducer.setDeliveryMode, MessageProducer.send).

Here's how the message reliability is determined:

• Message producer sends a message with the requested delivery mode. Note that the PERSISTENT mode is the default.
• If the destination for the message is set to allow producers to override reliability, the reliability setting defined on the connection factory for the given delivery mode is used. However, if the connection factory's setting is "As bus destination", the default reliability setting of the destination is used.
• If the reliability can not be overridden, the default reliability setting of the destination is used.
• If the resulted reliability level exceeds the maximum reliability setting for the destination, the exception is thrown or the message is routed to the error destination.

The takeaway is that, by default, the reliability settings on the destination are ignored.

Here are the two widespread misconceptions about JMS reliability:

• Default settings provide the best QOS/highest reliability. This is not the case. Connection factory is configured with "Reliable Persistent" by default which is a notch below the highest "Assured Persistent". "Reliable Persistent" could result in lost messages and dupes as the messages are persisted asynchronously.
• Non-persistent reliability mode means that messages are never saved to the message store and kept in memory. This is not the case. WAS saves non-persistent messages to the message store when the queue depth becomes too high.

When choosing reliability, try to determine the minimally acceptable reliability level for the application. A non-persistent reliability level will always be faster than the persistent one. Be especially wary of the "top of the line" "assured delivery" level. In this mode WAS synchronously saves each and every message to the message store. If you're using a database to host the message store, this would result in a database hit for every message delivered to the destination.

Have a question about WebSphere JMS tuning/configuration? Please comment on this post. You may also be interested in other WAS-related articles on this site.

Need help with WebSphere or JMS? Interested in performance tuning or in implementing fully automated configuration management for your middleware? Consider our consulting services and get in touch.

There are basically three build tools that can replace Ant: Maven, gradle and Buildr.

It is important to be able to continue using existing Ant scripts and custom tasks alongside the new tool. There is a multitude of useful open-source custom Ant tasks and with Ant being a de-facto standard for years, many development shops built vast libraries of Ant scripts and custom tasks.

Out of all three, Gradle has the best integration with Ant. It allows for using existing custom Ant tasks pretty much without any changes. It also allows for importing Ant scripts into Gradle build script. Gradle tasks can even depend on Ant targets (and vice versa). There is also easy access to Ant properties.

The bottom line, for any Ant shop, there is really nothing to loose from migrating to gradle. The benefits though are substantial:

• Full power of Groovy
• Easy integration with Groovy and Java
• Built-in dependency management
• Plugin system

What about Buildr and Maven?

Buildr provides some integration with Ant but it's certainly not as sophisticated as gradle's. And Maven is simply not a scripting tool in the same way Ant or gradle are, it is declarative as opposed to procedural (there is, of course, a blurry line between these two characteristics -- gradle could be made quite "declarative-like" via the use of plugins and Maven allows for invoking Ant tasks in a "scripting" fashion). So migrating complex Ant build scripts to Maven could be quite a complicated affair oftentimes involving developing custom Maven plugins.

• Task for quiescing domains and objects. This task is able to wait for objects to go into the target state. This should be useful for fully automating "quiesce-import-unquiesce" deployment cycle.
• XPath-based transformation of DataPower configuration (or any XML file for that matter). This allows for creating environment-specific transformations of any complexity. Adding, deleting and updating elements is supported. Setting text in attributes and elements (similar to the current <a href="/datapower-deployment-policies-and-xpath"override feature of setConfig task) now supports expressions. E.g., if you wanted to add a prefix to the current server value in a load-balancing group, you could do this: <setText xpath="//LBGroupMembers/Server" expression="dev.+#currentValue"/>. All these features are supported for both import (including importing zip files) and copy tasks.
• Task for verifying operational state of objects. E.g., you may want to verify that all objects/services are in "UP" state after import.
• Integration of DataPower-related environment variables (e.g., a port number) with the prefix-based device definition, so all environment-specific properties could be defined in one place: dev.backend.port=9080, prod.backend.port=80.
• Task for downloading multiple files from the device
• Task for deleting DataPower objects, services and domains.
• Task for secure backup (execute secure backup and download the resulting file).
• Downloading of log files from the device.
• Improved error reporting for import and other tasks.

Stay tuned for more updates.

This will greatly simplify use of DataPower for development. For example, development and test instances can be implemented as VMs, whereas production could remain hardware appliance-based.

Hopefully, this will also lead to increased popularity of DataPower platform as it makes it easier for potential customers to try it out (will we see a trial version of DataPower?).

Here are the steps:

• Create an Eclipse project for DataPower artifacts. You can use "Generic" project for this.
• Create Ant "build.xml" in the root directory of your project and define a target for "dp:copy" task, for example:
  

  <target name="copy.files" >
      <property name="wsdl.dir" value="${basedir}/wsdl" />
      <dp:copy cleanDirectories="true"  >
  		<dpFileset prefix="${dp.wsdl.dir}" 
  			dir="wsdl" includes="**/*.xsd **/*.wsdl"/>
      </dp:copy>
  </target>
  

• Define custom builder for your project. Go to project properties, builders, New. Select Ant Builder. Point to your build.xml on the "main" tab. On the "targets" tab specify the name of your target:

You don't want to specify a target for "Auto Build" since in this case the Ant file will run every time you update any of the project's resources.

• Update any of the files, then go to Project/Build project. This will invoke the Ant file which will copy your resources to the target device. Note that Ant will run only if any of the resources changed. If you need to "force-run" any target, simply open build.xml and execute it from Eclipse (Alt+Shift+X, Q).
• If you need to work with multiple devices, define connection properties for all your devices using environment prefixes, e.g., "dev.dp.xmlmgm.url=https://9.59.97.79:5050", "test.dp.xmlmgm.url=https://9.59.97.80:5050". You can find more details on environment prefixes in DPBuddy documentation. You may want to specify all environment properties in a separate property file. Then go to the builder definition, properties, uncheck "Use global properties ..." and add "dp.env.prefix" property with the value for your current environment ("dev"). If later you want to point to a different device, simply update this property:

One of the most useful features is auto-complete for Ant tasks. Just press Ctrl-space and you'll see all attributes and nested elements supported by the task.

Auto-complete comes very handy when working with DPBuddy Ant tasks (and for developing WebSphere DataPower-related artifacts in general).

Just type '<dp:' (assuming that this is the prefix you assigned to DPBuddy's antlib) and then Ctrl-space and you'll see the list of all DPBuddy's tasks. Pressing Ctrl-space anywhere after the name of the task shows the list of attributes or nested elements.

Unfortunately, auto-complete won't display help for custom tasks. Apparently description of Ant tasks is embedded inside Eclipse and does not seem to be extendable.

SOMA "CreateDir" action errors out when it is used to re-create the RAID mount directory. In this release of dpbuddy logic was added to ignore the error.

The updated DPBuddy package can be downloaded from dpbuddy download page.

• Tasks for quiescing domains and objects. The task will be able to wait for domain or object to go into the quiesced state..
• DPBuddy's xpath-based alternative to deployment policy can be used with import and even with copying files. Currently this feature is only supported with setConfig task, whereas majority of dpbuddy users rely on import. In other words, you'll be able to apply a simple xpath expression to make environment-specific changes to your configuraiton or files.
• Integration of DataPower-related environment variables (e.g., a port number) with the prefix-based device definition.
• Task for downloading multiple files from the device
• Task for deleting configuration and domains.
• Task for secure backup (execute secure backup and download the resulting file).
• Automated downloading of the log file from the device in case of errors.
• Tasks for various device management "actions".

What else would you like to see in the new version? Please comment on this post or in our google group.