Suppose you wanted to send a greetings card to someone living in a foreign country. You could address the envelope to "King Alfred, The Broadway, Winchester, England" and post it anywhere in the world. Suppose you did this in the US. The local postman only needs to see the country part of the address to get the envelope heading in the right direction. It'll be conveyed to an airport from where an aircraft conveys it across the Atlantic. On landing in England, it'd reach a sorting office and be routed within the English postal system. The English postie will know where Winchester is. Well, you'd hope so anyway. Each of the US and UK postal systems is its own domain, with knowledge of how to deliver mail to addresses in that domain, and how to route mail addressed to another domain.
This is pretty much how WAS messaging works too. You can link SIBuses together so that messages can be routed from one bus to the other. Why would you want to do this? Why not just create one great big bus? Well, to a limited extent you could try and do this - but eventually you'd run up against one of a number of limits. An SIBus is defined within a cell and can't extend beyond the edge of the cell. There's a limit to how large you want to make your cell - in terms of numbers of nodes and servers and in terms of geographical span or organisational spread. So your bus will only reach as far as the cell that contains it and if you have an application in that cell that needs to send a message to a remote application - one that is in a different cell - then you're going to need to be able to reach outside of the local cell.
You could use a client connection but you'd need to know how to route the client connection to an apropriate endpoint, or liaise with the other cell administrator to bridge the coregroups between the cells. But you'd need to do this for all applications that need to send such messages and it would be a lot of work, and fragile. It's much more natural to connect your application to the local bus and let the SIBus do the leg-work. Hence it's better to link the buses.
You may have created multiple buses within the same cell, e.g. for traffic separation and then decide you need to link them together. That's done just the same way as for a pair of buses in different cells.
So how do you do it? You define a foreign bus and you designate a pair of messaging engines, one in each bus, that will link to one another. The foreign bus is a lot like the US Postal System knowing that there is a country called England and knowing which airservice to route it to. The link is like the air service, and the messaging engines are like the airports used by the air service. When the link and the foreign bus are defined, an application can send a message addressed to a destination hosted in the foreign bus, and the messaging engines in each bus will take care of routing the message, via the link, to the other bus and ultimately to the destination within that bus.
Since WAS v6.0 it's been possible to do this. You'd create a definition of a "foreign bus" and a "link" to the other bus. You could create a direct route to a neighbouring bus or an indirect route - meaning that you can reach another bus by routing through an intermediate bus. So you could construct a spanning tree of interconnected buses. The foreign bus support in WAS v6.0 allowed for the fact that the foreign bus could be either another SIBus or it could be a WMQ queue manager. In the latter case protocol conversion is needed at runtime, so you have to create an appropriate type of link - either a SIB-SIB link or a SIB-WMQ link. You could then create the foreign bus definition, including the name of the link.
There were a few difficulties with the support in WAS v6. One difficulty was knowing what objects you needed to create; another was that the creation of these objects required separate wizards or console panels; yet another was that you had to cretae the link before the foreign bus or there'd be strange fizzing noises and something in the distance would go bang. The separation of the objects was bad for usability. There was also a certain amount of finesse required to know that certain parameters should ideally match the values for certain other parameters.
All in all it was a bit hard, which made it a great opportunity to impress your friends and the bad news is that WAS v7.0 has a simple wizard that makes the task a whole lot easier...even your manager might stand a chance of getting it right. The wizard provides a single start point in the console for creation of a foreign bus connection between SIB-SIB or SIB-WMQ. The wizard guides you through the process prompting for the minimum amount of information and creation all the necessary ojbects in a consistent manner.
It's not a panacea - some of our more experienced users who got to grips with the early drivers found the wizard rather limiting, because it does hide a lot of the complexity. For them it hid too much; they're used to bashing all the configuration properties into one huge panel. Instead they now have to step through the wizard to create what is effectively a simple object and then go into the detail view of that object to set up some of the more advanced properties, such as SSL. I guess it shows that the mantra of "making simple things easy..." can backfire occasionally, or maybe that you "can't please all the people all the time"!
There are of course wsadmin commands that'll let you do everything in a single action. But we're aware that the wizard is not to everyone's liking and will try and improve upon it next time around.
Graham
