Patterns for Federated Architecture.

Abstract

An enterprise federated architecture intends to mirror the structure of the organisation, aiming to provide better support for both new and legacy applications within a distributed environment and facilitating data exchange between applications to support information integration. Under this architectural form, the organisation's information systems are separated out into autonomous co-operating application clusters, each connected to a message-oriented federal highway acting as the vehicle for inter-domain communication. The federated approach intends to avoid unnecessary coupling (in the distributed computing sense) by grouping highly interdependent modules and applications into domains, whilst minimising the strength of inter-domain connections. This article presents how to design a distributed federated architectural form using three architectural patterns, and shows how these three patterns are to be connected to comply with the specification of the the federated form. MOTIVATIONLet us consider this example: SafetyNet Insurance started as a small Australian company selling house and car insurance, but it expanded very quickly by merging with another company specialised in life insurance. The merger was to take advantage of the synergies between the different insurance products by offering their customers discounts and other advantages if they were loyal to the company by conducting all their business with SafetyNet. Based on the success of their sales force, the organisation expanded with branches in other capital cities in Australia. It was considered crucial that salespeople maintained at least the same level of satisfaction with their jobs, so new incentive schemes were introduced to reward the high selling branches, salespersons, etc.The inital attempts to provide the necessary information for the new way of doing business were paper or file based. Lists of customers, sales, policy information, and other data were exchanged on paper or via files by Head Office and the different branches and groups within their branches, such as General insurance, Life Insurance, Human Resources, Finance, Actuarial Services, and Management Information Systems. Very soon a stream of problems started to emerge: DESIGN PATTERNS FOR A FEDERATION ARCHITECTURE 136J OURNAL OF OBJECT TECHNOLOGY V OL. 2, NO. 3 The processing of an agent's commission is slow and unreliable.The processing of an agent's commission is housed at Head Office on a central computer that also runs another mission-critical legacy application. Each time a new insurance policy is issued by a branch, the sale information is manually loaded into a local client application, and a transaction with the central system is fired to update the commission of the employee. However, the central computer is slow, and many times the transaction is left hanging with the branch waiting for the system to respond. Often, the transaction times out, and it is necessary to kill the process and start over, frustrating the branches who get bogged down with the agent's commi...

F-CBR: An Architecture for Federated Case-Based Reasoning

“…Distributed and federated architectures are sometimes mistaken for one another and used interchangeably in certain situations. Nevertheless, they are two distinct architectural styles [23], [24]. A distributed design is adopted primarily to address the issues of parallelism, scalability, and availability.…”

“…The reasoning in F-CBR is performed by a loose federation of participating local CBR systems, known as members and is coordinated by a central server, the federator. The F-CBR architecture is inspired by the paper on design patterns for federated architectures [23].…”