Using TIBCO Silver Mobile with TIBCO Web Messaging

Every company has or it's planning to have a mobile app these days and among other top priorities like Social, Event Processing, Analytics and Cloud, Mobility is a hot topic for CIOs looking for how they can change the game and put on their internal and external consumers' fingertips the right information at the right time with the right context. Not only that requirement but also how to capture, sense, act and respond to business events and notify mobile users of actions they need to take or what just happened that's so important to them.

Sometimes, there is a big disconnection between the "App" and all the backend systems that really do all the heavy lifting.

Integrating those two distinct worlds is getting easier primarily because of technologies like TIBCO Silver Mobile and TIBCO Web Messaging. Those product already have their huge value attached to their capabilities but when you combine them then the value brought to the table is extreme. 

TIBCO Silver Mobile is an open mobile development application platform (MDAP) that lets you build and manage mobile apps and create your own secure enterprise app portal. The platform lets you leverage whatever investments you've made in back-end automation infrastructure, whether from TIBCO or another provider.

Some of the Silver Mobile benefits are:

- Helps decrease mobile application development time and cost with a cross-platform, write-once environment and simplified Java and HTML5 back-end integration capabilities
- Lets you easily build onto your web application code base and add provisions for using pictures, video, contacts, and other data collected by mobile workers to mobile applications
- Deploys mobile apps securely on your own mobile app portal using your existing security standards and controls access to app downloads and the information available through them
- Supports Android, iOS, and others – and provides a familiar mobile app download process
- Gives front-line mobile workers access to the full resources of the enterprise by letting them access and contribute information in real time

You can download TIBCO Silver Mobile from the TIBCO Access Point (TAP) here: http://tap.tibco.com/storefront/trialware/tibco-silver-mobile/prod15310.html

On the other hand, TIBCO Web Messaging overcomes traditional HTTP-based web architectures that simply don't provide the real-time, bidirectional communication that today's new applications and services demand by using HTML5 WebSocket.

Some of the Web Messaging benefits are:

- Build compelling real-time applications using the new HTML5 WebSocket standard for low-latency web communication with a fraction of the overhead of existing web architectures.
- Use HTML5 API for Java Message Service, support legacy browsers, and natively integrate TIBCO EMS for faster and at less costly web and mobile application development.
- Don't sacrifice enterprise readiness to get next-generation web services with TIBCO Enterprise Message Service integration, enhanced security, and connection offloading.
- Natively integrate with TIBCO Enterprise Message Service to extend the reach of enterprise IT infrastructures through asynchronous or synchronous communication.
- Provide real-time full-duplex communication for web applications with HTML5 WebSocket at a fraction of the overhead of existing web architectures.
- Simplify application development for multiple client platforms with a JMS-client API familiar to enterprise developers.

In conclusion, combining these two powerful technologies give the business users not only full access to the information they need at any time and any place but also leverage the resources your company already invested on.

An Introduction to STOMP

STOMP (Simple (or Streaming) Text-Oriented Messaging Protocol) is a simple text-oriented protocol, similar to HTTP.

STOMP provides an interoperable wire format that allows clients to communicate with almost every available message broker. STOMP is easy to implement and gives you flexibility since it is language-agnostic, meaning clients and brokers developed in different languages can send and receive messages to and from each other. 

There are lots of server implementations that support STOMP (mostly compliant with the STOMP 1.0 specification). The following is a list of STOMP 1.0 compliant message servers:

• Apache ActiveMQ – http://activemq.apache.org

• Apache Apollo – http://activemq.apache.org/apollo

• CoilMQ – http://code.google.com/p/coilmq

• Gozirra - http://www.germane-software.com/software/Java/Gozirra

• HornetQ – http://www.jboss.com/hornetq

• MorbidQ – http://www.morbidq.com

• RabbitMQ - http://www.rabbitmq.com/plugins.html#rabbitmq-stomp

• Sprinkle - http://www.thuswise.org/sprinkle/index.html

• StompServer - http://stompserver.rubyforge.org/

On the client side, there are many implementations for a vast number of technologies. Below, you will find the libraries available for the most popular languages.

