Some existing packages, for exmaple search, use the service contract implementation name to determine which contract to call. The search package uses the object_type of the item to index or the name of the full text engine driver to call the service contract.
Some other packages, notifications, acs-authentication, store the impl_id from the acs_sc_impls table in an internal package table to find which service contract to call.
In notifications each notification type is related to the service contract implementation_id.
Table "public.notification_types"
Column | Type | Modifiers
-------------+-------------------------+-----------
type_id | integer | not null
sc_impl_id | integer | not null
short_name | character varying(100) | not null
pretty_name | character varying(200) | not null
description | character varying(2000) |
The auth_authorities table has quite a few service contract impl_ids:
Table "public.auth_authorities"
Column | Type | Modifiers
--------------------------+-------------------------+------------------------
authority_id | integer | not null
short_name | character varying(255) |
pretty_name | character varying(4000) |
help_contact_text | character varying(4000) |
help_contact_text_format | character varying(200) |
enabled_p | boolean | not null default true
sort_order | integer | not null
auth_impl_id | integer |
pwd_impl_id | integer |
forgotten_pwd_url | character varying(4000) |
change_pwd_url | character varying(4000) |
register_impl_id | integer |
register_url | character varying(4000) |
user_info_impl_id | integer |
get_doc_impl_id | integer |
process_doc_impl_id | integer |
batch_sync_enabled_p | boolean | not null default false
I am curious if there is an advantage to either approach. Personally I feel that using the implementation name preserves the interface abstraction more cleanly than storing a primary key from the acs-service-contract tables.
