Friday, December 4, 2009

What's new in iBeans?

Before I get into the new stuff, here is a quick introduction. iBeans is a project I've been working on that aims to make integration for web applications much easier than it is today. It does this by focusing on simplicity and task-based integration and avoids technical jargon and new concepts wherever possible. In a nutshell iBeans offers –


  • Easy to use integration for doing things like -


    • publishing and subscribing to JMS queues and topics

    • Sending and receiving email

    • Polling resources such as Databases and ATOM feeds

    • Scheduling tasks

    • Creating HTTP/Rest Services

    • Consuming external services such as Amazon EC2 and S3, Twitter, Flickr, Google and lots more


  • A Tomcat distribution which drops straight into tomcat, no need to mess with your project dependencies and works with developer tooling for Tomcat or Tcat

  • A really simple API using annotations. This means iBeans can be plugged into your existing web apps easily

  • Easy unit and mock testing using JUnit

  • IBeans Central offers a great place to discover and try new iBeans in your applications



What's new in 1.0-beta-9




  • An iBeans plugin for Eclipse makes it really easy to create and debug web projects that use iBeans. The plugin works with the JEE distribution of Eclipse, enabling you to create and test a web application on Tomcat or MuleSoft Tcat in minutes. See iBeans Eclipse plugin for more information.

Thursday, October 29, 2009

New iBeans Release; Simple Web Integration

I have been busy the last few months with the MuleSoft team working on a new project called iBeans that aims to greatly simplify integration for applications on the web. Today we're pleased to announce the 1.0-beta-8 release of iBeans.

What is iBeans?


iBeans is a service that simplifies integration for web applications. iBeans exposes its API as a small collection of Annotations which can be used to easily integrate with existing or new applications. iBeans is installed in the Application Container and provides integration services to your applications, right now Tomcat is supported with others to follow.



There are two parts to iBeans API -

Friday, July 3, 2009

To ESB or not to ESB



Many of us have had to ponder this question. Technology selection is notoriously difficult in the enterprise space since the criteria and complexity of the problem is often not fully understood until later in the development process.
There is an interesting post from ThoughtWorker Erik Dörnenburg with the unfortunate title “Making the ESB pain Visible”. Erik provides a real-world example of when not to use an ESB citing that -

Based on conversations with the project sponsors I began to suspect that at least the introduction of the ESB was a case of RDD, ie. Resume-Driven Development, development in which key choices are made with only one question in mind: how good does it look on my CV? Talking to the developers I learned that the ESB had introduced “nothing but pain.” But how could something as simple as the architecture in the above diagram cause such pain to the developers? Was this really another case of architect’s dream, developer’s nightmare?

Later, Erik quite rightly points out that an ESB should not have been used in this scenario. This is a fairly common problem for ESBs and other enterprise technology like BPM/BPEL where the technology is not chosen for the right reasons and then the technology gets blamed when the project struggles. Given that much of the enterprise software disillusionment today stems from the incorrect usage of the technology I thought I'd offer some rough guidelines for selecting an ESB.

ESB selection checklist


Mule and other ESBs offer real value in scenarios where there are at least a few integration points or at least 3 applications to integrate. They are also well suited to scenarios where loose coupling, scalability and robustness are required.
Here is a quick ESB selection checklist –

  1. Are you integrating 3 or more applications/services? If you only need to communicate between 2 applications, using point-to-point integration is going to be easier.

  2. Will you really need to plug in more applications in the future? Try and avoid YNNI in your architecture. It’s better to keep things simple re-architect later if needed.

  3. Do you need to use more than one type of communication protocol? If you are just using HTTP/Web Services or just JMS, you’re not going to get any of the benefits if cross protocol messaging and transformation that Mule provides.

  4. Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing? Many applications do not need these capabilities.

  5. Do you need to publish services for consumption by other applications? This is a good fit for Mule as it provides a robust and scalable service container, but in Erik’s use case all they needed was an HTTP client from their front-end Struts application.

  6. Do you have more than 10 applications to integrate? Avoid big-bang projects and consider breaking the project down in to smaller parts. Pilot your architecture on just 3 or 4 systems first and iron out any wrinkles before impacting other systems.

  7. Do you really need the scalability of an ESB? It’s very easy to over-architect scalability requirements of an application. Mule scales down as well as up making it a popular choice for ‘building in’ scalability. However, there is a price to be paid for this since you are adding a new technology to the architecture.

  8. Do you understand exactly what you want to achieve with your architecture? Vendors often draw an ESB as a box in the middle with lots of applications hanging off it. In reality, it does not work like that. There is a lot details that need to be understood first around the integration points, protocols, data formats, IT infrastructure, security etc. Starting small helps to keep the scope of the problem manageable and keep the fuckupery to a minimum. Until you understand your architecture and scope it properly you can't really make a decision as to whether an ESB is right for you.

  9. Generally, always validate a product solution for your needs. Don’t choose an ESB or any other technology because –

    • It will look good on my resume

    • I don’t need the features today but there is a remote chance that I _might_ in future

    • I had a great golfing weekend with the head of sales


