Negotiated Interface

Pattern Name and Classification: Negotiated Interface (Behavioral)

Intent: To provide a flexible common interface that preserves richness, for two or more software components that are non-identical but which share some common methods.

Also Known As: N/A

Motivation: When integrating existing software components into a Service-Oriented Architecture (SOA) it is necessary to create a Service Interface that captures the functionality of that software and makes it available as a Service. Similar software components should be wrapped with a common interface to enable them to be used modularly within the SOA. The Negotiated interface is an approach that produces a flexible interface which enables all the functionality from all the similar legacy systems to be represented, even though that functionality may be impossible to replicate on some other legacy systems.

Implementation: A Negotiated interface is an interface whose methods represent the union of all methods from two or more legacy systems that have been identified by experts as being important within a domain. The interface also includes methods that allow users of the service to query which methods are supported by the currently wrapped legacy system. This may be done by returning a contract that describes which methods are currently available, or by querying at runtime for the availability of individual methods.

Structure: Figure shows a Venn diagram comparing the hypothetical interfaces of two legacy systems (A,B) with the Negotiated interface. The union of A and B but with a negotiation interface that allows individual systems to declare whether they support methods at runtime.



Applicability: It is advisable to use a Negotiated interface when there is novel functionality in some legacy systems that experts believe should be reflected in a common interface even though it is not universally supported. However, a Negotiated interface adds runtime complexity, and makes systems less robust, as they may fail if functionality that is required is missing from the wrapped legacy system.

Participants: The pattern applies to at least two software components which have service-like behavior that is similar. It can be generalised to include more components.

Collaboration: The Negotiated interface pattern can be implemented as an Adaptor-style service.

Consequences: The Negotiated interface is cumbersome to define, but avoids complex expert decisions about definitive interfaces. It adds runtime complexity to a service framework, and because of its dynamic nature can destabilize a service-based system (although this can be mitigated by contract-style negotiation that allows for earlier error checking).

Known Uses: This pattern was used within the JISC FREMA project to wrap two item banks (TOIA and E3AN). The code is available from the FREMA website (www.frema.ecs.soton.ac.uk).

Related Patterns: Adaptor Pattern described how classes can be wrapped in Object Orientation, it is a structural pattern focusing on methods of implementation, rather than what parts of the wrapped class should be exposed. Lowest Common Denominator Interface and Most Popular Interface are alternative patterns that deal with defining common interfaces for similar software systems.