ESB*

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 is 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 than 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 ceilings and the studs in 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 kind of 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 types of appliances were much simpler back then, and I would wager that most of them were lights. Over time, people upgraded the wiring and added in 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 would not have guessed were there. In the meanwhile, 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 pr
oper 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 along [more electrical appliances and the resulting need for additional or upgraded wiring].
  • Scalability is very important: you need an infrastructure that can handle the necessary throughput without starving critical business applications the connectivity they need. [You don’t want your freezer to not work properly because you overloaded a circuit – we won’t even get into fire dangers.]
  • The infrastructure needs to be incrementally extendable and compatible with what was previously installed. [If you add a new room to your house, you better be able to wire it.]
  • You need to be able to support a wide variety of qualities of service.
  • Upward compatibility for applications is important [the appliances I bought ten years ago better still work with new wiring]
  • Standards are always being created and we need to be able to support 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. [When I was young we didn’t have the GFCI safety outlets, though it is now relatively simple to install them. I’m assuming you know what you are doing or have a licensed electrician do it for you!]

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 to 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 ThinkPad on which I am writing this entry 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 is 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 perform
ance and thus scalability. Pretty cool, no?

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).Incidentally, I’m writing this on a plane flying from Paris to Boston. I’m returning from a quick trip to Europe where I spoke at the XML & Web Services conference and with analysts and the press in London and Montpellier. It was good to see Patrick Gannon and Carol Geyer, some of my old friends from OASIS, even though I insisted on giving them grief over ebXML.

Web Services Articles in the WebSphere Developer Technical Journal

This month’s edition of the IBM WebSphere Developer Technical Journal is now online and contains several articles about Web services.

Back issues of the Journal are also available and include several other Web services articles.

Yak, yak, yak

Although I’ve been back in NY for just a few days, I’m going to London again tomorrow evening so I can give a talk called “Implementing Web Services” at the XML & Web Services conference. I will be in London for a day and a half, then about 18 hours in France, and then home late on Friday. Next Sunday I go to San Francisco for a day to give the opening keynote at the WebSphere Technical Exchange.

The “Implementing Web Services” talk is not actually about the individual steps you take to build a web service. Rather, it is an overview of our strategy and plans in the Web Services and SOA area, and will relate customer requirements, standards, open source, products, education, and consulting. So it is about implementation, but along the lines of how and what you should think about, at least from an IBM perspective. This talk is actually done; the SF one is going to require more work (but, hey, I’ve got a week!).

Wales, golf, and Java

As I write this, I am on a train from Newport Ghent in Wales to London Heathrow. I need to get off at Reading and take a coach to the airport, so I’ll have a bit more of a travel adventure before this day is done.

After spending last week at IBM‘s Hursley Labs near Winchester, I travelled to Wales to participate in a panel at the IIC conference held at the Celtic Manor resort. There are three beautiful golf courses at the Resort and the 2010 Ryder Cup will be held there. I golf, but I am not a golfer. That might have something to do with my only playing a round every two years or so and probably a convincing lack of natural talent. Nevertheless, I took a lesson on Saturday morning and it was a lot of fun. I learned though, that I probably need new clubs if I’m really going to get serious about the sport. Since I am 6 foot 4 inches tall, I need long clubs (which I do have) and I need a 4 degree increase in the angle of the club head to the shaft. (I know there is a fancy name for that angle, but I forget what it is. If only British Railways had wireless Internet access.) It might be possible to get my current clubs bent a bit, but I’m skeptical.

In any case, the reason why I was in Wales was to talk on a panel about “Developing a uniform, integrated application structure: dot.net versus Java”. We had a good spirited discussion about 1) why we shouldn’t be comparing Java with .Net, 2) why we should be talking about interoperability and QoS issues, 3) the types of choices that customers have, 4) the relative maturity of the technologies, and 5) how these relate to enabling legacy technologies, including messaging systems.

In any case, we played nice during the session. Look, interoperability and QoS are key to SOA. Also key are the standards that enable each. It’s important for you to look under the covers and make sure that the technology you use is mature, well tested, and based on enterprise experience and best practices. I fully understand that there are some situations where resources may dictate that you use .Net. That said, when you are talking about enterprise server applications (so no VB, thank you), there are so many overwhelming reasons to choose a Java-based solution that, to me, the argument to the CIO needs to be a proof of why the non-open .Net will meet your scalability, performance, reliability, SECURITY, and transactional needs. If you can make the case and can convince yourself that you won’t have a need for Linux, AIX, Solaris, HP-UX, OS/400, and z/OS, so be it. But if you are not sure, remember that WebSphere runs just great on Windows!

