Posts Tagged ‘developers’

When is a quantum leap not really a quantum leap?

November 3, 2015

Electronimage

A quantum leap, if I remember correctly, is the movement of an electron from one energy level to another energy level. So it is not really a big change – just the change from one discrete level to another discrete level. However the phrase “quantum leap” is often used to describe a big change, when in fact it is describing a very small change. Just like a quantum leap, MQ get updated from one fixpack to another. Sometimes this can be thought of as a small change. However in the case of the latest update to MQ V8, this change can represent significant change and new opportunities for MQ users. When an electron does a quantum leap and drops down to a lower energy level and emits a photon, let’s shine a light on the changes in the latest update to IBM MQ.

Last week, on October 23 2015, IBM brought out an update to IBM MQ V8 that included not just fixes, but some really important new features and functions. I will call out some of these here, and hopefully also link to some other sources of information to find out more about the parts I don’t cover.

The key enhancements I am going to cover are the addition of full MQ Light API support within IBM MQ, and also what we are calling the redistributable MQ Client. There are plenty of others (another interesting new feature is setting a Message Expiry Cap) and these are described in Mark Taylor’s short presentation – which can be found here 

Let’s start with the addition of the MQ Light API as a fully supported option. You can read my previous blog on MQ Light here   – but as a recap, MQ Light is a new API for messaging which is designed to allow developers working with Javascript, Ruby, PHP, etc. to make use of messaging as a part of their applications. This enables them to code microservices, and build applications making use of buffering, but doesn’t force them to learn the richer, more complex MQ API or JMS, or require them to code in C or Java. MQ Light is a good way for many enterprises to start to change some of their infrastructure into Hybrid deployments, supporting both on-premise and cloud deployments.  In this latest update, IBM MQ itself now supports the MQ Light API. So these developers can continue to script their applications making use of the MQ Light API in whichever environment they prefer, but now IBM MQ itself acts as the messaging provider. As these MQ Light  applications publish their messages or listen for their subscriptions using the AMQP protocol, this means that AMQP clients can now for the first time connect in to IBM MQ which is then receiving published messages and forwarding them on, or routing the subscriptions to the applications. By ensuring that only a single messaging runtime environment is needed, this lowers the operational burden, reducing complexity for the infrastructure team, and keeps costs down, while keeping the application developers happy with their preferred development environment and API. And the infrastructure team can ensure they support the growing demand for Hybrid infrastructure for cloud deployed applications, while still meeting their enterprise qualities of service for their middleware infrastructure.

The other key update concerns the MQ Client. The MQ Client is how many MQ customers make use of MQ, embedding the client libraries in their applications which then send and receive MQ messages. In this new update the MQ Clients are now also available as tar or zip files for easy embedding in the applications themselves. As well as removing the requirement for a separate install process, the license has been updated to allow applications that include the MQ Clients to be distributed inside and outside the enterprise without requiring permission from IBM as had been the case in the past, which had prevented the easy inclusion of the MQ Client libraries in many solutions. From now on, the MQ Client can be included in any solution, easily packaged and distributed to allow the seamless distribution and deployment of MQ connected applications anywhere required. I am looking forward to seeing many more customer and vendor applications including the MQ Client libraries from now on.

These two changes are substantial enhancements and dramatically change the options available for businesses looking to use IBM MQ for messaging, making this a real leap into the future, for both on-premise business critical applications and the rapidly changing world of Hybrid Integration.

For more details on using MQ Light and AMQP with IBM MQ to enable Hybrid deployments and more see here.

And for more information on the re-distributable MQ Client see here.

A leap into the future, and into the past was the subject of another ‘Quantum Leap’ – this time a TV series from the late 80s/early 90s. Scientist Sam Beckett would ‘leap’ from body to body throughout time. I guess that’s another example of a quantum leap not being quite a quantum leap. As he used to say when he leapt into someone else: “oh boy”.

QL-ohboy

IBM MQ Light – What’s in a name?

October 3, 2014

“A picture paints a thousand words”. A well-known phrase. Undoubtedly true, but a single word can be critical. Change a single word and the meaning of a sentence, a paragraph, maybe a whole book or more could be altered. So what about IBM MQ Light? Is it MQ, but Light? And what does Light mean in this case?
We see the description ‘Light’ every day. Some product advertises itself as “Light – all the flavour, half the fat”. You know the sort of thing. So does it apply to IBM MQ Light? How does this new product compare to IBM MQ itself?
Well, I would say that maybe the best way to think of it, is not IBM MQ but “Light”, but rather IBM MQ for those “Lightbulb” moments, such as when Archimedes shouted “EUREKA!”.

