Yuyue Zhu, Victoria Juan
System Description
Google Chrome is an open-sourced web browser developed by Google in December, 2008 ( Computer Hope). The co-founders Sergey Brin and Larry Page insisted in the idea of developing their own browser and hired some of the software developers from Mozilla Firefox to build a demonstration of Chrome (Wikipedia). At first, it could only run on Microsoft Windows, now it has been expanded its availability to run on MacOS, Linux and Android and iOS operating systems. Chrome has been used as a web browser and developer tools. It is also a way to access other Google properties, such as YouTube, Gmail, and google drive. There are six features that have significant impact on the architecture of Chrome: speed, simplicity, security, privacy, customization, and signing in (Chrome). When it comes to Chrome’s software architecture from a security perspective, Google Chrome use a sandboxing-based approach, which is a multi-process architecture. Each tab runs as its own process, which avoids vindictive code on one page from influencing others (Chromium Blog).
Architecture Description
Figure 1. Multi-process Architecture of Chrome
In a high architectural level, Google Chrome develops on a layered architecture, which the architecture is categorized as applications with distinct classes of serves that can be organized in a hierarchy (Hassan, 2009). The base of the hierarchy won’t talk with the other layers in its own order. Moreover, the Google Chrome’s subsystems have a good cohesion structure, because each layer does not rely on others in
a direct way. Therefore, these layers communicate through intermediate threads such as Inter-Process Communicators between the browser and the renderers. Because of the strong cohesion, it also helps to build the reusability of the layers.
To divide the entire architecture into different layers or components with their own functionalities, it includes User Interface, Browser, Data Persistence, Networking/Network Stack, JavaScript Interpreter, Rendering Engine/WebKit, Display Backend, XML Parser and Plugins as the diagram we produced below. We will be introducing them separately.
Figure 2. Software Architecture of Chrome
The User Interface is a layer that enables the user to access all the functionalities of the browser, which the UI should be ideally user-friendly and easy to understand. There are two parts which are the client area and non-client area in UI. The interaction made by client on the client area will be read as a message and pass on to the browser engine for event handling. However, Chrome introduced their unique feature that the client and non-client area are coterminous compares to other browser’s UI.
To manage the layers, the Browser act like the center among them. In Chrome architecture, the rendering engine have to talk to the browser to achieve the action beyond rendering-specific services(3). Moreover, the Browser build the security policy for that rendering engine instance, which characterizes the benefits to that rendering engine.
Data Persistence characterizes any information that will outlast the execution of Chrome and incorporates the accompanying parts includes cookie database, history database and password database, which it all accomplished through browser with mainly file system communication (3).
The network stack is outside of the browser and has few dependencies on the rest of Chrome. The main task of network stack is to handles Universal Resource Locator (URL) requests by the browser, fetch the resources form the network, and also requests caches of results for further use (3).
V8 is what JavaScript Interpreter in Chrome and its different than other JavaScript Interpreter. There are three main features has being developed, hidden classes, generates machine code instead of using an interpreter and precise garbage collection respectively.
The rendering engine/WebKit is an open source task to design pages that has been taken from Apple. It includes three parts, WebCore, JavaScriptCore and WebKit. But Chrome is only using the WebCore in their system, it render web components for Chrome which are CSS, DOM, HTML and XHTML.
Display Backend has three main functionalities, widget creation, graphics rendering and font rendering respectively (3). There are four parts for displaying backend which are views, Windows Template Library, Skia, and GDI. When WebKit parses the HTML, it talks to the Display Backend in order to render the web page. Skia works to create the images and graphics from the site and GDI get text from WebKit to produce it in such setted style, font and size. The Windows Template Library is there to create basic widgets of the UI elements such as buttons which it’s a Windows basic style UI and views framework build complex widgets which requests assistance from Skia to create the vector graphics and GDI that places the text onto element.
Nowadays for Chrome, XML has been handed to a more third party sources instead of internal handling. The libXML has been introduced to be easily ported, light weighted and relatively small package used. Chrome also uses package libXSLT which based on libXML to handle XSLT which libXML doesn’t support.
Plugins give a particular capacity to the browser that isn't as of now contained in that and it can help improve the overall experience and functionalities within Chrome. It is located outside of browser and rendering engine which can help improve stability of the browser. More reasons, there should only be one instance of a plugin for the entire browser expected by developers and the plugins has to talk to operating system directly which sanderboxing of the rendering engine blocks it.
Architecture Analysis
Layered Architecture style and object-oriented style are the most dominant architectural style chrome employs. Layered architecture style is mostly used to separate functions into layers that are stacked together. In this case, it includes the UIs, the browser, and the webkit, etc. All serve as different layers of the app. Object-oriented design pattern is used on the subsystems. The coupling between the browser and V8 JavaScript Engine demonstrates this kind of behavior.
For Layered architectural style, multiple benefits emerge along with this style.
Abstraction: Layers allow changes to be made at the abstract level. Since there are multiple separate layers of functions, you can increase or decrease the level of abstraction you use in each layer of the hierarchical stack.
Isolation: Future programmers can isolate technology upgrades from individual layers so that there would be minimal risks or impacts onto the overall system. This protects system integrity.
Manageability: Layered architecture style helps users separate different kinds of dependencies, and thus, all the complex codes can be organized into different manageable sections for managing purposes.
Performance: By using this architecture style, that different functions are distributed at different layers, the app gains improved scalability, fault tolerance, and performance. More stable performance is acquired with this style.
Reusability: Since the system is layered, it would be easier to extract one of them to reuse for other purposes while not affecting other layers.
Testability: Increased testability arises from having well-defined layer interfaces, as well as the ability to switch between different implementations of the layer interfaces. Separated Presentation pattern allows building mock objects that mimic the behavior of patterns such as the MVC during testing.
For object-oriented architecture style:
Domain alignment: Reuse of common services with standard interfaces increases business and technology opportunities and reduces cost.
Abstraction: Services are autonomous and accessed through a formal contract, which provides loose coupling and abstraction.
Discoverability: Services can expose descriptions that allow other applications and services to locate them and automatically determine the interface.
Interoperability: Because the protocols and data formats are based on industry standards, the provider and consumer of the service can be built and deployed on different platforms.
Rationalization: Services can be granular in order to provide specific functionality, rather than duplicating the functionality in number of applications, which removes duplication.
OOP makes modifications rather simpler than other kinds of architecture. With either composition or inheritance or polymorphism, additional object can be added rather simply to make improvements to the software. Layered architecture also provides benefits for future implementation. Programmers can sort out the layout of the app structure rather easily thanks to the clearly defined functional layers and thus, no extra efforts would be needed to locate where to implement desired code. Additionally, loose-coupling from both styles helps with future modification since there is not much entanglements between existing elements, which is good news when it comes to adding more potential elements to the system. Isolation of different elements let programmers only need to worry about their own module instead of others.
Architecture Diagram
https://www.lucidchart.com/invitations/accept/8e6d932c-4340-4582-b57a-e61050b3844f
References
https://www.computerhope.com/jargon/c/chrome.htm
https://www.google.com/chrome/browser/features.html
https://archrometects.files.wordpress.com/2009/10/assignment-01-conceptual-architecture-of-google-chrome-archrometects.pdf
https://developer.chrome.com/apps/app_frameworks
https://www.chromium.org/developers/design-documents/multi-process-architecture
https://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html
https://developer.chrome.com/extensions/devguide
https://msdn.microsoft.com/en-us/library/ee658117.aspx
http://slides.com/joelross/arch-w18-oop#/28