You will comply

If you do a web search for “SOA,” you come across several interesting things having that abbreviation. In addition to one of the primary topics of this blog, you also get the Sarbanes-Oxley Act, a US law about corporate financial practice and governance. I mention this because compliance with Sarbanes-Oxley, HIPAA, Basel II, and other regulations is clearly important to businesses and thus to IT departments. It’s not good enough to say you will comply, you need to figure out how you will do it.

In this context I finally got around to reading the analyst research paper SOA Meets Compliance: Compliance Oriented Architecture by Stephen O’Grady of RedMonk. In the paper, O’Grady specifically ties the general principles of SOA to the specific notion of what services are necessary to do compliance right. They note that there is a lot of commonality in compliance regulations and that a properly engineered SOA-based IT infrastructure offers some compelling advantages for efficiency and scalability. This is definitely worth a read.

Another point of note about the report is that it is “free.” I use quotes because the actual license used is a Creative Commons one. This is oversimplifying, but think “open source for content.” You can get all the details and some of the content via the Creative Commons website.

Before I leave the Redmonk paper, I would love to see two things if they do a follow-up. First, a detailed before-and-after IT scenario showing specifically how and where the compliance services are used would be very useful. Second, I believe that the Enterprise Service Bus (ESB) will make it easier to do some forms of compliance. This is clearly related to what they are suggesting, but if they agree with me, I would like to see their thoughts on exactly how they think it work.

Hug your ESB today

The concept of the Enterprise Service Bus (ESB) seems to be confusing some people. I’m willing to blame everyone for this, especially the vendors, analysts, and press who all insist on offering a range of perspectives and opinions. I’m certainly not asserting that any of this is malicious, it’s just that since SOA and ESB are hot topics, everyone wants to get a share of voice and attention. We see this over and over when new and promising technologies come along. In fact, one of the reasons why IBM sponsored the W3C Web Services Workshop in April, 2001, was to get a lot of vendors together and start sorting out what Web Services was and was not. This didn’t prevent some companies from trying to throw wrenches into the works from time to time, but I think it hastened our reaching a common understanding and roadmap a whole lot sooner than we would have otherwise. Of course, WS-I.org now is the official “remover of FUD and confusion” when it comes to Web Services.

I spoke at a CIO/CTO breakfast event last week in Dayton, Ohio, on SOA and, while there was a lot of good information sharing, there really wasn’t a whole lot of confusion about the need for SOA and the ESB idea. I really like it when certain IT and computer science notions become popular because, fundamentally, they are just really good ideas. Thus it is that many of the requirements around SOA and ESB have grown up naturally over the last few years. We as vendors owe it to our customers to add support in our products that allows incremental adoption of the new technology and further enables what those customers have already installed. Standards are developed and then used because there is need for them. SOA and ESB are causing us all to better express how our integration and enterprise messaging products and solutions fit into these unifying concepts and developing standards.

If you have already deployed products like WebSphere MQ and Message Broker (to use IBM examples), you have an ESB today (and will tomorrow). The technologies you are purchasing today or bought last year will be the foundation for your SOA communications infrastructure for years to come. If integration vendors come to you with products or solutions that are, essentially, toys or only work best with a certain operating system, tell them you are interested in real connectivity and integration. Then throw them out the door.

Getting your ducks in a row

Since I mentioned SUN and open source Solaris a few entries ago, I thought you might find Steven J. Vaughan-Nichols’ column in eWeek interesting. I’ll let you read it and make your own conclusions, but I think it raises some important issues. To maintain credibility in open source it’s important to have all your ducks in a row before you manufacture news. Since there are a variety of open source licenses available, it’s critically important that people understand not just what you are going to put out there with the community, but how the intellectual property rules will work.

More open source from IBM

This is out of my usual area of discussion in this blog, but I wanted to make sure you all saw the announcement of IBM donating some of our speech recognition code to open source. The press release is online as well.

IBM is unparalleled in the industry in its support and contributions to open source. To learn more about some of the many open source projects we support, see the Open Source Projects zone on developerWorks.

IBM and WS-I

