Whitepapers & Broschüren

   

Strategien für schnelle Applikationsentwicklung

Terry Ragon
Chief Executive Officer
InterSystems Corporation

InterSystems fördert die Wahl eines flexiblen und praktischen Ansatzes bei der Applikationsentwicklung, anstatt streng eine der vorherrschenden Entwicklungstheorien zu verfolgen. Dieses White Paper enthält verschiedene Empfehlungen, die auf unseren Erfahrungen basieren. Die Anforderungen, Einstellungen und Stile unterscheiden sich jedoch – wir vertreten die Ansicht, dass jeder Entwickler den Entwicklungsansatz verwenden soll, mit dem er die besten Ergebnisse erzielt. Caché unterstützt eine breite Palette an Entwicklungsmethoden. Die hier vorgestellten bilden nur einen kleinen Ausschnitt.

Verwenden Sie Objekt-Technologie für neue Applikationen

Aus den folgenden Gründen empfehlen wir die Verwendung von Objekt-Technologie bei der Entwicklung von neuen Datenbankapplikationen:

  • Objekte unterstützen komplexere Datenstrukturen, die zur Abbildung von Daten aus der realen Welt besser geeignet sind.
  • Die Programmierung fällt leichter, weil Entwickler ihre Arbeit und die bearbeiteten Daten einfacher verfolgen können.
  • Standardklassen lassen sich problemlos durch eigene Klassen ersetzen. Dies vereinfacht die Anpassung einer Anwendung und die Unterstützung bei neuen Releases. Dieses Feature ist vor allem für VARs von Bedeutung, die eine Vielzahl angepasster Versionen unterstützen müssen.
  • Der bei der Kapselung verwendete Black-Box-Ansatz ermöglicht es Programmierern, die internen Abläufe einzelner Objekte zu optimieren, ohne dass der Rest der Anwendung davon betroffen ist.
  • Objekte stellen eine einfache Methode dar, unterschiedliche Technologien und Applikationen zu integrieren.
  • Die Objekt-Technologie harmoniert bestens mit Java und GUI-basierten Benutzeroberflächen und vereinfacht die Entwicklung von Web-Anwendungen.
  • Zahlreiche neue Entwicklungswerkzeuge setzen objektorientierte Technologien voraus.
  • Objekte gewährleisten eine saubere Trennung von Benutzerschnittstelle und der restlichen Applikation. So lässt sich selbst bei der Einführung einer neuen Benutzerschnittstellen-Technologie (wie Web-Schnittstellen oder auch eine heute noch nicht vorhersehbare, zukünftige Technologie) der größte Teil des Codes wiederverwenden.

Objekte sind am nützlichsten für Datenbankobjekte und temporär existierende ("kurzlebige") Objekte. Bei wenig temporärem Speicher ist es einfacher, nur eine oder wenige Variablen oder Arrays zu verwenden. Verwenden Sie in der Praxis die Option, die Ihnen am praktischsten erscheint.

Obwohl in der Regel ein Großteil der Daten in Form von Objekten gespeichert wird, kann es in manchen Fällen sinnvoller sein, direkt „globale Referenzen“ zu verwenden, um Daten im multidimensionalen Daten-Server von Caché zu speichern oder abzurufen. Dies gilt besonders für unübliche oder sehr speziellen Strukturanforderungen, bei denen der objektorientierte oder SQL-basierte Zugriff nicht notwendig ist, oder wenn die höchstmögliche Performance gefordert wird.

Der Gesamtentwicklungsprozess – ein iterativer Ansatz

Die Entwicklung ist in der Regel ein iterativer Prozess mit folgenden Elementen:

  • Design von Datenbankklassen, einschließlich der Spezifikation von Eigenschaften und Methoden
  • Erstellung von Code
  • Erstellung der Benutzeroberfläche

Obwohl es in der Theorie erstrebenswert ist, dass alle Aspekte einer Anwendung vor der Codierung vollständig im Design berücksichtigt sind, kann dies in der Praxis die Designphase unsinnig verlängern oder zu einer Applikation führen, die die wirklichen Anforderungen der Benutzer nicht berücksichtigt – oder die Anwendung wird nie fertiggestellt. InterSystems empfiehlt hier einen iterativeren Prozess.

