Service Registry

Introduction

The BPUA ServiceRegistry is not merely a container of already-constructed service instances. Its main role is to maintain mappings between service keys and service implementation types so that the platform can instantiate the required component only when execution reaches that point.

This differs from a strongly object-centric composition style in which the application is mentally modeled as a large live graph of services. BPUA instead models the application as a set of named executable responsibilities. A transition requests a service by key, the registry resolves the implementation type, and the runtime activates that type when needed.

The difference is especially important in large platforms. A business application may contain hundreds or thousands of registered handlers, processors, and use case services, while only a relatively small subset is exercised in normal daily work. Much of the remaining functionality may exist for occasional CRUD operations, reference tables, administrative maintenance, or specialized flows. In such a system, activation on demand is more economical than building the architecture around broad resident object graphs.

What the Registry Stores

• Registered types - services that can be instantiated later.
• Registered objects - process-local objects that already exist, such as the use case activator.
• Assembly facets - markers that record which kinds of processing have already been applied to an assembly.
• Use case state transition names - discovered transition names grouped by state-handler key.

Why Both Types and Objects Matter

BPUA does not only resolve future service instances. It also needs to keep process-local runtime objects that represent already-initialized infrastructure. For that reason, the registry supports both type registration and object registration.

Type Registration Versus Object-Centric Dependency Injection

The registry is intentionally optimized for type-based registration and deferred activation. This makes it well suited to large modular systems in which many capabilities exist, but only a fraction of them are used during a typical session.

In a more object-centric composition style, the architecture is often understood primarily as a graph of runtime objects and their dependencies. Even when object creation is delayed, the design still tends to revolve around wiring those relationships. BPUA takes a different direction. It first records what executable capability is available under a given service key, and only later creates the corresponding object when execution actually needs it.

This distinction is especially valuable in enterprise systems with many rarely used features. A large percentage of registered functionality may exist only for occasional maintenance operations, service tables, setup screens, or specialized administrative flows. Keeping the registry centered on service identities and implementation types helps the runtime remain focused on the functionality that is truly active.

Registration Order and Deferred Construction

Another practical consequence of this model is reduced sensitivity to registration order. Because registry entries usually describe service keys and implementation types, registration does not itself require the entire dependency chain to be constructed. In many cases, entries can therefore be registered independently and in any sequence.

This does not mean that dependencies disappear. Supporting services must still be available by the time activation occurs. But it does mean that startup logic does not have to mirror the full dependency graph of the runtime. That makes the registry particularly suitable for plugin-based business systems, where assemblies may be discovered dynamically and activated only when needed.

Registry Operations

The current implementation supports several families of operations:

• registration and try-registration,
• contains checks,
• typed object retrieval,
• prefix-based enumeration,
• assembly facet marking,
• state-to-transition mapping.

Architectural Meaning

The registry is not just a convenient dictionary. It is the runtime memory of what the platform currently knows. Without it, on-demand activation, routing, and service lookup would all require tighter coupling between components.

Because the registry is shared across the boot process, activation process, and request execution flow, it becomes the natural place to keep the runtime view of available services.

Summary

The service registry is the central runtime catalog of BPUA. It allows the platform to remain plugin-friendly while keeping type and object lookup explicit, deferred where appropriate, and inspectable.

Table of Content BPUA Chapter Previous: BPUAPlatformBootstrapper Next: Transition Routing

 

---

Business Process Programming in .Net
© 2004-2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.