This checklist is not exhaustive, but will help clarify when not to use an ESB. Once you have decided that an ESB is a good fit for your project you’ll want to add additional selection criteria such as connectivity options, robustness, error management, service repository, performance, data support, etc. The important thing to remember is that there is no silver bullet for good architecture and you need to know your architecture before making a technology decision.

With this checklist in mind it’s easy to see that Erik’s example never needed an ESB in the first place.



However, if the architecture looked something more like this, then an ESB would have probably been a good fit.



Choosing Mule


Obviously, as the creator of Mule I have some bias for wanting everyone to use Mule. However, it is critical to the continued success of the Mule project and to MuleSource that users understand when not to use an ESB. Open source makes a lot of sense for enterprise software because projects need time to try out the technology and refine their proposed architecture. Having access to the product and source code helps a huge amount in this discovery process and allows the customer to make an informed decision.

In fact the MuleSource business model hinges on the ability of the user to self-select Mule and approach us only when they need development or production support. This has been working very well for everyone involved. Customers get to do a proof of concept (PoC) with our product knowing that if they end up using it for a mission critical application that they can get professional 24x7 support. For MuleSource it means that our customers buy from us rather than us selling to them, so they always get what they want – this is a far cry from the old proprietary upfront license model that used to hold the enterprise market hostage.

Monday, March 9, 2009

Ten Tips for Technical Presentations

Today I attended the morning session of Sun’s open source day in Malta. I was pretty disappointed by the quality of the sessions. These sorts of events cost time and money, doing them badly can do more harm than good. I don’t think Sun did themselves any favours today.

I thought I’d share some tips that I have picked up over the years that would have made today a better experience for the audience.


  1. Always introduce yourself and what you are presenting. I watched 4 presenters today where only one did this. I want to know who is talking and more importantly what the talk is about.

  2. Understand the single message you want to get across to your audience and make sure the presentation supports it. It’s very easy to try and include the kitchen sink when you have an hour with a captive audience. However, it’s better to use that time to get a single message across that trying to cover many different facets of the subject.

  3. Articulate the goals of the presentation and conclude with a recap. This seems obvious but a presentation should have an agenda. This clearly defines what you will cover and lets the audience know what to expect. The content should circle back on these goals and ultimately leave the audience feeling they learned something useful.

  4. Tailor your material to run in the time allotted. Two of the presenters apologized for having too many slides then proceeded to rush through the content. It renders the session pointless.

  5. Understand your audience. Most presentations I see the audience is usually curious but not an actual user. There is an art to presenting information to new users and I confess I haven’t quite figured this one out yet, but I am conscious of it and do seek other people’s opinions.

  6. Always provide the 'Why' in your material, all I heard today was the 'What'. Try and answer some fundamental audience questions such as-

    • Why should I give you an hour of my time?

    • Why should I use this project/approach/pattern?

    • Why is this method better than others?

    • Why will I remember this talk?



  7. It is almost inevitable in a technical presentation that you’ll want to look at code. Code and slides don’t usually work well together and IDE resolution is usually too small. Make sure that any code will be readable 30 feet away and ensure you don’t bombard the audience with reams of code that they cannot absorb.

  8. Always solicit feedback. You have a captive audience, use them to ask a few yes/no questions that will help you understand the level of knowledge of your audience. The feedback can be used when delivering the presentation right away and in future.

  9. Reduce technical jargon. You can only get across a couple concepts in an hour. Make sure you describe and reiterate these. Remember these should tie into the goals and overall message of the presentation.

  10. Learn from others. Use resources such as Parleys.com to watch other presentations. Note the ones you like and figure out why. Doing good presentations is a skill and like any other skill you need to practice and learn from others.


