Dr. Robert S. Sutor

Subscribe to Dr. Robert S. Sutor: eMailAlertsEmail Alerts
Get Dr. Robert S. Sutor: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, SOA & WOA Magazine

J2EE Journal: Article

The WebSphere/SOA Connection

Updating your wiring

One of the major architectural themes for WebSphere Application Server Version 6 is its support for service-oriented architecture (SOA). IBM has supported Web services in various products for over four years, such as earlier versions of the application server as well as the WebSphere Business Integration Server Foundation, announced in April 2004. In v6, we have focused on support for standards such as J2EE 1.4, SOAP, WSDL, WS-Security, and WS-Transactions, and we've also made sure we had powerful, easy-to-use and easy-to-configure components such as the new JMS engine.

Though they are certainly connected, SOA is bigger than Web services. It is very reasonable to ask why there is all this interest in SOAs now versus, say, two years ago or two years hence. There are, in fact, several reasons, but let me focus on one in particular.

Web services appealed to a lot of people because it felt like a reasonable part 2 to the exploitation of the World Wide Web for communications between businesses and organizations. The Web set tremendous expectations in that when you put a URL in your browser, you didn't have to think about whether the page was going to be served up by WebSphere on Linux or z/OS, or BEA on Solaris, or Microsoft on Intel. Actually, that is not quite true because while I do 95% of my Web browsing using Firefox, there are still some sites that require Microsoft's Internet Explorer. Nevertheless, it is a great testament to standardization that so many sites work with so many browsers.

Before the Web came along, we had companies like Prodigy and AOL that had fairly closed environments. You called their phone numbers and you got their content. You had to use their clients to view that content and the navigation schemes were standard only to their worlds. The Web and standardized browsers changed all that. This is not to say that you can't get valuable additions by using AOL today, but you demand access to all the Web content as well, plus support for the standards.

So it was not unreasonable to ask for similar abstractions or loose coupling when we wanted to leverage the Internet and XML for program-to-program communication. If you are my business partner, I really don't care how you built your IT infrastructure as long as it is interoperable with mine and supports the quality of service we need to engage. That's why IBM helped create the Web Services Interoperability Organization and has helped drive the standards for SOAP, through WSDL, through security, transactions, reliable message delivery, and so on. There have been many, many companies and individuals who have contributed to the ongoing standardization of these standards. That has been essential to its success.

One of the things that IBM brought to the table was our experience in enterprise computing. Perhaps it would have been fun from a computer science perspective to take 20 years recreating all of the requirements and standards for interoperable and highly secure, reliable, and available services, but the reason why Web services has advanced as far as it has is because it has leveraged what we learned before. We've taken the good bits and tried to build those into a componentized system of standards that allow you to use only what you need, and we've tried to avoid the techniques and architectures that would lead to early failure.

So, I would argue a lot of the early motivation for building Web services was to take the enterprise experience and push it out to the Web. Of course we thought it would be useful inside companies as well, but we had technologies to handle most of the intra-enterprise requirements. Ultimately, we are after a set of standards and technologies that work seamlessly end-to-end from inside my organization, out through the firewall, maybe through intermediaries, through your firewall, and eventually to the endpoint application or service inside your world. To do this, we need to leverage the technology that is already installed and working at the quality of service levels we require. IT is all about legacy enablement, because the cool system you install today is tomorrow's legacy.

So here is part of my thesis: SOA is hot now because it reflects a concerted effort to have a full end-to-end architecture that works within and between enterprises.

We are now using the early experiences and the maturing standards of Web services to work in the enterprise with traditional middleware products. To use IBM examples, that is why we have put so much effort into evolving and teaching products like CICS, WebSphere Application Server, WebSphere Business Integration Server Foundation, WebSphere MQ, and DB2 about Web services standards. These products are all highly useful for SOA use within and between organizations. We will continue to add support where it makes sense to our software product line.

