Message Exchange
tached to the default exchange group. Back end services will still be able to see any services on the default exchange group which had a service audience of "*".
Note that different exchange groups should not overlap. That is, they should only ever share at most one process with any other exchange group. In effect, exchange groups when used should form a hier- archy. The only time that loops are allowed within the way processes are connected is when creating a distributed exchange server for a specific exchange group.
Scalability of the Framework
Because there is no dedicated message exchange server process serving as the sole repository of serv- ice information, the service registry in each process will contain a record of all services it can see. As the size of an application grows to have very large number of services this may result in the size of what otherwise should be a small process to grow unnecessarily.
Currently there are couple of approaches that can be taken to reduce this problem, however, it is rec- ommended that if you know that you will have very large numbers of services and specifically pub- lishers and subscribers, that you might be better off purchasing one of the commercial products which are specifically designed and targeted at such large scale systems. Such products might not support the concept of distinct services and instead implement a flat name space for subscriptions, but they are more likely to scale better.
In other words, the design of the service agent framework and the message exchange framework lends itself to small to medium size systems. Don’t expect to be able to run the whole of the New York stock market data feeds through this system as it will more than likely not suit your requirements.
Having made this disclaimer, the first things you can do to reduce growth in the size of the service reg- istry in each process, is to not export a service beyond the scope of a process unless you really need to. That is, if the service only needs to be visible within its own process, sets its service audience to be the empty string.
Such a service will not be visible outside of the process and that service will not be able to subscribe to services outside of the process, but in most cases the service will still be able to make a request against a remote service. Restricting the visibility of a service to its own process will also cut down on traffic between processes relating to the existence and withdrawal of services.
The next thing which can be done is to look more closely at the relationship that exists between serv- ices. If there are a group of related services which only need to talk to each, locate them together. This can be done by putting them in the same process and restricting visibility to that process, or by sepa- rating them from the remainder of the application by creating a distinct exchange group. In both cases, have only the services which need to be public actually visible globally.
78
