Some posts by my fellow blogger Bob Sutor
have made me think more about what an ESB
(Enterprise Service Bus) is. A specific comment that caught my attention, in ESB*?
, is "if you use WebSphere MQ and other WebSphere brokers or integration servers, you have an ESB today.
Well, yes and no. I think there are two closely related but distinct issues:
- what's come to be known as the Message Bus pattern (disclaimer: I'm a co-author of the book)
- what is generally today being called an ESB
If you want an ESB today, it's a build-your-own affair. In terms of IBM products, you use:
- WebSphere MQ so that all of your applications can talk to each other
- WBI Message Broker if you want to route and transform the messages while they're being transmitted between applications
(WBI-MB runs on top of WMQ.) This provides the basic means for applications to invoke each others' services. Each service is represented by a pair of Request-Reply
queues. Any application that wants to invoke a particular service places an appropriate request message on the request queue for that service, and then listens for the response message on the service's reply queue. Any application that provides a particular service listens for requests on the service's request queue, performs the service, and then sends the response on the service's reply queue.
The thing is, this is really a Message Bus, not an ESB. Enterprises with sophisticated use of messaging have been doing this for years, and it's still where we are today for the most part. So today, I don't think it's fair to say that we can really do an ESB, but we can do a Message Bus, and that's a pretty good start.
So, what's the difference between a Message Bus and an ESB? I think there are two key differences in the way clients (applications that invoke services) will interact with an ESB that is better than what they can do with a Message Bus today:
- describing -- A service in an ESB will be self-describing. Whereas with a Message Bus, the client has to simply "know" the format of the request and reply messages, an ESB can tell you what those formats are. The formats will probably be described with WSDL.
- discoverable -- An ESB client will be able to query the ESB to ask it what services it hosts, and what queue pair to use for a specific service. This directory capability within the ESB will probably be fairly UDDI-like, in that the client can say "How do I invoke the service with this WSDL?" and the ESB responds with the queues to use (perhaps expressed as WS-Addressing endpoint references (EPRs)). This brings me back to the discussions I've been having with another blogger, James Snell, about What is wrong with UDDI? and Thoughts on the UDDI Problem.
An ESB can do lots of other things, and for that matter a Message Bus can too. (A lot of this is broadly referred to as "mediation.") But how will the client experience differ? And how will you code your clients to work differently? An ESB's services are self-describing and discoverable; a Message Bus' are not.
Why is this not practical yet? Standards. Today WSDL describes the format of the SOAP request and response messages and the HTTP URL for invoking the service. WSDL need to be expanded with a standard way to specify a pair of request-reply queues instead of an HTTP URL. Given the URL/address for an ESB, there needs to be a simple and standard way to access its directory service, which must implement a standard for querying an ESB for its services and how to invoke them.
These standards are coming, but we don't have them yet. Which is why today, while we strive for an Enterprise Service Bus, we're still at the stage where what we can build is a Message Bus. But don't let that hold you up; a Message Bus is still a very good place to start, and you can start doing that today. (For more help, see "Understand and implement the message bus pattern
" by James Snell.)
I don't know what this has to do with J2EE, but hopefully you'll find it interesting.
I'm reading a rather insightful book called How We Choose to Be Happy
). The authors asked people for the happiest people they know and interviewed these happy people to learn why they're happy. They also interviewed many people who ought to be happy--due to riches, fame, etc.--and yet are not. They've been able to summarize their findings in nine steps happy people tend to follow.
- Intention -- Happy people start each day planning to be happy today.
- Accountability -- Happy people take responsibility for their actions. They don't blame themselves or others.
- Identification -- Happy people figure out what they want out of life in order to be happy.
- Centrality -- Happy people make sure to do in their daily lives what they want to be happy, and to avoid things that make them unhappy.
- Recasting -- Happy people find the bright side of a situation and make difficult events into learning experiences.
- Options -- Happy people are open to possibilities and don't insist that events must go as planned.
- Appreciation -- Happy people are thankful for the good things and good people in their lives.
- Giving -- Happy people help their friends and their community/world in general without expecting anything in return.
- Truthfulness -- Happy people are honest with themselves and others and do not allow themselves or others to disrupt their plans for happiness.
This is a pattern language
for being happy, best practices for having a satisfying life. Like a lot of best practices, some of this stuff seems obvious. But also like a lot of best practices, to the extent that you're not being as successful as you might like, you might ask yourself if you're following these best practices as well as you can. And if you were to follow these best practices better, would that help?
The developerWorks WebSphere zone
has a feature called Meet the Experts
. Each month a different expert is featured, who accepts questions from readers within a particular topic area and answers them.
I'm this month's expert. (Makes me think they must be running out of experts. :-) Not too surprisingly, my topic area is J2EE architecture and design. So, check out my answers
and leave me a comment here if you'd like to discuss any of these issues some more.[Read More
I just had a rather difficult day of programming that reminds me how frustrating writing code can be. I like writing code, and as an architect I often don't get to spend as much time writing code as I'd like. But today I spent too much time, or at least didn't accomplish as much as I would've liked to in the time I spent.
My task was to write a relatively simple JMS
producer and consumer pair, just to show that we could successfully send and receive a message over a topic or a queue. I quickly got past the coding errors and the runtime exceptions and got to the point where the code seemed to be sending a message successfully, but didn't seem to be receiving one. Everything seemed to work fine, except nothing was happening in the receiver.
This kind of asynchronous messaging problem is notoriously difficult to debug. Maybe the sender isn't sending right, or the receiver isn't receiving properly, or maybe the messaging system isn't working, or maybe some combination of the three. When it doesn't all work, it's hard to tell what's wrong. I spent several hours this afternoon looking at code that ought to work right but clearly wasn't, changing all kinds of things just to see if something would help but ultimately making very little visible progress.
Luckily a colleague came through for me. He was reviewing my code and comparing it to some JMS sample code, and eventually he asked, "Where do you call start?" I was only half paying attention and didn't understand the question, but I had it in the back of my mind for several hours that I seemed to remember the need to start things somehow. But what? MessageConsumer didn't have any sort of start() method; what did?
My colleague pointed out to me that once you have a JMS Connection
, you have to call start()
. More specifically, according to the javadocs, start()
"Starts (or restarts) a connection's delivery of incoming messages." So that was it. I added connection.start()
to the receiver's code, started it again, and out popped all those test messages I'd been sending. start()
was all I needed. Now I'm going back and uncommenting all of the code I commented-out or otherwise changed trying to find the problem.
This seems like an example of the ultimate limitations of programmers writing code: It can be very difficult to get simple things working, and simple mistakes can cause strange behavior that is difficult and time-consuming to diagnose. (For another example, see Problem with Service Locator Pattern
Even with higher-level languages like Java, is code just too detailed and fragile a way to describe how an application should behave? Shouldn't I be able to simply describe the sender and receiver and have the IDE write a pair of compatible ones for me? Should I have to remember that it's not just enough to have to create a Connection, you also have to start it? But you can send to a Connection without starting it, you just can't receive from it? And receive()
on an unstarted Connection doesn't throw an Exception, it just waits forever on a message that is never going to be delivered? Isn't this a lot to have to know, just to send (and receive!) a message?
I guess this why fans of model driven architecture
think it'll save the world. I think the jury's out on that. But there's got to be a better way.
since last Friday, it's official
: Lenovo Group Limited
of Beijing, China will acquire IBM's business for making desktop computers and ThinkPad laptops. (Reuters
) Shedding the PC division is seen as positive financially for IBM because the PC business is high cost and low profit margin as compared to its growing software and services businesses. (CBS MarketWatch
) This is big news in my hometown, the Research Triangle
, because much of the PC division's workforce is here. (Raleigh News and Observer
Now the rumor is that perhaps IBM wants to buy Apple, whose Power Mac G5
is made with
the IBM PowerPC
, The Register
, IT Jungle
) Then again, the Xbox uses PowerPC
, so maybe IBM should buy Microsoft. In any event, for more about the PowerPC, see the developerWorks Power Architecture zone
I just learned about a rather surprising change to the way JMS Session
s work in J2EE 1.4
Section J2EE.6.6: JMS 1.1 Requirements of the J2EE 1.4 specification
Application components in the web and EJB containers must not attempt to create more than one active (not closed) Session object per connection. ... Application client containers must support the creation of multiple
sessions for each connection.
This means that in a J2EE container (web or EJB), a Connection can only have one Session. The spec doesn't explain why this change has been made, but it has to do with the way JMS is now built on the J2EE Connector Architecture 1.5
(commonly though unofficially called "JCA") and the way its connection model works. In JMS, a Connection represents a connection to the messaging provider and a Session represents a transaction within a connection. In JCA, a Connection
represents both a connection and a tranactional context. To make a JMS connection work like a JCA connection, it can only have one session.
As a practical matter, this won't make code less efficient because connections are pooled and reused by the container. But it does affect the way you write your code. (In a J2SE container, a JMS client still has the previous behavior of a JMS Connection being able to support multiple Sessions.)
This change in J2EE 1.4 means that when you port your J2EE 1.3 code (from WAS 5
to WAS 6
, for example), you need to review the places in your code that create JMS sessions and make sure they only create one session per connection, or else the code will fail at runtime. It won't affect your MessageDrivenBean
(MDB) code because the container creates the connections and sessions for MDBs (for example, in WAS, this is managed by a ListenerPort). Likewise, your J2EE code probably doesn't create MessageConsumer
s; it should use MDBs instead (unless you have an aversion to EJB
s in general). But this change may well be a problem for your sender code.
What you need to search for is code creating MessageProducer
s (i.e. QueueSenders and TopicPublishers) that does something like this:
ConnectionFactory factory = /* get the factory from JNDI */
Destination toDestination = /* get the destination from JNDI */
Destination fromDestination = /* get the destination from JNDI */
Connection connection = factory.createConnection();
Session session1 = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session1.createProducer(toDestination);
. . .
Session session2 = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer consumer = session2.createConsumer(fromDestination);
(For simplicity, this example shows JMS 1.1 code. Your JMS 1.0.2 code will use the corresponding Queue- or Topic-specific subtypes.)
The problem here is that connection
is being used to create both session1
. You will need to change this code for J2EE 1.4 to create two connections, then create a session for each. On the other hand, if you existing code creates a Connection and then uses it to create only one Session, that code will work fine in J2EE 1.4 as is.[Read More
, I'm attending the IBM WebSphere 2004 Technical Conference
, Germany. It's a combination of two conferences in the United States, IBM WebSphere Technical Exchange
and IBM Transaction and Messaging
. In the US, the first conference focuses on WAS and WSAD, whereas the second conference focuses on CICS and MQ.
At this European conference, the main two topics are CICS (about 40% of the talks) and WBI/MQ (about 40% of the talks), whereas WAS, Studio, and J2EE are fairly small topics. This is apparently a reflection that J2EE is much more popular in the US than in Europe, at least amongst IBM customers. Also, the area labs are sending their developers as speakers, which influences the topics being presented. Many of the speakers on MQ and WBI are developers from the Hersley (England) lab, and there are developers from the Boeblingen (Germany) lab speaking on Process Choreographer
As in San Francisco, Bob Sutor
gave the keynote here as well. He explained quite nicely what all this SOA and ESB stuff is all about.[Read More
I heard a quote recently that I think is rather insightful:
Everybody is three people:
- who they really are,
- who they want to be,
- and who everybody else thinks they are.
Does anyone know where this quote originally comes from? Where I heard it was on the HBO TV show "Real Time with Bill Maher
," in the November 5, 2004 episode
. It was spoken
by D.L. Hughley
, who I think of as a funny actor but not necessarily a source of philosophical quotes. I assume this is a well known saying, but by who?
In any event, I think it makes a good point.
"This above all: to thine own self be true" -- William Shakespeare, Hamlet
I will be speaking at the WebSphere Technical Conference
in Munich, Germany, Nov 29-Dec 3. I'll be presenting two sessions:
- WF05I - Enterprise Integration Patterns: A Brief Introduction
- WF06I - Architecting and Developing J2EE Applications Using Patterns
If you attend the conference, please look for me and say hello.
My fellow blogger Bob Sutor
will also be speaking
What is Richard Monson-Haefel
of Enterprise JavaBeans
and J2EE Web Services
) up to? Turns out he doesn't plan to write technical books
anymore. Rather, he's now an analyst for someplace called the Burton Group
. They've now published a paper by Richard with the startling title "J2EE: A Standard in Jeopardy
." You have to be a paid member to read it, so I have not, but according to the summary:
The future of the J2EE standard is uncertain. Market forces, including commoditization, open source alternatives, new disruptive technologies, and the maturing Microsoft .NET framework will change the landscape of the J2EE specification and market.
According to "Report: J2EE in Jeopardy
," (another catchy title), Richard believes that the J2EE vendors/community should turn over that responsibility to the open source community. The vendors should focus on the J2EE "super platform." Needless to say, this is a hot discussion on The Server Side: "Analyst Report: J2EE In Jeopardy?
The recent OOPSLA 2004
conference featured a panel, "The Great J2EE vs. Microsoft .NET Shootout
" The speakers were Don Box
(Microsoft), John Crupi
(Sun Microsystems), Rob High
(IBM), Anders Hejlsberg
(Microsoft), and Alan Knight
(Cincom). See "Programming Legends Debate .Net, J2EE
(biased towards Java? Nah!) has captured some of the more memorable quotes that were said in the article "Microsoft's "Java Envy" Is Undeniable, Don Box Admits
." This is something Don has talked about in this blog. Now Microsoft's paying attention: "Does Microsoft Have Java Envy?
I was there. Honestly, each side had nice things to say about the other. Each technology is influencing the other. The main difference is that Java is a federation of separate companies and individuals who thus debate alternatives in public, whereas .NET is run by one company ("the big house") which debates alternatives in private. The debate on where to go next is happening with both technologies; we just don't hear about the private conversation we're not invited to.
has a new section I didn't know about, the Power Architecture Zone
, dedicated to Power Architecture technology. You might ask, "What is Power Architecture technology?
" It's a set of microporcessors produced by IBM
that are the CPUs for Macintoshes
and a lot of IBM eServer
There's also a blog on this topic, Power Architecture zone editor's notebook
, by Nora Mikes, who just so happens to be the editor of the zone. She also has an article, "POWER to the people: A history of chipmaking at IBM
So, if you want to learn more about the hardware used to run some of J2EE and WebSphere Application Server software, go check this out.[Read More
My fellow blogger James Snell
and I are having a friendly debate about the relative merits of UDDI
. In UDDI and DNS-EPD
, responding to my subtlety-titled UDDI Sucks
entry, James rightly points out that different tools work for different purposes. Indeed, as I said, "UDDI seems like a reasonable solution to the stated problem... [but] the problem is the wrong one to solve."
So, what's wrong with the approach UDDI solves? Here are some of the problems:
- Synchronous, point-to-point web services -- UDDI enables the client to lookup the URL for invoking a web service over HTTP. This requires invoking the service synchronously. Assuming the caller invoking the web service is another application, application-to-application integration is best accomplished asynchronously.
- Multiple matches -- With UDDI, the client specifies the WSDL for the web service it wants, and UDDI returns a list (URLs) of providers of that service. It is then the responsibility of the client to choose one of those service providers, yet it has very little information with which to make an informed decision.
- Repeated lookups -- After a caller looks up a service's address, things may change. The service may relocate to a new URL, other providers of the service may become available, the quality of the connection to the various providers can fluctuate. This makes the client defensive, repeatedly looking up the service to see if there's anything new. Likewise, the chosen provider may become unavailable, forcing the client to go look up an alternative (unless it has cached that information, but then it may become stale).
An Enterprise Service Bus
(ESB), on the other hand, encapsulates all of these details and handles them for the client so that it doesn't have to:
- Asynchronous -- One client thread fires and forgets the SOAP request, another thread listens for the SOAP response (or fault). This also enables multiple network paths to the same provider, and resiliency (via queuing) in cases where none of the providers are available at the moment.
- One channel per service -- To invoke a service, the caller puts the request (whose format is described by the WSDL) on the proper channel/queue/pipeline, then listens for the response on the appropriate reply channel (either specified in the WSDL or specified by the caller in the request message). If there are multiple service providers, the ESB figures out which one to dispatch the request to. This can be based on real-time metrics like load, latency, availability, etc. The way most messaging systems work, this balancing is done automatically--a provider which is overloaded or out-of-service simply won't consume the request.
- Single point of contact -- The caller need only know how to address the request channel (such as its URL). This can remain fixed even as service providers come and go and sometimes change their addresses. It's a level of isolation between the callers and the providers that adds stability.
One more point: An ESB can act as a directory service in the same spirit as UDDI. Basically, a caller would ping the ESB much the way it pings a UDDI server, saying "who implements this WSDL?" and the ESB responds with the request and reply channels to use. So maybe DNS-EPD
should provide a way to find ESB hosts as well as UDDI hosts. (And it probably does.)
|Microsoft has quite a presence at the OOPSLA conference this year. Microsoft historically hasn't been very involved at OOPSLA, but as they're trying to participate better with the rest of the industry, they seem to be doing so at OOPSLA. (See comments by MSDN and Harry Pierson on the topic.)|
A few examples:
- Keynote, "The Future of Programming" by Rick Rashid, head of Microsoft Research. Decent keynote, but then he took time out to let someone from the Visual Studio team supposedly demonstrate some new domain specific language features in Visual Studio 2005. (See "The Role of Models.") Like Visual Studio really needs the publicity. The whole demo came across badly; seemed to mostly demonstrate that Microsoft has reinvented HotDraw twenty years later. I still don't know what Visual Studio does for DSL.
- Invited talk, "Realities of Modern Software Construction," by Steve McConnell. (See "Swiss Army Knife Designs.") Steve's not a Microsoft employee, but his book, Code Complete, is from Microsoft Press.
- Invited talk, "Objects, Patterns, Wiki and XP: All Systems of Names," by Ward Cunningham. Ward has accomplished a lot, as he recounted in his talk. About a year ago, he joined Microsoft.
- Invited Talk, "Concrete Languages on Virtual Platforms," by Herb Sutter of Microsoft. He is developing C++/CLI, a new standard version of C++ that runs on virtual machines. Visual C++ 5.0 will be built on C++/CLI.
- Each attendee received a free (no extra cost) copy of Jack Greenfield's new book, Software Factories (with the scary-sounding subtitle "Automating Application Development"), a big topic at Microsoft.
So Microsoft is very active at OOPSLA this year. They're embrassing and extending
objects and the whole OO thing. The question is where this will lead.
To return back to Rick Rashid's keynote, here's one assessment
from the OOPSLA wiki
Tuesday's opening keynote by Rick Rashid was quite interesting until it was derailed by an offensive (and irrelevant?) commercial product announcement and demonstration. A sizable number of oopsla participants left the keynote in disgust and there were several unsavoury words directed towards the hucksterism by the disgruntled crowd gathered outside. Disappointing to say the least.
When Bill Gates
gave an invited talk
at OOPSLA 2002
(in Seattle), there was a lot of concern that it would just be a Microsoft promo (and/or that the audience would be quite hostile). Indeed, his assistants gave demos of a couple of interesting technologies Microsoft was working on, including the handwriting recognition algorithms that went into their new tablet version of Windows
. Rather than being commercial, this came across as educational. The talk was well received.
The demo part of this year's keynote was not well received because it came across as being a commercial and self-serving, not educational and serving the interests of the conference community. Hopefully this example is not typical of what Microsoft's participation will be like in the future.
I'm attending OOPSLA 2004
. Steve McConnell
, author of Code Complete
, gave this morning's invited talk, "Realities of Modern Software Construction." He made a lot of really great points, some of which I may relate in the future, but today I want to focus on an analogy he made, the Swiss Army knife.
A Swiss Army knife
is a knife whose handle not only contains the knife blade, but also contains a bunch of other tools like a corkscrew, scissors, tweezers, and so on. This can be a really handy pocket device if you indeed need all of these tools.
The analogy for programmers is that too much of the code we write is too much like a Swiss Army knife. What our customers need is a knife, but that's not what we build them. Rather, while we're building them a knife, we also build them a whole lot of other stuff they haven't asked for and don't necessarily need. Because of these extra and unneeded features, the program is unnecessarily complex, takes longer to develop than it should, and costs more than it would if it were just a knife. And sadly, the knife often isn't very good, mostly because we couldn't focus on making it good because we had too many other features to work on.
This is a failure to apply the principle You Aren't Gonna Need It
. This principle is that you should only develop what your customer needs right now and no more. If they need more in the future, you can develop it for them at that time. This is likewise a principle of Test Driven Development
: Develop tests for what the customer needs, and then only develop code that helps make tests pass.
It's very tempting, while developing a needed piece of functionality, to develop a bunch of other related and interesting pieces of functionality while you're at it. Resist the temptation. Develop what you need and no more. It'll make you a better programmer.