This month, I thought I would take a below-the-surface look at what needs to
be done to achieve transactional access to the IBM MQSeries messaging product
from WebLogic Server within the context of an Xa transaction managed by
WebLogic's JTA subsystem. Of course, from the outset I would like to note
that WebLogic Server itself boasts a very capable and reliable messaging
system - which is getting more capable with every release - but it is a fact
of life that MQseries for various reasons (most predating the existence of
Java, never mind the JMS messaging standard) has a large installed base, so
good interoperability with it is a requirement whatever your infrastructure
religion.
So Tell Me the Good News
Well, Okay, I will. The first piece of good news if you are looking for
programmatic integration between WebLogic Server and MQ is that there is
working code to ach... (more)
Sad, I mused - you don't often see that any more. My mind then wandered to
hoping that, as technologists, we aren't somehow tacitly colluding in the
erosion of the fabric that holds society together. Hmm, I seem to have come
over all melancholy. Excuse me whilst I visit The Hunger Site...
Understanding JTA
That's better. Anyhow, I digress. I promised to look this month at when to
use transactions and when not to. There's no better place to start than by
examining where the transaction specification (JTA) fits into the whole J2EE
jigsaw.
At a high level, all J2EE specifications fa... (more)
As we've discussed over the past few issues, JTA-style transactions provide a
way for multiple data updates to be tied together so application logic can
operate safely in the assumption that it will succeed or fail consistently,
even in the face of technical failures along the road.
There are, however, times when you do not want all the work you do to succeed
or fail in one big lump.
Among the scenarios that may lead you to want to break work up into smaller
chunks are: Progress/error logging Long-running operations Wide-spanning
operations I discussed the last two scenarios in a... (more)
That was what an old girlfriend periodically said to me. Needless to say,
we're no longer together - I wasn't keen on the comparison. "Shall I compare
thee to a dog?" is rather less poetic than I like. But in thinking about this
month's transaction column, the comment seemed strangely germane to the world
of app servers and transactions.
I've mentioned several times in these articles that the underlying purpose of
an application server is to provide out-of-the-box functionality that you
would otherwise have to write and maintain yourself, despite it having only
indirect relevanc... (more)
The waves of IT, as they are often called to, are marked out reasonably
accurately by languages. Starting almost at the beginning, take COBOL. With
its love of uppercase characters, and overly restrictive attitude to what
column the uppercase characters appear in - not to mention its extraordinary
zeal for the full stop - COBOL has always struck me as a language for
programmers to use to shout at computers. I guess that's a reasonable
alternative to feeding them punched cards, or worse, flicking switches on a
front panel - you can see why the original COBOL guys wanted to shout!
... (more)
Peter Holditch is a senior presales engineer in the UK for Azul Systems. Prior to joining Azul he spent nine years at BEA systems, going from being one of their first Professional Services consultants in Europe and finishing up as a principal presales engineer. He has an R&D background (originally having worked on BEA's Tuxedo product) and his technical interests are in high-throughput transaction systems. "Of the pitch" Peter likes to brew beer, build furniture, and undertake other ludicrously ambitious projects - but (generally) not all at the same time!
David Lucas
Cathy Lopez
Shaul Efraim
Terence Martin Breslin
Cory Marchand
David Hughes
James Carlini
John Iffert
Dan Stolts
Joe Zeto