SOA is of such great interest because we are now using the Web services technologies and standards to do a better job inside the enterprise, rather than the other way around. Two years ago we didn't have enough Web services standards for this to be viable. We can do SOA better now because there is enough in place to understand the principles and patterns of the overall architecture. Sure, we'll know more in two years, but we have enough to start tying all this together today. The programming models will continue to evolve to do a better job of simplifying how we access data and services, and the middleware will evolve to support those new models. Indeed, I would argue that programming models will continue to evolve to focus much more on SOA and less on language artifacts.

I mentioned earlier the new JMS engine in WebSphere Application Server v6. This new engine makes it easy to connect to a WebSphere MQ-based enterprise backbone. This means that we have evolved the application server to become an important part of what we might call the universal connection infrastructure, in addition to the usual enterprise messaging products that you might think of. Industry analysts and many vendors have settled on "enterprise service bus," or "ESB," as the name for this universal infrastructure.

I'm beginning to think we need another word after "enterprise service bus." The problem is that some people think that an ESB is a product and that causes confusion. Evidently, they believe you go and buy one and then you are all set. Your friend down the street also buys one and you both have the same thing. This is wrong. An ESB is not like a simple consumer item where two people can buy the same model and it fully meets all of their individual requirements.

An ESB is something you build for your enterprise or organization to give you the connection architecture you need to meet your IT and business goals. It can be built incrementally from multiple products and it needs to support the performance, reliability, and range of protocols that real, non-toy infrastructures require. If you have enterprise messaging products in place now or are about to install them, you have an ESB and a strong basis for future expansion and use of developing standards. To put it bluntly in IBM terms: if you use WebSphere MQ and other WebSphere brokers or integration servers, you have an ESB today.

Here's an analogy: our house was built in 1820, well before houses were wired for electricity. There wasn't much in the way of indoor plumbing in those days either, but that's another story. When it first became viable to wire houses, it was done with relatively primitive technology called "knob and tube." The positive and negative wires were separate, often running down different sides of the wood joists in the ceilings and the studs in the walls. Where you needed to affix a wire, you used a ceramic knob that was screwed or nailed to the wood. Where you needed to go through a joist or stud, you drilled a hole, put in a ceramic tube, and then ran a wire through that. Aside from not being grounded, the life of the wires was supposed to expire sometime in the 1950s. In our previous house I was replacing this old wiring with the new style well into the 1990s. I'm sure some of it is still there, but we moved, so it's not my problem any more.

Aside from the wires, the knobs, and the tubes, there were differences in how you wired a house then versus now. For one, you were lucky if each room had a single outlet (ungrounded, of course). The appliances were much simpler then, too, and I would wager that most of them were lights. Over time, people upgraded the wiring and added radios, refrigerators, microwaves, and computers. You can now even use household wiring to create a home network, something no one imagined when those first knobs and tubes were put in.

In theory, when new electrical codes come in (think new standards), everyone is supposed to rush right out and replace all the old stuff so the house doesn't burn down. In practice, this is done incrementally, to at least give you time to figure out if you really need to tear down that ceiling or wall to get the new wire through. In theory, you could just poke a hole and run a wire. Old houses are notorious for having obstructions that you wouldn't have guessed were there. In the meantime, the electrical system keeps working. Doing it incrementally allows you to budget for the work as well.

In the process of upgrading an electrical system you should probably add more outlets (most modern houses have outlets every six feet or so), and you may need to run a new electrical service to the house to get more amperage to power all the things plugged into all those shiny new outlets. The cost can quickly add up.

With the possible exception of brand new cookie-cutter development houses, condos, or apartments, residences have different configurations of electrical wiring. You don't go to a hardware store and buy a completely preconfigured set of wires that exactly fit the new power requirements and your house's architecture. You or your electrician (think consultant) buys a long length of wire and then cuts it to the proper length to connect to some appropriate point in the existing wiring infrastructure. As part of this, you probably installed a new junction box and outlet. Even then, there are some choices to make because you may need to put in a GFCI outlet if the location is outside or near a wet area like a sink or shower. There are a few more variables, but I think you get the idea.

