A colleague recently asked me where to find out about IBM's take on what an ESB
is. I figured, why not make a blog entry out of it? So here it is.
First, so far at least, there is no single definition
IBM always uses (nor one the industry agrees on). Here's the definition from our executive's guide
An ESB enables software applications running on different platforms, written in different programming languages and using different programming models to communicate with each other, without requiring expensive, time-consuming reengineering.
Second, IBM's general company line is this: ESB is not a product, it's a pattern.
(By my standards, a very broad pattern; an architecture++ level pattern that spans multiple applications across an enterprise and even between enterprises.) It's more about the goals achieved and the way multiple products work together than any one product. You don't just "install an ESB," take satisfaction, and walk away. It's something you design custom for your enterprise and then implement using the products that provide the features you need. (See flexible infrastructure for end-to-end integration
for a list of ESB capabilities and our products that provide them. Keep in mind that you don't need all of the products, just the ones for the capabilities you want your ESB to have.) Having said that, I remember a day when an app server wasn't thought of as a single product anyone agreed on. So I can imagine the day where an ESB might be a single product, or a single core product with several optional add-ons; but the industry isn't there yet.
Third, IBM thinks that ESBs have many different capabilities
. I've seen the list expressed different ways, as you'll see in my references. Without getting into enumerating all of those here, let me summarize by saying that we believe many competing (e.g. non-IBM) products that call themselves ESBs do not have the range of capabilities that IBM's products do. Some competitors' views of what an ESB is are more limited than IBM's, a reflection of their products' more limited capabilities. (Hey, I'm not trying to flame anyone, I'm just espousing IBM's basic position here. You be the judge.)
Forth, we think an ESB is a key part of making an SOA work
in production (see Services Oriented Architecture and Web services
): an ESB enables the SOA providers to make their services available and the SOA consumers to invoke those services. SOA is one of our key approaches to helping you develop what we call an On Demand Business
So, where can you find out more info?
There's a new web site, the PatternShare Community
. It's the brainchild of Ward Cunningham
and is being hosted by Microsoft
. It's an effort to collect patterns from several different sources, summarize them, and show how they fit together into a unified pattern space. The idea is to help answer the question, "How do the patterns in this one book fit with the patterns in this other book?" (See "What is a PatternShare
To start with, a group of authors and their publishers decided to work together to use their books to seed the web site. So the books that are represented now are Patterns of Enterprise Application Architecture
, Domain-Driven Design
, Enterprise Integration Patterns
, and several other prominent patterns books
The site has been a long time in the making, but is still just getting started. We authors are endeavoring to link our material together better. We also hope other authors will want to join, and we will add their work in over time. Meantime, have a look; hopefully you will find it helpful.
Here's a question that keeps coming up that I keep forgetting the answer to:
Say you're trying to measure how long it takes some data to get from one computer to another, whether it's an RPC call
or a message
or whatever. Or say you want to use message expiration
. In either case, to measure the elapsed time, both computers have to agree on what time it currently is. How do you make sure that two computers' clocks are synchronized?
The answer (as you may have guessed from the title) is the Network Time Protocol
(NTP). It runs on Internet Protocol
(IP), typically on port 123. It uses a master/slave configuration: the master hosts a reference clock
and the NTP service to make that clock available; the slaves synchronize by getting the time from the master and using that to set their own clocks.
For more information:
BTW, a handy dandy site for showing the time to us humans (at least in the United States) is The Official U.S. Time
, operated by the National Institute of Standards and Technology
(NIST) and the U. S. Naval Observatory
(USNO). It displays Coordinated Universal Time
(UTC) for any U.S. time zone
you choose, including adjustments for Daylight Saving Time
Did you know you can configure Windows XP
to automatically synchronize your computer's clock with an Internet time server? See Synchronizing your computer clock
The Apache Software Foundation
has announced a new Struts
. Struts Shale is a JSF
-based version of Struts. The old version of Struts will be renamed Struts Classic and will continue to be maintained (if there are people interested in doing so). (For some JSF links, see Service Data Objects (SDO)
A colleague of mine just asked me about keeping up with blogs, so here's the answer as a blog entry (kinda self-referential):
In summary: I use SharpReader
, and so does James Snell
Here's the long version:
A current thread of discussion is what blog readers to use. A problem with blogs, as you may well have discovered, is that there's lots of them and they're updated at all different rates. It gets old checking them each day just to find that there's nothing new, but it also sucks to check one after a week and find there's been something useful there for several days but you didn't know about it. You kind of wish blogs worked more like e-mail, such that each new blog entry would be mailed to you and you'd be notified. Perhaps you could just subscribe to the ones you're interested in (and not all one-bazillion blogs there seem to be in the world these days), and perhaps have a different mailbox for each blog.
This is the idea behind RSS
feeds. They syndicate information in a machine-readable form (XML
--what a shock!) so that a feed reader (which works like a web browser or e-mail viewer) can process the information and present it to you. Not only can the reader subscribe to only the blogs you point it at and keep each one's feed separate, but it can automatically check the feeds periodically and let you know when there's new content.
For example, if you're reading my blog on the developerWorks site
, in the upper-right corner of the web page, you'll notice a calendar and a button under it labeled "RSS." If you click on it, the link
returns not an HTML
document but an XML
document. The XML's root element is an <rss> element, containing a <channel> element, containing a bunch of <item> elements. Your RSS reader interprets this and displays the blog to you in the manner it sees fit.James Snell has commented
that he uses SharpReader
, which is also what I use. Seems like a tried several a couple of months ago and settled on this one. It's a GUI that runs like a web browser or e-mail viewer. Bob Sutor
and Bill Higgins
say they like to use Bloglines
, which is a web site that shows you the blogs you're interested in.
What I like about something like SharpReader is that I can sync it, then read stuff off-line, something you can't do with Bloglines since it's a web site. (Then again, some blog feeds don't support off-line reading, they essentially just feed a URL to the entry, which isn't much of a feed. Or they only feed the first paragraph, so you have to be on-line to read the rest of the entry. Guess they're saving bandwidth.) Bill says that Bloglines is not so much a reader, but a community that lets you know who's reading what blogs and other blogs that are similar to the ones you like. So I guess it all depends on what you're looking for.
One problem that RSS feeds still can't solve is that once you subscribe to one, you get all of the items published on that feed, even if you're only interested in some of them. There is currently no "RSS policy" that us authors can use to describe their items and you subscribers can use to filter the items they receive.
James Snell has also made some interesting comments
about the information pull model that services like RSS and Atom represent as opposed to the push model of e-mail, where you get lots of junk pushed your way by anyone who knows your e-mail address, and where you have to actively ask someone else to unsubscribe you from a mailing list.
In any event, if you're manually polling blog web sites and thinking there's got to be a better way, there is. Check it out.
As noted two weeks ago
, the latest JDO
2.0 draft (JSR 243
) was not approved. Also, as noted back in October
, a lot of the JDO effort is now being channeled into JSR 220
Now Richard Monson-Haefel
(J2EE: A Standard In Jeopardy?
) posts The Death Knell: The JCP EC Rejects JDO 2.0
, where he speculates that the rejection will "make JDO a footnote in the annals of Object-Relational persistence
." He believes all significant Java O/R persistence effort will now occur in EJB, not JDO.
Interestingly, Richard asserts: "Right now it makes more sense to use JDO or Hibernate than it does to use EJB 2.0/2.1 container-managed persistence
" (for new development) because EJB 3.0 will likely be more like the former than the latter. I've said otherwise
, that WebSphere
customers should stick with J2EE. The way I've heard it, the J2EE vendors have a very strong steak in supporting their customers by making sure the new versions of EJB and J2EE are backwards-compatible with code developed for the current ones. Yes, prominent JDO and Hibernate figures are on the JSR 220 committee now, but so are EJB 2.x people who care very much about getting current customers to buy the next version of their products.
I don't decide these things for IBM, but it's hopefully a no-brainer
that current customers will be supported going forward. Therefore, I would stick with J2EE, and change when J2EE does, not before.
The World Wide Web Consortium
(W3C)--keepers of the pivotal Web specifications like HTTP
, and SOAP
--has announced a new initiative to make SOAP more efficient and therefore make Web services faster. (Web services that are SOAP-based, anyway.) This comes out of an effort called SOAP Optimized Serialization Use Cases and Requirements
, part of the SOAP 1.2
effort. Optimized SOAP consists of three parts:
Do you want to know more?
- XML-binary Optimized Packaging (XOP) -- Enables an XML document to contain binary data. Previously, the binary data would have to be converted to character data, increasing the size of the data.
- SOAP Message Transmission Optimization Mechanism (MTOM) -- Enables a SOAP message to contain binary data using XOP. This effectively replaces SOAP w/Attachments (SwA), which was never supported by Microsoft and therefore not part of the WS-I Basic Profiles 1.0 or 1.1 (although WS-I Attachments Profile 1.0 does support SwA). MTOM can also be used to encode an entire SOAP message in binary form, decreasing the size of the message.
- Resource Representation SOAP Header Block (RRSHB) -- Enables a SOAP message to contain references to external resources. These resources can be cached by the recipient so that they don't need to be transmitted in the message, which saves bandwidth when multiple messages contain the resource.
Remember Six Degrees of Separation
(and Six Degrees of Kevin Bacon
)? Ever heard that you're not just sleeping with
someone, you're sleeping with everyone they ever slept with
? Well, here's picture of what those relationships look like.
This is an interesting example of how graphics can be used illustrate data. Time Magazine
recently had an interesting article, "A Snapshot of Teen Sex
." It describes the results of a study of sexual behavior amongst students at an anonymous
but real high school in the Midwestern United States in 1995. An accompanying graphic illustrates who had sex with whom. (Besides describing what teens are up to, the really interesting part of the article is the graphic, which isn't included in Time Oneline Edition
version. You can find the graphic in Sexual network of high school mapped by researchers
, shown below.)
The picture shows who had relations during an 18-month period. It shows a number of small clusters of people who had relations in small groups (such a 63 monogomous
pairs), and then one huge ring of 288 students that each had relations with someone else in the cluster. It's difficult to describe, but easy to see in the picture, hence the value of showing statistical data graphically.
This also shows the limits of graphics
, and how they can be misleading
. The picture hopes to show how an STD
can easily spread from one person to many. The problem is, the picture doesn't show time
. Those 288 students probably didn't all have sex at the same time
. The circle was probably many isolated parts until people between parts connected to make bigger links and finally a full ring. In other words, there was no ring until enough time went by for enough people to have enough sex with enough partners, and that took awhile (although apparently less than 18 months). So to show the potential path of an STD, the links not only need to show encounters, but the order of the encounters.
Many readers probably look at a picture like this and don't think too discerningly
about it. They read the article, glance at the picture, and think, "Golly, if any one of those 288 teens has an STD, so will the rest of them.
" Well, only if the teen with the STD was part of the first couple in the statistical period to hookup
, and only if everyone else in the ring became part of the ring when they hookedup, not through later activities of their partners. So the graphic is interesting, and compelling, but can also lead to false assumptions.
Separately, I also like this quote from the article: "Adult sexual networks...usually involve clusters of wanton individuals known to public-health experts as "core transmitters." (Think prostitutes, NBA stars.)
" NBA stars? See Wilt Chamberlain
Oh, and if you really want to be disturbed about how teens are behaving today, see the movie Thirteen
. For a lighter take, see Mean Girls
Here's an interesting conflict between JMS and J2EE that I just rediscovered:
You can't run an implementor of MessageListener
in a J2EE container. J2EE 1.3 says not to do it in the EJB container. J2EE 1.4 says not to do it in the Web container either. Basically, you can't use it in any container that controls thread creation, which is any container except an application client container.
WAS 5 and 6 don't allow MessageListeners to be used in either container. When you try, you get an error like this:
javax.jms.IllegalStateException: Method setMessageListener not permitted
. . .
So WAS doesn't actually prevent you from deploying a class that implements MessageListener, but when you try to run your code, WAS prevents the MessageConsumer.setMessageListener(MessageListener)
method from running by throwing an IllegalStateException
. For details, see IBM WMQ FAQ answer #92
and IBM Technote #1114239
So when you get this error, the problem isn't a bug in your code, it's your entire approach. In a nutshell, if you want to run a MessageListener in J2EE, don't implement a MessageListener, implement a (can you guess?) messsage-driven bean
(the JMS kind, which implements MessageListener). And if you don't like using EJBs
? Get used to it. MDBs work in J2EE; MessageListeners don't.
A book that simply has not been receiving the amount of attention it deserves is Domain-Driven Design
by Eric Evans
(a friend of mine). This book does an excellent job of taking the most powerful object-oriented practice so far, domain modeling
, and explains it with what is probably the most revolutionary documentation technique of at least the past decade, patterns
. The result is a book that describes exactly how to develop the domain model your application needs. As Kent Beck
commented, "The book is absolutely fabulous! I wish I had written it."
There's now an article by Jimmy Nilsson
(another friend), "Simplify Your Efforts With DDD
." In it, Jimmy captures the essance of Eric's book and techniques (in a nutshell, as it were) and illustrates why it's so useful. Give it a read and find out what you're missing.
For more thoughts on books you might want to check out, see my recent post ISSW Recommended Reading List
Say a file server has a really popular file that everyone wants to download all at once. (My latest blog posting?! No, something important, and huge, like the latest release of RedHat Linux
.) How can a server (or even a cluster) possibly have enough bandwidth? Who wants to pay for all those servers and network connections?
The answer is "download swarming." Swarming enables a server that's being hit with numerous requests for the same file to upload that file with more bandwidth than the server actually has. Impossible, right?
A swarming download is first of all a segmented download
, whereby the server breaks the file into parts; parts can be downloaded concurrently and enable an interrupted download to be resumed. Swarming takes segments one step further: The way a swarming download works is that as the client downloads segments, it must also upload segments to other clients that are downloading the file. (The main server redirects new clients to these established clients.) Thus a swarming download has a multiplier effect: the original server uploads to a few clients, which in turn upload to more clients, and so on.
Why should clients upload and not just download? Because upload throughput regulates download throughput; you have to upload more to download more. As one FAQ
puts it: "You could hack the source to not upload, but then your download rate would suck. Downloaders engage in tit-for-tat with their peers, so leeches have very little success downloading.
There's an open-source program, BitTorrent
, which is all the rage for swarming. It's the brainchild of Bram Cohen
, recently praised in "Downloading Hollywood
." According to the docs
, "Its advantage over plain HTTP is that when multiple downloads of the same file happen concurrently, the downloaders upload to each other, making it possible for the file source to support very large numbers of downloaders with only a modest increase in its load.
" Wikipedia has an incredibly thorough write-up
with pictures and everything. (Although another page then seems to say that segmented downloading and swarming downloading are the same thing. Oops.)
A similar effort is Peer Distributed Transfer Protocol
(PDTP): "PDTP decreases the amount of bandwidth a server needs to effectively serve files to a large number of clients by having the clients distribute portions of files to each other whenever possible.
" Interestingly, Onion Networks
claims to have invented the swarming approach to file transfer and to have multiple pending patents.
As usual, the collective wisdom of Slashdot
was on this years ago: Finally Real P2P With Brains
. It's potentially a way to help handle the Slashdot effect
. (Again, a problem no one accuses my blog of ever having caused.)
IBM has Download Director
, a Java applet that performs segmented downloads transparently. But it doesn't do swarming (nor would customers want that, I suspect; "I have to upload to download?!"). IBM also has an experimental grid downloader, creatively called "downloadGrid
," that runs on an experimental grid computing network
." The grid approach is not just downloading segments concurrently from one server, but from lots of servers, whichever currently can serve you best. But that's still not swarming.
For more information about grid computing, visit the developerWorks Grid Computing zone
. We don't have a Swarming Computing zone, at least not yet.
This is a bit outside the scope of my blog, but interesting news: Carly Fiorina
(no longer here
), the chairman and CEO of Hewlett-Packard
, has resigned. Fiorina has been facing pressure from HP's board and stockholders because the controversial merger with Compaq
she spearheaded in 2002 has not produced the increased shareholder value that was promised. HP and IBM are often seen as each others biggest competitors.
See Carly Fiorina steps down as chairman, CEO of Hewlett-Packard
and HEWLETT-PACKARD: Why Carly's Big Bet Is Failing
Each month, the WebSphere Developer's Zone
column "Meet the Experts
" features an IBM WebSphere expert to answer your questions. I was the expert in December
. This month's expert is one of my IBM Software Services for WebSphere
colleagues, Gang Chen, talking about J2EE transactions. Gang is wicked smart about how transactions work inside of WAS. So put Gang to work; ask him some questions
Lately I've been speaking with some colleagues who are knowledgeable people, but who know relatively little about messaging. So for their benefit and for any of you who feel a little confusion along these lines, here's an explanation of basic messaging terminology. For reference, I'll use terms from the Java Message Service
(JMS) API and the corresponding patterns from Enterprise Integration Patterns
, the book I co-authored with Gregor Hohpe
and several contributors
Messaging is a technology applications use to exchange data, to transfer a data structure (such as a record or set of records, a serialized Java object, the text for an XML document, etc.) from one process' memory heap to another. To transfer the data via a messaging system, the applications put the data in a Message
) and transfer it via a Destination
(aka Message Channel
). An application that adds messages to a destination does so using a MessageProducer
. An application uses a MessageConsumer
to remove messages from a destination. (A.k.a. Message Endpoints
There are two kinds (subtypes) of destination in JMS:
- Queue (aka Point-to-Point Channel) -- A queue delivers each message to exactly one consumer. A queue can have multiple consumers, but only one will get each message. (See Competing Consumers.)
- Topic (aka Publish-Subscribe Channel) -- A topic delivers each message to all of the topic's consumers, so every consumer gets a copy of every message.
A queue producer is called a QueueSender
and a queue consumer is called a QueueReceiver
. A topic producer is called a TopicPublisher
and a TopicSubscriber
is a topic consumer.
So, some quick conversational messaging-speak: An application uses a sender to send a message to exactly one receiver (via a queue), but uses a publisher to broadcast a message to multiple subscribers (via a topic). For more of a quick overview of what messaging is all about, check out the EIP book's introduction
Now, the next time you're at a dinner party and the conversation turns to messaging, you'll be prepared. You can thank me later.
There was a court ruling on Tuesday that didn't end the SCO Linux lawsuit, but it didn't go well for SCO. I don't know anything about this except for what I read, so here you go: