CHANGQING YE's WEBLOG

Have you seen the following exception when you run your application in Websphere application server?

“CWSIA0114E: The property JMS_IBM_MsgType should be set
using type java.lang.Integer, not java.lang.String.”

I do have such a problem. Why?

As we know JMS messages are composed of three pars on the JMS specification:
- Header
- Properties
- Body
Among them, Properties include Application-specific properties,Standard properties and Provider-specific properties.

Websphere MQ messages are composed of three parts:
- MQ Message Descriptor (MQMD)
- MQ MQRFH2 Header
- Body

From JMS message to MQ message or from MQ message to JMS message, the transformation is required. The transformation model is defined below:

The transformation is done in two approaches:

Mapping – where the MQMD includes a field that is equivalent to the JMS field, the JMS field is mapped onto the MQMD field. Additional MQMD fields are exposed as JMS properties, as a JMS application may need to get or set these fields when communicating with a non-JMS application.

Copying – where there is no MQMD equivalent, a JMS header field or property is passed, possibly transformed, as a field inside the MQRFH2.

In this case, mapping is not correct. The MQ specific property JMS_IBM_MsgType is integer type and has to be set as
JMSMessage.setIntProperty(“ JMS_IBM_MsgType”,some-valid-value)

In a message pass through use case, we need to copy inbound message properties to outbound message properties, we can check if inbound message is websphere message type using following approach:

if(inboundJMSMessage.getClass().getName().startsWith(" com.ibm.jms.JMS") ||
inboundMessage.getClass().getName().startsWith(" com.ibm.ws.sib.api.jms.impl.Jms"))

{
// do mapping and copying
}

More about Mapping JMS messages onto WebSphere MQ messages, refer to
http://www-306.ibm.com/software/integration/mqfamily/library/manualsa/csqzaw04/csqzaw2r.htm
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzaw.doc/csqzaw1481.htm

 

Java CAPS supports JDK 1.5. To run Java CAPS on JDK 1.6, we need to manually change the packaged JRE 1.5. Java CAPS includes several components which run on their own JRE environments. We take Logical-Host as a example. You can do as follows:

• Install logicalhost somewhere, for instance, C:\JavaCAPS\logicalhost

• Create domain1

• Rename C:\JavaCAPS\logicalhost\jre to C:\JavaCAPS\logicalhost\jre.old

• Download JDK 1.6 and install somewhere, for instance, C:\java

• Copy C:\java\jdk1.6.0\jre to C:\JavaCAPS\logicalhost\jre

• Copy C:\java\jdk1.6.0\lib\tools.jar to C:\JavaCAPS\logicalhost\jre\lib

• Copy C:\JavaCAPS\logicalhost\jre\bin\javaw.exe to C:\JavaCAPS\logicalhost\jre\bin\is_domain1.exe

• Copy C:\JavaCAPS\logicalhost\jre\bin\javaw.exe to C:\JavaCAPS\logicalhost\jre\bin\isprocmgr_domain1.exe

• Change C:\JavaCAPS\logicalhost\is\domains\domain1\config\domain1.xml as a workaround:

<!--

<jvm-options>

-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

</jvm-options>

-->

• Start domain1

• Deploy projects into domain1 and projects should run fine.

There are some unsolved issues. For instance, if we do not comment out:

<jvm-options>

-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

</jvm-options>

The following exception will be thrown while the projects created by Java CAPS get deployed:

Caused by: java.lang.NoSuchMethodError: org.w3c.dom.Document.getXmlStandalone()Z at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.setDocumentInfo(DOM2TO.java:373) at com.sun.org.ap|#]

Both JDK 1.5 and JDK 1.6 support DOM Level 3 compliant coding. Why does the project not work with JDK 1.6? These issues will be solved later.

I have been thinking about some use cases in telecommunication or VOIP network which can be used by CAPS or OpenESB recently. It is a very thing if two types of applications can be merged and integrated together. I worked for telecommunication and VOIP network for years. Based on my experience, it seems that we can do lots. Even I have been thinking that we may recreate billing system based on CAPS and OpenESB technologies. But it is not easy to get some concrete use cases if you leave that domain for that long. I need to refresh my memory. One that I am interested is SNMP. I am writting down thoughts which can be discussed in detail later.

Simple Network Management Protocol (SNMP) is an industry standard for network management. The SNMP network consists of managed devices, managers and agents. A managed device is a network node which contains an SNMP agent resides in a managed network.

