Architecture – IEC 62304 compliant Architecture definition

The definition of 3-tier architecture is a special case of the n-tier architecture. In an n-tier architecture, there are n components and each one only interacts with the component immediately "above" and "below" it. A three-tier architecture has three such components.

Typically, a three-tier architecture consists of a user interaction layer, the business rules layer, and data services (including databases) layer. The user interaction layer only issues requests to the business rules layer, which retrieves data from the various data services, processes it, and then returns it to the user through the user interaction layer.

The n-tier architecture is an example of an architectural pattern (or architectural style). It simply defines some constraints on the architecture of the system. By itself, it is not a complete view of the architecture of the system. Although I'm sure that there are systems that implement something like a three-tier architecture, it is just a pattern that's meant to set up a discussion for additional design and implementation of a system.

User Interface

The requirement for working on a range of devices from smart phones to desktops is addressed by two different approaches:

• Recognize the type of device and produce a different site page for phones versus desktops. This often yields funny results on large tablets. Not funny in the good sense.
• Use strong dynamic layout with cascading style sheets to position items on the page based on screen size and resolution. This yields very usable, scalable sites. They also work quite well when users want to rescale the browser page on a desktop. Here is a good discussion.

The dynamic layout approach then suggests that you organize your dashboard into a set of UI widgets. Each widget would have a set of graphical elements, fixed textual elements, dynamic text and dynamic graphical elements. The widget is then tied together with scripts that properly display the widget as well as querying the back end for data.

Client Back End

As you have already identified, your server back end would be accessed by REST requests initiated by individual widgets. Each REST request would be essentially stateless. That is not to say that you wouldn't store your client profiles and user profiles in such a way that you couldn't always determine that any particular web application can only see exactly what it should see.

Each widget needs to periodically get updated data from the server. It will poll the server using a REST request passing the parameters configured into it as well as a session ID used to authorize access to that data.