Wir sind überzeugt von der Relevanz eines gut durchdachten Designs und der Ansicht, dass sich bei komplexen Applikationen das eigentliche Design im Laufe der Anwendungsentwicklung herauskristallisiert. Darüber hinaus erfordert eine nützliche und sinnvolle Applikation Änderungen, die auf dem Feedback der Benutzer basieren. Eine der Stärken von Caché ist, dass Programmierer Code schnell entwickeln und einfach verändern können. Hierdurch können Änderungen am Design schnell implementiert und Code-Teile sofort umgeschrieben werden, während mit dem Programm erste Erfahrungen gesammelt werden. Die Entwicklung geht mit weniger Programmierern schneller voran – aufgrund der hohen Produktivität von Caché bei Entwicklungsaufgaben. Dies führt letztendlich zu einer Anwendung, die besser auf die Anforderungen der Benutzer abgestimmt ist.

Die Tatsache, dass Caché die Entwicklung von Anwendungen beschleunigt, bedeutet nicht nur, dass Projekte mit weniger Ressourcen schneller fertiggestellt werden können. Es vereinfacht auch die Entwicklung von Anwendungen, die sonst eventuell nie fertiggestellt würden. Es ist bekannt, dass bei einem Software-Projekt zusätzliche Programmierer die Komplexität erheblich vergrößern – mehrere Personen müssen miteinander kommunizieren, eine Einigung bei Themenstellungen erzielen und jeder versteht immer weniger vom Ganzen. Trotz des verstärkten Einsatzes von Ressourcen dauert es oftmals länger, bis die Software die Marktreife erreicht, und auch die Zuverlässigkeit leidet häufig bei zu vielen Entwicklern. Nicht selten kommt es dadurch sogar zum Abbruch eines Projektes.

InterSystems empfiehlt, mit dem grundlegenden Datenbank-Design zu beginnen. Ist das Design fertig gestellt, können Geschäfts- und Datenbanklogik in der Regel zeitgleich mit dem Code für die Benutzeroberfläche erstellt werden. In manchen Fällen empfiehlt es sich, den zentralen Code für die Geschäftslogik vor dem zugehörigen Code für die Benutzeroberfläche zu erstellen, um die erforderlichen Informationen zu bestimmen. Manche Entwickler beginnen lieber mit dem Code für die Benutzeroberfläche, um die Beschaffenheit und das "Look and Feel" der Applikation zu bestimmen. Dieser alternative Ansatz eignet sich besonders bei einfachen Applikationen, bei denen relativ wenige Datenbankeigenschaften vorhanden sind. Bei komplexeren Applikationen empfiehlt es sich, mit der Definition der Datenbank zu beginnen. In der Praxis sollte dies ein iterativer Prozess sein, in dem Klassen und Code fortlaufend verfeinert werden. Das Wichtigste ist, überhaupt anzufangen.

Sehr nützlich erweisen sich hier informelle Diagramme, die den Logikfluss der Algorithmen und andere komplexe Code-Bereiche aufzeigen. Sie können die Zuverlässigkeit und Vorhersagbarkeit der Applikation verbessern, sowie die Codierung und die Design-Spezifikation der privaten Eigenschaften und Methodensignaturen vereinfachen. Oftmals ist es nützlich, diese Algorithmen direkt nach der Aufzeichnung in den Diagrammen zu codieren, wenn sie die Entwickler noch klar vor Augen hat. Dies ist ein weiterer Grund, bei der Entwicklung interativ vorzugehen.

Sollte ein Modellierungswerkzeug verwendet werden?

Caché unterstützt verschiedene Modellierungswerkzeuge, wie Rose von Rational Software, die von vielen Organisationen mit einer extensiven Designphase bevorzugt eingesetzt werden. Diese Werkzeuge sind eine wertvolle Hilfe, um die Aufmerksamkeit auf das statische Design von Strukturen, wie die Datenbankeigenschaften, zu richten. Darüber hinaus macht das Arbeiten damit in der Regel Spaß.

