Wenn Sie bei Google angemeldet sind, ist die Google-Startseite mit mehreren anderen Diensten verknüpft (z. B. Gmail, Play, Google Drive).
Q1) Gibt es ein SOA-Muster, das beschreibt, wie sie die UIs für jeden Dienst locker koppeln, aber gleichzeitig auch eine Standardmenüleiste, Standard-Look-and-Feel und Single-Sign-On für ihre Anwendungen bereitstellen?
Q2) Gibt es Dokumentation, die ihre Architektur zum Verknüpfen des UI-Inhalts beschreibt?
Bearbeiten
Ich habe einen Blick auf Firebug geworfen und es scheint, als gäbe es eine Zwei-Wege-Beziehung zwischen der Menüleiste und der Anwendung. Die Menüleiste enthält eine Verknüpfung zu jeder Anwendung, aber jede Anwendung enthält auch die Menüleiste.
Ich kann dies mit der Eclipse Benutzeroberfläche in Verbindung bringen, in der eine Anwendung zum Anwendungsmenü beitragen kann, aber jedes Menü in dem Kontext lebt der Eclipse-Anwendung, die alle separaten UI-Plugins aggregiert.
Wie macht Google das in ihrer Benutzeroberfläche? Es sieht so aus, als gäbe es einige Javascript-Zauber, wobei die Menüleiste in jede Anwendung eingefügt wird.
Ich kann nicht von Google erzählen, aber ich habe auf Websites gearbeitet, die ähnliche Dinge tun. In einem Beispiel handelte es sich um eine Website für eine große Immobilienagentur mit Büros auf der ganzen Welt. Die Homepage (und andere Seiten) enthalten ein Karussell, das landesspezifische Inhalte anzeigt. Alle Büros verwenden unterschiedliche Instanzen desselben CMS um ihre eigenen Inhalte zu verwalten.
Was passiert, ist, dass der CMS (.NET-basiert) benutzerdefinierte und Benutzersteuerelemente (.ascx) verwendet hat, um die endgültige ASPX-Seite zu rendern. Diese ascx-Dateien (für Header, Footer und Karussell), alle Styles und Javascript in Bezug auf diese Dateien (in einem Ordner, der nicht manipuliert werden kann, genannt _CSS und _JS gemäß unserer Konvention) werden zentral verwaltet und dann auf alle lokalen Websites repliziert .
Die CMS-Instanz - die für ein einzelnes Landesbüro spezifisch ist - erstellt dann ihre eigenen Seiten, aber alle verwenden diese gemeinsamen Kopf- und Fußzeilen, die von der zentralen Anwendung bereitgestellt werden.
Der letzte Teil des Bildes besteht darin, all das synchron zu halten. Sie benötigen eine Art Agent oder Dienst, um diese gemeinsamen Komponenten auf alle Server und CMS-Instanzen zu übertragen, um sicherzustellen, dass alle die gleichen Steuerelemente verwenden , Stile und Javascript (Stile und JavaScript können zentral referenziert werden, aber benutzerdefinierte Benutzersteuerelemente müssen mindestens für .NET in der Anwendungsdomäne des jeweiligen CMS vorhanden sein). Wir haben Repliweb für solche Aufgaben benutzt, aber ich bin nicht sehr vertraut mit seinen Details.
Aus architektonischer Sicht sehe ich es als eine Art Plugin-Architektur für die Benutzeroberfläche, also haben Sie Recht, es mit der Eclipse-Architektur zu verbinden. Das zentrale CMS ist ein abstrakter Typ, der eine Schnittstelle bereitstellt, die bestimmte Site-Instanzen einhalten und implementieren müssen.
%Vor%Google verwendet eine eigene Verschlusssammlung für den UI-Teil:
Was ist die Closure-Bibliothek?
Die Closure Library ist eine breite, gut getestete, modulare und Browserübergreifende JavaScript-Bibliothek. Sie können genau das ziehen, was Sie brauchen eine große Anzahl wiederverwendbarer UI-Widgets und -Steuerelemente und von untergeordneten Ebenen Dienstprogramme für DOM-Manipulation, Serverkommunikation, Animation, Daten Strukturen, Komponententests, Rich-Text-Bearbeitung und mehr.
[...]
Wer verwendet die Closure-Bibliothek?
Suche, Google Mail, Google Maps, Google Docs, Google Sites, Bücher, Reader, Blogger, Kalender, Google+, Fotos
Das Projekt hawt.io hat einen interessanten Ansatz:
hawtio ist hochgradig modular, so dass es genau herausfinden kann, welche Dienste in einer JVM enthalten sind, und dynamisch die Konsole aktualisiert, um eine Schnittstelle zu ihnen bereitzustellen.
Der Link ist hier
Tags und Links javascript design-patterns architecture soa