It’s now been more than two and a half years since IBM, Microsoft, and seven other companies announced the formation of the Web Services Interoperability Organization (WS-I.org). Our reasons for starting the organization were varied, but boiled down to a couple of basic notions:

  1. Because of the sheer breadth of the technology involved, Web services standards were going to be developed in multiple standards organizations, so we needed a third party group to help rationalize them all into a coherent whole, and
  2. We needed an organization that could take the standards and apply real life, vendor-neutral experience to them, creating best practices, test cases, and stating what bits should or should not be used. The result of this would strengthen subsequent generations of the standards and ease implementation. Of course. the ultimate intended result, was maximum interoperability.

IBM developerWorks has devoted a special section within the SOA and Web services Zone to IBM’s demonstrated commitment to the work of WS-I.org, customer success stories, and further resources. If you are serious about being succesful with Web services, you owe it to yourself to read this section.

I had the privilege of being the IBM executive driving a lot of what we did to create WS-I.org, as well as being the one to face some of the controversy at its genesis. The original yelling and screaming is ancient history now. I’d like to personally thank the IBM team and, specifically, people like Pam Allen and Tom Glover for their hard work and the dedication they’ve put into making WS-I.org a resounding success and organization critical to the IT industry.

Back in the UK for a bit

I’m in the UK this week to take part in an IBM Business Partner technical meeting on CICS and WebSphere Business Integration and internal meetings. Originally I was just scheduled to come over next weekend to participate in a J2EE vs .Net panel at The Triple i Convention, but I extended it a week to spend the time with some of IBM‘s partners and the local IBM software leadership at the Hursley Labs near Winchester. We’ve got a lot going on now and all sorts of plans for next year and beyond, so it’s good to get some facetime.

I flew out yesterday via Chicago and, since it was September 11, I had no idea what to expect in terms of how busy the airports or how full the planes would be. My first flight into Chicago was at perhaps one-third capacity, but the flight to London was completely full. I suppose this is good news, but it’s still a bit eerie flying on that tragic anniversary.

I’m still debating with myself about whether I should do a book on SOA and Web services slanted towards managers and executives. That is, no XML angle brackets, but enough about the business and technology to make people dangerous, or at least able to make good business decisions about how and when they should use the technologies. It’s clear it would have to be a weekend and holiday activity. Maybe when the cold of winter sets in I can look at it seriously.

I’ve co-authored two books in the past in my previous mathematical/internet publishing life: Axiom: The Scientific Computation System, which seems to be out of print, but describes what is historically a very significant programming language and symbolic computational environment; and The Latex Web Companion: Integrating Tex, Html and Xml. I co-wrote the first with the recently departed and dearly missed Richard Jenks and I wrote a chapter about techexplorer (now owned by Integre) in the second.

The Eight Defining Concepts of an Enterprise Service Bus

I promised earlier that I would talk about the Enterprise Service Bus (ESB) idea and have already pointed to a Forrester research article on the topic. In this entry I want to list what IBM considers the eight primary defining concepts of an ESB. Note the following are not my personal work but rather that of the IBM Enterprise Messaging team. I will, however, return to these in future posts to add details and examples. In no particular priority order …

  1. Universality
    An ESB is a universal connectivity layer that extends the scope and scale of integration across an extended enterprise.
  2. Heterogeneity
    An ESB includes integrated, multi-protocol, multi-API, message distribution, routing and processing middleware to support extremely diverse systems and applications.
  3. Interoperability
    An ESB uses open protocols to support the interoperability of middleware from multiple vendors.
  4. Incremental Integration
    An ESB can distribute low-function message brokers to provide low initial costs and step by step growth capabilities (though other software can be part of the ESB as well).
  5. Qualities of Service
    An ESB supports a variety of qualities of persistence, performance, reliability, security, availability and transactionality.
  6. Substitution
    An ESB uses open APIs to allow the substitution of middleware from different vendors.
  7. Event Orientation
    An ESB allows you to decouple applications that publish business events from subscribing applications.
  8. Service Orientation
    An ESB is middleware that facilitates loose coupling between software components.

As I said above, I’ll flesh these out in future entries. In the meanwhile, you might want to take a look at how the notion of an ESB fits into your integration solution today. In the meanwhile, you should keep repeating to yourself “An ESB is not a single product, an ESB is not a single product, …”.

Two Web Services packages among top alphaWorks demos

I just got a newsletter from IBM alphaWorks that noted that two of their top downloaded demos are in the Web services area. From the text they sent me …

