launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

So, this has come up a few times, how should we do object ids.

I've got a proposal, which I ran past wallyworld (as a time-zone
friendly person I knew has live-fire SOA experience).

Remember that SOA object ids are opaque: you cannot depend on their
structure in code. 'foo' is a valid object id, as is 'dr strangelove'.

However, humans do debugging and inspection of things, and for them we
can choose to be a little nicer.

The constraints are:
 - no two object ids can be the same unless the same object is being referenced.
 - object ids cannot change (unless some explicit process is
undertaken - e.g. messages to all services to update their references)
 - object ids must be bounded in length: no 4K strings.
 - *only* the service emitting the object needs to be able to
dereference it: there is no 'global' allocation or parsing authority

I propose the following scheme for our SOA ids:
$service$instance:$type:$typeid

Where service is one of ('lp', 'oops-tools', 'sso') today, with more
services allocated as we bring up additional microservices.
$instance is one of ('', '-qastaging', '-staging') and is used to deal
with collisions with objects created on staging services. It also
allows us to consume both a production and a staging service from a
staging service, if we want to. (And we will, for the librarian,
eventually).
$type is allocated within the service itself. Examples are 'person',
'archive' etc. Types that are exported, basically.
$typeid is any string value that the service wants to use to get back
to the original object. For instance, a UUID, or a row id, or a pg
object id would all be valid. For things where no-guessability
matters, using a UUID is appropriate, for other things using the DB
primary key is fine, as long as it meets the stability and uniqueness
constraints.

As an example - 'lp:person:2' - would be able to be passed around to
multiple services (team membership, audit trail, notification
service). Only LP itself could interpret the string however to mean
Person 2.

Unless folk can poke holes in this, I will update the SOA docs to
reflect this as the overall approach, and we can see how it goes.

-Rob