Client-Server-Computing
Geschwurbel von Daniel Schwamm (25.10.1994 bis 26.10.1994)
Gesammeltes zum Thema
Informationsmanagement (IM) im Wandel von zentral nach dezentral. Heterogene
Rechnerwelten werden integriert (Rightsizing), wozu eine geeignete
SW-Architektur nötig ist: Client/Server-Techniken (C/S) können die Leistung von
mehreren Rechnern in das Rechnernetz (RN) erbringen, wodurch alte Investitionen
weiter nutzbar und vorhandene Ressourcen optimal verteilbar sind.
C/S: Logisches Konzept für SW-Architekturen zur
verteilten IV in RN. Jede vollständige SW besteht bei C/S aus mindestens
einem Client und einem Server (Gegensatz zu monolithischen Programm). Die
Auftragsbeziehung geht immer vom Client aus, aber Server kann gegenüber anderen
Programmen ebenfalls zum Client werden. Wichtig für die Interoperabilität:
Gemeinsames Protokoll.
-
C/S!=offene Systeme, denn C/S unabhängig von der Netzarchitektur.
-
C/S!=verteilte Systeme, denn VS sind eine Obermenge von C/S.
-
C/S!=HW-Konfiguration, denn C/S ist eine SW-Architektur.
-
C/S!=denzentrale IV, sondern kooperative IV.
Vertikale Verteilung von C/S der ersten Generation (Sinn: Jeder Rechner erledigt
nur sein Spezialgebiet):
- Verteilte Präsentation: X-Server übernimmt Bilddarstellung.
- Verteilte Verarbeitung: "Number Cruncher" erledigt Rechenaufgaben, RPCs.
- Verteiltes Datenhandling: DB-Maschine erledigt DV.
Über SQL-Server kann auf Ingres-, Sybase-, Oracle- und DB2-Datenbanken in gleicher
Weise zugegriffen werden (Zugriffstransparenz). SQL-Statements über das Netz versenden
ist aber nicht sehr effektiv. Besser: Client stösst Server nur zur Arbeit an => der
produziert die nötigen SQL-Statements selbst, findet lokal die Daten und sendet die
Antwort an den Client zurück. Auf diese Weise lässt sich Online Transaction Processing
realisieren, welches nicht auf das eigene LANs beschränkt bleiben müsste.
C/S kommunizieren über IPC oder Netzprotokolle, die
aber intransparent sind. Der RPC-Mechanismus erlaubt die transparente Nutzung
entfernter Funktionsserver. Mittels Transaktionsmonitoren wie Tuxedo oder
Transaktionsdienste wie OSI-TP können Mainframe-Monitore ersetzt werden.
Alternativ zu RPCs werden auch objektorientierte, verteilte Systeme
realisiert.
Mögliche Interaktionsmuster: Pipelines,
Peer-to-Peer-Interaktion, C/S-Interaktion, Heartbeat-Interaktion,
Probe/Echo-Interaktion, Token-Passing-Interaktion.
Kommunikationsmodellarten: Mitteilungsorientiert (simplex), auftragsorientiert
(duplex, blockierend) oder transaktionsorientiert (duplex, blockierend, zuverlässig).
Verteilte Systeme können mittels Distributed Computing
Environment der Open System Foundation realisiert werden, das aber nicht
objektorientiert ist. Die OSF ist eine non-profit Hersteller-Vereinigung (HP,
IBM, DEC). DCE ist unter AIX, UNIX und OSF/1 verfügbar, soll für MVS (Multiple
Virtual Storage), OS/400 und MSDOS realisiert werden. DCE bietet:
- RPC: Hier immer blockierend (OSI bietet auch nicht-blockierende RPC an).
- Threads: Parallelisierung innerhalb eines Prozesses.
- Cell/Global Directory-/Time-/Security-Services
- Distributed File System: Transparente Verteilung von Dateien.
- Diskless Support: Integration von Diskless Workstations in die DCE.
DCE: Server-Schnittstellen werden mit der IDL (Interface
Definition Language) beschrieben, die sehr C-ähnlich ist (abgesehen von
den Zusätzen "in" und "out" für Input-Parameter oder
Output-Parameter). Der IDL-Compiler erzeugt daraus eine C-Header-Datei, die der
Client einbinden muss, um die Server-Fkt. aufrufen zu können.
Ansonsten wird der Client genauso programmiert, als würde er keine RPCs benutzen.
Der IDL-Compiler erzeugt ausserdem einen Client- und einen Server-Stub,
die über die Netzwerk-Komponente den RPC ausführen. Meist wird noch
ein Binder zwischengeschaltet. Initialisiert sich ein Server-Prozess, dann
sendet er den Export seines Funktionsangebot an den Binder (zusammen mit einer
Versionsnummer und seiner Adresse). Ein Client, der zum ersten Mal einen RPC absetzt,
kontaktiert ebenfalls den Binder, um seine Funktionswünsche zu
importieren. Der Binder erkennt, ob ein passender Server ex. und sendet dessen
Adresse zurück.
Typische Probleme, die im Zusammenhang mit RPCs auftreten,
sind: C und S verstehen sich nicht; C und S benutzen verschiedene
Adressräume, sind daher auf Kommunikation angewiesen; C und S
können abstürzen; C und S können nicht beliebige Argumente
austauschen; globale Variablen wie "errno" nicht einsetzbar; variable
Parameterzahlen wie bei "printf" unmöglich zu realisieren. Einige
Hauptprobleme und ihre Lösungen seien im Folgenden genannt:
Client findet Server nicht:
Grund : Server nicht aktiv, Client-Stub veraltet, Binder defekt
Loesung: Fehlerrueckmeldung und -Handling (ist aber intransparent).
Server empfaengt nichts:
Grund : Nachricht ging unterwegs verloren.
Loesung: Timeout-Technik (Zeit allerdings schwer berechenbar).
Server sendet nichts zurueck:
Grund : Sever vor/waehrend/nach Reply abgestuerzt.
Loesung: Timeout+Sequenznummern gegen nicht-idempotente Wiederholungen.
Die Wiederholungsstrategie hängt ab von der Semantik:
-> Hoechstens/Mindestens/Genau einmal-Empfangs-Garantie.
V.a. bei zustandsbehafteten Servern problematisch!
Client empfaengt nichts:
Grund : Client abgestuerzt, neu hochgefahren, neue Portnummern.
Loesung: Orphan-Behandlung
- Ausrottung: Jeder RPC wird in Protokollliste eingetragen.
- Reinkarnation: Neue Epoche starten, alle RPCs abbrechen.
- sanfte R.: Neue Epoche, nur Orphan-RPCs abbrechen.
Wichtig: Gekillt RPCs verhindern u.a. Entblockierungen von Dateien!
Call-by-Copy/Restore: Ähnlich wie bei einem
Call-by-Value wird hier ein komplette Struktur (und nicht nur ein Pointer) an
eine Funktion übergeben, die die Struktur kann aber verändern werden
(Gegensatz zum Call-by-Value). Um C-typische Call-by-References über RPCs zu
ermöglichen, kopieren die Stubs die gesamte Pointer-Struktur und
übergeben sie als Call-by-Copy/Restore (funktioniert aber nicht bei
komplexeren Strukturen).
Während die Clients über RPC völlige Transparenz bezüglich der Funktionsverteilung
realisieren, sind die Stubs selbst
eher intransparent: Sie benutzen explizit die Befehle "send()" mit
anschliessendem "receive()", um zu blockieren, bis der Server die Antwort
sendet. Da die Stubs jedoch automatisiert erstellt werden, bleibt die
Transparenz für den User und Programmierer erhalten.
NFS ermöglicht ein verteiltes System unter UNIX, auch
wenn das Mounten von Verzeichnissen in das eigene Verzeichnis nicht
transparent ist; auch müssen Pfadnamen weiterhin angegeben werden. NFS
erleichtert dadurch aber den Einsatz von RPCs. Transaktionen sind aber nicht
möglich, da NFS zustandslose Server verwendet!
Über X11 kann eine verteilte Präsentation
realisiert werden. Der X-Server, der i.d.R. auf dem Arbeitsrechner läuft,
verwaltet Tastatur, Maus und Monitor. Zur Kommunikation wird das X-Protokoll
verwendet, welches auf TCP/IP bzw. UDP/IP aufsitzt. Im Gegensatz zu den meisten
RPC-Protokollen ist X nicht-blockierend.
NetWare von Novell: Das klassische Client/Server-System
für PC-LANs (Local Area Network). Dieses System ist offen, d.h. es unterstützt
Ethernet, Token-Ring, FDDI, MSDOS, OS/2, UNIX, Macintosh-OS und OS/400, bietet
aber auch das eigene Netzwerk-Protokoll IPX/SPX an. Inzwischen ist NetWare über
einen X.25-Anschluss auch WAN-tauglich (Wide Area Network), wobei es auf X.500
als Directory-Dienst zugreift.
Vor- und Nachteile von C/S:
-
Vorteile von C/S: Durch abgekoppelte und dann zentralisierte
DV kann u.U. Integrität erhöht werden; Ressourcen können
gemeinsam genutzt werden; Verfügbarkeit+; Integrationspotenzial+;
Modularisierung erlaubt bessere Wartung; spezialisierte=dedizierte Rechner
einsetzbar; Ausbaufähigkeit+; Parallelisierung von Anwendungen möglich;
RPC-Möglichkeit und andere innovative Techniken; Imagepunkte; Weiterverwendung
von Mainframes möglich; Client kann zwischen mehreren Servern wählen, d.h.,
Kompromisse bezüglich der Qualität sind möglich; flexibler; feinstufig anpassbarer.
-
Nachteile von C/S: Kommunikationsaufwand;
Zeitintensität; Standards werden nicht befolgt (oder sind nur faule
Kompromisse wie Token-Ring UND Ethernet UND ...); Gateways zur Integration
schlucken Performance; CASE-Tools zur Client/Server-Applikationen-Entwicklung noch Mangelware; Server
muss stabile Interfaces anbieten; Transparenz-Forderung nur schwer
einhaltbar; Datensicherheit und Integrität schwierig; verlangt schnelle
Netze und leistungsstarke Rechner; Kosten-Erfassungsmängel;
Schulung/Betreuung+; Mainframe-Betreuer geben nur ungern Macht ab; nur 5% der
Kosten durch HW+SW (nur 5% des Personals vertraut mit C/S); Gefahr zu
Unterschätzung der Anstrengungen wie bei CIM-Salabim!
Vor- und Nachteile von Workstations:
-
Vorteile Workstations gegenüber Mainframes: Billiger
(45.000 DM für Server, 1.000 DM für Clients); Leistung wächst
schneller; Parallel Computing leichter realisierbar; kürzere Lebenszyklen
und dadurch innovativer; benutzerfreundlicher durch bessere Präsentation
(Multimedia, Hypermedia); papierloses Büro; bessere Antwortzeiten;
Ergonomie; v.a. Qualitätsverbesserung (weniger Kosten-Verbesserung); da
weniger Sicherung (wie z.B. über RACF) müssen Daten weniger redundant
gehalten werden.
-
Nachteile von Workstations gegenüber Mainframes:
Betreuungsaufwand+; Präsentation artet zur Spielerei aus; Nachteile von
C/S-Computing; nicht alle Mainframe-Applikationen umsetzbar; Akzeptanz nicht von alleine
gegeben; Schulungsaufwand; bieten keine leichte unternehmensweite
Informationslandschaft; Speichermangel; Durchsatz viel kleiner als bei Mainframes, da
Workstations die meiste Zeit auf User-Inputs warten.
SW-Zyklen in den Organisationen. meistens zu lange, daher haben sich
C/S-Systeme noch nicht überall durchgesetzt. Da aber inzwischen viele
Workstations in Organisationen vorhanden sind, dient C/S als Integrationsmodell zum
Rightsizing.
Tendenz: 4 von 5 Firmen steigen auf C/S um, wobei Mainframes
nicht ersetzt, sondern in Server umfunktioniert werden. 1/3 aller Unternehmen
sind laut Online aktiv dabei, auf C/S-Applikationen umzusatteln. Bis zum Jahr 2000
sollen C/S-Applikationen den Markt sogar zu 90% dominieren! Multiple Virtual Storage
(MVS) z.B. ist bereits C/S-freundlicher geworden und auch die ehemals proprietäre
AS/400 wurde bereits zum offenen System. Zu beachten sind auch die zahllosen
Kooperationen zwischen Firmen, um einheitliche, offene Produkte auf den Markt
zu bringen. Migrationen werden zunehmen, wobei C/S die Basis bildet aufgrund
seines Rightsizing-Potenzials.
C/S-Missbrauch: Häufig wird mit C/S nur plakativ
geworben, obwohl die Applikationen weit entfernt ist von einem kooperativen C/S-Computing
und Verteilung. Graphical User Interface (GUI): Die Oberfläche der alten Mainframe-Programme
werden als verteilte Präsentation realisiert. Besser ist es aber, gänzlich neue
Oberflächen zu erstellen, da moderne Workstations hier wesentlich weitreichendere
Möglichkeiten haben als die alten Mainframes.
Sicherheitskonzept für interagierende Clients und
Servers besonders aufwendig. Sie werden z.B. nötig, wenn ein Client
über einen Server Geld überweisen lassen will. Der Client muss
authentifiziert und autorisiert sein, damit er die Operation durchführen
kann, und während der Ausführung müssen alle Störungen
abgefangen werden. Mögliche Verfahren:
-
Authentifikation: Client weist sich gegenüber Server aus.
Damit er das nicht jedes Mal machen muss, kann der Server von einem
Authentifikationsserver den öffentlichen Schlüssel anfordern, um den
Client zu prüfen.
-
Autorisierung: Client erhält über Zugriffsmatrizen
(an Ressourcen gebunden) oder Capabilities (an Client gebunden) über
Ressourcen-Server Zugriffsrechte auf Ressourcen.
-
Integrität: Daten müssen in nachvollziehbarer
Weise modifiziert werden. Checkpoints, Roll-Back-Verfahren, 2-PC-Protokoll usw.
sorgen für Konsistenz der Daten.
-
Policy-Mechanismen: Gegen mutwillige Störungsversuche.
Wer die DCE nutzt, erhält automatisch ein
Sicherheitskonzept mit. Autorisierung, Authentifizierung und
Verschlüsselung werden durch dedizierte Server erledigt.
Benutzung von Threads (häufig mit leichtgewichtigen Prozessen
gleichgesetzt): Ein Client kann über das Thread-Konzept, wie es z.B. DCE
anbietet, nicht-blockierende RPCs realisieren, die eigentlich von DCE nicht
vorgesehen sind. Threads eines Prozesses können auf den gleichen
Speicherbereich zugreifen, verfügen aber über eigene Stacks. Auf
Server-Seite lassen sich über Threads parallele Server entwickeln, die
keine Sohn-Kopie von sich erzeugen müssen.
RPCs werden auch von der OSI angeboten: In der
Anwendungsschicht ex. verschiedene Application Service Entities, wie z.B. ROSE,
RPC, über die blockierende und nicht-blockierende RPCs möglich sind. Die
Darstellungsschicht (entspricht den DCE-Stubs!) mit ihrer ASN.1-Definition und
den Presentationskontexten ermöglichen es, auch in heterogener Rechnerumwelt RPCs
einsetzen zu können. Die Parameter werden über ASN.1 in eine globale
Transfersyntax übersetzt. Allerdings: Die IDL wird wohl auf mehr Akzeptanz
stossen als ASN.1.
Verteilte, objektorientierte Systeme bieten: Datenkapselung, Polymorphismus, Vererbung,
Klassenbildung, feinere Granularität (Objekte& lt;< Client-Prozesse), Persistenz,
by-reference-Übergaben erlaubt (angeblich - nur wie, das wurde nicht erklärt),
Migrierbarkeit von Objekten zur Laufzeit und damit optimaler Lastenausgleich.
Mögliche Strategien der Server-Objekte ohne Common Object Request Broker Architecture
(CORBA)): Lastanziehung oder Lastabstossung (Börsenalgorithmus). Problem: Bei der
Migration müssen alle kooperierenden Objekte über das neues Ziel informiert werden,
weshalb hier meist zentrale Instanz (CORBA) eingesetzt wird, über die dies
verwaltet wird.
Common Object Request Broker Architecture (CORBA):
Von der non-profit-Organisation OMG (Object Management Group) entwickelt. Konzept
ähnlich wie bei Distributed Computing Environment (DCE wurde z.T. integriert), aber
CORBA-Interface Definition Language (IDL) erlaubt auch
objektorientierte Elemente zu nutzen, v.a. Vererbung. Im Gegensatz zu DCE
können die Schnittstellen auch dynamische Typen verarbeiten! Eine
Migration der Objekte zur Laufzeit wurde bisher nicht berücksichtigt.
Objekte, die eine Fkt. ausgeführt haben wollen, senden ihren Aufruf an
CORBA, und der sorgt für einen passenden Empfänger. Vorteil: CORBA kann
bei redundanten Objekten entscheiden, welches weniger ausgelastet ist.
Rightsizing: DV-Applikationen auf die Rechner verlagern, die
dafür am besten geeignet sind. Wichtige Frage: Wie weit lasen sich
operative Anwendungen dezentralisieren? Support und Fehlerbehandlung bei C/S
noch mangelhaft im Vergleich zu Mainframes. Meistens bleibt daher Doppelbetrieb
bestehen, der aber nicht eben billiger ist. Viele Rightsizing-Applikationen
unterstützen Workflow-Management.
Mainframe-Abbau:
-
ERSATZ durch Midrange-Systeme wie z.B. (mehrere) AS/400
=> die Investition des Terminal-Netzwerks bleibt erhalten.
-
PC-Netzwerk: Rechernetz statt Terminalnetz => i.d.R. leichter erweiterbar.
-
HOST und PC-Netzwerk: C/S-Verbund. PCs dann nicht nur
für die Informationsdatenverarbeitung (IDV) da, sondern auch im operativen Geschäft einsetzbar.
Mainframe-Zukunft:
-
IBMs /390 Vector Facility wollen 62% laut Online-Umfrage auf keinen Fall kaufen!
-
Dedizierter Einsatz: Mainframes als Batch-Server.
-
IBM macht sich mit den POWER-CPU-basierten Parallelsystemen SP1
und SP2 selbst Konkurrenz, da diese den RISC/UNIX-Markt stärken.
-
BS2000 wurde mit Open Server Dimension-Variante offen: Seitdem wird kräftig angebaut.
Die meistbenutzten Produkte: WINDOWS > TCP/IP > UNIX >
MSDOS > SQL > Novell NetWare > MVS. COBOL ist die verbreitetste
Sprache. 60% der Entwicklungsressourcen gehen dadurch für die Wartung von
Unwartbaren darauf.
SAP bietet ihre Integrationssoftware als Host- und Client/Server-Variante
an: R/2 und R/3. Derzeit feiern beide Produkte in den USA Erfolge. R/3 wird um
EDI erweitert für den elektronischen Datenaustausch zwischen externen Partnern.
Das System läuft auf UNIX und WINDOWS-NT. Langfristig ist die Integration von
OLE-Programmen wie Lotus Notes und MS Office in R/3 geplant (Integration statt
Interfacing!). Unter dem Codenamen "Heidelberg" ist eine Plug & Play-Version für
den PC in Arbeit. Das enorme Wachstum ihrer Produkte verschafft SAP inzwischen
Service-Probleme, dem u.a. durch Videoconferencing entgegengewirkt wird.
Massiv-parallele Variante von R/2 sind für IBMs S/390 in Arbeit, d.h., die
User werden hier nicht zum R/3-System genötigt. Ab 1995 soll jedoch ein
Migrationstools für den Umstieg von R/2 nach R/3 existieren.
Groupware: 3 Firmen dominieren hier: Lotus mit seinem Notes,
welches im Prinzip nur ein E-Mail-basiertes shared Repository darstellt. MS,
dass Groupware-Fkt. ins BS integriert. Novell, der sein Netz-Know-how
für Groupware nutzen will. Übrigens: Workflow und Groupware haben
verschiedene Zielsetzungen: Workflow will Kontrolle, Groupware will kreatives
Miteinander!
Workflow-Management: Aktionsorientierte,
prozessorientierte Vorgangsbearbeitung. Setzt getriggerte DBMS ein, die
Akteure zur Reaktion nötigt (Gegensatz zu Groupware, wo Individuen das System
zur Reaktion nötigen). Ist strategisch integriert ins Business Processing
Reengineering. Doppelarbeiten fallen dabei zwar häufig an, dafür ist
Qualität und Durchlaufzeit durch fehlende Schnittstellen wesentlich
erhöht. Ist konform mit dem selbstoptimierenden Prozess nach ISO9000.
Zu beachten: Wie gut unterstützt C/S die IT in der
Wertschöpfungskette? Umlage-Verfahren bzgl. der GK sind nicht mehr
up-to-date, C/S verlangt aufgrund seiner versteckten Kosten
Prozess-Controlling über Workflow-Management.
C/S-Anwendungen der 2.Generation: Horizontale Teilung der
vertikal geteilten Logiken Präsentation, Verarbeitung und DBMS. Das
führt zum Lean Application-Ansatz im Zusammenhang mit der objektorientierten
CORBA: Nur noch spezielle Applikationen-Objekt-Funktionen sind zu entwickeln,
während alle allgemeinen Applikationen-Funktionen ins Netz gespeist werden, wo
sie die CORBA aufnimmt und weiterleitet. Die Middleware, die die verteilte Präsentation
und DBMS-Logik enthält, bietet den Objekten APIs an. Der CORBA-Broker, der
auch verteilt realisiert sein kann, sorgt dabei für die nötige Interoperabilität.
Alternativ kann auch mit Remote Procedure Calls (RPC) von der DCE gearbeitet
werden, aber diese RPCs sind nicht asynchron, nicht objektorientiert, nicht
dynamisch, nicht reusable, Objekte nicht in Bibliotheken verwaltbar, kein
Polymorphismus, Granularität ist grob. Beispiel für Middleware: X-WINDOWS,
OSF/RPCs
Wrapper: Programme, die bestehende Applikationen einkapseln und als Objekt
einsetzbar machen, indem sie ein API nach aussen hin anbieten. Dadurch
können Altanwendungen leicht zu den horizontal verteilten Applikationen-Objekten
integriert werden.
UNIX als Ersatz-Betriebssystem für MVS kommt v.a.
deshalb infrage, weil es:
- offen ist, d.h. nicht-proprietär, frei kopierbar.
- multiuser- und multitaskingfähig ist.
- als relativ sicher gelten kann (im Gegensatz zu MSDOS).
- es in C geschrieben und damit extrem portabel ist.
- die RISC-Architektur über C begünstigt.
Fehlertolerante Systeme: Die Verteilung gestattet auch
redundante Datenhaltung, die die Sicherheit der Daten erhöhen kann. Ziel
bei fehlertoleranten Systemen ist, dass das Gesamtsystem sicherer als
seine Komponenten ist. Dadurch, dass sie billiger als Spezialanfertigung
sind, und Fehler z.T. hohe Kosten verursachen, können fehlertolerante Systeme
u.U. billiger als Normal-Systeme werden. Weiteres Ziel: Fail-Save-Eigenschaft
(das System gelangt nicht in einen gefährlichen Zustand). Erreicht werden diese
Ziele durch HW-Redundanz (gespiegelte Platte, RAID, Voter-gesteuerter
Ersatzprozessor), SW-Redundanz (N-Versions-Ergebnisvergleich mit Voting
Majority). Beispiel für ein fehlertolerantes System: IBMs S/88!
IBM erkennt inzwischen den Markt für verteilte Systeme.
Ihr Netzwerk SNA wurde durch die Ergänzung APPN (Advanced
peer-to-peer-Networking) und der darin enthaltenen Norm LU 6.2 zum Open System
(alternativ kann auch OSI-TP eingesetzt werden!). Der Anwender muss nur
über die Schnittstelle CPI-Communication verfügen, dann kann er mit
IBM-Mainframes kommunizieren. CPI-C ist in OS/400 und OS/2 bereits von Hause
aus integriert! Auch wird intensiv an einem CISC-API gearbeitet, sodass
der Standard-Transaktionsmonitor von IBM vom PC aus genutzt werden kann.
Innerhalb von APPN können OSI-APs wie FTAM eingesetzt werden, die
Entitäten konfigurieren sich selbst (Plug & Play), das APPN-Netz ist
adaptiv und selbstlernend (die Knoten tauschen Routing-Informationen untereinander
aus). Aber v.a.: APPN ist dezentral organisiert, kommt ohne Zentralinstanzen
aus => Basis für VS!
Informationssysteme nach dem Dreischichtenmodell der IS-Planung:
- Strategische Unternehmensplanung
- Hersteller-unabhängige IS-Planung: Meistens zu klein.
- Hersteller-bezogene IS-Planung: Meistens viel zu gross.
MAP ist eine offene SW, die über das OSI-Modell eine
Fertigungsautomation in heterogener Rechnerumwelt gestattet => CIM-Module
können ohne Probleme miteinander kommunizieren. Über Standards wie
EDI (nicht international, branchenspezifisch/branchenübergreifend) und EDIFACT
(international, branchenspezifisch) lässt sich JIT realisieren. VDA
ex. bei Autoindustrie, SWIFT (transaktionsorientiert) im Bankbereich.