Also see: Giving effective product demonstrations.

UPDATE: Tadayoshi Sato has translated this post in Japanese. Thanks Tadayoshi!

Thursday, February 26, 2009

Gmail Fails, Cloud Computing Fails

While I don't go to the MotleyFool for my tech news, they ran an article this week about the Gmail Fail (or #gfail on Twitter). The Fool was in praise of Gmail because even though the service was down for a few hours some interfaces such as IMAP for the iPhone kept working (though this wasn't true for me). To me the fact that Gmail went down and affected people in Europe and the US was a big blow for the cloud exuberance we're currently experiencing. One of the benefits around cloud computing is being able to scale and utilise redundant machines if other machines fail. In this instance we had millions of users across continents lose email. What's worse it wasn't just the free Gmail service that failed but also their premium service. This means that the premium Google Apps service missed their SLA and Google have had to compensate (we got an email from them yesterday).

One can't help but see this as a blow for the Cloud since it shows how vulnerable we can be when we lose service. It also tells us that the one company who showed the world how to scale is not immune to severe outages. This incident didn't cost Google much, but most mission critical architectures that I have worked on would have suffered a 3 hour outage in a crippling fashion.

Does SalesForce go down all at once too? What assurances do we have in the cloud other than SLAs that can be easily broken? It is going to take a long time before companies will trust public SaaS services for anything remotely mission critical, they may never overcome that hurdle.

Wednesday, February 25, 2009

How SOA paved the way for Cloud

Though some think SOA failed and others see it only as a partial success, this has been because of the approach to SOA not its underlying principles. SOA (or what I’d rather call Service Orientation, but that doesn’t fit our obsession with TLAs) is responsible for beginning a new evolution in the way we build software. This change is as fundamental as the shift to OO programming but essentially a much bigger jump - OO was adopted one developer at a time, but SOA requires teams and departments to make the culture, technology and mind shift together. Where SOA has been most successful is evolving the way we build applications to the point where new deployment models become possible; enter the cloud.

There isn’t anything terribly new about the cloud. Virtualization (VMWare, XEN, Parallels, Hyper-V) has been around for a while, application scale-out solutions have existed in the forms of Grid computing (GigaSpaces, GemStone, Globus, GridGain, Paremus), Map Reduce (Hadoop) and distributed caching (Coherence, GigaSpaces). We could build clouds in the past, but there was a lot of work involved. Infrastructure as a Service (IaaS) was coined in 2006 and Amazon has been at the forefront of this movement. What changed recently was the ability to pull all of this stuff together in an easy way and the utility pricing model, driven by Amazon, has put all this technology in the reach of a far wider user community that couldn’t afford to play before.

In order for cloud to work, we also needed to change the way we built applications to run in the cloud. SOA has paved the way here, shifting our focus from building isolated applications that communicate using point-to-point integration to thinking of these applications in terms of services. Services are discrete pieces of logic that have a well-known contract and well understood function. This enables consumers to invoke services and execute their functions. The fundamental shift here is that you must think about how others will interact with your code. This is quite a big jump since most developers can happily develop in a vacuum and just get things working. In a service oriented application, your consumers may be your co-workers, other departments, the whole company, business partners or the whole world. The fact that other people will be using your services adds additional burden since interfaces need to be defined with consideration to hiding sensitive data, Security, versioning, data types, interface languages and a consistent API across services. SOA has been conditioning us to do this. For many organizations moving to the cloud is much easier because the heavy lifting has already been done. Applications that have been componentized into services are much better suited to the cloud, by their nature components are loosely coupled and can be hosted with location independence.

However, Moving your services to the cloud isn't necessarily a plug-and-play task. The cloud changes some of the rules for applications, I'll cover this in a follow up blog.

Tuesday, February 24, 2009

Twitter is Changing Community Dynamics


It seems the mirco-blogging platform is being used for a lot more than just posting links and banal commentary on the days events.

