Modeling Web Browser Use

In a previous post, I wrote about modeling spreadsheets. In it, I described two methods of modeling these. I settled on modeling the Excel application not as an Application Component, but as an Infrastructure Service. That post laid the ground work for this one (so I advise reading it first). This post is about modeling the use of web sites and web applications.

Note: the content of this post has been superseded (amended and extended) by the content on this issue in my book Mastering ArchiMate. Follow this link to the book page (with downloadable PDF)  for more information.

It is good to think about the reality of what happens when you use a web site. You start up your browser and you type in an URL, e.g.

https://archimatemusings.wordpress.com/wp-admin/post.php?post=99&action=edit&message=10

The browser connects to the web server and loads a web page that the web server sends. What the web server sends is based on the URL, which is composed of three parts: a protocol identifier (e.g. https://), a domain name (e.g. archimatemusings.wordpress.com) and the request part (the rest of the URL, e.g. /wp-admin/post.php?post=99&action=edit&message=10).

Now, based on that request part, the web server returns data to the browser using the ‘http’ protocol. That data could be everything, but in this case, the data conforms to a standard language, HTML, which the browser understands. HTML originally was just a simple description of markup/layout, but browsers these days are far more powerful. They have functionality that allows them to present active components to the user, say buttons, popups and so forth and also ways to run code. This code is normally JavaScript code, which is built in in almost every browser. JavaScript, by the way, has nothing to do with the programming environment ‘Java’. JavaScript was originally called “Mocha”, then “LiveScript” until somebody at Netscape thought it a good idea to change the name so it could profit from the hype surrounding Java at that time.

Anyway, what is being sent from web server to web browser is a file, a stream of bytes. In ArchiMate terms, this is an Artifact. Now, this Artifact realizes both passive and active (behavioural) elements. What actually happens is that your browser interprets the file (html/JavaScript) and realizes both a passive Data Object and an active Application Component. This is just like Excel interpreting the spreadsheet and realizing both passive (Data Object) and active (Application Component) objects as described in the previous post. But there is a difference. With a web browser getting the file from a web server, the file may be just ‘in memory’ and the whole setup is created ‘on the fly’. There is no Artifact on a disk anywhere, it may just exist in memory of the desktop running the browser. Here is a picture, detailed on the left, a minimal summary on the right:

From a security perspective, that sounds like a nightmare by the way. Some external organisation sends you code which you execute in your environment. Just like that. This is why the JavaScript language is designed to be contained within the browser. It cannot touch anything outside the browser and that makes it safe (almost).

Anyway, the downloaded/in-memory html/JavaScript Artifact realizes an on-the-fly Application Component which performs the Application Function that has been defined in the downloaded file. To be able to actually perform that function, the browser is needed, as it contains the platform to execute the code.

And suppose the website contains materials that require a plugin of the web browser to run? Well, the browser is capable of loading this plugin. As a result, the browser can execute code that is written for it, e.g. Flash, Silverlight, Java, etc. (This of course, has security implications).

Just as with the previous post about spreadsheets, it is useful to model the use of a web application (including a web page with some JavaScript in it) with your browser in the role of platform, as an Infrastructure Service. And the actual Application Components are created on the fly by your browser. This is important, because your Business Process is not using “Internet Explorer”, it is using an Application Component running inside Internet Explorer and what that Application Component does is defined by the external party, but within the limits of the web browser and its plugins.

The question of course is: is it useful to model the state of affairs at this detailed level? In the previous post, about modeling spreadsheet use, my answer was a clear “yes”. Not modeling those ‘hidden’ spreadsheet applications is sloppy and it seriously undercuts the usability of your models for analysis. In this case, the situation is slightly different, though. The functionality remains inside the browser, if only because of security considerations. So, there will never be direct relations with other functions in your landscape. Modeling the on-the-fly objects may be the most correct way to do it, in terms of the uses of your models, you might do with less detail. What you at least do need to know is the dependency of the Business Process on the browser and its plugins and on the web server. I could personally live with a model without the passive and active objects and the Application Function that is performed by the on-the-fly Application Component. Then it would look like this:

If the web site needs the plugin, the direct Used-By relation between plugin and Application Service is there. If not, the Application Service still depends on it, as the plugin’s existence may influence (e.g. break) normal browser behaviour.

For me: when the web page functionality is really complex, so complex that it needs to be used by various different processes in your business, I would at least like to model the different functionalities (Application (sub)Functions). As an example, think of a complex web-based application where you also have stuff like access control of users and you need to model that separately because you want to show your auditors that you are in control.