So although I've used a wiring example, there are a few concepts here that we can relate to IT:

  • No one ever ends up with the original connectivity infrastructure that may have been planned on day one, because new requirements come in.
  • Scalability is very important: you need an infrastructure that can handle the necessary throughput without starving critical business applications of the connectivity they need.
  • The infrastructure needs to be incrementally extendable and compatible with what was previously installed.
  • You need to be able to support a wide variety of qualities of service.
  • Upward compatibility for applications is important.
  • Standards are always being created and we need to be able to support both the new ones and the old ones, assuming they have not been supplanted for safety reasons. The implementation of the standards has to be accomplished in an evolutionary way to be practical.
Think of this home wiring example when you ponder ESBs. They are not a scary, futuristic topic. We and others in the industry have started to use the term in an umbrella way to talk about how we systematically simplify how we talk about enterprise connectivity that includes features for reliable message delivery, support for both new and legacy protocols and transports, data transformation, logging, high availability subject to connection requirements (that is, always connected, sometimes connected, rarely connected), and so on. We need this to support service, event, and traditional messaging infrastructure. It's easier to say "ESB" than everything else I mentioned in this paragraph.

Ideally, we could take some of the processing that originally had to take place at the endpoints and move it into the connection infrastructure (the "bus"). To use another electrical example, the IBM ThinkPad on which I am writing this article has a power supply that automatically switches between 110 and 220 volts. This means that, assuming I have the proper adapter, I can use the same laptop in the US or Europe without modifying the computer in any way. Users of early computers may remember a little switch on the power supply that you had to push one way or the other for either of the voltages. By the way, it's a really bad idea to plug a 110-volt device into a 220-volt electrical service.

Anyway, the little black box that sits between the electrical outlet in the wall and the plug I stick in the ThinkPad is akin to having intelligent functionality that is on the bus versus being at an endpoint. We've been able to move those smarts away from the endpoint, thereby simplifying it. In our IT example, if we can do data transformation on the bus, we don't have to teach all the applications or services that plug into the bus to do the transformation. This greatly simplifies the development of the applications. It also means that we can go to one or more designated places on the bus and add new transformations. Moreover, we can upgrade the physical servers on which the transformations take place in order to get better performance and thus scalability.

IBM customers who have been using WebSphere Business Integration Message Broker (and its otherwise branded predecessors) connected to applications via WebSphere MQ have been able to do this for years. These same products have been incrementally adding support for XML and Web services. We will continue to add features to our WebSphere products, as appropriate, to support the new standards. This means that the "bus" will support all the important things it does now, plus the new stuff as well.

So what do we call this concept to get people away from this single product notion? Here are some possibilities, and I'm only going to consider adding one or two words at the end of "Enterprise Service Bus," lest we confuse people even more:

  • ESB Architecture (yuck; hard to talk about with SOA in the same breath)
  • ESB Pattern
  • ESB Infrastructure
  • ESB Implementation
  • ESB Network
  • ESB Blueprint
Please let me know if any of these ring true to you or if you have better suggestions (I hope you do).

Conclusion
I've taken this discussion a long way from WebSphere Application Server v6, through SOA, and then into how to think about ESBs. WebSphere enables SOAs and provides many new and updated features to help you build a modern, standards-based, high performance, and highly available infrastructure that ties in and helps you better utilize your legacy investments.

More Stories By Dr. Robert S. Sutor

Dr. Bob Sutor is Director of Marketing for IBM's WebSphere Foundation Software as well as its Web services and SOA efforts. A 21 year veteran of
IBM, Sutor has spent most of his career in IBM Research, specializing in symbolic computation and Internet publishing. In 1999 he moved to the IBM Software Group and focused on jump starting industry use of XML. This led to positions on the Board of Directors of the OASIS standards group and the vice chairmanship of the ebXML effort, a joint OASIS/United Nations endeavor. Sutor then led IBM's industry standards and Web services strategy efforts. He currently leads IBM's marketing efforts around the WebSphere Application Server and enterprise modernization software. Sutor is a frequent speaker on WebSphere, Web services, and Service Oriented Architecture. He is widely cited in the press and was recently featured in interviews in the Harvard Business Review and InfoWorld.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.