I am an avid user of TripIt for organizing my frequent travel schedules. TripIt works by allowing users to forward their travel arrangement emails to TripIt, which will then parse the emails and create a travel schedule for you. Genius. A couple of weeks ago I booked a flight from Malta to London, moments later I received my confirmation email and dutifully forwarded to TripIt. I know from previous attempts that TripIt does not parse emails from AirMalta, I raised this as an issue with TripIt a while back (I do between 10-20 flights out of Malta each year) and I still forward the confirmations just in case they added support in the meantime. As usual my confirmation email was rejected, so I tweeted my minor annoyance. Then something interesting happened, TripIt tweeted me back saying they’d like to fix the issue. Within the hour they had added support for AirMalta confirmations.

It occurred to me that the model of community support was changing. I had tried the normal channel support channel with TripIt but got no response, but now they had found me.

About a day later I tweeted that GMail IMAP support should expose an “Archive” folder so that clients such as the iPhone could archive mail. Within a few minutes I had a friend from Google raise the issue with the Gmail team and a couple of other responses from my, erm, Twuniverse tell me about a work around. There was definitely a pattern emerging. Rather than me having to sign up to a community and ask for help, I was being offered help.

I am usually a good community member, I join, I ask questions, I leave comments, I raise issues. However, these days I do not have the time to be actively involved with any more than two communities. With the shift of social media and the plethora of communities out there it has become impossible to be part of the 10 percent that actually contribute in some way to more than a couple of communities. The Twitter community model says that I don’t need to join a community to get assistance; I can write a 140 character cry for help and post it to Twitter. Forward thinking services such as TripIt will be trawling the sea of Tweets and can reach out to me. I’d call it the ‘message in a bottle’ community model.

The question is whether this model will scale if Twitter goes mainstream. Given the possible influx of requests it may become difficult to service those requests. However, large companies are having success with this approach. ComCast employee Famous Frank aka @comcastcares has demonstrated that it is possible to support a large user base one tweet at a time (there is a good article about ComCast in Wired this month). Famous Frank set out to help change the tarnished image of ComCast support and now has a team of people offering support via Twitter.

One reason communities are the way they are is so that users can talk with other users and self-serve by trawling the archives. The Twitter model doesn’t make it easy to view a useful history of the resolution. Also, with the restriction of 140 characters it will sometimes be necessary to switch to email or phone to resolve an issue. Finally, offering support like this means that a support issue is not created and tracked, which may be problem for some companies.

It seems there is an opportunity here to integrate Twitter into more traditional forms of support and community. Twitter can still be used as the communication channel, but the conversation can be logged and tracked in other tools to provide a ticket and searchable history. Surely this a job for Atlassian?

You can follow me on Twitter @rossmason

Monday, February 23, 2009

A New Chapter for MuleSource

It’s been an exciting couple of months for MuleSource. We began the year with 2 blowout quarters behind us. Last week we announced that Mark Burton, the former executive vice president of Sales from MySQL has joined the MuleSource board of directors. Mark brings a wealth of sales operating experience from one of the most successful open source companies to date. Mark has an excellent understanding of the different sales dynamics an open source company faces and has an uncanny ability to communicate his ideas on sales operations and strategy that makes you wonder why you never thought of them yourself.


The big news for MuleSource this week is that Greg Schott has joined us as CEO. Greg comes from SpringSource where was senior vice president of Marketing. He’s no stranger to open source and has a extraordinary understanding of open source business models and strategy. Greg also has a proven operation track record where he served as vice president of corporate development at Agile Software (acquired by Oracle). And served as vice president of marketing and vice president of operations at DG Systems. It's been a pleasure getting to know Greg and truly believe he is the right person to lead the team to build on the success of Mulesource. I am really looking forward to working with him.

Here is to the exciting next chapter of MuleSource, thank you for reading.

Friday, February 20, 2009

Pragmatic SOA Governance

I recently wrote an article that appeared in eBizQ on the topic of SOA governance. In this article, I argue that the primary reason that many pundits have declared “SOA is dead” is that the traditional “top-down” approach to SOA and governance have failed. Vendors have for too long evangelized a “big bang” re-architecture of development processes, using their tools to enforce new behaviors from developers, in order to realize the benefits of SOA. These approaches have failed because they make the average developer’s life more difficult, rather than simpler. Development teams, already stretched for time and resources, are generally reluctant to do extra work in the pursuit of some abstract notion of “service reuse.” Instead, modern governance approaches that are getting traction today actually help developers by integrating with existing tools and streamlining, rather than obstructing, familiar processes.

