Tuesday February 19, 2008 MA0Y: IBM WebSphere MQ Bridge for HTTP - v1.1
HTTP interface for WebSphere MQ (WMQ) is a new feature that allows client applications to connect to a queue manager using the HTTP protocol. The first version of this support pac was released in June 2007.
We are now excited to announce the release of version 1.1 of WebSphere MQ Bridge for HTTP. Please visit http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24016142&loc=en_US&cs=utf-8&lang=en for more information.
What is new in this release:
Mithun V Katti
IBM India Software Labs
Tuesday January 29, 2008 Messaging Service Client for C/C++
A new version of Message Service Client for C/C++ (XMS for C/C++) is released. Have a look at the announcement page here.
I am always open to new technology and offerings. With windows 64 operating system making its presence in the desktop arena, there is scope for lot of opportunities. XMS being a worthy alternative to JMS in non-Java world, it is quite natural to expect XMS on windows 64. Yes, a new version of XMS for C/C++ (Message Service Client for C/C++) is now available.
What's new in Version 1.2.7 ?
# Support for windows 64 bit platform# Support for WebSphere Enterprise Service Bus v6.1 & WebSphere Process Server v6.1
Keep pace with technology !!!
Harsha
Harsha[DOT]mp[AT]in[DOT]ibm[DOT]com
Monday January 28, 2008 Filtering out the messages in the micro broker bridge
Message filtering is a pretty popular concept and when seen from a pervasive messaging perspective it can be to filter out all the unwanted messages entering the enterprise servers (like MQ). Message can is filtered based on lots of parameters. One may wish to filter the messages based on content or some property in the header, etc.Here's a small trick to achieve message filtering in micro broker bridge. Here we filter out messages based on the topic at which the message arrives. For example if there are messages arriving at the topic "in/unwantedtopic" let's filter that out and allow messages on other topics like "in/topic", etc to pass through.
1. Create a micro broker and create a pipe to MQ
Bridge bridge = broker.getBridge();
MQJMSConnectionDefinition mqjmsconn = bridge.createMQJMSConnectionDefinition("MQConn");
mqjmsconn.setPort(1414);
mqjmsconn.setHost("MQHOSTNAME");
2. Create a out bound flow with source in/#.
FlowDefinition outFlow = bridge.createFlowDefinition("OutFlow");
outFlow.setSources(new TopicDefinition[]{bridge.createTopicDefinition("in/#")});
outFlow.setTarget(bridge.createTopicDefinition("out/topic"));
3. Now let's filter out all the messages that are published under "in/unwantedTopic" and let others pass through. For this we need to create a transformation. Here's the example:
public class MessageFilterFactory extends AbstractTransformationFactory{
public Transformation getTransformation() {
return new MessageFilter();
}
public String getName() {
return MessageFilter.class.getName();
}
}
class MessageFilter extends Transformation {
public BridgeMessage doTransformation(BridgeMessage input) throws BridgeException {
BridgeDestination sourceDest = input.getSource();
String sourceTopicName = sourceDest.getName();
if(sourceTopicName.equals("in/unwantedTopic")) {
return null;
}
else {
return input;
}
}
public void initialise() throws BridgeException {
//Do nothing
}
}
4. Now set the transformation created above to the flow
MessageFilterFactory mtf = new MessageFilterFactory();
TransformationRegistry.INSTANCE.registerTransformationFactory(mtf);
TransformationDefinition td = bridge.createTransformationDefinition("myTD");;
td.setClassName("test.jndibridge.MessageFilter");
TransformationDefinitionList tdl = bridge.createTransformationDefinitionList();
tdl.addTransformation(td);
outFlow.setTransformations(tdl);
Connect the micro broker client and you'll see the messages getting filtered. Refer to the information center for a detailed description: http://publib.boulder.ibm.com/infocenter/ledoc/v6r11/topic/com.ibm.rcp.tools.doc.microbroker/ovr11660.html
From: Neeraj Krishna & Vijay ( Jan 28 2008, 12:02:25 AM EST ) Permalink Comments [2]
Sunday January 27, 2008 Registering the transformations in micro broker bridge
Transformations can be either be a part of the project that configures the bridge or in a different client services project. If written in a different project the transformation package has to be exported in the manifest file so that the micro broker bridge can access that. In any case transformation factory needs to be transformation registry. When the pipe starts and a transformation is set on any one of the flows or the pipe itself, it queries the transformation registry and checks if the transformation factory is registered. When the broker automatically starts often you will see the log message:2621=Pipe
Here are small tricks to avoid it:
When the broker factory service is registered, the transformation factory needs to be registered with the Transformation registry. This can't be done remotely using remote administration.
Here is an example:
HelloTransFact mtf = new HelloTransFact();
TransformationRegistry.INSTANCE.registerTransformationFactory(mtf);
Once this is the done the pipe will be able to connect to the remote end. Its works well when done soon after the broker factory service get registered.
Here is pseudo code for broker start up:
addingService(reference) {
brokerFactoryService = (BrokerFactory)bundleContext.getService(reference);
if (!brokerFactoryService.exists(brokerName)) {
Create and start a new broker
}
else {
Broker already exists
HelloTransFact mtf = new HelloTransFact();
TransformationRegistry.INSTANCE.registerTransformationFactory(mtf);
}
}
In the above method you will observe that the broker will be waiting for the transformation to be available after printing 2621 log message. The pipe starts only when the transformation is registered. To avoid the log message, you can use setAutoStartEnabled(false) on the broker definition. This implies that only the broker factory service get registered and the broker will not start. Hence you can register the transformation and then manually start the broker.
Here is the pseudo code for this:
addingService(reference) {
brokerFactoryService = (BrokerFactory)bundleContext.getService(reference);
if (!brokerFactoryService.exists(brokerName)) {
Create the broker definition
brokerDef.setAutoStartEnabled(false);
Register the transformation
TransformationRegistry.INSTANCE.registerTransformationFactory(mtf);
LocalBroker lb = brokerFactoryService.getByName(brokerName);
Start the broker
}
else {
Broker already exists
HelloTransFact mtf = new HelloTransFact();
TransformationRegistry.INSTANCE.registerTransformationFactory(mtf);
LocalBroker lb = brokerFactoryService.getByName(brokerName);
lb.start();
}
}
More details on transformations is available in the updated information center page .
From Neeraj Krishna and Vijay ( Jan 27 2008, 11:45:00 PM EST ) Permalink Comments [2]
Monday January 21, 2008 Micro broker Information center
Here's the micro broker information center (documentation) . It has only micro broker information and excludes Lotus expeditor info. It gives you the javadoc for MQTT, micro broker administration and transformation. The complete Lotus Expeditor information center can be accessed over the web here.From: Neeraj Krishna & Vijay ( Jan 21 2008, 03:04:31 AM EST ) Permalink Comments [0]
Tuesday January 08, 2008 Links to developer works resources on IBM messaging products
Here are the links for forums, community spaces and feature pages:For links to new releases, articles, and many interesting things in the IBM messaging space visit: Messaging community space
WebSphere MQ
WebSphere Message BrokerLotus Expeditor Micro broker
WebSphere MQ everyplace
( Jan 08 2008, 12:26:05 AM EST ) Permalink Comments [0]
Simplest micro broker JMS client
If you want to quickly get started with writing a micro broker JMS client and connecting to a micro broker, here's how you do it.JmsFactoryFactory is your entry point into the JMS implementation classes. You need to add com.ibm.msg.client.jms and com.ibm.msg.client.mqtt as imports along with javax.jms in the manifest.
Get started with creating a connection factory like this
JmsFactoryFactory jmsFactory = JmsFactoryFactory
.getInstance(MQTTConstants.PROVIDER_NAME);
JMS 1.1 simplifies messaging with unified domains and hence you just need to create a connection factory and use it for both topics and queues
ConnectionFactory connFactory = jmsFactory.createConnectionFactory();
Now set the URI telling the factory how to connect to the server
((JmsConnectionFactory) connFactory).setStringProperty(
MQTTConstants.MQTT_CONNECTION_URL,
MQTTConstants.MQTT_TCP_SCHEMA + "127.0.0.1:1883");
From here you can go ahead creating a connection (don't forget to set the clientID as this is unique for each client) and a session and the other JMS objects as required.... Full example is given in this article in listing 2.
Regards,
Neeraj Krishna & Vijay
( Jan 08 2008, 12:03:49 AM EST )
Permalink
Comments [0]
Monday January 07, 2008 Micro broker logs
If you are working on Lotus Expeditor, you would have probably figured out how to see INFO level logs for particular bundle. For micro broker also you can increase the logging levels the same way Here are 6 simple commands that can be used in the XPD console for you to see all the micro broker logs at INFO level.setlogrlev com.ibm.micro INFO
setlogrlev com.ibm.micro.bridge.jndi.jms INFO
setlogrlev com.ibm.micro.bridge.mq.jms INFO
setlogrlev com.ibm.mqttclient INFO
setlogrlev com.ibm.micro.utils INFO
setlogrlev com.ibm.mqttclient.jms INFO
There are other ways of setting the logging levels. Its documented here
Regards,
Neeraj Krishna and Vijay
( Jan 07 2008, 10:45:02 PM EST )
Permalink
Comments [0]
Sunday January 06, 2008 Micro broker bundles
If you see Lotus Expeditor installation, you'll see many bundles, Here your guide to identifying the micro broker related bundles.- com.ibm.micro.bridge.mq.jms_XXX.jar or package com.ibm.micro.bridge.mq.jms contains the classes that you need for connecting to WebSphere MQ using MQJMSConnectionDefinition from the micro broker bridge
- com.ibm.micro.bridge.jndi.jms_XXX.jar or package com.ibm.micro.bridge.jndi.jms contains the classes required for the miro broker bridge to connect to a JNDI enabled JMS provider using JNDIConnectionDefinition.
- com.ibm.micro.gettingstarted_XXX.jar contains sample broker. If deployed and started, it runs a broker at port 1883
- com.ibm.micro_XXX.jar This contains all the micro broker core classes
- com.ibm.micro.utils_XXX.jar This contains all the utility classes that are needed by the core micro broker
- com.ibm.mqttclient.jms_XXXX.jar This contains all the classes that are needed for a micro broker JMS client
- com.ibm.mqttclient_XXX.jar This contains the classes needed fot a normal MQTT java client
- Bundles ending with nl1, nl2, nl3 are fragments that are needed for NLS support.
If your deploying on a device, you can install only the required jars in the device environment. For example, com.ibm.mqttclient_XXX.jar is enough if you are running a MQTT client only, if you are running a micro broker with a MQTT bridge only the core bundles com.ibm.micro_XXX.jar and com.ibm.micro.utils_XXX.jar are sufficient.
Regards,
Neeraj Krishna and Vijay
( Jan 06 2008, 09:15:46 AM EST )
Permalink
Comments [0]
Saturday January 05, 2008 Using the Expeditor's JNDi feature in micro broker bridge to MQ
Here's is a simple tip to help you bind the MQ objects to the JNDI repository of Lotus Expeditor.
Here we use the programmatic JNDI feature. The Lotus Expeditor's initial context is com.ibm.pvc.jndi.provider.java.InitialContextFactory.
Let's start with creating the initial context
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.pvc.jndi.provider.java.InitialContextFactory");
InitialContext context = new InitialContext(env);
Follow the instruction in this documentation link so that we can use the MQ JMS objects in our code.
Here how you can bind a MQ queue.
MQQueue mqQueue = new MQQueue();
mqQueue.setBaseQueueName("MQQUEUE");
context.bind("jms/MQQUEUE", mqQueue);
Similar you can bind the MQ Connection factory
MQConnectionFactory connectionFactory = new MQConnectionFactory();
connectionFactory.setHostName("127.0.0.1"); //Replace with correct IP address
connectionFactory.setPort(1414); //Replace with correct port
connectionFactory.setTransportType(JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);
context.bind("jms/MQConnFact", connectionFactory);
Once all the required objects are bound, you can use it in the JNDIConnectionDefinition :
JNDIConnectionDefinition connDef = bridge.createJNDIConnectionDefinition("MQXPDConnection");
connDef.setInitialContext("com.ibm.pvc.jndi.provider.java.InitialContextFactory");
connDef.setConnectionFactoryKey("jms/MQConnFact");
connDef.setDeadLetterKey("jms/dlq");
connDef.setSyncQKey("jms/syncq");
connDef.setURL("local");
Whenever MQJMSConnectionDefinition or JNDIConnectionDefinition is created to WebSphere MQ, you'll observe that the messages that reach MQ are JMS messages. Here's a small tweak that can make the micro broker bridge to send normal MQ messages instead of JMS messages.
When binding the MQ queue to the JNDI initial context, set the target client like this mqQueue.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ)
Regards,
Neeraj Krishna and Vijay
( Jan 05 2008, 01:11:44 AM EST )
Permalink
Comments [0]
Wednesday December 19, 2007 Singling out CLNTCONN channels
Client channel definition tables, or CCDTs for short, are convenient ways for the client to read channel definitions. A CCDT file contains all CLNTCONN channel definitions of a particular queue manager.So, how does a client using a CCDT know which channel to use ?
The answer lies in the way the CCDT itself is written by the queue manager. The queue manager writes channel definitions on to the CCDT file in alphabetical order. So, the client picks up the first channel whose QMNAME parameter matches with the queue manager name parameter of the MQCONN (or MQCONNX) call. In the event there are more than one channel definitions that have matching QMNAME parameters, simply the first one encountered is used. This serves as an extremely useful mechanism to initiate fail-over.
Click here to understand how a queue manager interprets a CCDT
Arriving to the focus of this post - how does one deliberately make use of a channel that is lower down in the alphabetical list of channel names ?
Wildcards - are the answer. The queue manager name passed to MQCONN(X) can have the wildcard character *, in which case, any channel with a matching QMNAME parameter is picked up.
The twist in the story, however, lies in the fact that neither the name of the queue manager passed to MQCONN(X) nor the QMNAME parameter need to have the actual name of the queue manager ! If your head is reeling at this moment, take time to peruse through this example.
Our queue manager, say QM1 has 2 CLNTCONN channels viz. ALPHA.CLNTCONN and BETA.CLNTCONN. The idea is to make use of BETA.CLNTCONN bypassing ALPHA.CLNTCONN.
Modify QMNAME of BETA.CLNTCONN to a dummy queue manager name, say, NOQM
i.e. ALTER CHL(BETA.CLNTCONN) CHLTYPE(CLNTCONN) QMNAME(NOQM)
Allow the client to do an MQCONN(X) in the fashion MQCONN("NO*", . . . )
and voila ! BETA.SVRCONN is being used.
( Dec 19 2007, 09:06:45 AM EST )
Permalink
Comments [1]
Wednesday November 28, 2007 New Enhanced Version of Message Broker V6 : Release 1
In the realm of Messaging Products, a new version of Message Broker is released. Have a look at the announcement letter here.
I was always curious to watch something new in Message Broker, not only that I work on it, but, the fact of the NEW Message Broker supporting a new variety of Nodes. The new set of nodes supports the ERP applications, the High Performance XML Parser, the enhanced support to WebService, are something to watch for.
What’s new in Version 6.1?
- Extended platform and operating system support for runtime environments
- New WebSphere Adapters nodes
- Ability to process data in files
- New EmailOutput node
- New Collector node
- New Route node
- New DatabaseRoute node
- New DatabaseRetrieve node
- Enhancements to the XSLTransform node
- Ability to browse WebSphere MQ messages
- New and enhanced Web services support (including new SOAP nodes)
- New and enhanced message domains and parsers
- Enhancements to message sets
- Node Properties view
- New security manager
- Using databases in the Message Broker Toolkit
- Calling a Java method from a mapping node
- Switching Trace nodes off
- XPath expressions
All documentation for this new release could be found here.
Have Fun !!!
IBM-Messaging-Evangelists ( Nov 28 2007, 03:00:22 AM EST ) Permalink Comments [0]
Tuesday November 20, 2007 Lotus Expeditor micro broker
If you are wondering how to extend your ESB to the small devices like PDAs, Smartphones, sensors etc.... you have reached the right place. This is where you enter the pervasive world and pervasive messaging enables flow of information between your device world and enterprise world.Louis V. Gerstner described pervasive computing as "a billion people interacting with a million e-businesses with a trillion intelligent devices, all interconnected…". Now we live in a world where there are lots of messaging media, such as cell phones, voice mail, e-mail and fax. Pervasive messaging is all about linking these remote devices to back-end systems. Now for IBM, pervasive messaging is about the middleware software that makes it easy to connect remote devices. So what would this middleware in this context do? - It just means that you don't need to worry about getting the data from device to enterprise( and back the other way) - that bit is done for you.
If you have started thinking, what product suites the pervasive messaging, its micro broker. Its shipped as bundles along with product Lotus Expeditor. Developer works has lots of resources for you to get started : http://www.ibm.com/developerworks/lotus/products/expeditor/
Looking at standards, we have MQTT ( MQ Telemetry Transport). You can read more about it in htpp://www.mqtt.org . In short its a light weight publish/subscribe messaging protocol over TCP/IP ... We'll talk more about this in our future blogs also.
In micro broker version 2.1.x, support for JMS Point to Point, Transmission Control, etc are announced. ( Nov 20 2007, 12:40:11 AM EST ) Permalink Comments [0]
Monday November 19, 2007 Welcome to the IBMers' Blog on Messaging
The first post of a Blog - irrespective of the subject in question, is as intriguing and challenging as publishing your first Best-seller.
Audience a warm welcome to 'The IBMers' Blog on Messaging '
'The IBMers' Blog on Messaging ', is our next entity, post to 'The developerWorks Space on Messaging'.
This portmanteau of weblog is dedicated to IBM Messaging products, viz. WebSphere MQ, WebSphere Message Broker ,WebSphere MQ Everyplace, & Lotus Expeditor micro broker.
Moving further we would have write-ups, work-arounds, discussions, problems–solutions and compositions pertaining to these Messaging products.
As a reader your comments & suggestions are valuable to us. And if you are interested in publishing a post, please connect with any of these:
Akhila S
Neeraj Krishna
Pranavaditya K
Rahul Gupta
Srihari Kulkarni
Vijay Raj
or
Simply write to us at msgevangelists-AT-googlegroups-DOT-com
Thanks,
IBM-Messaging-Evangelists