Modellierungswerkzeuge sind jedoch für relationale Datenbanken besser geeignet, da hier die Komplexitäten der natürlichen umfangreichen Struktur von echten Daten in flache relationale Tabellen zerlegt werden – mit der daraus resultierenden Fülle von Beziehungen zwischen diesen Daten. Diese Zerlegung ist in Caché nicht erforderlich.

InterSystems empfiehlt deshalb nicht unbedingt die Verwendung von Modellierungswerkzeugen zusammen mit Caché. Wir empfehlen stattdessen:

  • Arbeiten Sie direkt mit dem Caché Object Architect, um zuerst die Datenstrukturen einiger Hauptklassen zu definieren (und eventuell die Signaturen der wichtigsten Methoden), insbesondere der Hauptklassen der Datenbank.

  • Beginnen Sie dann, den Code zu erstellen

  • Verfeinern Sie im Rahmen des iterativen Prozesses das Design weiter

Für diesen Ansatz sprechen folgenden Gründe:

  • Umfangreiche theoretische Debatten über die Beschaffenheit von Objekten und wie sie strukturiert werden sollten können vermieden werden. Manche Projekte scheitern, weil die Entwickler zu viel Zeit für die abstrakte Modellierung aufwenden.

  • In der Regel wird die Beschaffenheit und Funktionalität von Methoden-Code, wie auch welche Methoden und privaten Eigenschaften benötigt werden, beim Erstellen des Codes viel klarer. Der Programmierer kann viel früher im Entwicklungszyklus etwas demonstrieren.

  • Bei diesem Ansatz wird ein einziges Werkzeug für das Design und das Erstellen des Codes verwendet. Für die Entwickler ist dies eine Erleichterung, da sie bei der Weiterentwicklung des Designs nicht ständig die Arbeit mit einem speziellen Designwerkzeug koordinieren müssen.

Caché-Einsteigern empfehlen wir, mit dem Schreiben von Codes (Methoden) anzufangen, um möglichst schnell Erfahrung mit der Software zu sammeln.

Auch wenn dieser Einstieg nicht üblich ist, können unserer Ansicht nach auf diesem Wege schneller bessere Applikationen entwickelt werden. Dieser iterative Prozess ermöglicht die fortlaufende Verfeinerung des Designs anstatt in einer vordefinierten Struktur festgelegt zu bleiben, die irgendwann überholt ist und im Laufe der Weiterentwicklung zur Altlast wird. Dies vermeidet auch Lähmung und Über-Analysen, die mit fehlender praxisbezogener Erfahrung einhergehen kann.

Modellierung und Datendesign in Caché

Beim Design von Objekten besteht die Gefahr, sich in abstrakte Diskussionen über die Beschaffenheit von Objekten zu verwickeln sowie darüber, welche Methoden sie aufweisen sollten. Dies ist nicht nur zeitaufwändig, sondern die daraus resultierenden Methoden weisen oftmals nur eine geringe praktische Relevanz für die betreffende Anwendung auf. Nach den Erfahrungen von InterSystems werden im Laufe des Codierungsprozess die Anforderungen und die Beschaffenheit der meisten Methoden viel klarer.

Natürlich muss ein gewisses Grunddesign vorliegen, bevor mit der Codierung begonnen werden kann. Wir empfehlen hier, mit dem Caché Object Architect folgende Punkte festzulegen:

  • Wie lauten die Hauptdatenbankklassen? (z. B. Rechnungen, Lieferanten, Patienten)

  • Wie sehen ihre öffentlichen Eigenschaften aus? (also die Eigenschaften, die andere Objekte sehen können, im Gegensatz zu privaten Objekten, die vor anderen Objekten verborgen sind und auf die nur die Methoden derselben Klasse zugreifen können)

  • Welche Referenzen und Beziehungen existieren zwischen ihnen? (z. B. kann ein Patient die Eigenschaft Hausarzt haben, die eine Referenz zu seinem Hausarzt darstellt, sowie eine Eigenschaft Rechnung, die eine 1:N-Beziehung zu einer Gruppe von Rechnungspositions-Objekten darstellt)