Read the entire article here.

What I didn’t talk about in the article was some of the real-world activity I have seen from MuleSource customers. The way our customers use Mule Galaxy - our SOA governance platform and registry - validates this new pragmatic approach to governance. For example, one user has incorporated Galaxy into their software development lifecycle, integrating their IDE environment using Galaxy’s REST API, making it easy for developers to find services. This user also stores services in the Galaxy repository, allowing them to enforce policies around their services, including WS-I BasicProfile and a number of security policies. Another user has service metadata defined within Java classes via custom annotations – using Galaxy and a couple of lines of Groovy code, they are able to automatically extract this metadata, publishing it in Galaxy for others to find and reuse. Finally, a third user pushes builds from their continuous integration system into Galaxy using the Apache Ant build tool, then using Galaxy to track the lifecycle information of particular application builds and services. Once a new service was pushed into staging or production, Galaxy’s application deployment feature (Mule NetBoot) could detect the change and automatically download and start that service.

In today’s world, it’s clear that the traditional top-down philosophy for SOA is outmoded and outdated – a new approach is needed for today’s organizations to see real value. The implications on SOA governance are clear – the focus should be on making things easier for everyone*, not about virtuous architecture; on improving existing organizational structures and processes rather than wholesale re-engineering; on implementing pragmatic tools at the work-group level (e.g., using open source tools) rather than embarking on massive enterprise-wide software implementations. Whether you are calling it SOA, composite applications, mash-ups, or any other buzzword of the day, only when the everyday IT professional sees the benefits of a new approach to development will the enterprise see value overall.

To see a live demonstration of Mule Galaxy, view this 7 minute screencast.

* Historically the role of the developer as a user of an SOA registry has always been overlooked. Martin Fowler wrote an interesting post on Humane Registries that touches on ways in which the right information can be tracked from a developers perspective to make the tracking of services more useful to developers (yes, Mule Galaxy supports tracking developer metadata outlined by Martin).

Monday, February 9, 2009

Android Predictions


Android is getting momentum with more phone vendors gearing up to release Android phones this year. While I don’t think Android is at par with the iPhone yet, it is a much more compelling platform for innovation. The openness of Android is a blessing and a curse. The community around Android will flourish since developers and startups will be more comfortable investing in an open platform. Open also means that the platform is subject to abuse and without regulation will suffer from low quality software. These factors and more will foster a new community of mobile vendors. Here are a few predictions-

Distributions


We’ll see a host of Android distributions (a la RedHat) crop up in the next 1-2 years. These distributions will provide a supported software suite with consistent behaviour and look and feel. As the Android Market gets flooded with applications it will be difficult for users to select the best applications. Having a consistent distribution managed and supported by a single vendor will be compelling for the mass market.

Certified Markets


Along the same lines as distributions, there is need to have a third-party assess applications for their stability, quality, behaviour and user interface. While the community can do much of this, we’ll see new Android markets that offer a certification process. There is always money in certification.

Enterprise Offerings


A common criticism of the iPhone and the reason that the Blackberry has done so well is that the Enterprise needs secure, robust messaging and support. This means integrating with Microsoft Exchange and Zimbra, but also providing secure groupware tools for communication and collaboration. I suspect there are folks already working no this. If you are, I’d be interested in hearing about it.

Entertainment


One thing that bugs me about Android platform is that it has the potential to be as good or better than the iPhone for entertainment. It’s going to require co-ordination with the phone manufacturers to enable Android to compete in this area. There are already applications cropping up to fill the lack of video support on the G1, but what is more important to me is that the phone manufacturers add simple features such a headphone socket. One killer feature of the iPod was the dock, since it grows an ecosystem of hardware vendors too. I hope the next generation of Android phones look to replicate this.

Device Diversity


The focus on Android is primarily on phone devices but it is clear that the operating system could be suitable for other types of devices such as tablets, netbooks and internet/media devices. In fact vendors have started hinting at more Android-powered devices such as the Archos Internet tablet.

Friday, February 6, 2009

Cloud: Defining the Undefinable