eureka
IBM MQ after all already delivers the benefits of messaging to millions of applications running in tens of thousands of businesses around the world. I have described some of those benefits on these pages already. It does this primarily for enterprise critical applications, written in C, Java or even COBOL, dealing with Systems of Record. These applications handle business critical transactions, moving key customer and enterprise data between applications systems and services. And it makes a lot of sense to ensure these applications, and the associated data can benefit from IBM MQ’s reliability, robustness, security and scalability. After all if you are moving and updating business transactions, you want to scale, be secure, and be highly available.
However, there are many millions more applications that don’t face the same requirements, but yet are still critically important to the business. Maybe the app helps the business interact with customers with more immediacy. Maybe it shares information more widely with partners. Maybe it is building brand awareness or promoting the business across different platforms and devices. These type of apps are written by a different type of developer, using different languages, for very different purposes to the more traditional application that works with the systems of record. These are unlikely to be updating business critical information systems or processing transactions, although they will need to interact with existing systems. So maybe they don’t need everything that IBM MQ has to offer. But does that mean they don’t need anything that IBM MQ has to offer?
Messaging as provided by IBM MQ, does after all benefit program architecture and operation. Applications can be simpler. Applications producing and consuming data at different rates can be easily buffered. And aspects of security can be built in. Along of course with the ability to connect and exchange data across different systems, even if one application is down.
If messaging can bring all these benefits, why would the programmers of all applications not use it, when there is a widespread and well proven technology like IBM MQ? We have already called out many of the reasons. The developers are a different set of people, with different skills, and code in languages that IBM MQ doesn’t natively support. And IBM MQ is designed around the needs of those critical business transactions. That doesn’t mean that it can’t handle simpler needs, but if you are not familiar with using IBM MQ, there can seem to be a lot more options in the API to deal with than maybe are needed for a different, more straightforward use case. So why not produce a messaging product, which takes everything from IBM MQ that would be useful to this new set of developers, but presents it to them with a simpler API, more in line with the restricted needs of the type of applications they are producing. This is what IBM has done with IBM MQ Light.
IBM MQ Light is a new and different messaging product from IBM. It aims to bring the benefits of messaging to a new set of developers building the latest applications for a rapidly changing world.
The goals of MQ Light are as follows:
• Provide messaging that application developers will love to use
• Help applications be responsive and scale to meet demand
• Make it easy to get access to the code and to start to use it – simply download, unzip, use
• Run on premise or on Bluemix in the cloud
• Offer simple, open APIs in a mix of popular scripting languages
• A new breed of tooling to ensure developers know what is happening to their messages
You can see by these goals, this is something new. And also MQ Light is not trying to be an alternative to IBM MQ. It is very different. It focuses on the needs of the new developers. And in keeping simple, it means that it doesn’t provide some of the key characteristics of IBM MQ. There is no clustering, no high availability, and no transaction support. If your application is likely to need those functions, then the right choice should be IBM MQ. If however your application doesn’t need any of those, but it still could benefit from messaging, allowing it to buffer and scale workload, respond to events, schedule actions or queue responses, then MQ Light may be a good match for them and their developers.
For development use, MQ Light is of course free to download, and is available on Windows and Linux for x86 or Mac OS X. Once applications are developed and ready to be put in production, they can be run on premise in the MQ Light runtime (payable per Install), or deployed using MQ Light in Bluemix (payable per Message). And in the future, as mentioned in the IBM MQ V8 announcement letter, there will be the ability to run MQ Light applications in IBM MQ itself.
All in all, enough to make a lightbulb go off in anyone’s head. If it is going on in yours – check out the MQ Light webcast to learn more. Or even better download it today and be using it in a few minutes.

lightbulb-idea-14606269

WebSphere MQ. You want it? It’s yours. For free.

October 4, 2013

No kidding. Image

That’s right. WebSphere MQ for free. In fact even better than that. WebSphere MQ Advanced. Not just the industry leading simple, reliable, rapid and secure messaging engine of WebSphere MQ. Not just that. Including Managed File Transfer with WebSphere MQ Managed File Transfer. Including end to end encryption of message contents with WebSphere MQ Advanced Message Security. And connectivity to mobile and M2M devices with WebSphere MQ Telemetry. 

All of that capability. For you to download. From today. For free. What”s the catch? No catch. It is actually our WebSphere MQ Advanced for Developers offering we made available earlier this year. That is still available for development and Unit Test use, priced per Single User, with IBM Support. This is the exact same product, also limited to development and unit test use, but without IBM Support. But that means you can download it for free. Develop apps for free. Build your skills for free. Get a jump start on everything you want to do. 

What’s the most innovative thing you can do with WebSphere MQ Advanced on your laptop? What projects can you dream up? Tell us what you are thinking of.

So what are you waiting for?

Go here to download it

Go on – go!

Image

WebSphere MQ Advanced for Developers – another exciting step forward

March 19, 2013

Yes. It’s that time again. Another blog entry, so we must have something new to say about WebSphere MQ. And yes we do.

I’m very pleased that we have another announcement to make today. WebSphere MQ Advanced for Developers. You can read the announcement letter itself here. But in the meantime what are the key points you really ought to know?

