Enterprise service bus (ESB)

Another take on OSGi

Last week, WSO2 released an update tailored around OSGi to its SOA framework. Rob Hailstone, analyst, The Butler Group told us that he rated the WS02 implementation favorably, because it ”does seem to have built out a more comprehensive set of features than most of the competitive open source offerings.” Continued »

Light-weight, open-source themes discussed at Sun GlassFish Portfolio debut

By Jack Vaughan
Sun Microsystems is attempting to move deeper into the world of open source software with its Sun GlassFish Portfolio. Now included are a light-weight LAMP-style stack (which itself includes Tomcat, Memcached, Squid and Lighttpd with support for PHP, Ruby and Java) a Sun GlassFish Liferay-portal-based Web Space Server, and a JBI-base ESB. A proprietary Sun Enterprise Manager for monitoring is also available.

GlassFish has arisen as a potential lightweight alternative to established J2EE application server architecture - but Sun likes to note that GlassFish can span from the light-weight to the heavy-weight solution.

There are indications development may diverge into a lightweight, or LAMP camp, and a heavier J2EE style. “We want to break down that chasm,” said Paul Hinz, chief architect, Sun. He said GlassFish Webstack modules support LAMP development scenarios. These do not require application servers. Yet a GlassFish application server is available too, with JEE5 compliance (and a JEE6 preview in the offing). That server supports JRuby and Groovy development, marking Sun’s embrace of languages beyond the realm of Java.

Sun is hoping to leverage the success of the MySQL database, purchased by the company last year, in packaging that pairs GlassFish with MySQL.

Kevin Schmidt, manager for infrastructure strategy, said the GlassFish ESB provides routing and messaging, using JBI. The core backbone is not JMS, it is JBI,” he said. “It is a normalized message router done in-memory.”

The Sun GlassFish Portfolio is said to be available immediately via a subscription-based pricing model starting at $999 per server.

The MySQL merger appears a bit rocky, just as Sun looks to extend MySQL popularity with GlassFish-powered offerings. Both Marten Mickos, former MySQL CEO, and Monty Widenius, a MySQL co-founder, have recently left Sun.

So how SOA are ESBs?

Last week we at SearchSOA.com ran a story about how ESBs aren’t as interoperable as users might expect them to be. The story prompted a response from StrikeIron CEO Dave Linthicum, basically wondering if the bigger problem here is bad architecture. He wrote:

Call me crazy, but would it not make more sense to have a centralized plan as to what the SOA should be, based on the requirements of the business, versus people dashing out and shelling out the dollars for an ESB for some one-off tactical reason, or more likely just acting out of reaction to the hype? Now, you’re left with a dysfunctional mess that’s not easily corrected, and clearly costly.

Joe McKendrick over at ZDNet picked up on that and put together a brief history of ESB criticism. Linthicum’s blog entry also drew a lot fire down in its comments section (be sure to check them out as iTKO’s John Michelsen, the interviewee in our original article, makes a few points on the unavoidable nature of multiple ESBs). The response in fact spurred Linthicum to write a follow up entry addressing some of the critics of his first entry. After pointing out many of the dysfunctional things he’s heard over the years, he wrote:

[W]hat I’m asserting is that there has to be some architecture forethought behind dragging any technology into the enterprise, and I suspect that’s not occurring.

To be fair, he doesn’t suspect it. He knows that’s the case. We all know that’s the case. As Software AG’s Miko Matsumura put it in another article we ran last week, “People are addicted to messed up IT.”

Anyway, Linthicum finished his latest post with a request:

So, in the spirit of having an open mind, send me your reasons for leveraging multiple ESBs, and why that’s a good approach for your enterprise architecture. Also, while you’re at it, make sure to send me the reasons you’re using an ESB to begin with: your requirements and the reasoning behind the solution. I won’t post them unless you say it’s okay.

It’s an interesting topic, so make sure to send Dave your reasons, if you’ve got some. For my part, I know a lot of people who despise ESBs. During one interview I did with an analyst back in 2005, he referred to ESBs at “methadone.” This was actually praise for the ESB, making the case that it was better than EAI. Yet I know others who just as adamantly argue that at some point you’ve got to implement a service or pull together applications after a corporate merger, and at that point you will find yourself wanting an ESB.

Earlier this year, I actually did a podcast with Mulesource CEO Dave Rosenberg about why he maintains that enterprises will need to accommodate multiple ESBs inside their SOAs.

I would argue the larger point here, and this is where Michelsen was focused in the original article, is that multiple ESBs are a fact of life. No matter if it may be sub-optimal in terms of architecture, a good architecture should be able to tackle this kind of problem, or at least good governance should help ameliorate it. Mergers and acquisitions will happen. You will need to combine services with outside entities. Different divisions will buy disparate products, even if they shouldn’t. This doesn’t even touch on technology creep from the open source arena.

So it’s really two questions. The first is do you even need one ESB let alone many? It’s a fair question and one that every end user ought to put serious thought into answering. The second is, how do you deal with multiple ESBs in your infrastructure? Because no matter how you answer the first question, you will need to manage this situation for at least the near term.

Having trouble with SOA? Pay attention to the architecture

There are some anecdotal claims out there in cyberspace that some companies are struggling with SOA. Mind you, we never really hear who these companies are or much about the details of what kind of trouble they’ve had.