Language	Libraries
C	libstomp - http://stomp.codehaus.org/C
C++	Apache CMS - http://activemq.apache.org/cms/
C# and .Net	Apache NMS - http://activemq.apache.org/nms/
Flash	as3-stomp - http://code.google.com/p/as3-stomp/
Java	Gozirra - http://www.germane-software.com/software/Java/Gozirra/
Objective-C	objc-stomp - https://github.com/juretta/objc-stomp
Perl	Net::Stomp::Client - http://search.cpan.org/dist/Net-STOMP-Client/ Net::Stomp - http://search.cpan.org/dist/Net-Stomp/
PHP	stomp - http://www.php.net/manual/en/book.stomp.php stomp-php - http://stomp.fusesource.org/documentation/php/book.html
Python	stomper - http://code.google.com/p/stomper/ stomp.py - http://code.google.com/p/stomppy/
Ruby on Rails	stomp gem - https://rubygems.org/gems/stomp  activemessaging - http://code.google.com/p/activemessaging/

STOMP is an alternative to other open messaging protocols such as AMQP (Advanced Message Queueing Protocol) and implementation specific wire protocols used in JMS (Java Message Service) brokers such as OpenWire. It distinguishes itself by covering a small subset of commonly used messaging operations (commands) rather than providing a comprehensive messaging API. 

Because STOMP is language-agnostic and easy to implement, it’s popular to application developers and technical architects alike. STOMP is also text-based. Since it does not use binary protocols like other message brokers, a wide range of client technologies work with STOMP, like Ruby, Python, and Perl.

STOMP is simple to implement, but supports a wide range of core enterprise messaging features, such as authentication, messaging models (point to point and publish and subscribe), message acknowledgement, transactions, message headers and properties, etc.

It's not lack of content...

We all have that excuse of no time for blogging or lack of interesting content for not updating our tech-y blogs but in fact there are tons of interesting things that I'm working on right now like a JDBC over WebSocket project which seems to be a really nice thing to do and also an end-to-end prototype that we at Kaazing put together for an airline company.

Basically, the airline use case goes from backend JMS-based systems to mobile devices over WebSocket using Kaazing WebSocket Gateway JMS Edition notifying the users about gate changes and flight cancellations. You gotta see this in action! It's super cool... Since it has some proprietary systems I won't be able to show you all parts but I've been working on a generic version of it where you can install all the pieces in your machine and run the whole thing locally. Ping me if you want to take a look on that.

The other project that I'm working on is the JDBC over WebSocket which basically uses Kaazing WebSocket Gateway HTML5 Edition to connect to an Apache Camel route with a Mina component and JDBC access to a MySQL database. Everything is pretty straightforward and I'll be writing a tutorial on that in the near future. But, if you need any additional info or sample code just let me know and I'll walk you thru whatever is needed to get you going...

Stay tuned!

How to Setup RabbitMQ Message Broker with Kaazing WebSocket Gateway - AMQP Edition

If you want to try the Kaazing WebSocket Gateway - AMQP Edition with RabbitMQ, take a look on the following steps...

If you are trying this setup on a Mac, make sure you have Erlang already installed otherwise have a look on my previous post on How to Install Erlang on Mac OS X Snow Leopard.

Install RabbitMQ


- Download RabbitMQ from http://www.rabbitmq.com/download.html

- Extract the file to the desired directory

- Navigate to RabbitMQ installation directory and run the following command:

$ sbin/rabbitmq-server

If RabbitMQ is started correctly you should see a message similar to the following:

Activating RabbitMQ plugins ...

********************************************************************************
********************************************************************************

0 plugins activated:


+---+   +---+
|   |   |   |
|   |   |   |
|   |   |   |
|   +---+   +-------+
|                   |
| RabbitMQ  +---+   |
|           |   |   |
|   v2.7.1  +---+   |
|                   |
+-------------------+
AMQP 0-9-1 / 0-9 / 0-8
Copyright (C) 2007-2011 VMware, Inc.
Licensed under the MPL.  See http://www.rabbitmq.com/

node           : rabbit@yoda
app descriptor : /Applications/Kaazing/kaazing-websocket-gateway-amqp-3.2.0/rabbitmq_server-2.7.1/sbin/../ebin/rabbit.app
home dir       : /Users/Marcelo
config file(s) : (none)
cookie hash    : AYkkciNJ6lsr2dyADBN8ww==
log            : /Applications/Kaazing/kaazing-websocket-gateway-amqp-3.2.0/rabbitmq_server-2.7.1/work/rabbitmq/rabbit@yoda.log
sasl log       : /Applications/Kaazing/kaazing-websocket-gateway-amqp-3.2.0/rabbitmq_server-2.7.1/work/rabbitmq/rabbit@yoda-sasl.log
database dir   : /Applications/Kaazing/kaazing-websocket-gateway-amqp-3.2.0/rabbitmq_server-2.7.1/work/rabbitmq/mnesia/rabbit@yoda
erlang version : 5.9

