Open Source SOA – Are we there yet?
I am often asked whether open source (OSS) SOA is a reality yet – whether it is ready for prime-time, as they say.
The answer, as is often the case, is ‘It depends’. There are many OSS projects in the marketplace around ESBs, Integration and SOA, but just having a project in place is a long way from having production-ready software. For a start, there are the questions of maintenance, support and even indemnification against possible future legal activities. The most useful projects are those that have an associated commercial company addressing these types of areas.
However, the other aspect to consider is that most opern source projects are started and driven by technically adept programmers, so they tend to be oriented towards programmer usage. In SOA, this may be acceptable, depending on requirements, but it may also be desirable to have a solution more oriented to business analysts. They key is to be clear on what you want, and on what is being offered.
For a longer discussion on this topic, Lustratus has just published a free assessment of one particular OSS integration vendor, MuleSource, and its open source offering Mule. This paper considers a number of these types of key questions over OSS SOA, but of course in the MuleSource context.
Steve
Posted in enterprise service bus, esb, Imported, Mule, MuleSource, Open Source, SOA, SOA developmentThe onward march of Linux falters – any lessons for OSS SOA?
Linux may be reaching a natural plateau with regards to corporate adoption as a UBS survey reported that 90% of CIOs not currently using Linux will not make the leap in 2007 (this is up slightly from 87% in 2006) according to a UBS survey reported on here and here.
In effect this means that those who are open to Linux are already using it and the hold-offs are mostly not about to change their minds any time soon. This should not be regarded as some sort of ‘peak Linux’ type event as organisations already using Linux in some places will continue to extend their usage of the OS. The report also reinforces the point that Linux is mostly replacing Unix rather than taking market share from Microsoft which is sometimes characterised as the target of Linux. All of which really means that Linux is coming to the edge of its natural market – UNIX shops which can easily switch – and will struggle to break into organisations which are traditionally Microsoft only. This does not mean that Linux is not wildly successful and making a lot of money for companies selling services around it.
Turning to OSS and Service Oriented Architectures, are there any lessons to be learnt? At one level the Linux story bears very little relationship to SOA based projects – Linux was about the commoditisation of very mature specifications and technologies while software associated with SOA is comparatively immature (when compared to Linux/UNIX) and lacking in any specifications in many cases. Also, with Linux the old established industry giants now rule (IBM et al with the exception of Red Hat as a new giant). In contrast, OSS SOA is still mostly the preserve of startups (such as Mule Source , Bostech and Sopera, as well as some integration specialists (IONA) and … Sun and Red Hat.
As I said above, Linux may be plateauing but at a huge scale. Inevitably, OSS SOA will also reach its natural extent but the risk is that it may reach it before the service providers can achieve viable scale because right now the market for OSS SOA is large enterprises with java skilled developers who are willing to even consider the risk of replacing closed source integration products. This is a finite market with a lot of incumbent solutions. Moreover, this is a very tough market for any new solution: evaluation processes are becoming more and more extended and even if selected the project may well be dumped as IT budget continue to be stretched. [One could argue that the same challenges face the 'closed source' vendors but in their case they are able to extract more revenue from a small pool of customers and remain financially viable.]
Am I therefore saying that OSS suppliers are doomed in SOA? Not at all – I believe that there is an opportunity for these businesses to succeed (and become the RedHat of integration perhaps?) but it will be a tough going. In particular, it is a lot harder than suggested by most coverage of OSS which focuses on huge download rates and arguments such “Its free, developers love it, everybody will use it” and ignoring the real world issues around adopting any enterprise integration technology (which are mostly not related to the license fees).
Of course the OSS suppliers already know this and are developing different strategies to address the problem. For instance, Mule Source is particularly focused on promoting community based development of additional components such as application adapters and transports – thereby deeping their engagement with customers and making it easier for customers to get a ‘complete’ integration solution – and has recently launched MuleForge to support this effort. IONA has been buying OSS expertise and has relaunched its OSS efforts (now called Fuse) deliberately focusing on the most popular Apache SOA-related projects with the obvious benefits of existing customer base and large pool of developers. RedHat is also acquiring technology to provide strong data management capabilities by open sourcing MetaMatrix which is currently closed source. Other suppliers have different ways to crack this nut but whether any of these strategies will succeed or fail is of course more complex than can be easily covered in a blog entry of reasonable length – however we will be addressing the area in upcoming Lustratus papers.
Ronan
Posted in Bostech, enterprise service bus, esb, Imported, IONA, Mule, Open Source, Red Hat, SOA, Sopera, Vendor newsIs your legacy integration just a veneer?
Summer seems to be a time for reading through that huge pile of interesting articles and magazines that you can only find time to look at on vacation.
On flicking through my own mountain of stuff, I came across the Q2 edition of Financial-i, a magazine targeted at the Financial Services industry. One point to jump out at me was a comment from Paul Joynt of Nordea, a Scandinavian finance house. Paul was pointing out that SOA does not necessarily solve the problems associated with legacy integration.
The article, ‘SOA – is it worth the effort’, is available from the Financial-i site if you register, but Paul comments that covering a legacy system with a wrapper “so it looks like what you want” still leaves problems with the next level of change, because “it’s only a veneer”.
I think Paul has hit on an important point here. Different vendors in the SOA space have different approaches to addressing the problem of integrating legacy systems. Some will simply ‘hand off’ the request for legacy information to a tool from the legacy supplier – in the case of IBM mainframes this might mean using WebSphereMQ as the bridge, for instance. Others might approach the problem in some sort of screen-scraping or other interface simulation approach, where the legacy application is fooled into thinking it is running in its normal mode of operations. Yet more may generate code-based wrappers for each individual need, to be executed whenever a particular service is required.
To me, this all sounds too much like veneer in Paul’s terms. Although this might address immediate needs, future changes will continue to generate substantial additional work and the generation of more and more ‘special-case’ code and wrappers.
Instead, the best of breed legacy integration solution should embrace SOA and integration rather than try to fool it with wrappers designed to seal off the legacy world from the outside. Legacy integration should be about making the legacy system a full and active participant in the service definition and execution. For example, orchestration should be possible both outside and within the legacy environment. Services should be built with full participation from both sides. By taking this approach, the best of breed legacy integration tool will ensure that future changes will become easier, quicker, cheaper and more reliable.
For more information on the whole subject of legacy integration, specifically in the case of mainframe systems, Lustratus offers a free paper on the subject.
Steve
Posted in BAM, enterprise service bus, esb, Financial Services, Imported, legacy systems, SOA, SOA development, Web ServicesThe Year of ESB-ability
Recently, I wrote about the ESB (enterprise service bus) maturing at a basic functionality level, and how the focus was swinging around to the ‘-abilities’ such as scalability, availability, usability, manageability, etc.
There is also a free paper on this subject, available from the Lustratus web store, available here.
I noticed my post generated a number of responses from various people. These were all on a theme which I found quite amusing. The accusation was that ESBs are NOT mature – but the posts then went on to demonstrate exactly what I was saying. Take, for example, the illustrious Jame McGovern’s excellent blog on Enterprise Architecture. In his wrap-up of links for 2007-08-05. James discusses my post :
Another industry analyst gets it twisted by stating: the ESB concept has matured, the functionality checklists are of less value – everyone ticks most of the boxes which holds true if you decide to ignore enterprise security considerations.
David failed to consider more carefully what I said about basic ESB functionality. My point was that now that ESBs in general can support the basic functions of an ESB – pass messages from component to component with mediation services available in-flight for enrichment etc, support key standards such as web services etc – that attention is turning to the functionality surrounding these basic operations. That is, the characteristics and all those functions to actually make the thing usable in a production environment. If David had gone on to read the Lustratus paper I referenced, he would have seen that security was classified as an honourary ‘ability’ and is indeed one of the types of functions that people are now demanding.
Other posters fell into the same trap. So, I think we are actually all in riotous agreement. I may not agree with the next bit of David’s post about the need to support such standards as SPML, XACML and WS-Federation, but that is largely because I can never keep up with the stream of new standards, and as most people know who read this blog regularly, I have a highly cynical view to many standards – particularly to WS ones outside of the obvious and more mature ones, as I outlined in my post on WS-Madness.
Steve
Red Hat: The last ESB start-up?
As part of my work prior to updating of “Best of breed ESB” paper, I was recently briefed by Red Hat about their current ESB and SOA related projects which will become a supported ‘product’ called JBOSS Enterprise SOA Platform towards the end of the year.
This puts them rather late in the game when compared to both open source and closed source offerings. Combined with the focus of the briefing on functionality over value, it felt very much like I was talking to the last ESB start-up to appear.
As a characterisation this should not be taken a wholly negative: For a company the size of Red Hat with its strong JBoss application server franchise, it would not have been surprising if they had simply done a me-too ESB to match that available from other stack vendors. Instead they are putting together a much more interesting set of capabilities but lack some others that will required for most serious enterprise use. On the positive, they seem to have a good grasp on the importance of data within SOA including both their MetaMatrix acquisition– once it has been open sourced – and pipeline based transformation (allowing complex manipulation of messages in-flight often required within deployed SOAs). Counter-balancing this, there is still much to do around service life-cycle and in particular how to support service reuse. I won’t attempt to go into much more detail at this time until the report is completed.
Ronan
What is a best of breed ESB (four years on)?
Four years ago my colleague, Steve Craggs, wrote a seminal paper for the Integration Consortium called “Best of Breed ESB” (available from the Integration Consortium web-page and some other places such as here).
It was seminal in that it put an early stake in the ground defining what to look for in an ESB. At the time, the concept of an ESB was pretty new and the definition was very vague (usually a single sentence from Gartner). Four years on the ESB category has matured – the major vendors now all have something they call an ESB – but there is stil confusion to dispell and diversity in product offerings which we will be covering in an upcoming new edition of this paper.
Back in 2002, Steve’s paper set the ground rules for what to look for in an ESB by setting out and discussing what users should expect to see:
“Fundamental ESB characteristics:
• XML, messaging, transformation, intelligent routing services
• Basic connectivity (Web Services, J2EE Connectors, JMS)
• Service-oriented architecture
• Support for highly distributed deployments
• Manageability
Key, value-add characteristics:
• Robustness
• Scalability and Performance
• Security
• Breadth of connectivity
• Development / Deployment toolset”
Unlike many of the analyst papers that followed it did not simply provide a lengthy ticklist of standards to be adhered to – rather it discussed why capabilities are needed and what alternative approaches were taken by vendors to provide those capabilities. This was particularly important as not only did it clear confusion and FUD that was already gathering in the space, it also reflected the reality that the diversity of use cases and organisation types considering ESBs meant that there could be no single magic ticklist. Back in 2003 when the paper appeared, I was CEO of PolarLake, one of the first ESB vendor, and it resonated because it solved a major problem for vendors and buyers alike: It provided a framework for matching requirements against products and comparing products.
Four years on looking at the vendor offerings, while the basics are now settled there is even more diversity at a value-add feature level as well as new market dynamics (OSS has become a major force in ESBs). On top of which, great diversity remains in use cases. For these reasons, now seems like a good time to update and revise Steve’s earlier work and I am now in the process of producing a new Best of Breed ESB paper. While taking a simiar approach and covering some of the same bases, there will be a very different focus reflecting the major issues being faced by users today. In particular: how do ESBs help with the SOA skills shortage and how do they support service reuse – as well as a whole raft of deployment issues. The paper should be out in September as I am now in the process of being briefed by vendors.
Watch this space…
Ronan
Be fair to OSS – lay off the sauce
Open source software has come on by leaps and bounds over the last ten years or so.
There are more and more examples of credible OSS (Open Source Software) solutions available today, including well-known brands such as Firefox and LINUX. However, OSS seems to me to face a major enemy – itself.
The problem is that, deep down, the OSS community can sometimes see itself as a bastion of freedom against the evil commercial ISVs – certainly some of the more vocal supporters of OSS are guilty of making more and more outlandish claims about their own projects, really pouring on the sauce. Some of this is to be expected, of course, but there comes a point when fanatical over-statement of the facts can so offend credibility that prospective OSS users are turned away.
I was reminded of this problem by a recent article by Dennis Byron, writing for ebizQ. While I found the article both interesting and informative, the section on enterprise service buses (ESBs) illustrated my point. In the article, Dennis states
ESBs are especially interesting because they may turn out to be the first category of software code that was OSS from the get go.” And later, “The OSS movement in turn blocked those early non-OSS ESB market leaders before they could gain a lot of traction.
The ‘early non-OSS ESBs’ phrase refers to companies such as Progress, Cape Clear and Fiorano, according to the article. This is the type of hyperbole that in my view causes the OSS movement to weaken its own credibility. The implication is that OSS has ruled the ESB market from the start, apart from some minor incursions by early ESB vendors such as those listed.
Now, I will agree that OSS ESBs are maturing nicely – the Mule OSS ESB, for example, already lists a substantial number of production implementations on its website. I think that as time goes on, these OSS offerings will become more and more competitive to the commercial offerings. However, to state that ESBs were ‘OSS from the get go’ is just ridiculous. For the first three years of the ESB market’s life, the only serious usage was with commercial offerings. While it may be true that some of the early players failed to gain much traction, there are now commercial ESBs available from all the major vendors such as IBM, Oracle, SUN and BEA, and some of these are performing strongly in the market.
I believe the OSS cause is best served by a more realistic assessment, without all the sauce. We are now at a stage where OSS ESBs are a viable choice alongside commercial offerings. There are references for successful usage of OSS ESBs, and the future appears to be bright – for example, OSS solutions with a supportive community could result in pools of less common adapters being available to satisfy a wide range of needs, something less likely to happen in a commercial world. But to state that commercial ESBs never made it, and OSS ESBs ruled the roost from the start, is in my opinion a wild exaggeration.
To be fair to Dennis, later in the article, while discussing message-oriented middleware and the impact of OSS offerings here, he states
But it will be well into the period 2011-2020 before commodity MOMs/ESBs significantly displace IBM MQSeries and like products.
This comes across as more realistic, and hence makes a far more credible claim. MOM (Message-Oriented Middleware) products like MQSeries are much more extensively deployed that ESBs, with many thousands of users, and therefore even if there were attractive OSS alternatives (and this is definitely arguable today) it would take some years for any significant displacement to happen.
Steve
Which ESB for me?
The Enterprise Service Bus (ESB) came into parlance around five years ago, and in the intervening years it has matured.
As a result, most ESBs offer common functionality, at least at a basic level. So how should people decide which ESB to choose when going through product selection?
When I wrote the first paper on ESBs, ‘Best-of-Breed ESBs’, all those years ago, the questions to be answered were all around the definition of this new thing called an ESB, and what functionality it supplied. In that paper, I offered checklists of functionality to identify whether a product fitted the ESB definition, and how well it covered the functional requirements. Of course, as the idea became popular the ESB definition got severely mangled by analysts and vendors as each searched for an angle, but the functionality has remained largely agreed at least at the basic level.
But now the ESB concept has matured, the functionality checklists are of less value – everyone ticks most of the boxes. Instead, users seem to be focusing more on the characteristics of different ESBs as they try to make their purchase decisions or validate their original decisions. So now, the differentiators between ESB suppliers tends to be about what I call the ‘-abilities’ – that is areas such as scalability, manageability, availability and usability. In other words, given that most ESBs ‘do what they say on the box’ in functional terms, it is now more important to understand how they will serve the production environments for which they are destined.
Expect more focus on the ‘-abilities’ as ESB vendors strive to improve their competitive positoning. For anyone interested, there is a free Lustratus Insight on this topic, ‘The Year of ESB-ability’, available from the Lustratus webstore. We have also decided that the time is right to produce a new version of the original Best-of-Breed ESBs paper to take the new level of ESB maturity into account, which we hope to make available in the next few weeks.
Steve