Federation permits a client to support a set of requirements by enlisting a number of service providers, each of which may support a subset of the client’s requirements, even if none could meet all of the requirements by itself.
As the CTS2 services are stateless, there is no infrastructure to arrange to federate service providers; clients can simply request what they need from the services they know. (Of course, the service provider will want to know the requests are coming in order to ascertain the level of service they can agree to provide.) Further, the independence of the respective providers means that the client can also continue to use native methods alongside service calls for as long as this approach makes business sense: there is no imperative to migrate more requirements than the client wishes.
If a service provider knows its clients will want information that the provider does not have, the provider may implement its own client requests to retrieve the information from other providers, caching it for future use. Such a decision lies within the service provider; it should be invisible to the service client.
A notional example of a federated ecosystem is shown in figure 4.
Federation decisions are assisted by the profiles a service provider asserts. An implementation profile publishes the technology a provider uses (REST or SOAP in XML, with JSON and XML RDF in the works). A functional profile publishes the kinds of service functions provided, e.g., read, query, export. And a structural profile publishes the kinds of resources the provider trades in—value sets, code systems, etc.