-- rabbit boot start
starting file handle cache server                     ...done
starting worker pool                                  ...done
starting database                                     ...done
starting codec correctness check                      ...done
-- external infrastructure ready
starting plugin registry                              ...done
starting auth mechanism cr-demo                       ...done
starting auth mechanism amqplain                      ...done
starting auth mechanism plain                         ...done
starting statistics event manage                      ...done
starting logging server                               ...done
starting exchange type direct                         ...done
starting exchange type fanout                         ...done
starting exchange type headers                        ...done
starting exchange type topic                          ...done
-- kernel ready
starting alarm handler                                ...done
starting node monitor                                 ...done
starting cluster delegate                             ...done
starting guid generator                               ...done
starting memory monitor                               ...done
-- core initialized
starting empty DB check                               ...done
starting exchange, queue and binding recovery         ...done
starting mirror queue slave sup                       ...done
starting adding mirrors to queues                     ...done
-- message delivery logic ready
starting error log relay                              ...done
starting networking                                   ...done
starting direct_client                                ...done
starting notify cluster nodes                         ...done

broker running 

Install and Run Kaazing WebSocket Gateway - AMQP Edition

- Download and install Kaazing WebSocket Gateway - AMQP Edition

- Navigate to the Kaazing WebSocket Gateway installation directory and start it using the following command:

$ bin/gateway.start

Open your web browser of choice and navigate to http://localhost:8001 then select DEMOS on top menu.

At this point, you should be able to run any of the demos available using RabbitMQ as the backend messaging system.

Load-balanced Ordered Message Processing with Apache ActiveMQ

On my previous post (Preserving Message Order with Apache ActiveMQ) we took a look on what would be necessary to preserve message order using Apache ActiveMQ (FUSE Message Broker). We then explored on the ActiveMQ capabilities called Exclusive Consumers.

But, Exclusive Consumers bring one disadvantage that is having active consumers not doing anything (actually not consuming messages) and that may be not the desired behavior. So, let's take a look on how ActiveMQ (FUSE Message Broker) can help to avoid that situation and explore what capabilities and/or techniques are available to process messages in order when multiple consumers are active.

ActiveMQ has a feature called Message Groups which is the way to load balance multiple active consumers listening to the same queue while preserving message order. ActiveMQ will then group messages on the queue and it will guarantee that all messages of a particular group arrive in order on the same consumer.