The managed devices collect and store management information which is accessible from SNMP managers.  The managed devices can be routers, access servers, switches, bridges, hubs, computer hosts, etc. The managed devices can be hardware or software components. An agent is an SNMP module that resides in a managed device. The agent has local information about the managed device. A manager is an SNMP module that monitor and control managed devices via using SNMP commands, for instance, GET, GET-NEXT, GET-RESPONSE, SET and TRAP. (note: TRAP is a special command which is sent asynchronously by a agent to manager as some event reporting). Both the manager and agent use a management information base (MIB) to define and collect information on managed devices.

As we know that Sun Java Composite Application Platform Suite (CAPS) is J2EE-based enterprise integration suite which is used to develop and deploy SOA platform. And the Open ESB is to implement an enterprise service bus (ESB) runtime using Java Business Integration which allows you to easily integrate enterprise applications and web services.

The question is that how CAPS and OpenESB can be fitted into SNMP network?

CAPS already offers SNMP agent eWay to allow you to forward CAPS alerts to the third-party SNMP management system. All CAPS’ modules, for instance, Integration Servers, Messaging Servers, eWays, Collaborations, can be monitored and controlled. You can use the CAPS SNMP agent to get a list of properties of CAPS application servers and project components and start/stop/restart project components.

If CAPS provides SNMP manager eWay, many existing agents or legacy agents can be managed and monitored through SNMP GET and SET protocols. More complicated applications can be created using web services or collaborations which are provided by CAPS. CAPS needs to provide a way to import the SNMP agent MIB.

SNMP BC can be added into OpenESB, SNMP BC can be acting a SNMP agent or SNMP manager, just like what CAPS does. But acting as a SNMP manager will be more useful for telecommunication or VOIP network and the SNMP manager BC will be used for managing and controlling agents which are running on the SNMP network.  All the controlling and managing functionality can be done by business process.

Overview

Several years ago we started building C++ or C applications on various UNIX platforms using default 32-bit mode and we ran Java applications in 32-bit JVM environments without need of considering 64-bit options. Now we have many options: Do I compile C++ or C applications in 64-bit objects or 32-bit objects? Do I run my 32-bit applications in 64-bit computing environments or in 32-bit computing environments? What 64-bit options do I need to run Java applications? What benefits or performance do I gain to port 32-bit applications to 64-bit objects? All these questions become valid.

Fundamental Benefit of 64-bit Computing

The memory addressing of 16-bit computing is 64KB, and the memory addressing of 32-bit computing is increased to 4GB. Running out of addressing space is a traditional difficulty in computing and in many large data processing, even 4GB is still very limiting. Then how large is the memory addressing of 64-bit computing? It is 16 exabytes. It gets pass 4GB barrier and will take a long time to run out of addressing space in 64-bit computing.

The fundamental architecture of hardware from 32-bit to 64-bit is changed. The operation systems has to be modified to take advantage of the 64-bit computing architecture. However usually most applications are still 32-bit, the operating systems for these 64-bit architectures still support both 32-bit and 64-bit applications. Some operating systems can start with 32-bit mode kernel which allows to run 32-bit applications only.

There are debate on whether 64-bit computing is better than 32-bit computing if the memory addressing is not more than 4GB. And also there are some cases that some 64-bit applications would not gain any benefits from 64-bit architecture from performance point of view. All these issues will not in the scope of discussion.

General Differences Between Building 32-bit Applications and 64-bit Applications

▪ Data Types

32-bit and 64-bit computing base on two data models: ILP32 is for 32-bit and LP64 is for 64-bit. The differences in size of data types of two data models are one of primarily concerns of building 64-bit applications or porting 32-bit applications to 64-bit applications. The table below lists the basic C types and their corresponding sizes in bits.

C Data Type	ILP32	LP64
char	8	8
short	16	16
int	32	32
long	32	64
long long	64	64
pointer	32	64
enum	32	32
float	32	32
double	64	64
long double	128	128

We can not assume that above data type sizes are always true by default for all compilers on various UNIX platforms. There are some exceptions, for instance,on AIX 5.x if you use VisualAge C++ / C v6.0 compiler long double is 64 bit by default. When compiled with ldbl128 option, long double is increased to 128 bit. And long long integers is allowed when compiled with longlong flag. On other platforms, for instance, Red Hat Linux AS 3 for AMD 64, Solaris 8, 9 and 10 for Sparc, Solaris 10 for AMD64, HP-UX 11, 11i for PA-RISC, HP-UX 11i for Itanium, Tru64 UNIX 5.1A, if you use compilers that came with operating systems, the above data models are true by default. But it is always suggested to check with your compiler user guide first.

