Service registry and dynamic collaboration

The service registry is OSGi's in-process collaboration layer.

Registration

A registration contains service interface names, an object, properties, a provider bundle, and lifecycle. Properties support discovery and ranking.

(&(objectClass=com.acme.PaymentGateway)(region=eu)(secure=true))

Filters use LDAP syntax. Treat property names and value types as API.

Selection

When several services match, service ranking and service ID define ordering. Prefer explicit target filters representing business meaning. Ranking is useful for defaults and replacement, but invisible ranking wars are fragile.

Scope

Services can be singleton, bundle-scoped, or prototype-scoped. Scope answers whether consumers share the same service object. It does not replace thread- safety design.

Dynamics

A provider can stop after a consumer starts. Holding a service object beyond its valid reference lifecycle creates stale collaboration. DS reference policies handle this:

• static: component restarts when a bound service changes;
• dynamic: bind/unbind occurs while the component remains active;
• reluctant: keep a suitable current binding;
• greedy: move to a better candidate.

Choose policy from business continuity and component invariants, not from a desire to avoid restarts.

Registry anti-patterns

• service locator calls spread through business code;
• caching ServiceReference or raw service objects indefinitely;
• publishing implementation classes instead of contracts;
• storing large mutable application state as service properties;
• assuming exactly one provider without declaring cardinality.

Feynman check

The registry is a live phone book. DS is the receptionist that updates your call when entries change. Explain why manually polling the phone book spreads infrastructure concerns.