So, to give you an example, let's say we're processing records about drivers (adding new drivers, updating drivers' information, processing speed tickets, revoking tickets, etc). You definitely don't want to process the revoke information before the ticket record because that would cause a lot of problems when the ticket doesn't exist yet and the application will try to update its information. Then, to solve that problem we could group messages by driver's license number and then let the message broker process them accordingly. Now, from the global sense the messages may not be processed in order but from the important business application sense of related messages they are delivered in the preserved order.

In the picture below, messages addressed with the same JMSXGroupID, in this case "GRP1" and "GRP2", will be pushed to a unique consumer, in other words, Consumer A will get messages that contain the JMSXGroupID equals to GRP1 and Consumer B will get messages that contain the property JMSXGroupID equals to GRP2.

In summary, ActiveMQ will correlate messages based on the property JMSXGroupsID and will deliver those to the same consumer.

On a side note, messages without a group (meaning messages with no value specified in the JMSXGroupID header property) will be distributed (load balanced) among active consumers as they would be in the normal ActiveMQ queue message processing.

But, how to implement message groups?

Very simple… the only thing you have to do is to set the JMSXGroupID property on the client producer before you send the message with whatever value you want to use for correlation. The broker itself will take care of everything else for you.

Here is a snippet of a Java client producer creating a JMS Text Message and then setting the JMSXGroupID property:

Message message = session.createTextMessage(“<foo>hey</foo>”);

message.setStringProperty(“JMSXGroupID”, “Msg_group_1”);

In the example above, all messages in the queue with JMSXGroupID set to Msg_group_1 will be directed exclusively to a single consumer.

How the messages reach the correct consumer then?

Well, the message broker maintains an internal hash map with the Group IDs and the consumers receiving messages for that specific group.

The consumer will then receive messages for that group until it drops the connection or a producer closes the message group by sending a message with a property called JMSXGroupSeq containing the value of -1 (minus one). That's going to be the flag telling the message broker that the group is no longer needed and the reference in the hash table can be removed.

For new message groups, the broker does a random selection of the active consumers and then start placing messages on that consumer.

So, to illustrate how to close a group, the following code shows the Java producer client closing the Msg_Group_1:

Message message = session.createTextMessage(“<foo>bar</foo>”);

message.setStringProperty(“JMSXGroupID”, “Msg_group_1”);

message.setIntProperty(“JMSXGroupSeq”, -1);

producer.send(message);

Then, if another message is sent to the same message group ID, the message broker will handle that as a new message group randomly assigned to a new consumer.

Preserving Message Order with Apache ActiveMQ

There are some use cases and business scenarios where you have to process messages in order. Basically, when multiple consumers receive messages from a queue and process them in parallel, message order is not preserved.

Apache ActiveMQ has the capability to process messages in order using a feature called Exclusive Consumers. With Exclusive Consumers all messages from a single queue are processed by only one consumer (other consumers listening on the same queue will take over if the exclusive consumer fails).

So, fundamentally the diagram below shows how Exclusive Consumers work where Consumer A and Consumer B are both listening to the same queue but only the Consumer A is consuming messages from it.

The Exclusive Consumer feature is configured at the consumer level, so at the code level you have to explicitly say what queue you're listening in and also say you're an an exclusive consumer.

Here is a piece of code showing how to set the Exclusive Consumer:


queue = new ActiveMQQueue(“TEST.QUEUE?consumer.exclusive=true”);


That's very simple and still powerful…


But, there's more to that! You also have the choice to set a priority for each consumer.

One way to ensure that high-priority applications get messages to process is to set the consumer priority. When multiple consumer request exclusive access to a queue, the consumer with the highest priority is selected by the broker.

So, another case for Exclusive Consumer priority is the machine speed you have available. You may want to give a higher priority for consumers deployed on faster machines and set the priority according to the resources you have available.

To set the Exclusive Consumer priority all you have to do is set another option on the consumer code like the below configuration:


queue = new ActiveMQQueue(“TEST.QUEUE?consumer.exclusive=true&consumer.priority=10");

The diagram below shows how the consumer priority would play with these settings.

One disadvantage of Exclusive Consumers is that you have active consumers doing nothing but we are going to cover how ActiveMQ helps you avoid that situation on a future post.

Stay tuned!

Apache ActiveMQ Enhancements to JMS

The JMS (Java Message Service) specification is very well-known for those working with messaging platforms but it has been around for quite some time and honestly not getting updates lately which gives a lot of room for enhancements and extensions.

As you can imagine Apache ActiveMQ goes beyond the JMS spec and implement lots of cool things where you can gain more in functionality, performance and scalability.

Starting from the top ConnectionFactory object, ActiveMQ has its own called ActiveMQConnectionFactory, as other JMS providers also create their own specific factories, ActiveMQ enhances the JMS with some settings that you can activate right away with little configuration and definitely see gains in performance.  Of course, when you optimize for performance, most of the time, you have the trade-off of more CPU utilization but I think CPU cycles are getting really cheap when comparing with network bandwidth and disk I/O.

Here is a list of things you can use to optimize performance extending the JMS specification with Apache ActiveMQ:

disableTimeStampsByDefault - it sets whether or not you're going to include the Time Stamp in the message header. The story behind this is that when you create a JMS message (actually when you call the send() method) we have to make a call to the system kernel to get the time stamp. This setting could save you a trip to that level and save you some time optimizing performance if the time stamp is not required in your messaging application.

copyMessageOnSend - The Java Message Service specification says that inside the send method we have to make a deep copy of the message object before sending it from the client to the broker. Setting the copyMessageOnSend property to false (default is set to true) will save you a cycle as the client won't make that copy of the message saving local resources.

useCompression - I think the property name here is self explanatory... but the ActiveMQ client will compress the message payload before it goes to the broker. So, the question is why not to use compression all the time and send smaller messages over the wire? Well, in order to compress the message payload you're going to spend CPU time and then the point is CPU vs. I/O. It's a trade-off that you may have to consider... in other words, you'll have to consider spending more CPU to compress the message or more bandwidth sending larger messages. Personally, I believe (and have seem) that if you have the chance to use compression you definitely should.

objectMessageSerializationDefered - Imagine that you're sending an Object Message and you're using an embedded broker for example (client and broker running on the same JVM). What this feature really enables you to do is that you tell the client to delay the object serialization as long as it can until it needs to hit the wire or store the message on disk. Basically, everything inside the same JVM should not be serialized as marshalling and unmarshalling objects can also be expensive.

useAsyncSend - Let's say you're sending NON_PERSISTENT messages to the broker which is equal to non-blocking call with no immediate acknowledgement and in fact it's ver fast but still not reliable messaging.
On the other hand, you can also use PERSISTENT messages which is going to be a blocking call from the client to the broker. So, one of the things you can do is to set useAsyncSend to true (default is false) and then change the behavior of PERSISTENT delivery mode to be asynchronous and no acknowledgement would be expected. In reality,  the send() method will return immediately giving you more performance because it reduces the time that the message producer waits for the message to be delivered. Keep in mind that this setting can possibly cause message loss but that's another trade-off that you have to consider when designing your messaging infrastructure.
This is a good approach if you can tolerate some message loss... typically on systems where the most updated information (last message) is always what you care about or when you have a reconciliation process in place to catch those conditions.

useRetroactiveConsumer - This feature allows you to work with limited window of memory topics where you can configure a policy to deliver let's say for example the last 10 messages sent to the topic, the last 5MB of data that went through to that topic or simply the last message sent to the topic... and all of that without the need of durable subscribers :-)
This is actually far more lightweight than using durable subscribers and it's really easy to configure and very easy to use.
Finally, since this is not JMS standard, of course, it's not set by default.

For a complete list of ActiveMQ enhancements to the JMS specification see the ActiveMQ product documentation.

I hope this helps you to push the go-faster button in your messaging infrastructure.

FuseSource Tour in Brazil

I had the pleasure to spend a week in Brazil doing a FuseSource Tour in two of the major cities... Sao Paulo and Rio de Janeiro. It's pretty clear that the Open Source community is growing really fast and the integration and messaging opportunities are hot.

Unfortunately, I couldn't visit all of the prospective partners and customers that had contacted us because we couldn't find a single empty spot on the agenda but I think the tour was an amazing experience and I'm pretty I'll back in the near future for more fun with the techies.

Some of the things I realized while traveling throughout Brazil is that the traffic is really crazy and made me remember some other cities like Los Angeles or Mexico City... You have to be really creative in terms of logistics to be able to meet more than two customers in the same day especially in Sao Paulo.

Food was a big surprise and it was pretty good either in Sao Paulo or Rio and I met nice and friendly people all over the place... Gotta keep up on the workout front to shed some extra pounds!

On the business side, I've met mostly customers in the financial sector and partners that already use Apache technologies like ActiveMQ, Camel, CXF and ServiceMix and I was able to have a good tech talk with them while discussing some architectural aspects as well as development techniques.

While talking to a couple of big banks in Sao Paulo, it sounded to me that companies are realizing the value and maturity of, for example, Apache ActiveMQ where their are not only reducing licensing costs but also exploring features that other messaging products don't offer at this point.

Of course, the reliability and extensibility as well as high performance are key factors for all of these organizations and ActiveMQ is/is going to be part of their architecture.

Sao Paulo Subway System

Then, on the second part of the week (more precisely in Rio de Janeiro), I visited a telecom company who's using ServiceMix as part of their core engineering systems and I was happy to discuss patterns and features they are using and also some things they can do to improve it in the next rollout.

Rio de Janeiro's Sugar Loaf

Interesting enough, all of the developers and architects I had the pleasure to talk to were really amazed with Apache Camel and there are tons of use cases where they see possibilities of writing a couple lines using either Java DSL or Spring XML Configuration rather than several lines of code where they need to manage everything from the connection to the business logic. What everybody really liked during the Camel demos is the abstraction layer that Camel provides where you concentrate on the business logic and not on the details of the implementation. Gotta a comment that we're now "High-tech plumbers" connecting all of the enterprise applications with the simplicity and power of Camel, ActiveMQ, CXF and ServiceMix. 

But, the best moment was when I did an Apache ActiveMQ, Camel, CXF and ServiceMix overview presentation in one of the largest companies in the country for 100 developers and technical folks. I was really impressed on how excited they got after the talk and Q&A and they are really looking forward to apply the discussed topics on their projects right away. The same presentation should be the core of a webinar that I'm planning to do in December... a quick overview about the technology and how FuseSource has been helping customer/partners to successfully work with those Apache projects from conception to deployment.

To celebrate the successful talk, next morning I went for a run at Ipanema's beach where I ended up with the view below... Simply amazing...

Ipanema's Beach

Well, I'm really looking forward to continue to work with organizations in Latin America and come back soon...