Emerging Technologies Toolkit
The ETTK is a software development kit for designing, developing, and executing emerging autonomic and Web service technologies. It provides an environment in which to run emerging technology examples that showcase recently announced specifications and prototypes from IBM‘s research and development teams.

Web Services for Life Sciences
This package is a collection of examples of Web services for life sciences. It includes examples for PubMed, GenBank, BLAST, Phylogenic Tree, ClustalW and other Life Sciences Demos.

ZDNet article

There is an interesting article over at ZDNet by David Berlind – “Sun’s Schwartz living a Linux nightmare”. I’ll admit to not really understanding Sun’s open source strategy around Solaris and how it relates to Linux. This doesn’t mean I haven’t tried to understand it …

I do know that when there was all the public discussion about open sourcing Java a few months ago, Sun decided to come out and talk about open sourcing Solaris (again). By some accounts, they’ve been talking about this for several years. Nevertheless, I couldn’t avoid thinking they were trying to change the subject.

Implementing Web Services talk

If you are in London at the end of September and are attending the XML & Web Services 2004 conference, please stop by on the afternoon of September 29 and say hello. I’ll be giving a talk called “Implementing Web Services” and will be highlighting various IBM technologies that you can use to build and deploy Web Services both within and between enterprises.

IBM's Mark Colan, Web Services and SOA EvangelistI want to put in a plug for one of my colleagues, Mark Colan. Mark is IBM’s premier evangelist for Web services and SOA. Each year he travels tens if not hundreds of thousands of miles to talk about the latest standards and how we are implementing them. Many of his latest talks are online, so check those out. If you ever see that he is appearing at a conference, I encourage you to attend his talk. Some of his recent talks include “SOA and Web Services: Where we are, where we’re going”, “SOA and Web Services for Architects and Developers”, and “Web Services Security – How WS-Security builds upon existing security technology”.

Fences, shrubs, and rocks

Although today is Monday, it is part of the US Labor Day weekend and thus I think it’s ok to talk about the fence I am building in my side yard. For the amount of intellectual energy I’ve put into this, you would think it extended the full width of my property. As it is, I planned the total length to be 21 feet long.

Our house was built in 1820 and on one of the main roads of the village. Back then they put houses fairly close to the roads, especially in northern climates where snow plows were not quite as efficient as they are now. Today our road is larger yet, and in the summer the sight of cars can be distracting when you are hanging out in the back yard. On the left side of the house (facing the front) we have a porch that was rebuilt earlier this year. Behind that is a stone wall running out orthogonally from the house, and nestled between the stone wall and the house there is a perennial garden. So standing in the backyard looking toward the street you see garden, wall, porch on left, and then cars buzzing by on the street. The distance from the porch to the end of the stone wall is about twenty feet.

Inspired in part by P. Allen Smith’s Garden Home, I wanted to do something at the top of the wall to block the view of the street. That would give us more privacy in the garden and allow me to better landscape the now more contained space. A complicating factor was that if I built a fence, it would have to connect to the porch, and so architecturally I was limited in what I could do. The house is a Federal stylde Greek Revival, in case you are keeping track.

A good place to start in case you are thinking of building a fence is George Nash’s Wooden Fences. What you soon learn, however, is that there are an infinite number of fence varieties, and you can change almost every detail such as the style and height of the posts, the infill (pickets, for example), the spacing between the posts, and even the color of the fence. Nash recommends, and I concur, that you drive around and try to find a fence you like. Start with your neighborhood, but a particularly wonderful place to see old homes and fences is Bennington, Vermont.

Did I really want to put a fence there? Building a fence, even a short fence, is hard work. Perhaps the most difficult and most nerve racking part of the process is measuring and then setting the posts. If you have stable, rockless soil, the job is straightforward. You can even rent an augur to dig the holes. In my case, I was putting the posts on the uphill side of a rock wall that was backfilled. There almost certainly were going to be rocks there.

Another option was to put a line of hedges above the wall. I nixed that because 1) I didn’t want to have to trim the hedges and 2) I didn’t want the hedge trimmings to fall in the garden. Next to be considered were some sort of trees or bushes. My wife ruled out arborvitae because we planted 25 of them along the sidewalk in front of the house, they were to supposed to grow fast, and they didn’t. They also tend to get brown dead spots after a hard winter. My other choices were ruled out when I visited a nursery and was strongly advised not put broad leafed evergreens on a western exposure. During the winter they tend to dehydrate and so you have to spray them with an anti-desiccant like Wilt-Pruf. You usually need to reapply it mid-winter, and the last thing I could see myself doing was standing outside in February in upstate New York trying to spray shrubbery. The final bit that ruled out a living solution to my problem was that I could not plant anything behind the steps to the porch, and so I would not have a solution that sufficiently blocked the view of the street.

