I am looking at some architecture changes in our environment. One of the new features that was created in 8.X was Broker Clustering. It looks like Broker Clustering is much like Territories, but without the automatic document forwarding. However, does anyone know how to connect a IS Cluster to a Broker Cluster? I realize I could connect the IS to a single Broker that is a member of the cluster, but this doesn’t achieve the flexibility that I am looking for. I really am looking at Broker Clustering for the JMS Cluster policies that it offers. The IS 8.2 Admin Console still only provides a single connection to a single Broker.
Other question. If you establish a Broker Cluster, then how do you communicate between a cluster of brokers and a territory? When I am configuring Brokers in the My webMethods server I don’t see an option to tie a cluster gateway or a territory gateway to a Broker Cluster. How is this communication achieved?
The more I read about Broker Clusters, the more I don’t like them and feel that they are too limiting. Is anyone using Broker Clusters?
I’ve not used the new Broker clusters facitlity but upon reading the docs (and having used territories and Broker HA in the past) here are my thoughts:
As you noted, clusters are a slight variation on territories. The difference being only that clusters will not forward published docs to other Brokers in the cluster. I’m not sure I understand the scenario in which clusters provide value.
Like territories, clusters do not support a “connect to logical name” approach. Clients must explicitly provide their own load-balancing/failover functionality by connecting to different Brokers as appropriate. Based on the docs, only the JMS facilities support this at this time (e.g. IS Broker config does not).
The docs infer that clusters and territories are mutually exclusive. You’ll use one or the other, not both. Or if you use both, they won’t communicate with each other with the provided facilities. You’d need to create your own bridge.
Glad we are on the same page. I was afraid that a custom bridge between a territory and a cluster would be required, which is in my opinion not an enterprise solution.
I am considering a “ESB Territory” with IS & Broker pairs that are distributed on a functional basis (i.e. web services, TN/EDI, Mainframe, JMS, Batch). How have you used territories in the past? Today we have siloed instances for specific applications that share a lot of the same functionality. When I say this I mean that each IS & Broker instance connects to the Mainframe, provides web services or TN/EDI functionality for various applications. We feel that segmenting based on function will provide greater flexibility from an upgrade, scale and outage perspective. We have only used territories in specific cases where one siloed Broker wanted to talk to another siloed Broker. In this case the territories only had a single Broker as a member, which doesn’t really leverage the functionality of territories very much.
My experience with territories is that no one uses them, except for one company that went to an extreme–they had hundreds of IS instances and many, many Brokers. They went somewhat bonkers, IMO, in using territories. They segmented them via business function.
Each functional area had a territory. To connect territories they started out using direct territory to territory gateways. Thus, territory A might connect to territories B, C and D.
This became an administrative headache so they created a special territory that was used to house territory gateways. In this manner, territory A would connect only to a gateway in this “intermediary” territory and they’d manage document management and forwarding from there.
Territories are a reasonable way to achieve a bit of scalability wrt Broker. Broker clients connected to the Brokers in the territory can exchange docs easily without needing to know which Broker other clients are connected.
The misconception many have about territories is that client A can now dynamically connect to any Broker in the territory (the phrase “many Brokers treated as one” in the documentation infers this). That is not the case. It can only connect to 1. Connecting to that 1 Broker lets the client communicate to any other client connected to any other Broker in the territory. That’s where the scalability comes from. Alas, it isn’t a facility intended to provide load balancing or failover.
The word “cluster” tends to infer dynamic load balancing and failover facilities. Alas, neither Broker territories nor clusters provide those. They provide scalability through relatively static component segmentation.
[Edit]: The main reason most don’t use territories is because, in general, they aren’t needed. Broker isn’t the bottleneck in most places. IS is.