That makes it hard to assess what the problem is. Are these users actually pursuing service orientation or are they buying products with an SOA label and expecting them to work miracles? I suspect the latter is a common trait of those who feel they haven’t gotten enough bang for their SOA buck.

Here’s one thing I can tell you: I’ve lost count of how many slide show presentations I’ve seen on SOA, but in every success story presentation I’ve ever seen there is an architecture slide. For instance, when I saw a presentation in April by State Street Corp. centered around how it’s using an ESB for the messaging involving the $15 trillion in assets in has under custody, the slide show did not proclaim ESBs are great and everyone should have one. Instead it delineated where the ESB fit inside State Street’s architecture, what role it served and how it played with other critical functionality in achieving the scalability, reliability and high performance that State Street desires.

If you can’t produce a representation of your architecture and then demonstrate that you’ve actually built systems in accordance with that architecture, then you can’t claim to be doing SOA. You may have undertaken a Web services project or bought some product that might be able to help you with an SOA if you had one, but there is no getting around the primacy an architectural blueprint. Those who lack it are begging for trouble.

Interestingly, in our user survey last fall, readers reported that the top SOA development challenge they are facing is a lack of internal skills or training (30.5%). Nothing else even came close. It’s no secret that the supply of architects who actually understand SOA is lagging behind the demand. Yet the discipline involved with service orientation is far from obscure.

Recently we ran two articles from Thomas Erl about the difference between service orientation and object orientation (second part here). We also recently published some architect best practices. And if you need an example of what can be achieved by adopting a service orientation perspective and paying attention to your architecture, look no farther than this case study from ING Card. ING adopted exactly no new technology when it first waded into the SOA waters and was able to streamline its international credit card business. They were able to do this because they had an architecture at the core of the business plan.

Analysts often wear themselves out reminding users that SOA isn’t something you buy, it’s something you do. Well, architecture is the something you do.

Podcast: Mulesource CEO on why SOA requires many ESBs

This podcast with Mulesource CEO Dave Rosenberg covers the role of the enterprise service bus (ESB) inside an SOA. Rosenberg notes that an ESB shouldn’t be thought of as a singular piece of software sitting in the middle of every application, tossing aside the hub-and-spoke model from the EAI world that often gets grafted onto SOA. He stresses that SOA “is not about integration,” but rather a sensible infrastructure that can handle modular development and changing business needs.

 

 Standard Podcast: Play Now | Play in Popup | Download

Other topics covered in this interview include:

• How users are more likely to have an “enterprise service network” with multiple ESBs rather than a single or master ESB
• The role of open source in SOA development
• Why neither the Java EE nor .NET meets are well-suited to service orientation
• The roadmap for the Mulesource, particularly in the management area
• What constitutes “SOA infrastructure”
• Data issues, including getting data out of 3rd party SaaS applications

Highlights from the “Pragmatic SOA Governance” seminar

We at SearchSOA.com have just finished up with the maiden run of our “Pragmatic SOA Governance” seminar. The first two shows were in suburban Philadelphia and Washington D.C. and I’m pleased to report they went swimmingly.

Here’s a few of the high points from the show:

• Anne Thomas Manes, VP and research director at Burton Group, noted that a lot of users want to standardize on a single enterprise service bus, neglecting the reality that most every company will need to support multiple ESBs. She also suggested not thinking of the ESB as a “bus” because it implies that there’s something in the middle of your services. Instead she suggested the term enterprise service network.
• Miko Matsumura, deputy CTO at Software AG, used the image of a crack pipe to illustrate a point during his presentation, namely that bad development habits can be hard to kick.
• Daud Santosa, CTO at the National Business Center inside the U.S. Department of the Interior, made a great point about choosing foundational pieces of technology — if the technology in question requires consistent and costly upkeep, then it shouldn’t be a foundational piece of technology. “This is hard enough,” he said, pointing to the detailed reference architecture he’s trying to implement at NBC. “Look for technology that makes your life easier.”
• Dan Foody, VP of Actional products at Progress Software, made a great observation in response to a question on how can you sell your business on the merits of SOA: take a sales course. His reasoning was you need to describe what service orientation means to your business and outside IT fiefdoms and that will require real professional sales skills.
• Many attendees bemoaned the communications difficulties that plague IT projects, but Matsumura offered that there is a common language everyone speaks: money. The line drew a hearty laugh from the Reston attendees, but later one person from the audience mentioned to me that the “money” line helped crystallize what he needs to do to get executive buy-in.
• John Woolbright, CTO at Synovus Financial Corp., noted that many real-time systems are undone due to a lack of data quality. He suggested defining systems of record for data. “If you want your SOA to be successful you need to know where that data is and how to access it.”
• Foody stressed creating visibility not only into the IT infrastructure, but to the business process itself. Failure to provide that visibility can lead you down the path of applications that don’t deliver as promised for the business, he noted.
• Manes continually stressed the importance of getting a handle on the producer/consumer relationship inside SOA as a key element for governance. Apparently too many users are running into problems caused by unchecked service consumption.

Most of all, a hearty thanks to our attendees. Rarely do you see audiences that are anywhere near that engaged during the presentations. It served as reminder that the practical implementation of SOA governance has become a pressing concern for app dev and IT shops.