So it was back to a fence. To make a long story short (maybe too late for that now), I decided on a 3 section fence, 7 feet on center. Originally I was going to do pickets, but on the strong urging of my wife I changed the planned infill to be 1 x 4 slats with section tops shaped like arches. We have arches on the front of the house, so this will tie in well.

On Saturday I set out to put in the posts. I did all the right things to determine the proper post spacing and started in on the first hole coming out from the porch.

Rock.

Big rock.

I managed to move and then remove several smaller stones but there was one I just could not budge. Since I wasn’t deep enough yet to just put the post on top of the rock (boulder?), I had to come in closer to the house. This shortened the first panel width by 4 inches. This meant I had to reduce the other panels accordingly and, just like that, I lost a foot off the length of the fence. That was still ok, since I had allowed for some potential problems. If it had been a much longer fence I would have either had to deal with a shorter first panel or maybe re-jigger things to get more panels. After a few hours I had set all three posts in concrete and I called it a day.

On Sunday, I cut the top of the posts to the right height. The fence is going to step down 6 inches per panel, moving right to left as it goes down the hill. The posts will also project 6 inches above the height of the slats, so this took some careful measuring and leveling. I then put in a couple of the stringers and set to work attaching a 2 x 4 to the porch to hold that end of the fence. I could not set a post there because the stone wall comes right up to that point. I set the attachment piece with 2 galvanized lag bolts and one masonry bolt into the mortar between the bricks toward the bottom of the porch base. It isn’t going to move soon. I added two more stringers and left the final two for today.

I got up this morning, measured the first 2 x 4 stringer to the length between the posts, and then somehow managed to cut it short. Not a little short, but something in the neighborhood of a couple of inches. I have no idea how this happened. I cut the other 2 x 4 to the right length and installed that, but now I need to get one more stringer. I’ll do that some evening this week before I head off for the UK next weekend.

The fence frame is made of pressure treated lumber and so it needs to dry before I can paint it. The usual recommendation is 3 to 6 months. That would put me in the range of December to March. If I wait, it isn’t likely that I’ll be able to paint until late April or May, so I may just try to give it a few weeks and paint it as late as I can in October. I’m going to use regular lumber for the infill, so I can prime that and put it up. Clearly I should have built this earlier in the year, but I had to wait until the porch was rebuilt and I had some time to do the work. So the saga will continue for at least a few more weeks.

Stop with “XML Web Services” vs. “Java Web Services”

Ok, this is a rant. I get annoyed every time I see a reference to “Java Web Services” or “XML Web Services.” The latter was invented by Microsoft to ensure that people wouldn’t possibly associate a non-favored technology with the developing Web Services technology. Then Sun came back and started talking about Java Web Services to make it clear that that was where the real action was.

For a long time I agreed with Sun because I certainly placed Java on a pedestal as the preferred way of implementing Web Services. And since Microsoft was being so obnoxious in trying to get everyone to say “XML Web Services” and therefore trace that phrase back to Microsoft itself, I was more than happy to play along with the Java bit. I still think this is the case, that Java is more important than .Net for Web Services, though we all need to play nice and interoperate. Then in 2003, to great acclaim, we (IBM) introduced SOAP support for CICS. Were we suddenly going to start talking about “CICS Web Services” or “COBOL Web Services”? And what about those vendors that sell C++ support for Web Services? Do we have “C++ Web Services”? Oh, my gosh, is the Web Services world fracturing? Run for the hills!

The point is, we have Web Services. These are defined by real standards like SOAP, WSDL, WS-Security, BPEL4WS, and the emerging ones like WS-Addressing, WS-Notification, and so on. You don’t get to make up your own definition for what a Web Service is or isn’t anymore. This is not a marketing exercise. Stop it.

XML is certainly an absolutely important standard for Web Services, but did you realize that SOAP is not 100% necessary? WSDL (Web Services Description Language) is really the key standard at the center of Web Services. You can use other ways of communicating Web Services data than SOAP. For example, in some cases you might optimize the Web Services invocation to a function call. By the way, you might not even end up using HTTP. This is about standards and IT efficiency, it is not about religion.