Given that the definition of cloud is still somewhat fuzzy and the terminology is already spiraling (yes we have Private clouds, federated clouds and heavenly cloud cakes), I decided (for my own understanding), to map out where IaaS, PaaS and SaaS sit. The bit I was struggling with was that PaaS has multiple layers. Big thanks to Alexis for helping to organize my thoughts on this.



The cloud itself is just a category that groups more concrete concepts together.

The next step would be to drilling down into these layers and defining what services are required for each one.

Making The Same Mistakes With Cloud

I’m watching the rise of the cloud with some disappointment. It was inevitable but still I hoped that we would take a more pragmatic approach to defining the cloud. The term cloud is being bounded around by almost all vendors, analysts and many technologists, but following the forums and blogs it’s clear we have very different views what the cloud means. I do find it amazing that so many companies are anchoring themselves to a concept so indefinable. This reminds me of how we all jumped on the SOA bandwagon earlier in the decade and I fear we’re going to make the same mistakes.

Like SOA, the concept of “cloud” is built upon a set of interesting ideas and principles that make a lot of sense. The underpinnings of SOA state that we should architect systems in terms of services to enable reuse, promote decoupling and enable systems to be agile enough to respond to the ever-changing needs of the business. At its simplest form, the cloud focuses on the way we deploy software and handle the need of on-demand scalability.

As we have seen with the SOA is Dead rejoicing, good principles can be vastly overshadowed by hype, leaving early adopters disillusioned. I blame this hype pattern on the vendors making wild promises about their technology (there is no silver bullet. Ever.) And to some degree the analysts who need to look into the future and set benchmarks that vendors feel compelled to reach. This doesn’t mean all vendors and analysts are evil, just that they help create market forces bigger than themselves, which vendors cannot resist in a competitive climate (case in point, listen to Larry Ellison: What the Hell is Cloud Computing?).

I am not in the “fuck the cloud” camp, but I do think they naysayers raise relevant arguments that cannot be ignored. We’re going to see an absolute mass of cloud “offerings” of all types of in the coming year with every vendor and his fluffy friend jumping on the hype wagon. Before talking about technical solutions, security and vendors I would urge consumers to consider the following questions:


  1. What are your expectations of cloud computing?

  2. What the key drivers are for considering a cloud solution in your organisation?

  3. What is the business value you hope to achieve and how will you measure it?

  4. What is the total cost? (Cloud is usually not cheaper, but sometimes easier to build out scalable infrastructure)

  5. How will a shift to the cloud affect your users, operational staff and developers?

  6. How will you manage the change so those affected feel empowered and see real value? (Change is always resisted, but will be accepted if value is demonstrated)

  7. How will it affect your existing infrastructure? How will you partition and manage it?


I am a huge advocate of taking a pragmatic approach to technology adoption. To me this means starting small and building on a proven track record. It’s good to have a long-term strategy, but break that strategy up into small manageable units of work that build on top of each other to enforce the value of the strategy. In the current economic climate we are already seeing customers doing this naturally. Big Bang projects are so 1999.

Monday, January 26, 2009

Stephen Fry on Twitter

I just posted about Twitter and then just found a link from @Scobleizer on Twitter showing and interview with Stephen Fry about why he uses Twitter.

Stephen Fry is not the only celebrity on Twitter, many others including Barack Obama was on twitter (until his account got hacked). Check out CelebTwitter for a full list folks you might know. I am currently following Johnathan Ross (@wossy), William Shatner (@williamshatner), Andy Murray (@andy_murray - hero of British Tennis), Lance Armstrong (@lancearmstrong) and of course my favourite, Stephen Fry (@stehpenfry).

Why Twitter?

I started using Twitter around the middle of last year as an experiment to see what the fuss was about. The idea of micro-blogging seemed banal to me, I couldn't understand the popularity of Twitter so decided to give it a go. Needless to say I have been sucked in by it for the same reason most other people. It provides a platform for effortless communication. I can ask things and get real replies in seconds, there is no pressure to read or reply to messages and I can tune in or out at my leisure.

Being on Twitter is like being at party (without the cocktails), there is a lot of idle chat that you can ignore but occasionally you pick up something useful or interesting. According to Robert Winston, participating in social engagements is one of the most taxing activities for our brain. Twitter shields us from those complex social exchanges and allows people to communicate their thoughts as they have them any time any place. I love using Twitter in London since its a great way to kill time while queuing (which is one of the top past times for Londoners).