Wenn eine Eigenschaft angegeben wird, ist es normalerweise auch sinnvoll, die Merkmale dieser Eigenschaften anzugeben. (Ist für diese Eigenschaft ein Wert erforderlich? Muss dies ein eindeutiger Wert sein? Sollte er indiziert sein?) Dies ist auch ein guter Zeitpunkt, um Code für berechnete Eigenschaften zu erstellen (z. B. wird der Wert der Eigenschaft Alter auf der Basis der Eigenschaft Geburtsdatum berechnet).

Wie verhält es sich beim Anfangsdesign mit der Angabe von Namen und Signaturen von Methoden? (Die Signatur umfasst den Typ des Rückgabewerts, falls vorhanden, sowie die Anzahl und den Typ der Eingabeparameter.) Entwickler möchten unter Umständen beim Anfangsdesign die Signaturen von wichtigen und dringend erforderlichen Methoden definieren, aber die meisten Methoden sollten während der Codierung definiert werden, wenn konkreter Bedarf besteht. Auch verändert sich im Laufe der Erstellung des Methodencodes häufig die Signatur. Oftmals ist es am einfachsten, eine Methode gleichzeitig zu codieren und die Signatur festzulegen.

Drei Arten von 3-Schichten

Wenn man über die 3-Schichten-Architektur spricht, gibt es oftmals Verwirrung, weil dies in der Regel drei ganz verschiedene Dinge bedeutet:

  • Deployment auf drei Hardware-Schichten – eigene Rechner für Datenbank-Server, Applikations-Server und Benutzeroberfläche.

  • 3-schichtige Architektur der System-Software – Datenbank-Server-, Applikations-Server- und Benutzeroberflächenschicht, die aber nicht unbedingt auf getrennten Rechnern vorliegen müssen

  • 3-schichtige Applikationsentwicklung – Datenbanklogik, Geschäftslogik und Logik der Benutzeroberfläche, wobei der Code in diesen drei Schichten streng getrennt ist. Auch hier können alle Schichten auf demselben oder auf verschiedenen Rechnern liegen.

Caché verfügt über eine 3-schichtige System-Architektur und unterstützt eine breite Palette an Deployment-Optionen.

Der Caché-Entwickler muss hierbei die Deployment-Architektur nicht kennen. Um alles von einem Rechner auf eine 2-schichtige oder 3-schichtige Hardware-Architektur zu verschieben, muss nichts rekompiliert oder die Software neu gelinkt werden.

3-schichtige Applikationsentwicklung

Konzeptionell betrachtet, enthalten die meisten Datenbanken Code, um drei verschiedene Arten von Funktionen auszuführen:

  • Benutzeroberflächenlogik – Dies ist der Code für Eingabe/Ausgabe-Operationen, wie Client/Server-Windows-Code, Browser-Code usw. Dieser Code gibt an, wie Informationen eingeholt und angezeigt werden, welche Geschäftslogik in Antwort auf verschiedene E/A-Ereignisse aufgerufen und wie dies grafisch dargestellt werden soll.

  • Geschäftslogik – Die Geschäftslogik macht in der Regel den Großteil des Applikationscodes aus. Sie enthält Code-Algorithmen, die die „Geschäftsregeln und –prozesse“ implementieren. Dies ist im Wesentlichen das, was die Applikation konkret macht. (Beispiel für eine Geschäftsregel: Alle Rechnungen über 100.000 Euro erfordern die Genehmigung von zwei Managern. Beispiel für einen Geschäftsprozess: Zur Zahlung einer Rechnung muss diese Rechnung mit der genehmigten Bestellung abgeglichen werden. Es muss weiterhin geprüft werden, dass die Waren und die erforderlichen Genehmigungen durch das Management vorhanden sind. Ferner muss ein Scheck gedruckt werden.)

  • Datenbanklogik – Das Speichern und Abrufen von Daten von Platte, das Ausführen von Datenbankabfragen, die Wahrung der referenziellen Integrität der Datenbank usw. So kann beispielweise die Ablage einer Rechnung in der Datenbank zu einer Aktualisierung verschiedener Datensätze (dies ist mit Objektzugriff viel einfacher) und verschiedener Statistiken führen.