Gartner just published an article called Consider WSDL a Critical Standard (you have to pay for it). IBM has been stressing for almost the four years since WSDL was published that it is the definition of the interface and then how you actually bind to do the communication that is important. For example, in a ComputerWire article in May of 2002, I said

“Web services will be fundamentally WSDL based. You have to use WSDL to describe [a web service] and then you can build up from there,” Sutor said. “There will be a tremendous amount of use for SOAP… but there may be a more optimized protocol.”

So Gartner is right: WSDL is (and has been) a critical standard for Web Services. Not XML Web Services or Java Web Services or COBOL Web Services, but just plain old Web Services.

What is JavaOne?

I was rather disturbed by some news reports a couple of weeks ago that said that Sun is considering merging its Sun Network conference in with JavaOne 2005 (see Sun postpones Network product event, for example). What’s up with this?

Sun Network is a Sun-specific conference for its customers and partners that is firmly rooted in Sun’s commercial interests. Most of the large vendors have one or more such conferences a year and, of course, they are well within their rights to do so. We’ll all continue to do so while we can afford to hold the conferences. Moreover, the conferences morph over the years as times change. For example, since IBM nows Rational, we merged the old Rational Users Conference with IBM developerWorks Live. This makes sense and supports our customers and partners. Microsoft and others do similar things.

I thought JavaOne was supposed to be an industry event where any Java vendor or user who wishes to attend can do so and be part of the Java community. There they can represent their own interests or learn about what the rest of the industry or the Java Community Process is doing, but it is not supposed to be a lot of people there to support and further Sun. We’re there to support and further Java. We’re there to help accelerate the adoption of Java because we believe in the technology, its promise, and that it is supposed to be an open, non-proprietary technology. That’s why I, at least, have gone to JavaOne in the past. Sure marketing goes on, but all the vendors do it and there is some balance.

If Sun Network merges in with JavaOne, will we all just be participants in a Sun infomercial? (As others have noted, it already has some infomercial tendencies.) Why would vendors pay the very hefty sponsorship fees to help Sun marketing? I’m not delusional in thinking that JavaOne isn’t important to the Sun marketing organization and I know they spend a lot of money on it, so they get the right to be very visible. They even get to have keynotes where they bash other sponsors … :-) .That said, they walk a fine line between keeping the focus on Java vs. Sun. Merging Sun Network with JavaOne would completely cross over the line toward making this an explicitly Sun event. At that point it becomes a lot less interesting as a community get-together.

I believe the Java community will keep growing and growing. As I mentioned in an earlier post, the sheer number of specs on JDocs shows the health of the Java world beyond the offical Java Community Process. IBM is firmly behind helping Java grow and grow into new areas.

So this is my request to Sun: keep the community JavaOne and Sun-specific Sun Network conferences separate. From what I’ve read, Sun has not made a final decision. I urge you to err on the side of the community on this one.

What do you think?

Enterprise Service Bus (ESB) Article by Mike Gilpin of Forrester

I’ve been debating with myself about whether I should mention reports by analysts in this blog since 1) we speak with many analysts and I don’t want to appear to be favoring any one over the others, and 2) many of the reports cost money to read. I ultimately decided that over time I could strike a balance among the different analyst companies and their published work. As to the money issue, you can decide for yourself if you want to pay for the research. You may have already done so, in fact.

So, anyway, the first one I want to mention is “What Is An Enterprise Service Bus?” by Mike Gilpin of Forrester Research. I think this is a very good introduction to the notion of the modern Enterprise Service Bus and nicely addresses the legacy requirements as well as what we will need for SOA and Web services.

Toward the end of the report Mike mentions an “excellent” Redbook from IBM about ESBs. It is called Patterns: Implementing an SOA using an Enterprise Service Bus and you can download it for no charge. See, you did get something for free after all …

New WS-Eventing spec announced

Over the last few months, IBM has worked with Microsoft and others to evolve the WS-Eventing spec and to better foster interoperability. The new and updated version was announced today. We hope that this leads to eventual convergence with the WS-Notification family of specs. IBM is committed to having a final set of standards that are functionally rich enough to meet the demands of our enterprise customers. So, with this in mind, we’re continuing our leadership efforts to help pull together the industry with common, interoperable specifications, and we remain strongly committed to completing the work in a standards organization.