Twitter may seem a little introverted to the outsider, but I now know more about my friends and the people that I meet than I could have possibly learned through normal communication channels. If I meet colleagues we talk about work, but on Twitter I also find out if they enjoy snowboarding, what movies they like or articles they find interesting. Twitter enables us to engage in a wider social network in a meaningful way.

Friday, January 23, 2009

Friday Fun: Beer

Heineken does it again!



What goes through your mind when someone says "lets go for a drink?"



Wednesday, January 21, 2009

iPhone is from Mars, G1 is from Venus



I recently got my hands on a shiny new G1 phone. Despite being a little jaded by all the promises made by phone providers in the past, I was excited about getting this phone. I am a fan of the iPhone for the most part and I had high hopes because the iPhone has been out for a while now giving vendors time to replicate and improve. However, the G1 is a completely different experience.

The G1 has a touch screen like the iPhone but doesn’t have some of the cool tapping features. Also, I don’t find the screen as responsive as the iPhone but I guess that can be fixed in the OS. The big plus is the G1 keyboard, which is very usable and sturdy (I’m not usually a fan of moving parts on a phone). The G1 interface is easy on the eye but needs the attention of a few UI folks to iron out some of the windozie-behaviour such as the “are you sure” dialogs. I would like to see a more finger-orientated interface. If you want to type you must flip out the keyboard, this can get a bit annoying when typing quick messages or names.

What was startling about the G1 was the complete lack of consideration for entertainment. The iPhone is designed around the very successful iPod, which makes the phone very appealing to a wide audience. I would think this is something to replicate, but the G1 offers a weak story here. There is an MP3 player but no support for video except YouTube, but most troubling is the lack of headphone jack. The do provide a pair of mini-USB headphones, but that ain’t a lot of use to the rest of the world.

Where the G1 excels is in the apps department. The integration with Google Apps means its very easy to work with email and calendar. At MuleSource we use Google apps for our internal mail and calendaring but with the iPhone I had to mess around with 3rd party calendar-sync tools all the time. It was pretty frustrating. With the G1 I see exactly what I would see on-line, no more dropped appointments or duplicates. The Gmail application is great because I can label and archive messages as I would in Gmail. My only complaint here is that the Gmail shortcut keys don’t work on the G1.

My gripe with the iPhone has always been that the phone itself sucks. This is something that the G1 has mastered, calls are clear and accessing the dialer is easy.

The reason I got the G1 phone wasn’t for the phone itself but for the Android platform. Being an open platform, I think we’ll see far greater collaboration between vendors and users on Android. I already find the applications on Android more innovative than the iPhone and believe the community around Android will increase the lead. The iPhone is an iPod with some bells and whistles, which makes it by far the best entertainment device out there. I’d like to see Android close the gap on the iPhone by acknowledging that a phone needs to be an entertainment device as much as a productivity tool.

Tuesday, January 20, 2009

The Server Formerly Known as Prince


I was in the pub the other night discussing Sun’s innate ability to confuse its customers. Sun has just announced that they are releasing a version of the Sun Java System Web Server version 7 as open source software under a BSD license, which is a shining example of a confusing product strategy. For those who aren’t watching carefully, or just don’t care this server has had more name changes than P Diddy. In fact, I didn’t know what “Sun Java System Web Server” was and who on earth thought that was a good product name? This server was formerly known as -


  • Netscape Enterprise Server (NES)

  • iPlanet Web Server

  • Sun ONE Web Server

  • Sun Java System Web Server


This is a classic example of Sun’s ineptitude in the Product Marketing department. Sun is changing for the better and many (including myself) want them to succeed. However it seems they are making the same mistakes with their next generation of product lines with their ESB offerings going by the name of JCAPS, OpenESB, GlassfishESB and Fuji. During the conversation in the pub no one quite understood how each of these related. Sun really needs to align their branding to build a complete story that is easy for customers and users to follow. It looks like they are heading that way with Glassfish, but people are still confused. Sun has a load of great products to offer and is still making acquisitions; it is imperative that they build a better product marketing strategy.

By the way according to comments on InfoQ, Java System Web Server version 7 does not include Admin tools or support for dynamic web content. The Web Server race was won by Apache WebServer long ago, I'm not sure Sun would bother spending time on this.

Monday, January 12, 2009

