A Unique ID Service service is expected to provide a unique ids of values. The requirements can be summarised as
- Database independent
- Support for getNextValue, getCurrentValue
- Support for Specifying Increments
- Prefetch-buffer, to prevent Database hit
- Multi-Thread/Clustered deployment aware
Note: Unique ID Service service guarentees generation of unique, ID's, but not necessarily sequential
The ID's generated are meant to be used as key fields in database tables, unique counter values or others.
Using generated/surrogate keys for business data allows changes to the underlying data to not effect the nature
or identity of the data so that it can continue to be tracked.
This service does not produce sequential ids and should not be used for tracking the order of entity creation.
Approach 1 (Prefered and followed): Each id service to be deployed as a separate carbon component
Advantage: IDs are now referencible using a ref:// and can be easily changed/updated
Disadvantage: Too many components.
Approach 2 (Discarded) : ID's can be grouped, and one component can service multiple sequences
Advantage: Unique ID Service is a single block, and individual id's can be referenced by their id names
Disadvantage: Looks like a step away from the carbon ideology of "What is a component"