Classifications: Alle Arten von WIM-Objekten (Dokumente, Themen, Projekte, usw.) sind "Rubriken zugeordnet. Über Rubriken können Klassen von Objekten definiert werden. Beispielsweise, eine Klasse von Dokumenten die noch bearbeitet werden und daher nicht allgemein sichtbar sein sollen. Auch Klassifikationen, die Dokumente für bestimmte Zielgruppen bestimmen sind in Gebrauch.

Client: Im System gibt es oft Auftraggeber /Veranlasser für eine Aktion. Dabei können Aktionen sowohl vom Browser als manchmal von einem Server oder dem Worker veranlasst werden. Normalerweise wird nur der darstellende Prozess im Browser als "Client" bezeichnet. Es können aber auch andere "Auftraggeber" ebenfalls in die "Client"-Rolle schlüpfen.

(Client-)Service: In einem System, dass Aufträge bearbeitet, wird zu jedem Auftraggeber (= "Client") ein (Client-)Service" (kann beispielsweise eine "Sitzung" sein) als Kommunikationspartner und Auftrags-Bearbeiter eingerichtet. Für einzelne in einem (Client-)Service" zu bearbeitende Aufgaben werden dort "Prozesse" eingerichtet.

Connection: Eine Connection steuert auf der Seite eines Clients die Kommunikation via Netzwerk mit einem Service mittels Packages von Messages. Dabei ist der Client der aktive Partner und der Service reagiert auf Anfragen mit in Packages zurückgesendeten Messages. Sowohl Client als auch Service können mehrere Connections (zu verschiedenen Partnern) nebeneinander betreiben - mit Ausnahme des Browsers-Client und des (Service-)Workers, die (normalerweise) aus technischen Gründen "fest" an einen einzelnen Server gebunden sind.

Flags: ...

Login: Eine Anzahl von Aktionen dürfen nicht von jedem Nutzer eines WIM-Systems durhgeführt werden. So darf beispielsweise ein Dokument nur von seinem Besitzer (notfalls auch von der Administration) geändert werden. Dazu ist eine Anmeldung des Nutzers ("Login") notwendig. Je nach Berechtigungen des Nutzers werden dann weitere Aktionsmöglichkeiten verfügbar und Darstellungselemente sichtbar.

Master-Service: Während "lesende" Operationen auf Objektdaten des "nächstgelegenen" Services (Service-Worker oder Cloud-Server) zugreifen, werden "schreibende" Operationen (also Änderungen der Objekt-Inhalte) bis zu einem Zentralen Server (= "Primär-Master") durchgereicht und von dort aus dann wieder an alle anderen Services verteilt. Daher ist zu jedem Service mit Ausnahme des "Primär-Master-Service"  ein "Master-Service" definiert, an den Schreiboperationen weitergereicht werden, sobald diese technisch möglich ist. Auch Änderungssperren für Objektdaten während Editier-Operationen müssen über den Master-Service beim Primär-Service ausgelöst werden.

Message: Die Informationen zwischen den kommunizierenden Prozessen auf den verschiedenen Komponenten (Browser-Client, Service-Worker, Cloud- und User-Server) werden mittels "Messages" ausgetauscht. Es gibt verschiedene Typen von Messages für die diversen Aufgaben, die Klassen (REQUEST, RESPONSE, EXCEPTION, WARNING, ERROR, DEBUG, usw.) zugeteilt sind.

Obj(ekte): Alle inhaltlichen Daten des WIM-Systems sind in Objekten gespeichert. Jedes Objekt hat innerhalb seiner Projektgruppe eine eindeutige Kennung (ObjId). Objekte werden von Clients über ihre volle Objekt-Spezifikation ("ObjSpec") angesprochen, die aus der Kombination von Projektnamen und Objektkennung besteht. Beispielsweise zrm:monitoring . Auf Basis dr Projektgruppe werden Objekte über die Projektguppen-Spezifikation (gObjSpec) identifiziert. Beispielsweise verkehr|monitoring .

ObjId: ...

ObjSpec: ..

Package: Über eine "Connection" werden Null bis mehrere Messages in Packages gebündelt zwischen den Kommunikationspartnern übertragen. Mit den Packages werden zusätzlich zu den Messages Informationen über die Partnersyysteme übertragen.

Primär-Master-Service: ...

Process: Innerhalb eines (Client-)Service sind meist verschiedene Aufgaben zeitlich überlappend zu erledigen. Solche Aufgaben können oft nicht durchgehend in einem Lauf erledigt werden, sondern dauern wegen technisch bedingter Wartezeiten (Wartezeiten auf Platten-Operationen, Server-Antworten, Nutzereingaben etc.) eine kleine bis große Weile. Die "Process"-Konstruktion hilft dabei den roten Faden der Abarbeitung zu wahren.

Project: ...

ProjectGroup: ...

REF: Ein (Client-)Prozess kann mehrere Aktionen nebeneinander laufen lassen müssen. Um die Reaktionen eines beauftragten (Client-)Service den einzelnen Aktionen treffsicher zuordnen zu können gibt ein Client seinen Messages eine (eindeutige) Kennung im REF-Parameter der Message mit. Alle Antworten des ClientProcess müssen die REF angeben - es sei denn es ist eine Message direkt an die Prozess-Steuerung des Client (beispielsweise Meldungen, Signale, uws.).

Service: In Erweiterung des klassischen Client-Server-Modells können im WIM-System auch "Server"-Leistungen von beispielsweise dem Worker (im Browser) übernommen werden. Daher werden alle Komponenten, die Aufträge bearbeiten können unter dem Begriff "Services" subsummiert. Ein Service-System ist immer multi-client-fähig (siehe (Client-)"Service"). Auf Seiten der Clients werden die Services mittels Connections verwaltet.

ServiceId: Wenn ein Client Aufträge an einen (Client-)Service schickt, muss (im Package) eine vom (Client-)Service generierte ServiceId zur Identifikation verwendet werden. (Anmerkung: Die SrviceId entspricht in etwa einer SessionId)

ProcessId: Wenn ein Dienst eines Services in Anspruch genommen wird, der eine Weile genutzt wird, dient die vom bearbeitenden Prozess benannte "processId" dazu, dass der "Client" dem zuständigen Prozess gezielt Meldungen  zuschicken kann. (Anmerkung: Die ProcessId wird in den Messages verwendet).

User: ...

(Service-)Worker: Ein "Hintergrundprozess" im Browser, der in der Lage ist, dem Client-Prozess des Browsers den Zugriff auf einen (Cloud-)Server ganz (offline-Modus) oder teilweise (local-Modus) zu ersetzen. Ein Service-Worker ermöglicht es auch, das WIM-ystem als "App" zum Browser zu installieren.

...