Lokale Grenze bedeutet andere Betriebsverantwortung
Die Headless-Modul-API darf kein separater REST-, TCP- oder WebSocket-Steuerdienst sein, auch nicht lokal. Der integrierende Host kann eine solche Netzwerkschnittstelle selbst betreiben und daraus die vorgesehenen lokalen Modulfunktionen aufrufen. Prozessintegration, Ownership, Threading, Zustandsübergaben und Updates bleiben explizite Integrationsaufgaben; der Anbieter TI-M Pro verantwortet den Betrieb und die GTI-Abstimmung (A_28679, A_28849, A_28850).
Für MEMM ist diese Trennung wichtig, weil die öffentliche Headless-Architektur nicht mit dem generischen Plattform- oder Administrationsbereich vermischt werden soll.
Was bleibt trotzdem projektspezifisch?
- Zielplattform und Packaging der jeweiligen Integration.
- Host-Lifecycle, Update- und Rollback-Verantwortung.
- Betriebsgrenzen zwischen Primärsystem, Headless-Komponente und externen Diensten.
- Unterstützte Profile, externe Versionen und Abnahmekriterien.
Versionierte Primärquellen
Was hier ausdrücklich nicht behauptet wird: Die Seite behauptet nicht, dass jede MEMM-Funktion ausschließlich lokal oder ohne Netzwerkkommunikation arbeitet. Beschrieben wird die lokale Host-Grenze des Headless-Integrationspfads; externe Kommunikationsdienste liegen außerhalb dieser lokalen Steuergrenze.