As promised, I'm attending the IBM WebSphere 2004 Technical Conference in Munich, Germany. It's a combination of two conferences in the United States, IBM WebSphere Technical Exchange and IBM Transaction and Messaging
Conference. 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 and BPEL.
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]
Bobby Woolf: WebSphere SOA and JEE in Practice
Bobby Woolf 120000HQ53 566 Visits
I just learned about a rather surprising change to the way JMS Sessions work in J2EE 1.4.
Section J2EE.6.6: JMS 1.1 Requirements of the J2EE 1.4 specification states:
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 MessageConsumers; it should use MDBs instead (unless you have an aversion to EJBs in general). But this change may well be a problem for your sender code.
What you need to search for is code creating MessageProducers (i.e. QueueSenders and TopicPublishers) that does something like this:
(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 and session2. 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]
As rumored 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 processor. (SYS-CON, 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.[Read More]
Bobby Woolf 120000HQ53 678 Visits
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.
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 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 (website). 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.
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?