Tag Archives: Java

I’ve been involved with Spring (the Java framework, not the season…) for a couple of years now – since I joined VMware in 2012 through the former SpringSource organisation in the UK – and I’ve remained “involved” with it through my transition to Pivotal and the framework’s evolution into Spring 4 / Spring.IO under Pivotal’s stewardship.

To be clear, although I’ve been a “Java guy” / hacker through my time at IBM, I have never been a hardcore JEE coder, and my knowledge of Spring itself has always been limited. My good buddy Josh (MISTER Spring, no less) has done his best to encourage me, I briefly played with Spring Shell last year with @pidster, and the brilliant work done by the Spring Boot guys has been helpful in making me look at Spring again (I spoke about Boot – very briefly, as a newcomer to it – at the London Java Community unconference back in November).

Taking all of that on board, then, I’m still an absolute Spring n00b. I recognise a lot of the benefits, I see the amazing work that has gone into Spring 4, and I’m excited by the message and mission of the folks behind the framework. I would say that though… wouldn’t I? 🙂

[considering this is my first blog post in a while, I’m taking a while to get past the preamble…]

This week, I chose to flex my coding muscles (!) with a quick diversion into Spring Integration. With a long history in WebSphere Integration back in my IBM days, this was both something of return to my roots, and also a learning experience!

With the new Spring.IO website (written with Spring, and hosted on Pivotal Web Services Cloud Foundry, fact fans!), the Spring team introduced the new Spring Guides – simple and easy-to-consume starter guides to the different technologies available in the Spring family. I knew that the team had added MQTT support via Eclipse Paho, so I thought I’d take a look at how I could modify a Spring Integration flow to take advantage of MQTT.

Once I’d figured out that it is useful to ensure the latest versions of the various modules are listed as dependencies in the build.gradle file, it wasn’t too hard to adapt the Guide sample. In the example, the docs lead a developer through creating a new flow which searches Twitter and then passes tweets through a transformer (simply flattening the tweet sender and body into a single line of text), into an outbound file adapter.

The bulk of the changes I made were in the integration.xml file. I wanted to replace the file output with the tweets being published to an MQTT topic. To do that, I added the int-mqtt XML namespace information to the file, and configured an outbound-channel-adapter. It was also necessary to add a clientFactory bean configuration for a Paho MQTT connection. You’ll notice that, by default, my example posts results to the test broker at Eclipse (iot.eclipse.org port 1883 – an instance of mosquitto for public testing). Full information on how to build and test the simple example can be found in the project README file.

Thanks to my colleague Gary Russell for helping me to figure out a couple of things, as I was a Spring Integration newcomer!

Pivotal is bringing together a number of key technology assets – our Open Source cloud platform (Cloud Foundry), agile development frameworks like Spring, Groovy and Grails, a messaging fabric (RabbitMQ), and big, fast data assets like Pivotal HD.

What we’re announcing today delivers on that promise and our vision – the consumer-grade enterprise, enabling organisations to create new applications with unprecedented speed. The cloud – infrastructure clouds, IaaS like Amazon EC2, VMware vSphere, OpenStack, CloudStack, etc – can be thought of as the new hardware. It’s like buying a beige server box back in the 90s – the IaaS layer gives you a bunch of CPU, network, and storage resources, and for your application to use them, you need a layer in between – an operating system, if you like. We’ve spoken of our ambition for Cloud Foundry as “the Linux of the Cloud”, and it already runs on all of those infrastructures I’ve listed above – in the future, hopefully more.

Why is that important? Why should developers care about this Platform (PaaS) layer? A development team shouldn’t have to go through an 18 month delivery cycle to deliver an app! We’re putting an end to the whole cycle of calling up the infrastructure team, having new servers commissioned, operating systems installed, databases configured etc etc just to get an application deployed and running. When you first push an application to Cloud Foundry, and can then bind data services and scale out with simple individual commands, it really is a liberating experience compared to what traditionally has been required to get your application running. We’re making it quicker and easier to get going – a friction-free, turnkey experience. You should just be able to write your code and make something amazing.

We’re also delivering choice – of runtimes and languages, data services, and also importantly, a choice of “virtual hardware”. When Comic Relief ran in the UK this year, in order to avoid any risk of hardware failure (we all know there’s a risk that Amazon might go down), the applications were deployed on Cloud Foundry running on both Amazon EC2 with geographical redundancy, and on VMware vSphere – no lock-in to any cloud provider, and the developers didn’t have to learn all of the differences of operating different infrastructures, they just pushed their code. We’re happy to know that it was a very successful year for the Comic Relief charity, and that Cloud Foundry helped.