I would also like to welcome Sun to the fold on this spec and note that they were also part of the WS-Addressing update a few weeks ago. It’s great to be all rowing the boat in the same direction. I know our customers think so too.

Here are a couple of WS-Eventing stories that have been published so far: IBM, CA, Sun Sign Up for WS-Eventing on internetnews.com, and
IBM, Sun join with Microsoft on Web services event specification
in InfoWorld.

JDocs is wonderfully complete – no, wait, we’re missing some docs!

If you are a Java programmer and you have not checked out JDocs, you are in for a treat. The main page states that “JDocs is a comprehensive online resource for Java API documentation.” This great collection of docs is hosted by the JavaLobby. There you will find 106 sets of APIs for such things as Ant, Axis, Beehive, Eclipse, Groovy, Jython, UDDI4J, and Xalan. So this is a great and comprehensive collection of open APIs, or is it?

Sun decided that JDocs should not store the documentation for J2EE, J2ME, and J2SE because of copyright issues. So when you go to JDocs you get redirected to java.sun.com. This is a little odd because while all the documentation is actually copyrighted by Sun, the actual work in creating the documentation (and the specs) was done by the Java Community Process, that is, the hundreds of individuals who work independently and for their companies to advance these standards.

Is this an example of Sun being within their rights as the “stewards” of Java, or are they forgoing openness and the community and thereby acting like Gollum and saying “mine, mine, mine”? I would love to have your comments on this.

For more on this controversy (if it is one), see the InfoWorld article “Javalobby removes Java specs at Sun?s request: Sun said to want APIs such as J2EE, J2ME only on its own site” by Paul Krill.

By the way, when and will we see the NetBeans APIs on JDocs? (grin)

In any case, JDocs is a wonderful case in point of how much wonderful work is being in done in Java in the general community.

Screens, domes, and ceilings

I spent the better part of five hours today replacing the screening on two large window sections on the porch off our kitchen. Each section is about 3 feet by 8 feet, so it took some wrangling to remove the screens, work on them on the picnic table, and then replace them. I’ve done this before on other screens and it is one of my least favorite household jobs, which is probably why I waited so long to do these.

One of the screens had a hole big enough to drive a Buick through, and I still don’t know how it got there. It was in the area behind the railing for the porch, so the hole was most likely made from the outside. I was afraid one of our four cats would get behind the railing and then try to make a run for it, so I decided the time had come for the repairs.

Replacing the screening material is really like an architectural investigation because you come across all sorts of nails and staples from different generations. It always surprises me how many nails people put in the decorative wood trim that covers the staples. I live in upstate New York, not Florida, so having a hurricane rip the wood off the screens is not likely. By the time I come to putting in the new brads to hold on the trim I need to fill all the old holes left from the last generation of nails. I can usually tell if the screening was done by a professional or someone with significantly less skill. I always aim for a professional job because, who knows, I may be replacing these screens again sometime (though I hope not soon).

While we’re off my usual topics, I’m almost done with Brunelleschi’s Dome: How a Renaissance Genius Reinvented Architecture, by Ross King. It’s a very good read, as is his Michelangelo and the Pope’s Ceiling. My family and I went to Italy this summer and so I took the opportunity to reread Irving Stone’s The Agony and the Ecstasy: A Biographical Novel of Michelangelo. King’s book is more historically correct and less sanitized, but I would recommend all of these. I have one other book to read about the Medici and then I think it will be time to move on to something else. Of course, now I want to go back to Rome and Florence and stare at those buildings and statues for a lot longer than I had the chance in July.

IBM Redbooks about WebSphere and SOA/Web services – go get ’em!

IBM publishes an extensive collection of “Redbooks,” technical information in book form on all sorts of software and hardware topics. You can browse and search the collection and there is copyright information “to print multiple copies of specified IBM Redbooks or to make them available on an enterprise intranet or server for use by multiple persons in your enterprise”

Here are a few links to get you started:

You can download and read the PDFs for all of these.

Thinking about celebrating SOAP at 5 years (I know it is early)

Next April 26, SOAP turns 5 years old. Well, not the original SOAP, but SOAP 1.1 which really kicked off what I consider the Web services era. This is the version where IBM and Microsoft overhauled what had come before and, through our joint involvement, gave new focus to interoperable communication while taking advantage of XML, still relatively new.