In den letzten Jahren wurde die Entwicklung von Datenbankanwendungen unter strikter Einhaltung dieser drei Schichten in weiten Kreisen propagiert. In diesem Modell gibt es strenge Regeln, welche der drei Schichten Code in welchen anderen Schichten aufrufen kann. Dies führt häufig dazu, dass man in einer Schicht eine Menge von Klassen vorliegen hat, deren Namen, aber nicht deren Funktionalität, denen einer anderen Schicht entsprechen. So kann es beispielweise eine Geschäftslogikklasse Rechnung_bl mit einer Methode namens Speichern geben, die einfach eine Methode namens Speichern in einer Datenbanklogikklasse Rechnung_db aufruft, um die tatsächliche Speicherung auszuführen.

Das wesentliche Argument für die Entwicklung in drei Schichten ist, dass durch die Aufteilung in Schichten größere Teams von Programmierern eingesetzt werden können, um eine Datenbank-Unabhängigkeit einfacher zu realisieren.

Ist die 3-schichtige Applikationsentwicklung für Sie das Richtige?

Caché kann die Applikationsentwicklung in drei Schichten unterstützen. Wir empfehlen dies aber nicht. Wir empfehlen stattdessen:

  • Eine integrierte Schicht aus Geschäftslogik und Datenbanklogik

  • Einen strikte Trennung der Benutzeroberflächenschicht von der Geschäfts-/Datenbankschicht

  • Die Benutzeroberflächenschicht sollte möglichst dünn gehalten werden, und es sollte möglichst viel Code in der Geschäfts-/Datenbanklogikschicht platziert werden

Dies hat folgende Gründe.

Im Zentrum der Argumentation für eine 3-schichtige Applikationsentwicklung steht die Annahme, dass in der Schicht, die die Datenbanklogik enthält, viel Code vorliegt, der Spezialkenntnisse in der Datenbankprogrammierung erfordert. Dies ist bei Caché nicht der Fall, da ein Großteil der Datenbankfunktionalität über „intelligente Datenbankobjekte“ automatisiert wird, die die Speicherung und den Abruf von Informationen verwalten. Ein Query-Assistent führt durch die Erstellung der meisten Datenbankabfragen, die in Programmen eingebettet sind. Darüber hinaus ist es beim multidimensionalen Modell nicht erforderlich, ein komplexes Objekt in viele relationale Tabellen zu zerlegen, so dass der Caché-Code viel einfacher ist.

Aus diesem Grund gibt es in Caché relativ wenig Datenbanklogik, die vom Programmierer erstellt werden muss. Somit ist auch keine eigene Gruppe von spezialisierten Datenbankprogrammierern mehr erforderlich. Datenbankobjekte können das leistungsstarke Objektmodell exakter widerspiegeln. Statt der Erstellung von zwei Rechnungsklassen – eine für die Geschäftslogik und eine für die Datenbanklogik – gibt es nur eine Klasse, die die gesamte Rechnungslogik enthält. Dies ist ein erheblich einfacheres Modell, das zu einer schnelleren Programmerstellung, weniger Codierungsaufwand und später dann zu einfacher durchführbaren Modifikationen führt.

Eine strikte Trennung des Benutzeroberflächencodes, der möglichst wenig Code in der Benutzeroberfläche enthalten sollte, empfiehlt sich aus folgenden Gründen:

  • Die Programmierung von zukünftigen, weiteren Benutzeroberflächen wird vereinfacht.

  • Die Programmieraufgaben zwischen den Spezialisten für das grafische Design und den Programmierern der Kernapplikation sind klar getrennt.

  • Klassen in der Benutzeroberflächenschicht korrelieren nicht eng mit Geschäftslogikklassen.