Pivotal One also includes some amazing data technologies – Pivotal HD (a simple to manage Hadoop distribution) and Pivotal AX (analytics for the enterprise). We recognise that as well as building applications, you need to store and analyse the data, so rather than just shipping a Cloud Foundry product, we roll up both the elastic scalable runtime, cutting-edge technologies like Spring.io, and and our big data offerings. That’s different from many of the others in the same market. We’ve been running our own hosted cloud, now available at run.pivotal.io, on AWS for over a year now, so we’ve learned a lot about running systems at scale and Pivotal One can do just that.

Above all, I wanted to say just how excited I am to be part of this amazing team. It is an honour to work with some incredibly talented engineers and leaders. I’m also personally excited that our commercial and our open source ecosystems continue to grow, including large organisations like IBM, SAP, Piston … it’s a long list. We took out an ad in the Wall Street Journal to thank them. I also want to thank our community of individual contributors (the Colins, Matts, Davids, Dr Nics, Yudais… etc etc!) many of whom, coincidentally for me, are in the UK – check out the very cool Github community where some of their projects are shared.

I’m convinced that this Platform is the way forward. It’s going to be an even more exciting year ahead.

A small selection of other coverage, plenty more to read around the web:

Fresh from a quick presentation and supporting Hackference this past weekend (more on that soon), I’ve turned my attention to the next couple of months of travel and events. There’s a lot of stuff happening!

Instead of being in the UK, this coming weekend I’m headed to Santa Clara for Platform: the Cloud Foundry Conference – our first developer summit for the whole Cloud Foundry community. On the back of partnership announcements with companies like IBM, Savvis and Piston, this is looking extremely exciting. I don’t have a formal speaking slot, but I’m going to be heavily involved and have helped with the planning and scheduling. I’m hoping to get a couple of topics onto the agenda for the unconference slot on the Monday afternoon, too!

Immediately after Platform is the annual SpringOne 2GX event. There has been a huge amount of activity in the Spring community over the past couple of months and I think it is safe to say that this year there is some major excitement around where Spring has been headed. I’ve been privileged to spend some time with folks like Adrian Colyer recently, and I know the entire team has been working hard on many projects, so expect some very interesting news about the evolution of Spring and its capabilities. I’m speaking on the Cloud Foundry track, on the first morning of the conference, with my good friend (and Spring Developer Advocate) Josh Long, covering the topic “Build your Spring Applications on Cloud Foundry”.

Later on the same day I’ll be zipping up to San Francisco to participate in a panel discussion at CloudBeat 2013, alongside my friend Diane Mueller and others. The panel topic is “Is PaaS Still Coming?” and we’re on at 1.50 in the afternoon slot. If you are interested in coming along, full event details can be found here, and you can save 20% on a ticket (there is a bunch of great content throughout the event, so if you are in the Bay Area it looks worthwhile). Hashtag for this one is #cloudbeat2013.

[pause for breath… and relax]

The following week I’m enormously honoured to have been invited to a panel at GigaOM Structure Europe, at home here in London. The topic of this one is “DevOps: Is Synchronicity Here?” and rounds out day 2 of the event by taking a look at the current state of DevOps. This link should save you 25% on a ticket and I’d be delighted to see you there.

Our mission is to become the most popular platform for new applications and the services used to build them across public and private clouds.

That’s a pretty compelling mission statement, and I’d personally even add that we want to be the “best” platform, as much as “most popular”. One of the main reasons I wanted to spend a couple of weeks at the Pivotal office in San Francisco was really to immerse myself in the team and in the culture of Pivotal Labs, as well as to be at the launch event, and to get a strong handle on what is happening with Cloud Foundry, version 2…

Wait, what? Version 2?

In the middle of last year, the Cloud Foundry team started some major work to improve many of the features offered by the platform. Back then, it was written about on the Cloud Foundry blog. We initially started to refer to “ng” components like the Cloud Controller (“cc-ng”), and that’s what we now mean when we refer to “v2”. At the start of the year we published a roadmap which laid out a lot more detail in terms of what is coming. There’s some really great stuff in there – many bugs squashed; a new, high performance router; support for developers to collaborate on apps, via concepts of organisations and spaces; new containerisation via Warden; custom domains (yes, finally!); and most importantly, support for buildpacks. Buildpacks will bring a major change to our platform, replacing the former concepts of runtimes and frameworks (say, Java with Spring) with the ability to drop in whatever runtime or container you may choose, instantly making the platform more customisable. We’re pleased that the folks over at Heroku have allowed us to inherit the buildpack concept and having played with the new platform, I believe this gives us a really cool and solid way to support apps.

