WMQ v7.0.1 and WMB v7 have a new feature for standby processes that make the products more highly available.
The feature in WebSphere MQ, introduced in v7.0.1, is called multi-instance queue managers. The corresponding feature in WebSphere Message Broker, introduced in v7, is called multi-instance brokers. In both cases, the queue manager or broker runs in two processes, one active and the other on standby. If the active one fails, the product automatically fails over to the standby, with virtually no service interruption. Note that any resources the processes use, such as a database, must have their own high availability capabilities.
Multi-instance queue manager
In prior versions, to make WMQ or WMB highly available, one had to use hardware clustering (such as PowerHA (formerly known as HACMP) or Veritas). Hardware clustering may still be the gold standard for HA, but for environments that don't quite need the gold standard, software clustering via multi-instances may be good enough.
This new design reminds me of how the service integration bus in WebSphere Application Server works. An SIB bus is a collection of messaging engines managed by the WAS HA manager. By default, it runs two copies of each messaging engine, an active and a standby. If (parts of) the cluster lose communication with the messaging engine, the HA manager switches them to use the standby. Only one copy of the messaging engine can be active and only that one can maintain a lock on the external storage for the persistent messages. Multi-instance queue managers work in much the same way.
The new Redbook High Availability in WebSphere Messaging Solutions contains a section on multi-instance queue managers and brokers. To quote:
WebSphere MQ V7.0.1 introduced the ability to configure multi-instance queue managers. This capability allows you to configure multiple instances of a queue manager on separate machines, providing a highly available active-standby solution.
WebSphere Message Broker V7 builds on this feature to add the concept of multi-instance brokers. This feature works in the same way by hosting the broker's configuration on network storage and making the brokers highly available.
So if you needed a reason to upgrade to WMQ and WMB 7, now you have it.
Thanks to my colleague Guy Hochstetler who made me aware of this new feature.
How would you like early access to Websphere products and features?
I've talked about the WAS Feature Packs
for WAS 6.1. There are now feature packs for WAS 7.0
and some other WebSphere products as well.WebSphere software early programs
lists gives you access to new WebSphere stuff before it's production ready. Currently listed are a couple for WAS 7.0:
- IBM WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA) V1.0.1 Open Beta
- IBM WebSphere Application Server V7.0 Feature Pack for XML Open Beta
And a couple of other items:
- WebSphere MQ V7 Open Beta Program
- IBM Monitoring and Diagnostic Tools for Java - Health Center v1.0 Open Early Access Program
This is one of the IBM software early programs
, which also lists early programs for the Information Management, Lotus, Rational, and Tivoli brands.
Update: See also: WebSphere Software Early Programs
Technorati Tags: websphere, early programs, websphere application server, ibm || Digg it | Slashdot it | Post to del.icio.us |
The single most important book for security pros to read is Enterprise Integration Patterns.
|Isn't Enterprise Integration Patterns that book on best practices for using messaging systems and developing enterprise service buses (ESBs)? The one Forrester called "the core language of EAI"? Why yes it is.|
But it's that and more. According to Gunnar Peterson, the biggest hurtle to becoming a security pro is understanding security integration, and the best way to learn that is by reading EIP. This is because, Peterson explains, it's easier to teach security to developers who know how to design distributed systems well than it is to teach network security experts how to develop applications.
And I quote:
Rather than obsessing about the latest and greatest threat, its much more strategically important to sort out the logistics, constraints, and economics to distribute and scale out the security mechanisms and processes we have. Specifically how are they impacted by and how do they impact the message flows, endpoints, routing, transformation, and management. These patterns are aptly described and cataloged in Hohpe and Woolf's book and provide an important starting point for meaningful and useful security improvement over time.
So if you'd like to learn how to design distributed systems so that they can be secured easily and effectively, check out EIP
Technorati Tags: enterprise integration patterns, security, enterprise service bus, application integration || Digg it | Slashdot it | Post to del.icio.us |
As of WAS 7.0, you can now connect an MDB to a remote SIBus.
Great, so what does that mean? The Service Integration Bus
is the feature as of WAS
6.0 that is a built-in JMS
provider. Message-driven beans are EJBs
for receiving JMS messages. For an application's MDB to receive messages from a queue in a particular SIBus bus instance, the application must be running in a WAS application server or cluster that is a member of the bus, basically meaning that the bus has one of its messaging engines running in the server/cluster. Thus when an MDB reads messages from a queue, the bus for that queue is essentially local to the application.
An MDB is configured by a JMS activation specification. The JMS activation specification
in WAS 7.0 adds a new property, Provider endpoints, which (as the docs explain somewhat subtly) "allow the applications to consume messages from a remote cell." Technically, it will work with any remote bus, but the main reason to connect to a bus remotely is because it's in a different cell; if it were in the same cell, you could just add the application's server/cluster as a bus member of the bus and therefore make the bus local to the app.
With this property, when the MDB pool is activated, the beans will first try to connect to the bus specified in the Bus name property (if any). When that fails, it will then try to connect to the buses specified in the Provider endpoints. These Provider endpoint buses need not be local ones--ones where the server/cluster is a bus member. Because the buses are specified by the host name and port number of their bootstrap server (essentially, the point for connecting to a bus remotely via TCP/IP), the bus can be remote--the server/cluster does not have to be a bus member. A remote bus is sometimes also referred to as a foreign bus
Normally to connect to a foreign bus, you need to use a service integration bus link
to connect one of your server's local buses to the foreign bus. This is still the only way to send messages onto a destination on a foreign bus. But to receive messages from a destination on a foreign bus, you can now configure an MDB to connect to the bus remotely, bypassing the server's local buses (if any).
This new feature is now also available in WAS 6.x, but requires a fixpack. See PK77768: PROVIDER ENDPOINTS PROPERTY ON ACTIVATION SPECIFICATION NOT AVAILABLE WITH WAS V6.0/6.1
for more details.
Thanks to my colleague Rajesh Ramachandran for letting me know about this new feature.
Technorati Tags: websphere application server, message-driven bean, java message service, ibm || Digg it | Slashdot it | Post to del.icio.us |
With WAS 7 and WMQ 7, a WMQ queue manager can join an SIBus as a bus member.
OK, that takes some explaining. First, there's a new version of WAS available, WebSphere Application Server V7
. Second, it contains a built-in JMS messaging provider that was first introduced in WAS 6, internally known as the service integration bus
and what WAS calls "default messaging." Third, WAS can connect to WebSphere MQ as a JMS provider (see "Make WebSphere MQ the JMS provider for applications deployed in WebSphere Application Server
The question has been how to set up WAS so that its apps can use both an SIBus and a set of WMQ queues (what we're now calling a WMQ network) without needing to know which queues where in which provider. No doubt, WAS could have two providers--an SIBus and a WMQ network--and apps could access queues in both. But ideally WAS apps should just use the SIBus and non-WAS apps should just use the WMQ network, and the bus and network should be grafted together somehow.
As of WAS 6, the grafting was accomplished using MQ Link. The two bus and network were still separate, but bridged
via MQ link.
Now there is another option: Make a WMQ queue manager a member of an SIBus, essentially making the queue manager act like a messaging engine. Then, for the applications running in a WAS cluster that is a member of the bus, the queues in the queue manager act like queues in any other messaging engine--that is, they act like any other queues in the bus. While the SIBus in the WAS cluster and the WMQ queue manager are still separate, they're tied together as a single bus. This is a feature that was available in WAS 6, but only with WMQ 6 on z/OS. Now, with WAS 7 and WMQ 7 distributed (or WMQ 6 or later for z/OS), it works on all platforms.
For more info, see "Interoperating with a WebSphere MQ network
," which outlines the three options:The different ways of interoperating with WebSphere MQ
Why three approaches? Because none of them is always the best one. To learn the pros and cons, check out "Learning about interoperating with a WebSphere MQ network
" and "Choose the most appropriate interoperation method for each of your messaging applications
IBM's Graham Wallis also talks about these options in Connecting Buses
Technorati Tags: websphere application server, websphere mq, service integration bus, ibm || Digg it | Slashdot it | Post to del.icio.us |
A dude from Dopplr has posted a presentation on how it works.
"Made of Messages
" by Matt Biddulph explains "It's important to think about serverside architecture as an asynchronous system." It then explains how the internals of Dopplr
work very asynchronously. Good stuff.
The part that really caught my attention is slides 6-8, where Matt recommends reading Enterprise Integration Patterns
in order to understand asynchronous programming and messaging better. Matt says, "This is a great book. Really. Ignore the name." (Apparently there's a problem with the name?)
So if you're busy doing everything all Ajax, Web 2.0, mash-up and what all--hey, it turns out that Enterprise Integration Patterns
is still a good book for you, even if you don't think of what you're doing as "enterprise" or "integration." Thanks, Matt. (And thanks to my friend Andy Piper
for letting me know about Matt's presentation.)
Technorati Tags: messaging, asynchronous, enterprise integration patterns || Digg it | Slashdot it | Post to del.icio.us |
A couple of IBMers who help develop the messaging components in WebSphere products have their own blog.
The WebSphere and Messaging
blog discusses WAS
and messaging, specifically components like the service integration bus
. Topics include the new Cluster Bus Member Wizard
in WAS 7
, getting XA recovery working
in a bus, and how to connect multiple SIBuses
. For an overview, see WebSphere Application Server V7.0 Messaging
. This is obviously pretty deep technical stuff, not just marketing. I hope you'll find it useful.
These guys also contribute to the WebSphere Community Blog
, which isn't so specifically focused on messaging but on WebSphere products in general.
Technorati Tags: websphere application server, messaging, jms, ibm || Digg it | Slashdot it | Post to del.icio.us |
Now available: Beta versions of the next versions of WAS and WMQ.WebSphere software early programs
makes beta versions of products available for evaluation. It now has WAS 7 and WMQ 7:
It also has the beta of the SOA feature pack for WAS:
There are also GA (i.e. non-beta) WebSphere Application Server Version 6.1 Feature Packs
for Web Services
, Web 2.0
, and EJB 3.0
. See WAS Feature Packs
for details. There is also a RAD 7.5 beta
Technorati Tags: websphere application server, websphere mq, rational application developer, websphere, ibm || Digg it | Slashdot it | Post to del.icio.us |
Message-driven beans (MDBs) on the service integration bus (SIBus) can now be stopped and restarted.
I've talked about The Message Consumer Rollback Pattern
, which says that if a message is valid
but cannot be processed, you should roll back the transaction to put the message back on the destination. But then won't this cause the message to be read and rolled back forever?
Yes, unfortunately messages will tend to retry forever, at least until the problem processing the messages is resolved. To prevent this, you need a way to detect this circumstance and respond by stopping the consumers. The idea is that if they can't process messages successfully anyway, they should stop consuming messages until the problem is resolved and processing will be successful.
In WAS 5.x, the listener port
could detect a message that rolled back too many times and would stop. We lost this capability in WAS 6.x when we use activation specs to configure the connection between an MDB class and a JMS destination in the service integration bus
We have now regained this capability with activation specs with this patch: PK49507: The SIBus resource adapter will now indicate that an MDB should be stopped if a certain number of failures are hit
. I talk about this in detail on my wiki: Pausing SIBus MDBs
. (Thanks to Perficient's Dan Zrobok for pointing out this patch to me.)
In the process of documenting that, I also added or updated the following wiki pages:
Technorati Tags: websphere application server, service integration bus, java message service || Digg it | Slashdot it | Post to del.icio.us |
Several of IBM's messaging products developers have now started a blog.
The full name of the effort is "A bunch of bloggers from IBM software Labs working on WebSphere MQ, WebSphere Message Broker, WebSphere MQ Everyplace, IBM Lotus Expeditor micro broker," a group that calls themselves the IBM-Messaging-Evangelists. These guys are from the groups that develop some of IBM's various messaging products. They're doing a nice job of announcing new releases and linking to relevant materials so you can learn more.
Check out the IBM Messaging blog
and the corresponding IBM Messaging space
Technorati Tags: websphere messaging, websphere mq, websphere message broker, enterprise service bus, websphere, ibm || Digg it | Slashdot it | Post to del.icio.us |
Lately, I've heard people using the terms "adapter" and "mediator" somewhat interchangeably. I think they're different.
They are similar, in that they're different ways to accomplish the same goal, with advantages and disadvantages to each. For the full write-up, see Mediator vs. Adapter
(on my wiki
You may also wish to check out Message Channel Revisited
I've been thinking about the Message Channel pattern lately.
In conversation, I tend to call a pipeline between apps a "channel," by which I assume it is (or will be implemented as) a Message Channel
, for example a JMS Destination
. Recently I've had to clarify that, especially in terms of "Is HTTP a channel?" That's lead me to think of four patterns, which I've started to document in Message Channel Revisited
(on my wiki
How can I create a link between the SIBus and WMQ that is highly available?
See Creating a HA Link between WebSphere MQ and a Service Integration Bus
I have a new article on developerWorks
, "Running a standalone Java application on WebSphere MQ V6.0
It's an update of my previous article, "Developing a standalone Java application for WebSphere MQ
," which was written for WMQ 5.3. For this version, I have as co-authors T. Rob Wyatt and Kulvir Singh Bhogal; so to the extent this article is better than the first one, give them the credit.
I hope you'll find it useful for learning about JMS
and how they can be used in Java SE
(not just Java EE
), as well as how to admin and configure WMQ
Alphaworks has a new tool available for checking out a JMS messaging system.
I talk about it on my wiki
in IBM Client Application Tool for JMS