Ein weiterer Grund für eine dünne Benutzeroberflächenschicht ist, dass die Installation und der spätere Austausch von Benutzeroberflächencode eine größere Belastung für die Systemverwaltung darstellt als Änderungen an der Geschäftslogik, die mit dem Caché-Applikations-Server verwaltet werden.

Datenbank-Unabhängigkeit mit Caché

In Caché stellen die Caché-Speicherklassen (Caché Storage Classes) die Datenbank-Unabhängigkeit sicher. Bei der Definition einer Datenbankklasse gibt ein Programmierer an, welche Speicherklasse verwendet werden sollte. Diese Speicherklasse gibt entweder die direkte Speicherung in der multidimensionalen Caché-Datenbank oder in einer relationalen Datenbank an. Um die Applikation für die Verwendung einer relationalen Datenbank umzustellen, muss nur die Verwendung einer anderen Speicherklasse definiert (hierzu wird ganz einfach ein logischer Name für die gesamte Applikation neu definiert) und die Applikation rekompiliert werden.

Erstellen der Geschäfts- und Datenbanklogik

Caché-Objektklassen können mit dem Caché Object Architect definiert, bearbeitet und kompiliert werden.

Caché verfügt über "intelligente Datenbankobjekte". Entwickler müssen daher keine Methoden erstellen, um Objekte zu laden, zu speichern oder zu löschen. Caché erzeugt diese Methoden bei der Kompilierung der Klasse automatisch. (In manchen Fällen möchten Entwickler angepasste Datenbankmethoden erstellen. Dies können sie natürlich tun.)

Caché ObjectScript ist hervorragend für die Codierung von Geschäfts- und Datenbanklogik für eine Datenbankanwendung geeignet. InterSystems empfiehlt die Verwendung von Caché ObjectScript, das sie darüber hinaus eine weitaus schnellere Anwendungsentwicklung ermöglicht als mit anderen Sprachen. Die enge Integration in den multidimensionalen Daten-Server von Caché führt bei den meisten Datenbankapplikationen zu einer extrem hohen Performance und vereinfacht die Systemverwaltung, Konfigurationsänderungen sowie die Einführung von Code-Änderungen im laufenden System.

Dies ist aber nicht die einzige Option. Die Caché Objekt-Server können Caché-Objekte als ActiveX-, Java-, C++-, .net- oder EJB-Objekte für Entwickler darstellen, die lieber in Visual Basic, Java oder C++ programmieren.

Caché stellt unter Verwendung von ODBC und JDBC die Datenbank in Form von SQL-Code dar und ermöglicht die Verwendung von SQL-basierten Programmierwerkzeugen.

Erstellung der Benutzeroberfläche

Die Benutzeroberfläche wird meistens in Visual Basic, Delphi, C++, Java oder HTML geschrieben. Nach Angabe vieler Programmierer können damit Web-basierte HTML-Benutzeroberflächen am schnellsten entwickelt werden. Die Entwicklung von C++-basierten Oberflächen beansprucht oftmals erheblich mehr Zeit als die anderen.

Über die Objekt-Server ist Caché zu vielen Entwicklungswerkzeugen kompatibel. Darüber hinaus können HTML-Skripts direkt in Caché ObjectScript eingebettet werden.

Für die Entwickler von Web-Oberflächen sind besonders die Caché Server Pages interessant, mit denen Caché-Skripts mit Standardwerkzeugen für die Erstellung von Webseiten verwendet werden können.

Müssen sich Entwickler für eine Technologie für die Erstellung einer Benutzeroberfläche entscheiden, so ist für sie hier von herausragender Bedeutung, ob sie mit der Technologie vertraut sind oder ob diese schnell zu erlernen ist und ob sie einfach gehalten werden kann. Schnell sind Technologieoptionen in der Benutzeroberfläche mit verschiedenen Schichten komplexer Technologie überfrachtet.

Web-Oberfläche oder Client/Server-Windows?

Für viele ist eine der schwierigsten Entscheidungen, ob die Benutzeroberfläche für das Web oder für Client/Server-Windows codiert werden soll.

