Hi there.
We are trying to find the “best” Enterprise server/broker configuration for our company. We have multiple groups within the company (eg. Investments, Wealth Management, Creditor, Corporate, Customer Relationship Management). Some of these groups will need to exchange data. The amount of sharing and volume is not really clear yet. One of the big requirements at our company is to provide “isolation and independence” for each group. Security is also a big issue. If we put all groups in one Territory it appears that security becomes a bigger issue (???) Some of the data being passed around is very sensitive.
We are leaning towards putting each logical Enterprise Server in it’s own Territory and then connecting these groups to a HUB Enterprise server in it’s own Territory.

The webMethods version 6 GEAR document (GEAR Developer’s Handbook.doc) shows a sample broker topology (on page 43) that we are considering. The benefits of this topology mentioned in the doc are:

Truly global architecture with great scalability
o Hub territory eliminates direct territory-territory communications, allowing architecture to easily scale as the number of territories is increased.
o Number of brokers in each territory can be increased to provide scalability.
o Each hub broker server can be deployed geographically.
o Multiple organization/project broker servers connect to their local hub broker via gateway broker.
Each organization/project broker server pairs with a dedicated gateway broker that passes Canonical documents among gateways.
Dedicated Broker Server for every organization/project
o Provides isolation and independence.
o Dedicated ‘Canonical’ brokers.

If this topology makes sense, should we start with this type of topology immediately or gradually move to this topology as needed ? Adding brokers to territories AFTER they are populated seems like such a hassle. I’m worried that if we start with one giant territory containing multiple logical Enterprise servers we will run into issues when we choose to split these servers/brokers into separate territories later and connect them via Gateways.

Documents are good, but can anyone share their experiences dealing with multiple logical broker servers and Territories ?

Comments are appreciate as usual…

Regards,

Wayne

We’ve been through a couple different topologies and I think you are on the right track with the individual territitories connected by a central hub. We have very similar requirements here and we are doing the same thing.
I would implement it that way from the beginning. We were able to split ours pretty easily but you’d have to be very careful about developing dependencies between the logical groups.

Tim, thanks very much for the comments. In your topology how do you deal with shared corporate services (eg. Address validation, ldap update/lookup, corporate accounting, etc…) and/or shared common operations. All “group” broker servers will require these services. Our thinking was to dedicate a broker server for Shared/Corporate services…however I’m not sure what performance will be like going through a Territory gateway, hub territory to get to the shared broker (and then back again).
Any thoughts on fitting shareable (corporate wide) services into this topology ?
Another question: Are you doing any B2B with Integration Server ? If so, did you just “plug” the Integration server into the “hub” Territory using the IS/ES bridge ?

Thanks again.

Does anyone else have any comments on this topic ?

Regards,

Wayne

Shared integration reside on our hub/common broker. We don’t really have high transaction volume to these components so I haven’t seen any performance issues so far. We do have a B2B server connected to our common hub. We don’t do extensive B2B right now so our architecure is kind of ad-hoc in that respect.

Hi.
We have been having many headaches developing using multiple logical Enterprise servers under one Territory. Our real problem is lack of support people to manage the deployment to these brokers. So the developers end up deploying code…and sometimes wiping out other business unit integrations. Not a good thing. If we had a dedicated person to be the “gatekeeper” for the code in development we may not have this problem, but unfortunately we are limited on resources.
We are leaning back towards the one-Territory-per-business unit idea

Our business units are independent and distributed, however there will be integrations between business units. Currently each business unit is developing integrations assuming one big mother-of-all-territories. I’m not sure of the volume. For this reason
the multi-Territory option looks better for us. My questions/concerns are:

1. How much extra administrative & development effort is there when using the multi-Territory & Gateway option versus the multi-Enterprise servers in one Territory option ? (any chance that there is less effort ?)
2. I know there could be an extra performance hit for guaranteed msgs across the Territories/gateways. Can anyone highlight other pros and cons for these options ?
3. One of the best practices docs I have seen mentions “territories can add some complexity to a project design, development and maintenance. Allow longer development and debug time for implementing territories.” If we do separate our business unit Enterprise servers into their own territory, will changes be required to our existing integration components ?
4. Is one a bigger support/development headache than the other ? I know there will be extra support for the territory gateways…

I need to make a business case to hire more people.

Thanks in advance for your help.

Regards,

Wayne

I don’t like the concept of Territories very much, because they don’t provide much control…It’s like dropping a bunch of Brokers together, but not really increasing scalability or throughput, since they are multi-casting the documents amongst eachother. I do like Gateways b/c its a logical firewall and allows control amongst Broker document flow. But, you need a Territory as the mechanism that Gateways connect to, so I only put 1 Broker in a Territory and use Gateways across business units, functional segregation, or technical segregation (Side Note: functional segregation is often a waste of resources, as 1 Broker stands idle while the other is being stressed).

I have seen projects use a hub/spoke with Brokers/Territory/Gateways. It’s a really nice approach to creating a “Common Object Broker” that anyone can access.

Also, both Gateways and Territories are tradtionally buggy. They existed in ActiveWorks 3.x and continued to have major bugs through Broker 5.x (Havent tested them in Broker 6.X yet). I believe they were finally starting to stabalize in the later SP’s on Broker 5.x…Caveat emptor

Jordan, thanks for the feedback. We are doing a pilot by pulling one of our business units out of the common territory and putting them in their own territory. This business-unit-territory will “plug” into a “hub” territory. The other common territory will then "plug’ into the “hub” territory. Documents that need to be exchanged will be defined on the gateways. It sounds good in theory. Hopefully we don’t have to many problems with bugs.

Regards,

Wayne

Hi,

would like to know how to improve guaranteed storage functionality while using multiple territories and gateways. How does broker queue up the events if remote gateway is down?

Regards,