How to Define Services

Defining what constitutes a service when building service-orientated applications seems to be a common problem for developers and architects who are new to building services. The main issue seems to be the scope, i.e. what is the granularity of the service. This is actually quite difficult since the granularity of a service can vary depending on the application. The trick with any fuzzy problem is to break it into smaller pieces. There is a very simple service taxonomy defined in Thomas Erls SOA in Principals of Service Design book which I believe makes the approach to defining services much easier.

Essentially you can group services into 3 categories –

Utility Services
– These are usually fine-grained services that perform a single function. They are the most reusable.

Entity Services – These are services that model something concrete in your application (When I was at University, Entity Relationship diagrams were all the rage, we’re talking about the same sorts of entities here). These are business centric services that may model one or more entities in the organization such as Customer or Ledger. These types of service are highly reusable within the context of the organization.

Task Services
– These types of service typically model a specific function or process. They tend to compose or orchestrate other services. These are less reusable since their function is very specific.



Thinking of services in terms of task, entity and utility will make it easy to extract service definitions from your problem domain but it will also help to define the granularity of the service, i.e. you wouldn’t define utility or task functionality in an entity service. This makes the job of defining services much easier and ultimately your services will be of a higher quality and easier to consume by your users.

Sunday, January 11, 2009

Got the kites, now where's the wind?

I finally got my kiteboarding stuff yesterday after a TNT mix-up between New Zealand and here. I'm proud owner of 2 Slingshot Rev 2 kites and and an Underground FLX 35 board.

What I need now is a App for the iPhone and/or Android for tracking the wind. Everyone I know uses WindFinder. They have good mobile browser support and there is a great OS X Dashboard widget, but alas I haven't found any Apps for the mobile platforms. There are some good ones for snowboarding, sailing and surfing, but not kiteboarding yet. Is anyone working on one?

Thursday, January 8, 2009

Did SOA Just Die?

There is an interesting post by Anne Thomas Maines from Burton Group exclaiming that SOA has gone the way of the Dodo:

Once thought to be the savior of IT, SOA instead turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever.


Of course the part we all want dead is the vague, hand-wavy, SOA hype. Those that bought into proprietary-SOA and its heavy-handed, “big bang” approach lost out and everyone else got sick of fuzzy SOA promises. But behind any hype in the enterprise space you can find good ideas. The fact is that the ideas behind SOA are as important to us (the distributed masses) as Object Orientation was to the development of complex applications. The difference is that OO required that a single developer to think differently, SOA requires a whole organization of people to think differently-

Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates.


I believe this is true to a greater extent, but the large vendors have sold this "massive-shift" to companies with a hefty license price tag and endless services engagements. The fact that SOA requires a fundamental change has been the undoing of traditional SOA initiatives. The main hurdle that is often overlooked is the natural human resistance to change. The challenge of SOA is to be able to demonstrate change in a way that is recognizable by the people it affects. It doesn’t mean hooking together an suite of enterprise tools and dropping documents of new processes on peoples desks.

For Service Orientation (lets drop the A shall we?) to succeed it is important to understand the impact of change on the processes and people affected. The technology just helps facilitate this change; it does not provide the complete solution.

The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change.


I disagree that “spectacular commitment” is required. If this was so, we’re in real trouble because anyone that’s worked in a large company knows that it is difficult to get commitment on anything. What we have found at MuleSource is companies have a lot more success when they do start small with a view to a grander goal. Small means manageable, it means there are only a few stakeholders and it means many risks are mitigated. Starting small means a team can test the waters, not just with technology but also assess how these changes affect people and processes. When a project is small the number users affect by the change is smaller and easier to obtain feedback and educate. One of the key benefits of Mule being open source is that people can try introducing Service Orientation without the hefty cost of entry.

The other thing we’ve learned is that for Service Orientation to take hold the people affected must be able to recognize the value of the changes they experience. Once you get buy-in from users its much easier to affect further change without hitting their pain threshold. Conversely, the traditional SOA “big bang” approach creates an unmanageable amount of change that is often impossible to correct and the project usually fails.

I’ve seen firsthand the struggles of the SOA approach and fundamentally the organizations that succeed are those that recognize Service Orientation is an evolution not a project. Lets hope the SOA hype died so we can focus on the value of Service Orientation.