Die Erfahrung unserer Kunden zeigt, dass bei einem vorhandenen terminalbasiertem System, auf dem Caché bereits läuft, die schnellste und einfachste Lösung bei der Einführung einer modernen Benutzeroberfläche darin besteht, mit Caché Server Pages und eingebettetem HTML-Code eine Web-Oberfläche zu erstellen. Dies führt oftmals dazu, dass ein Großteil des vorhandenen Codes beibehalten werden kann. In gewisser Hinsicht ist dies, wie wenn man ein unintelligentes Terminals durch ein sehr intelligentes und grafisch ausgefeiltes Terminal ersetzt. Dieser Ansatz führt im Allgemeinen zu einer prozessorientierten Anwendung, die Browser-basiert ist. Diese ist jedoch häufig grafisch nicht so ausgefeilt und bietet nicht so umfangreiche Benutzersteuerung wie eine vollständig ereignisgesteuerte Client/Server-Windows-basierte Anwendung.

Beim Erstellen einer vollständig neuen Applikation ist die strikte Trennung von Benutzeroberflächenschicht und der Geschäfts-/Datenbankschicht sowie eine möglichst dünne Benutzeroberflächenschicht der Schlüssel zum Erfolg. In vielen Fällen ist letztendlich wahrscheinlich beides erforderlich – die Unterstützung von Client/Server-Windows wie auch die Web-Unterstützung. Im Allgemeinen ist eine Web-basierte Benutzeroberflächenschicht schneller zu entwickeln und hat den Vorteil, Browser-basiert zu sein, so dass ein größeres Publikum darauf zugreifen kann. Dies entspricht auch der weit verbreiteten Betonung des Webs, wobei Client/Server-Windows aber grafisch ausgefeilter sein können.

Bereitstellung und Wartung von Applikationen

Hardware-Plattformen und Betriebssysteme

Caché-Applikationen laufen in der Regel unverändert auf einer Vielzahl von Plattformen und Betriebssystemen wie Windows, allen wichtigen UNIX-Plattformen, OpenVMS und Linux.

Hardware Konfigurationen

Ein Caché-Applikation kann ohne Neuprogrammierung oder Rekompilierung auf einer der folgenden Hardware-Konfigurationen bereitgestellt werden: 1-schichtig, 2-schichtig, 3-schichtig oder Peer-to-Peer. In sehr großen Systemen können mehrere Caché-Applikations-Server sowie auch mehrere multidimensionale Caché-Daten-Server vorhanden sein.

Ein Client meldet sich normalerweise nur bei einem Caché-Applikations-Server an. Es liegt in der Verantwortung des Applikations-Servers, die Daten vom richtigen Daten-Server zu erhalten.

Im Allgemeinen ist der Aufwand viel geringer, wenn ein Applikations-Server auf Daten zugreift, die auf dem gleichen Rechner wie der Applikations-Server vorliegen. InterSystems empfiehlt daher, diese gemeinsam auf einem Rechner zu implementieren, falls nicht ein konkreter Grund für die Verteilung von Daten-Server und Applikations-Server auf getrennten Rechnern vorliegt.

Installation einer Anwendung und Änderungen am laufenden System

Wird eine Applikation erstellt, muss sie installiert und später in der Regel geändert werden. Bei Tausenden von PCs und mehreren Servern kann dies bei den meisten Technologien ein echtes Problem darstellen.

Caché vereinfacht die Installation der Applikations-Software. Caché ObjectScript-Code muss nur auf einem einzigen Daten-Server installiert werden. Andere Rechner erhalten über die Caché-Netzwerk-Technologie ECP Kopien davon und legen diese im Cache ab.

Um in ein laufendes System Änderungen in Form von Caché ObjectScript einzubauen, muss nur die geänderte Quellroutine auf den Daten-Server geladen werden, auf dem sich der Code befindet. Der Quellcode wird automatisch kompiliert und die Applikations-Server werden benachrichtigt, um die überarbeitete Routine neu zu laden. Natürlich sollten solche Änderungen mit Vorsicht implementiert werden: Ein Prozess, der aus der alten Version eine andere Routine aufruft, führt zu einem Fehler, wenn er zu der geänderten Routine wieder zurückkehren möchte.