Deploying Cloud Foundry v2 on Amazon

While I was in San Francisco, I used BOSH to deploy my own new Cloud Foundry v2 instance to Amazon EC2 (and also attended the AWS Summit, which was a bonus!). Right now the team is working on migrating our hosted cloudfoundry.com platform to EC2, and when we officially boot up v2 for the public, it will be running right there. This is not new news – both James, and our CEO Paul Maritz, have repeatedly spoken about AWS. The point of Cloud Foundry has always been that it is a platform that is Infrastructure-as-a-Service agnostic, even when it was started by VMware, and I’m seeing increasing interest from folks want to run it on OpenStack, AWS, and other infrastructures as well as vSphere (by the way, did you read about how Comic Relief 2013 ran on Cloud Foundry on vSphere and AWS? so cool!). There is no lock-in here – write once, deploy to cloudfoundry.com, to a partner running a compatible Cloud Foundry-based instance, or to your own private cloud on your on infrastructure, as you wish. The Open Source nature of the project is exactly why I jumped on board with the team a little over a year ago.

Talking of the update to cloudfoundry.com: it is also worth mentioning that when the beta period comes to a close we will have pricing plans, a nice web console for user, organisation and application management, and the start of a marketplace for partners to plug-in their own services for developers. I can’t give more details in this post, watch the official channels for news!

I felt very strongly that I wanted to write about version 2. It is a very big step in evolving the Cloud Foundry architecture, and I believe that it is important for the broader community to understand that it is a significant change. If you are running an app on cloudfoundry.com today, we’ll shortly contact you with information about migration to the new platform, as some changes will be needed to adapt to the fact that runtimes and frameworks are now buildpacks, there will be some changes to the way services work, and you will need our new ‘cf’ gem to deploy to the new service. We have already “paused” new signups on the current platform. If you look at the new documentation, you will find that it now focuses on version 2 – we apologise for any confusion during the transition process.

We’ve been talking with ecosystem partners about version 2 as well. For instance, our friends at Tier 3 recently blogged about Iron Foundry plans, and I had the pleasure of meeting with Stackato folks in person in San Francisco recently. If you are working with your own Cloud Foundry instance privately (we know that many organisations are!) I strongly urge you to talk to us via the vcap-dev mailing list to learn how you can start to take advantage of what the new platform brings.

There has been a lot of coverage over the past couple of days of some exciting announcements that I’ve been involved with at work. I’ve spent the past three days at EclipseCon Europe 2011, which doubled as the 10th birthday celebration for the Eclipse initiative. It was a funny feeling, because Eclipse started just a few weeks after I first joined IBM, and although I’ve used it and watch it “grow up”, I’ve never done EclipseCon before. The reason I’ve been out there for three days this time (as a WebSphere Messaging guy rather than a Rational tooling or build person, for example) was to get involved with activities around these announcements.

It’s all about machine-to-machine (or M2M) communications, Smarter Planet, and the Internet of Things.

Before I dive in to this, a few clarifications. First, I’m being described in a couple of news stories as “an IBM distinguished engineer”, and whilst I wish that was true, I’ve yet to ascend to those heights! Also, there are various numbers being quoted – note that the figures in the press release were not invented by IBM, the headline number of an expected 50 billion connected devices by 2020 comes from a recent study conducted by Ericsson AB. Oh, and this isn’t about a “new” protocol – MQTT has been in use since 1999.

The other clarification is that some articles seem to suggest that IBM is out to create some kind of new, alternative, Web – that’s not what has been announced, and I’m certainly not aware of any such plan! It’s about connecting “things” – sensors, mobile devices, embedded systems, even small appliances or medical devices for example – to the Web and the associated platform and ecosystem of technologies, not about reinventing or recreating them. I’m personally a huge fan of the Web as a platform 🙂

Oh, and of course, the obligatory “all opinions expressed are my own” – this is my understanding of where things are going, although of course I’m talking about events I’m directly involved in!

The MQTT specification has been published under a royalty-free license for some time, and that has led to a fantastic community contributing a range of different projects. IBM and Eurotech took this approach from early on, because it wouldn’t have been possible to compile and support code on every embedded platform that might come along – far simpler to set the protocol free.

IBM is seeding Eclipse Paho with C and Java client implementations of MQTT. Eurotech is donating a framework and sample applications which device and client developers can use when integrating and testing messaging components.

IBM had previously made some C and Java code available in some SupportPacs, but those are outdated and the license for reuse was never clear.

