AMQP for dummies - A guide for managers

(I start to like this "plane blogging" thing :))

Adrian blogged about Microsoft embracing AMQP.

Just from a technical point of view this is good news (assuming it will help the adoption of the Advanced Message Queueing Protocol (AMQP)), because AMQP is a very cool (and extremely well thought through) standard.

Given that there might be a renewed interest in the standard, let me just try to explain (again) what it is good for: The main benefit of AMQP (besides a couple of very cool features in the standard itself) is that it will (finally and for the first time) allow messaging stacks to interoperate. Today we have lots of good payload formats/protocols (e.g. XML) and even better standard APIs (e.g. JMS), but no standard wire-level protocol to allow one messaging stack talk to another. That means that currently all of your messaging endpoints need to have the same message stack. This creates a huge, hidden vendor lock-in. Yes, your JMS API allows your to replace a JMS provider with another one, but then you need to do it for all endpoints at the same time, because the wire-level protocol is different (and proprietary) for each and every message broker implementation.

Means right now you can only build homogenous messaging infrastructures. AMQP would allow you to build heterogenous messaging infrastructures, break the vendor lock-in and enjoy the power of choice. AMQP is the HTTP of messaging. I see AMQP as an enabler for
innovation.

Social Networking - Del.icio.us rediscovered! or Do we need the Open Social API?

(Blogging from a plane en-route from DUB to BOS using the email interface of blogger.com :))

The other day I updated my website with the details of my new employer and decided to give a second live to my del.icio.us account by using one of the widgets to include my reading list on my blog. I also had to decide, which of my social networks I reference on my site.

Currently I am using ...

• Social-Networking: Linked-In, Facebook, Xing, Plaxo
  
• Micro-Blogging: Twitter, Facebook, Plaxo
  
• Bookmarks: Del.icio.us, Facebook
  
• IM: AOL, Skype
  

... and there are probably a couple that I forgot/missed. For social-networking I decided to make Facebook, Xing and Plaxo point to my Linked-In presence, for micro-blogging I decided to make Facebook and Plaxo point to my Twitter account, for Bookmarks I will use Del.icio.us (because it is nicely integrated with NetNewsWire) and for IM I will use Skype.

The exercise made me thing about social networking. The power of social networking is to bring people together, but right now there is not one social network, there are probably hundred big ones (including mega-networks like youtube) and thousands of small ones. Each social network documents another shade of your personality/interests: What do you do? What do you like? What do you watch? What do you read? What do you publish (e.g. blogs and pictures)?

Initially I felt that having multiple implementations for the same shade of social networking was actually counter-productive, because it fragments the communities and increases the maintenance overhead (updating multiple sites with the same information).

In the meantime I changed my mind. I am a big fan of evolution and darwinism (mutation and selection, survival of the fittest). Therefore I believe for the time being having multiple implementations is actually beneficial, because this way innovative implementations have a chance to put a variation on a shade (e.g. using Facebook to create a private/personal presence and Linked-In to create a professional presence/identity).

But how do we deal with the fragmentation of the communities/networks and what do we do about maintaining these, at least partially, overlapping networks? Can we eat the cake and have it too?

Yes, we can. This is where the Open Social API can (and hopefully will) add value. This API will allow us to build meta-social-networks. With this API we will be able to update and maintain all of our social networks with one API and will also be able to learn more about our social networks (e.g. who is on all of my social networks). It is my expectation that this API will create new, innovative social-networking applications, which will turn the diversity of the networks into value.

A bookmark to a very nice Google Tech Talk about the Open Social API is on my Del.icio.us page. Check it out.

Link of the Month - FUSE TV

Great new content. Check out FUSEsource.com! 

4 weeks ago we huddled in our "new" HQ in Bedford for Managment Meetings (and other fun :)). Debbie had the great idea to take advantage of our presence there and record a first set of FUSE TV sessions. Great fun! Check out the result.

And yes mea culpa, "aaaeeeehhhhhhmmmm" is not a german word. No Oscar for me (this time :)).

Link of the Month - FUSE is moving on ...

... to FUSEsource.com. As part of the Progress acquisition we decided to change the host/domain name of the FUSE community website from open.iona.com to FUSEsource.com.

I like the new name better, because what we do here is not about a company (be it IONA or Progress). It is about a project. In our case FUSE.

The renaming will also allow us to role out more interesting stuff in the near future on a new, consistent family of good host/domain names. Stay tuned :). 

The iPhone screen - Is it a problem or a solution?

Lot's of interesting exciting stuff is going to happen with FUSE over the next couple of month. 

Especially on the tooling side. The other day I was riding in the car with Oisin Hurley (Head of Tool Development for FUSE) and we discussed the value of having NOT a lot of screen real-estate, because it really makes you think about what the problem is the user wants/needs to solve and how you can guide the user through that process.

There is a good video-cast available from Apple, which talks about the principles of good UI design for the iPhone. I believe these principles are good principles regardless how much screen real-estate you have. To that extend designing UIs for limited screen real-estate is more a solution than a problem. It creates the right attitude :).

Other opinions? Thoughts?

Complex Event Processing - An exiting (new) frontier

Through the merger (:)) with Progress, I got exposed to the new exciting field of (Real-Time) Complex Event Processing (CEP). There are a couple of obvious use cases in finance (e.g. algorithmic stock trading) and manufacturing (e.g.  detecting possible problems in the assembly line, which might effect your just-in-time service-level-agreements).

Complex Event Processing or Intelligent Event Correlation is not what excites me. That was/is also possible using large data-warehouses and suitable data-mining solutions, but then you learn about it after the fact. It is not so much Complex Event Processing, it is more Complex Event Analysis. 

What excites me is the real-time aspect. The possibility to re-act to a set of correlated events as they happen.

The longer I think about it the more use-cases I see. Last month a large (if not the largest) utility provider world-wide visited us in Dublin for a 4-day SOA workshop. Among other things, they are looking for a solution to detect failures in the power grid before they happen or narrow down the location of the failure (faulty transformer) after it happens (e.g. to get a repair team onsite faster).

Last night I found a talk on Google Talks describing a solution for Device-free Passive Localization for Wireless Environments. Another interesting use-case.

CEP is everywhere. I am dying to find out, what the value of a solution for this kind of problems is.