▪ Data Alignment

Aligning data on certain boundaries within memory is good a choice when handling data structures in some scenarios. But data alignment may be affected when a program is ported from 32-bit to 64-bit. Different alignment options may be chosen.

▪ Endian Dependencies

Bytes ordering in memory is platform-specific. Different platform architecture chooses different endianness, either big-endian or little-endian.

Arch	i386	alpha	amd64	X86-64	Solaris Sparc	Tru64	HP PA_RISC	HP Itanium	AIX
Endianness	Little-endian	Little-endian	Little-endian	Little-endian	Big-endian	Big-endian	Big-endian	Big-endian	Big-endian

▪ Exchanging Data Between 32-bit Applications and 64-bit Applications

64-bit applications get 64-bit values from operating for many parameters; 32-bit applications have 32-bit values from operating. It will cause inconsistency in many scenarios. For instance, socket invocation, shared memory, memory-mapped file.

▪ Compiler Options

C++ and C compiler on all 64-bit UNIX platforms offer various 64-bit compiler options. If these options are not set or enabled, some compilers generate 32-bit objects by default. The some basic 64-bit compilation and link flags for some platforms are listed below. But I suggest to consult compiler user manual to choose compilation and link options for the performance of the applications.

64-bit compilation options for various platforms

Platform	Compiler	basic 64-bit compilation and link options
RedHat AS 3 for AMD64	GCC 3.2.3	-m64, -march=k8, -mtune=k8
Solaris 8 and 9	Forte Developer 7 C++ 5.4	-xtarget=generic64,-xarch=v9
HP-UX 11, 11i For PA_RISC	aCC HP ANSI C++ 3.37	+DA2.0W, +DD64
HP-UX11.22 for Itanium	ACC HP aC++/ANSI C 5.52	+DA2.0W, +Dsitanium,+DD64,-AA
AIX 5.1 and AIX 5.2	VisualAge C++ / C v6.0	__AIX64__, -q64, -qldbl128
Solaris 10 for AMD64	Sun C++ 5.7	--xtarget=opteron, xarch=amd64
Tru64 UNIX 5.1A	Compaq C++ V 6.5	No flag needs to generate 64-bit objects

▪ System Libraries

32-bit applications are required to link with 32-bit libraries, and 64-bit applications are required to link with 64-bit libraries. The 64-bit operating systems provide both 32-bit and 64-bit systems libraries. The locations are platform-specific. On Solaris 5.9 for sparc, 32-bit system libraries are located under /usr/lib and 64-bit libraries are under /usr/lib/64. You can find them from your application link path also. On Red Hat Linux for AMD64, 2-bit system libraries are located under /usr/lib and /lib and 64-bit libraries are under /usr/lib64 and /lib64.

Command questions and Frequently-Used Commands

When work on various UNIX platforms, always there are lots of questions, following questions are commands for the answers, for instance,

▪ Is the Operation System kernel is 32-bit or 64-bit?

On Solaris 7, 8, 9 and 10, isainfo -v tells whether 64-bit application objects are supported, or whether the operating system kernel is running 32-bit or 64-bit. This command does not work Solaris 6 or early version.

On HP-UX 11, 11i, getconf KERNEL_BITS; on HP-UX 11.22 for Itanium, getconf SC_KERNEL_BITS

On AIX 5.1, 5.2, isconf -k or bootinfo -K or lslpp -h bos.rte

▪ Is your application binary 32-bit or 64-bit?

On Solaris 7, 8, 9 and 10, use file command to verify whether the application is ELF 64-bit or ELF 32-bit.

On AIX 5.1, AIX 5.2, use file command verify whether the application is 64-bit or 32-bit.

More questions can be:

▪ How to get CPU information?

▪ What to get Operation System information?

▪ What is the application's libraries link path?

▪ and more for runtime

These questions can be answers by various commands, but commands are sometimes platform-specific.

Some Resources Links

Solaris 64-bit Developer's Guide

HP-UX 64-bit porting concepts

AIX 5L Porting Guide

amd64 developer tools & porting documentation