77: Make NenjimHub the runtime owner and replace NenjimApplication with NenjimProcess
This commit is contained in:
+19
-13
@@ -119,24 +119,30 @@ PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'</code></pre>
|
||||
|
||||
<h2>Components and the central Registry</h2>
|
||||
<p>A Nenjim component is a fully constructed building block ready for use. Its consumer decides whether it acts
|
||||
as a service, application, algorithm, or adapter. <code>NenjimComponent</code> is therefore a pure marker,
|
||||
while <code>NenjimApplication</code> adds only a common <code>start()</code> operation and no common stop.</p>
|
||||
as a service, application, algorithm, or adapter. A service exposes a domain API, while application describes
|
||||
a user-facing or orchestration role. <code>NenjimComponent</code> is therefore a pure marker. Independently,
|
||||
the canonical <code>com.r35157.nenjim.process.NenjimProcess</code> marks an active component that the Hub can
|
||||
start and track; it adds only <code>start()</code> and no common stop, restart, or health operation.</p>
|
||||
<p>A <code>NenjimComponentId</code> is lower-case lookup metadata owned by one Registry, not a property of the
|
||||
object, an authorization boundary, or an artifact version. One object may have several IDs. Conversely, one
|
||||
registration is indexed under every component interface implemented by that object, so its typed service and
|
||||
application views retain reference identity.</p>
|
||||
registration is indexed under every component interface implemented by that object, so the Registry object's
|
||||
typed service and process views retain reference identity.</p>
|
||||
<p><code>NenjimRegistryService</code> is the injected read-only consumer view. It returns immutable,
|
||||
registration-ordered ID snapshots for a component interface and supports lookup by explicit ID plus expected
|
||||
interface. Missing IDs return <code>null</code>; requesting an existing ID through the wrong interface is a
|
||||
caller error. Registration is available only through a package-private administration view retained by the
|
||||
Registry manager.</p>
|
||||
<p><code>NenjimRegistryServiceManagerImpl</code> starts and registers the Registry first, registers itself second,
|
||||
and then constructs and registers the hardcoded component graph in dependency order. Applications own their
|
||||
selection and activation: the Ticker explicitly selects the Raydium EVE/USDT source ID while the hardcoded
|
||||
source remains registered but inactive. The manager activates only the existing explicit five-application
|
||||
sequence; it does not start every <code>NenjimApplication</code>.
|
||||
<code>com.r35157.nenjim.hubd.Main</code> is only the outer Java bootstrap; <code>Main.main(...)</code> starts
|
||||
this manager and is not itself a component or application.</p>
|
||||
caller error. Registration is available only through a package-private administration view behind the passive
|
||||
Registry manager. That manager exposes only registration, is neither a component nor a process, is not
|
||||
registered, and cannot start anything. The internal administration interface must remain package-private so
|
||||
an ordinary service consumer cannot cast the Registry object to a mutation view.</p>
|
||||
<p><code>NenjimHubImpl</code> is the global composition and runtime owner. It constructs the Registry assembly,
|
||||
starts and registers the Registry first, records its successful process ID, and then constructs and registers
|
||||
the hardcoded component graph in dependency order. The Ticker explicitly selects the Raydium EVE/USDT source
|
||||
ID while the hardcoded source remains registered but inactive. The Hub activates only the existing explicit
|
||||
five-process sequence after the Registry; it does not start every registered process. Successful process IDs
|
||||
are exposed as immutable ordered point-in-time snapshots, without implying continued health.</p>
|
||||
<p><code>com.r35157.nenjim.hubd.Main</code> remains only the outer Java bootstrap. It constructs the reference Hub
|
||||
through the public <code>NenjimHub</code> interface and calls <code>start()</code> once. The Hub is neither a
|
||||
component nor a process and is not registered inside its own Registry.</p>
|
||||
<p>The Registry remains internally open to later registration, but this version has one catalogue and no Context,
|
||||
version resolution, classloader integration, discovery, public runtime loading or registration, removal,
|
||||
persistence, events, ownership tracking, usage counts, permissions, scopes, filtered views, or automatic
|
||||
|
||||
+28
-13
@@ -183,32 +183,47 @@ hints kan på sigt foretrække en lavere kompatibel release.
|
||||
## 8. Componenter og det centrale Registry
|
||||
|
||||
En Nenjim component er en færdigkonstrueret byggeklods, som er klar til brug. Rollen som service, applikation,
|
||||
algoritme eller adapter bestemmes af den applikation, som bruger componenten; Registry-API'et bruger derfor det
|
||||
fælles ord `component` og ikke `plugin`. `NenjimComponent` er en ren marker interface. En startbar component kan
|
||||
desuden implementere `NenjimApplication`, som kun lover `start()` og ikke en fælles stop-operation.
|
||||
algoritme eller adapter og klassifikationen som aktiv proces er uafhængige dimensioner. En service eksponerer et
|
||||
domain API, mens en applikation beskriver en user-facing eller orchestration-rolle. Registry-API'et bruger det
|
||||
fælles ord `component` og ikke `plugin`, og `NenjimComponent` er en ren marker interface. En component, som Hub'en
|
||||
kan starte og tracke, implementerer desuden den canonical `com.r35157.nenjim.process.NenjimProcess`, som kun lover
|
||||
`start()` og ikke en fælles stop-, restart- eller health-operation. En service- eller applikationsimplementation kan
|
||||
derfor også være en process; passive componenter er det ikke.
|
||||
|
||||
En `NenjimComponentId` er registration metadata i ét Registry og er ikke en egenskab ved objektet. ID-formatet er
|
||||
lower-case ASCII med dot-separated segments og valgfrie interne bindestreger, f.eks. `nenjim.registry.service` og
|
||||
`assetaz.price-source.raydium-pool.eve-usdt`. Det samme objekt må registreres under flere forskellige ID'er, og én
|
||||
registration bliver automatisk synlig gennem alle component interfaces, som objektet implementerer. Registry- og
|
||||
application-view af Registry-objektet har derfor samme ID og samme object identity.
|
||||
registration bliver automatisk synlig gennem alle component interfaces, som objektet implementerer. Registry-
|
||||
service- og process-view af Registry-objektet har derfor samme ID og samme object identity.
|
||||
|
||||
`NenjimRegistryService` er det read-only katalog, som almindelige consumers modtager gennem constructor injection.
|
||||
Det kan returnere et immutable registration-order snapshot af ID'er for et component interface eller slå ét ID op
|
||||
gennem et forventet interface. Et manglende ID giver `null`; et eksisterende ID med forkert interface er en caller
|
||||
programming error. Public API'et kan ikke registrere eller fjerne componenter.
|
||||
|
||||
`NenjimRegistryServiceManagerImpl` konstruerer og starter Registry'et, registrerer Registry og manager først og
|
||||
konstruerer derefter den nuværende hardcodede component graph i dependency order. Den package-private admin-view er
|
||||
kun managerens registrationshandle og er hverken en component eller public API. Registration starter ikke et
|
||||
objekt, og Registry'et forbliver internt åbent for senere registration efter startup.
|
||||
`NenjimHubImpl` repræsenterer én kørende Nenjim runtime. Hub'en konstruerer Registry-subsystemet og hele den
|
||||
nuværende hardcodede component graph, ejer dependency wiring og vælger de processer, som skal startes. Et
|
||||
implementation-only Registry assembly udleverer read-only service-view, process-view af det samme Registry-objekt
|
||||
og en separat `NenjimRegistryServiceManager`. Manageren er kun Hub'ens passive registrationshandle: den er hverken
|
||||
component eller process, har ingen `start()` eller service-accessor, registreres ikke og starter aldrig en component.
|
||||
|
||||
Den package-private `NenjimRegistryServiceAdmin` er managerens interne mutationsadgang. Den må ikke gøres public,
|
||||
fordi almindelige consumers ellers kunne caste deres Registry-service til mutationsinterfacet og bryde det
|
||||
read-only service contract. Registration starter ikke et objekt, og Registry'et forbliver internt åbent for senere
|
||||
registration efter startup.
|
||||
|
||||
Applikationen ejer sine konkrete valg og sin activation. Tickerens initiale configuration vælger eksplicit
|
||||
`assetaz.price-source.raydium-pool.eve-usdt` gennem Registry'et; den hardcodede price source er registreret, men
|
||||
inaktiv. Manageren starter kun den nuværende eksplicitte, dependency-safe liste: Ticker, Production Evelyn, Test
|
||||
Evelyn, Production IOU Burner og Mission Control. Alarmen og øvrige tidligere udkommenterede applikationer bliver
|
||||
ikke automatisk aktiveret. `com.r35157.nenjim.hubd.Main` er kun det yderste Java-bootstrap; `Main.main(...)` starter
|
||||
manageren gennem `NenjimApplication` og er ikke selv en component eller applikation.
|
||||
inaktiv. Hub'en starter Registry-processen først og registrerer den som `nenjim.registry.service`. Derefter starter
|
||||
Hub'en kun den nuværende eksplicitte, dependency-safe liste: Ticker, Production Evelyn, Test Evelyn, Production IOU
|
||||
Burner og Mission Control. Alarmen og øvrige tidligere udkommenterede applikationer bliver ikke automatisk
|
||||
aktiveret. Efter hvert succesfuldt `start()` registrerer Hub'en process-ID'et i et immutable, ordered snapshot; et
|
||||
fejlet start bliver ikke registreret, og listen lover ikke fortsat health eller liveness. Startup er fail-fast og kan
|
||||
kun forsøges én gang uden generic rollback.
|
||||
|
||||
`com.r35157.nenjim.hubd.Main` er kun det yderste Java-bootstrap. `Main.main(...)` konstruerer `NenjimHubImpl` gennem
|
||||
det globale `NenjimHub`-interface og kalder `start()` præcis én gang. Hub'en ejer også det eksisterende online point
|
||||
og den afsluttende blocking wait. Hub'en er hverken component eller process og registreres ikke i sit eget Registry.
|
||||
|
||||
Det implementerede Registry er ét katalog og er ikke et authorization-system. Contexts, artifact-version semantics,
|
||||
resolution, classloading, automatic discovery, public runtime loading/registration, removal, persistence, events,
|
||||
|
||||
+8
-6
@@ -7,14 +7,16 @@
|
||||
|
||||
| Term | Beskrivelse |
|
||||
|------|-------------|
|
||||
| Service | Det offentlige domæne-API, som applikationer og andre services bruger i daglig drift. Det eksponerer almindelige domæneoperationer, men ikke lifecycle, configuration, data-source administration, refresh, parser eller mutation af intern viden. |
|
||||
| ServiceManager | Det offentlige lifecycle- og administrations-API, som en composition/lifecycle owner bruger. De konkrete operationer følger serviceområdet: JournalServiceManager har start, stop, data location, refresh og adgang til JournalService, mens første Registry service manager bevidst kun eksponerer start. Det er ikke det daglige domain/query-API for almindelige consumers. |
|
||||
| Nenjim component | En færdigkonstrueret Nenjim-byggeklods, som er klar til brug. Dens konkrete rolle som service, applikation, algoritme eller adapter bestemmes af consumeren; `NenjimComponent` er en ren marker uden ID eller lifecycle state. |
|
||||
| NenjimApplication | Et component interface med én fælles `start()`-operation. Første version lover ikke et fælles `stop()`. En konkret serviceimplementation kan implementere dette interface uden at lifecycle føjes til dens domain service interface. |
|
||||
| Service | Det offentlige domæne-API, som applikationer og andre services bruger i daglig drift. Det eksponerer almindelige domæneoperationer, men ikke lifecycle, configuration, data-source administration, refresh, parser eller mutation af intern viden. En konkret serviceimplementation kan samtidig være en `NenjimProcess`, uden at lifecycle føjes til service-interfacet. |
|
||||
| ServiceManager | Det offentlige lifecycle- eller administrations-API, som en composition/lifecycle owner bruger. De konkrete operationer følger serviceområdet: JournalServiceManager har start, stop, data location, refresh og adgang til JournalService, mens Registry service manageren kun er et passivt registrationshandle. Det er ikke det daglige domain/query-API for almindelige consumers. |
|
||||
| Nenjim component | En færdigkonstrueret Nenjim-byggeklods, som er klar til brug. `NenjimComponent` er en ren marker uden ID eller lifecycle state. Service, applikation, algoritme og adapter beskriver roller, mens process beskriver en uafhængig lifecycle-klassifikation. |
|
||||
| Applikation | En user-facing eller orchestration-rolle. Rollen gør ikke i sig selv en component til en process; en aktiv applikationsimplementation kan separat implementere `NenjimProcess`. |
|
||||
| NenjimProcess | Det canonical `com.r35157.nenjim.process.NenjimProcess` component interface for noget, som Hub'en kan starte og tracke. Det eksponerer kun `start()` og lover ikke stop, restart, health, Context eller dependency lookup. |
|
||||
| NenjimHub | Den globale ejer af én kørende Nenjim runtime. Hub'en konstruerer og registrerer component graph'en, ejer dependency wiring og startup-policy, tracker succesfuldt startede process-ID'er, erklærer online point og ejer den afsluttende runtime wait. Den er hverken component eller process og registreres ikke i sit eget Registry. |
|
||||
| NenjimComponentId | Canonical lower-case Registry lookup identity med dot-separated segments og valgfrie interne bindestreger. ID'et er registration metadata i ét Registry, ikke object state, authorization eller artifact-version identity. |
|
||||
| NenjimRegistryService | Read-only component-katalog for almindelige consumers. Det giver immutable registration-order ID snapshots og typed lookup, men ingen registration, removal, loading, lifecycle, permission eller persistence administration. |
|
||||
| NenjimRegistryServiceAdmin | Package-private registrationshandle i referenceimplementationen. Det er ikke en component, er ikke indexeret og udleveres ikke til almindelige consumers. |
|
||||
| NenjimRegistryServiceManager | Public lifecycle/composition API med kun `start()` i første version. Referenceimplementationen konstruerer Registry og den hardcodede component graph, registrerer ID'er og aktiverer kun den eksplicit valgte application subset. |
|
||||
| NenjimRegistryServiceAdmin | Package-private mutationsinterface i referenceimplementationen. Det er ikke en component, er ikke indexeret og må ikke gøres public, fordi almindelige consumers ellers kunne caste Registry-serviceobjektet til mutationsinterfacet. |
|
||||
| NenjimRegistryServiceManager | Public, passivt administrationshandle med kun `registerComponent(...)`. Det holdes privat af Hub'en, delegerer til det interne admin-view, er hverken component eller process, registreres ikke og ejer ingen lifecycle eller composition. |
|
||||
| Component registration | Bindingen mellem ét `NenjimComponentId` og ét object. Én registration indexeres under alle objektets component interfaces; flere forskellige ID'er må pege på præcis samme object instance. |
|
||||
| Journal | Et immutable, komplet snapshot af al aktuel viden om præcis én artifakt og dens kendte releases. Journalen er aldrig en delta. |
|
||||
| ArtifactCoordinate | Journal-kædens stabile identitet, udledt som `<GROUP>-<MODULE>-<ARTIFACT>`, f.eks. `com_r35157_nenjim-hubd-api`. Der findes intet separat `JournalId`. |
|
||||
|
||||
Reference in New Issue
Block a user