Question

When logged into to Google, the Google homepage links to multiple other services (e.g. Gmail, Play, Drive).

Q1) Is there a SOA pattern that describes the way that they loosely couple the UIs for each service, but at the same time also providing a standard menu bar, standard look and feel and single sign on across their applications?

Q2) Is there any documentation available that describes their architecture for linking the UI content?

Edit

I have taken a look with Firebug and it seems like there is a two way relationship between the menubar and the application. The menubar has a link to each application, but each application also has the menu bar included.

I can relate this to the eclipse UI, where an application can contribute to the application menu, but each menu lives in the context of the eclipse application which aggregates all the separate UI plugins.

So how does google do this in their UI? It looks like there is some javascript wizardry going on, with the menu bar being injected into each application.

Answer 1

I can’t tell about Google, but I have worked on websites that do similar things. In one example, it was a website for a large real-estate agency that has offices around the world, the homepage (and other pages) include a carousel that displays content specific to the country, all the offices used different instances of the same CMS to manage their own contents.

What happens is that the CMS (.NET based) used custom and user controls (.ascx) files to render the final aspx page. These ascx files (for header, footer and carousel), all styles and javascript related to those files (put in a folder that can’t be manipulated called _CSS and _JS as per our convention) are maintained centrally and then replicated to all local websites.

The CMS instance – specific to one country office – will then create its own pages but they all use these common headers and footers provided by the central application.

The last piece of the picture is to keep all of this in sync, you need some kind of an agent or service to propagate these common components to all servers and CMS instances in order to make sure that they all use the same controls, styles and javascript (styles and javascript could be referenced centrally but custom user control need to live within the application domain of the specific CMS at least for .NET). We used Repliweb for such tasks but I am not very familiar of its details.

From architectural point of view, I see it as some sort of a plugin architecture for the UI, so you are right to relate it to Eclipse architecture. The central CMS is an abstract type providing an Interface that specific site instances have to adhere to and implement it.

abstract class GoogleSite
{
    Control Header { get; set; }
    Control Footer { get; set; }

    public string Title { get { return "Default title"; } }

    public abstract void ProvideContents();
}

class Gmail: GoogleSite
{
    //still using same header and footer but Title is different
    override public string Title { get { return "Gmail"; } }

    public override void ProvideContents()
    {

    }
}


class GPlus: CentralCMS
{
    //Another CMS not overriding the title but Providing different contents
    public override void ProvideContents()
    {

    }
}