The SOAP 1.1 spec was published on April 26, 2000, and two days later, April 28, IBM posted a Java implementation on alphaWorks for free. This was called SOAP4J. Over that first weekend, more than 400 copies were downloaded (which reinforced what we thought developers did on weekends!). Within a month or so, SOAP4J was donated to Apache and became the basis for Apache SOAP. So, by my reckoning, this makes IBM the very first company to donate code to open source for one of the modern web services standards (and SOAP 1.1 was certainly a de facto standard, though there is now an officially blessed W3C SOAP 1.2 standard).

When this spec was first published we were deluged with press requests and I, in my naivete, thought “wow, they must think this is a really cool spec”! Of course, for many people the real story was IBM working with the folks from Redmond for the first time since OS/2. We’ve worked on web services specs ever since, IBM contributing its years of experience on how to build reliable, scalable, secure enterprise applications and messaging infrastructure.

So, my question to you is, what should we do when SOAP turns 5 years old next April? Post your comments below.

How do people start using Web services and SOA? Step 3

The final step or phase for Web services and SOA is to take an enterprise view. This means that you look at your entire infrastructure and try to understand how you can migrate from your collection of EAI and B2B and everything else to a situation where a service orientation dominates.

We find that most of the companies at this level are in the financial services industry. This really isn’t too surprising because

  • They are frequently at the leading edge of adopting new technology to gain efficiencies and support straight-through-processing initiatives,
  • Their industry has a lot of mergers and acquisitions.

To the second point, when two companies come together, they want to get the various systems talking to each other as quickly as possible. After that, they might want to consolidate functional systems or move to a model where it becomes easier to relocate datacenters.

When I speak with customers in the banking industry about SOA and ESBs (Enterprise Services Buses) they don’t take too long to explain that they have been thinking about these topics for some time. In the vase of ESBs, they may even have some in production based on modern SOA principles. I’ll talk more about the ESB concept in future entries.

I first wrote about these steps to using SOA in an article in ComputerWorld at the end of last year. Our conclusions then have continued to be borne out as we’ve spoken with customers this year. We encourage you to start pragmatically by choosing one or two projects that will help you understand how SOA and web services fit in your organization. This means getting a better view of what resources you can bring to bear and what the ROI is for your particular IT infrastructure. This is obvious, but no two companies have the same IT plumbing. So all this great and general advice about SOA and web services needs to be localized for your particular configuration.

Once you have the experience of a few web services “under your belt,” you can move on to connecting them together via BPEL. The WebSphere Business Integration Server Foundation can help you do this. During all this you should be thinking about what this would mean to your enterprise as a whole so that by the time you make that type of commitment you have practical experience and the resources and products to help you meet your business goals via SOA in your infrastructure.

Make sure you visit the SOA and Web services zone to learn more about SOA and Web services. This offers both basic and advanced technical material as well as many free downloads to get you started.

How do people start using Web services and SOA? Step 2

The next step or phase of adopting web services and SOA is where you start doing what we call “service oriented integration.” This means that you now have services that are becoming interdependent or at least are called sequentially. Here BPEL might come into play and more fine grained end-to-end security is frequently a requirement. Management also starts to become an issue, though we (the industry) don’t yet have the web services standards complete and implemented in this area. This hasn’t stopped companies like Amberpoint from providing some early solutions for management.

Next, the big view …

How do people start using Web services and SOA? Step 1

Ok, so let’s talk a bit about how people start using web services and SOA. We identified three main ways that people jump into this.

The first is what I call the “accumulation phase.” At this point people implement services very tactically: there may be one service to connect to a customer in one department, another to connect two internal applications, and perhaps a third to get non-critical business data from an outside source. If you ask the CIO about how many services his or her company has, you might not get an exact number. This is frequently an experimental phase where individual developers are trying to figure out if this technology has value for them in their environment.

At this point, you probably don’t need anything too fancy in terms of security or management: you can use coarse-grained security similar to what we do for encrypted Web pages and there aren’t so many services that you can’t manage the IT constructs that actually implement them, such as EJBs. If you wish, however, there are companies that do look at what it means to manage the services, though what they provide may not integrate smoothly with the rest of your management infrastructure.

Companies should use these early forays into Web services and SOA-land to understand what the ROI really can be for them given their IT infrastructure and the skills they have in house.

Once you start having more than a few services or you start having seriously dependent services, perhaps in a business process, you are ready to look at entry point or phase #2 …