Service Interfaces

Lately I have found myself in discussions about "Service Interfaces" again.
Based on these discussions I have found that there is still tension between service providers and consumers about interface size.
Regarding this issue, there are two schools of thought:

• GCD
• LCD

In the GCD (Greatest Common Denominator) school of thought, the service interface has to encompass every item of business information in its model. The full model is used as a vessel between consumer and provider. All information items on the model are considered optional and each Business Service "picks" the items that are of interest to it.

The problem with the GCD model is that every service provider and service consumer NEEDS TO BE AWARE of the full business model as a whole, even though they may only use a fraction of the model.

In the LCD (Least Common Denominator) school of thought, the service interface contains only the items of information REQUIRED to fulfill the service. Each Service has its own vessel of information interchange, that is passed between consumer and provider. The physical interface contract is strict. This facilitates that most of the semantic validation of the interface is enforced syntactically.

I found that adversaries of the LCD approach fear that soft-semantic changes to the service requires change to the interface.
This statement may not necessarily be correct.

The key lies in "separation of concerns". To be more precise, the separation of "Service" concern and "Data Management" concern.
Consumers are primarily interested in Services and concerned about "Service Integrity". Providers are traditionally concerned about "Data Integrity". Service Integrity and Data Integrity are not always the same thing, even though they are often heavily influenced by one-another.

Service Integrity strives for predictable behavior of services.
Data Integrity strives for consistency of information.
A Service provided by a system that has data integrity problems tends to behave unpredictable.

If the concerns of data management and service integrity are separated in the service interface, the service consumers will be issued with a LCD type interface into a course grained service. Additional information required by the service providers (but not the service consumers) is acquired by the provider through "choreography".
This approach includes the following steps

1. The consumer provides the information that it needs to know in order to use the service.
2. Choreography is used to aggregate the information provided by the consumer with other pieces of information required by the service providers. This could entail the use of ancillary services.
   
3. Providers process the aggregate information.
4. The service returns ONLY the information that pertains to it.

In the Policing domain, updating charge information would not require all the information regarding a Person of Interest including their criminal history etc... Typically a Charge Service would need a Person of Interest artifact and a Charge Artifact. The Person of Interest artifact could consist of only a reference number (integrity concern), name and date of birth (client concern) so that both service and end-user can make an accurate decision of adding a charge. The implementation of the Charge Service itself (rather than the service consumer) could then orchestrate the charge update in such a manner that Case Information, Criminal Activity statistics and such are appropriately maintained (data integrity).

LCD based interfaces do not necessarily have to be disjunct from a CIM (corporate information model). Items that make up the request can (and should) still use types that are defined in the CIM. This is precisely why a CIM must be carefully crafted.

The 3-way model for CIM model elements generally serves well.
This 3-way model provides each entity in a CIM to have:

• a "reference representation". The "reference representation" only includes a system based identifier and a human based identifier (where required).
• a "full representation". The "full representation" contains every element that makes up the entity with ALL elements that are required for data integrity purposes (from the perspective of the corporate model) set to "required"
• a "loose representation". The "loose representation" contains every element that makes up the entity with ONLY the system based identifier set to required.

"Reference representations" are generally only used by services that require the indication of dependency with non-service parts of the model. "Loose representations" are used by services that primarily require information for display purpose. "Full representations" are generally only used by the service providers and within the service itself.