This is the problem of relating your blog to a geographic formation. I am no longer living on a small island, I have moved to San Francisco. My blogging has a new home too at MuleSoft.
Thursday, August 12, 2010
Tuesday, March 16, 2010
I had a great time at Qcon London last week, it really is one of the more forward thinking conferences out there for the enterprise. I gave two talks on ESBs and Enterprise Mashups so I figured I'd share the slides.
ESB or not to ESB
The ESB has become synonymous with integration. While the ESB grew from the needs of enterprise integration, the landscape has changed and not every project that needs integration needs an ESB.
Increasingly, web application developers need to integrate with both public and enterprise services. This has evolved to the point where the presentation/logic/data tier model is limited since applications need to be connected to other applications and services.
This talk will provide insights about when to select an ESB, and when not to. We will also look at other alternatives for integration such as Web and REST services, and other frameworks.
Enterprise Mashups: why do I care?
Enterprise Mashups are important since they bridge a void between the web and the enterprise behind the firewall. They break down traditional barriers around data and open up powerful new ways for enterprises to leverage the web as a platform. This session will introduce some mashup concepts, discuss a number of software patterns and describe ways in which enterprises could do more with their applications, and provide a good grounding and practical knowledge about the emerging trend of Enterprise Mashups and how they might apply to the enterprise.
As the barriers break down developers should have an understanding of the implications and how the pieces fit together. Attendees will learn what enterprise mashups are, what they are not, and get to know some mashup patterns.
This session will conclude with an introduction and demo of iBeans, and new open source framework aimed at web developers to make common integration tasks much easier.
Friday, December 4, 2009
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
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
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 –
- 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.
- 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.
- 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.
- Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing? Many applications do not need these capabilities.
- 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.
- 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.
- 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.
- 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.
- 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.
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.