1)     This is an exciting new development in that we have added a new way to buy licenses of WebSphere MQ, and indeed the entire WebSphere MQ Advanced stack, but priced for individual developer deployment and use. We continue to have both the separate WebSphere MQ licenses and WebSphere MQ Advanced licenses, which are both priced by PVU, and suitable for production and testing. But this new licensing option is priced per ‘Authorised User Single Install’ which effectively means a fixed price per developer that wants to use it for their development use. We believe that by making the WebSphere MQ portfolio more available for developers, giving them individual access we will increase their skills, improve their ability to use WebSphere MQ in innovative ways, and also speed the time to develop more productive applications. Read the announcement letter and get the new part from Friday 22nd March.

2)     As part of this announcement we are also taking advantage of the opportunity to bring everyone up to date on the enhancements we have been making to the support for connecting to M2M devices and mobiles. Over the last couple of months IBM has been publishing new Messaging Clients to support Android and iOS mobile devices. These have been published on our new Messaging Community on developerWorks. This announcement has been timed to coincide with the first fixpack for WebSphere MQ V7.5 which adds in additional function that also allows connectivity from MQTT clients over WebSockets. This creates new opportunities for building new types of applications that can connect to the enterprise over WebSockets, which we expect to be very popular, especially when combined with the new Javascript API which supports both this style of connection as well as supporting the clients on Android or iOS devices. These clients support our Worklight offering, and with IBM MobileFirst this is a very exciting time to be adding this type of support.

3)     Finally as part of this update IBM has also made some changes to the licensing to support High Availability with WebSphere MQ. In recent years WebSphere MQ added its own approach for High Availability – called Multi-Instance Queue Managers, which allowed WebSphere MQ to automatically watch itself and failover if required. An additional ‘Idle Standby’ license was required for the failover system, which was substantially cheaper than a full license. In this update we have extended these Idle Standby licenses to also apply to other configurations that provide automatic failover – such as PowerHA, or 3rd party configurations like Veritas. Now the failover systems in these environments can also be licensed with the Idle Standby parts.

Hopefully these look like a good set of updates – and they have kept us busy working towards them. Don’t forget you can download the free trial for WebSphere MQ here. And visit the Messaging Community to find more stuff, including the Messaging Clients for M2M and Mobile. And look for a webcast from me on the Global WebSphere Community on April 11th.

WebSphere MQ, #uksnow and heating instead of plumbing

December 18, 2009

First, apologies it has been so long since I managed to find time for a blog entry. But now that I am here, what is it that I have to say. The origins of this blog topic go back to earlier in the year. We had a new wood-burning stove installed in our house – both for aesthetic reasons and to try to reduce our gas bills by heating the house using wood. Burning wood to heat your house is carbon neutral of course, and we could collect plenty of logs from the wood next to us.

So throughout the summer I have been slicing up dead trees and splitting logs, building wood sheds to build up our stock of wood, in the knowledge it would be cheaper than using our gas-fired boiler to pump water through all our radiators. Did I enjoy this? You bet I did – really makes you feel like you have achieved something, learned a skill – all that sort of thing.

And then we get to winter – and from September onwards we have been lighting the stove, and it has been great. Lots of heat – the house nice and warm. The fire looking good, and all my good work coming to fruition, with the added bonus of no heating bills with the heating off.

But then we get to proper winter as in the UK we get a cold spell with snow (currently filling up the twitterverse with the hashtag #uksnow). We found we needed the fire all day – and even though it is pumping out a lot of heat, and it sits in the center of the house, it can’t quite get all the extremities of the house warm – there are a lot of outside walls getting the heat sucked out of them, no matter how many logs we put in the stove.

So I started to think that maybe we would need to have the boiler on at least some of the time, and that maybe there was a reason that central heating with radiators has replaced fires (even efficient stoves). After all there may be a cost associated with central heating, but it is much less work, and it does ensure that the heat goes right where you want it, not spreading from one point.

Sure from an enjoyment point of view, it is less satisfying, but there is something to be said for progress, or at least a balance of solutions. And then it occurred to me that there was some similarity with the battles our customers have in deploying messaging middleware to connect and integrate applications. The programmers of course want to do it themselves, enjoy the task and it builds their skills. There is even some satisfaction at looking at what they achieve. But of course it can fail to scale up to meet the needs of the business. There might be a cost of buying WebSphere MQ, or an ESB like WebSphere Message Broker or WebSphere ESB, but the end result can be much less effort, and be more effective – at least in a number of deployment scenarios. And it doesn’t mean the programmers have to stop what they are doing – it just means that they don’t need to do all the heavy lifting – allowing them to get on with more tasks.

From a cost point of view, developers might say that it is a waste to buy a solution like WMQ, but in our heating analogy we are not talking about doing everything with the boiler, just taking advantage of its ability to heat the parts of the house the stove would find it more difficult to heat – much like WMQ can do things that roll-your-own solutions can find it difficult or complex to do. Does this seem to ring true?

In the meantime I need to put another log on the fire!