It’s important to realise that this stuff came from the embedded world of 10 (and more) years ago, and continues to be applied in that industrial space. That category of device typically runs some kind of realtime Java-based OS, or a Linux-based or other runtime with a GCC toolchain for the CPU in question. C and Java are genuinely the most useful implementations to get out there. Oh, and on that “those old languages” thing – I think you’ll find they are very widely used (Android, iOS etc run variants of sorts, most non-web app development is likely to be in one or the other).

We’re very fortunate that clients libraries for a wide range of languages already exist thanks to the MQTT community – see the list at mqtt.org!

Hold on… don’t we need a broker / server / gateway?

Yes. But, one step at a time! 🙂

There are brokers available for free today, either as precompiled binaries or as full Open Source implementations, so this is not a dead end from day one.

The Paho project scope outlines the intention to add a broker to the project in the future, and to host an M2M sandbox for developers as well. That is where we are today, and this position will evolve over time.

Why Eclipse?

The Eclipse Foundation has been a fantastic success story (oh, and, Happy 10th Birthday, Eclipse!). As the scope of their mission has broadened beyond an IDE to the web, build environments, and all kinds of other tools, it was a good place for Sierra Wireless to kick off the Eclipse Koneki M2M tools project, and is now a natural place for this primarily M2M protocol to be hosted under Paho. As James Governor notes in his write-up of the news:

… the Eclipse Public License is designed to support derivative works and embedding, while the Eclipse Foundation can provide the stewardship of same. One of the main reasons Eclipse has been so successful is that rather than separate software from specification it brings them together – in freely available open source code – while still allowing for proprietary extensions which vendors can sell.

How quickly will the code donation happen?

The Paho proposal tentatively includes dates in November and December 2011 – there will need to be various approvals as code is accepted into Eclipse, so that may “flex” a little, but it is all in the pipeline.

To answer this one adequately I’d probably end up addressing each individual difference between protocols in turn, and if you’ve heard me speak about MQTT I’ve covered some of this before – so I’ll keep this answer relatively brief. I will admit that I’ve been asked about all of these by journalists in the past couple of days.

There is space for a range of protocols to coexist, because they address different areas. In the messaging space, we’ve found over time that whilst efforts to create a single protocol have been made, that has often ended up as focused around a particular set of qualities of service, and not optimised to cover the the whole range of them.

For example, if we look at IBM’s own messaging protocols – there are several. There’s WebSphere MQ which is all about reliable, transactional, solid, clusterable, enterprise, JMS and other APIs, etc etc.. WMQ itself isn’t ideal for very high-speed in-memory or multicast scenarios, so there is also WMQ Low Latency (interoperable with the new multicast feature in WMQ 7.1, but a separate protocol). Neither WMQ LLM or WMQ scales down to unreliable device networks and embedded systems, so there is WMQ Telemetry (aka MQTT), which was specifically designed for constrained devices and networks, and that can interoperate with the main queue manager, too. Oh, and sometimes you want to deal with files (WMQ File Transfer Edition), or access message data via HTTP (WMQ HTTP Bridge). You need to address a range of requirements in a messaging story.

So why not those others? In this case, IBM believes that MQTT is ideally-suited to the Smarter Planet Instrumented->Interconnected layer – it’s tiny, not synchronous and brittle, isn’t specific to the web as it is all about data rather than documents, XML etc etc. In these scenarios, REST principles may add an overhead. Oh, and it has been around for over 10 years, and has been proven across a range of industries and in a range of extreme conditions. IBM’s commercial implementation is known to scale to hundreds of thousands of connected devices, and we know that is the direction that this space is heading.

Congratulations! / Thank you!

Thanks, but don’t congratulate or thank me! I’m familiar with this stuff, I’ve coded with this stuff, but I didn’t invent it and I didn’t write it. There are some amazing folks at both IBM and Eurotech (and some who have moved on) who started this all off in 1999, and who have helped to implement solutions using this protocol since then, and who have of course developed it. Several of them areon Twitter if you want to say hi! And huge thanks again to the community of folks that formed around mqtt.org and contributed client and server implementations – that absolutely helped to move things forward to this point.

HERE ENDS TODAY’S Q&A!

That, hopefully helps to clarify a few things and answers some of the questions I’ve seen via Twitter, forums, and mailing lists over the past few days. It has been something of a blur, to be honest, but a lot of fun. I’m looking forward to the next stage – working with the community more, working with our friends at Eurotech, Sierra Wireless and elsewhere, and making the M2M space much more real.

For more, here are a bunch of stories I’ve seen in the past couple of days… no particular order, just my cut-and-paste list!