Definition of module – coherent set o responsibilities, interfaces and quality attributes.
The following article aims at introducing SEI layered module views based on the template custom cloud -based application utilizing Azure SQL Database service. The following diagram depicts the layered view of the Azure SQL Database service:
The SEI module views created according to the layered architecture style consists of layers. Layers are defined as grouping of modules offering together cohesive set of services to other layers. The SQL Azure Database Service and any application based on it can be partitioned into following layers providing well-defined set of services:
- Custom Application layer – consists of any modules of custom applications utilizing SQL Service Database services.
- Client Tool layer – consists of tools utilized by custom applications to connect and communicate directly with SQL Database Service utilizing TDS protocol.
- Services layer – The following layers acts as gateway to the Platform layer and provide services related to the connection routing, provisioning and metering.
- Platform layer – layer offering services implementing database services and any other supporting ones
- Infrastructure layer – layer managing physical hardware and operating systems with Azure’s fabric controller and hypervisor.
The rationale behind such partition is to separate the automated, provided by Azure infrastructure and platform management services from modules created or modified by custom applications utilizing Azure SQL Database Service.
Each layer constitutes the grouping of modules– often quite diverse – providing coherent set of services. Client Tool layer contains diverse tools enabling the connection to Azure SQL Database TDS endpoint such as Azure SDKs, REST APIs, Portals or SQL Server Management Apps.
In the layered system each software module is allocated to only one layer. Decision of allocating module to the layer depends on the type of potential changes or based on cohesion. For instance, while designing web apps utilizing Microsoft Azure, most of modules manipulating the application data directly will be assigned to the Azure Database Service layer in the form of T-SQL database apps to locate together all pieces of software managing and storing the application data. Any changes to the way the information is stored and managed will be incorporated to the custom database applications.
Each layer may consist of other sub-layers (or sub-systems) or be segmented horizaontally. Platform Services consists actually from Azure Elastic DB and Azure SQL Database services utilized by custom application and their Supporting Services such as Elastic Database library allowing applications to create and manage sharded databases.
One of the assumptions associated with layering concept is that each layer will involve independently. In the case of Azure SQL Database Service Microsoft develops the Infrastructure, Services and parts of Platform layers whereas the application vendor focuses on designing modules handling the business logics and user interface interactions in Custom Application layer or information management and storage in Platform layer. Obviously, the application vendor benefits greatly from such arrangement as it does not have to cope with infrastructure and operating system management.
The layers are related with ‘allowed-to-use’ relations. If layer B is related with layer A with allowed-to-use relation denotes that the modules from layer B may use the modules in layer A but not the reverse. In our example, the modules from Custom Application Layer may utilize only services of the modules from Client Tools layer to interact with appropriate SQL databases in the Platform layer. The allowed-to-use relations between layers determine practically the sequence of interactions. The custom application utilizing may utilize the REST API to interact with the Azure SQL Database application. Module handling REST API connection must use the Services Layer to establish and handle the connection to the SQL database. The modules from Services Layer directly pass the database processing requests to the SQL Server databases in Platform layer. The custom application may not bypass services layer and use the SQL Server database in Platform layer directly.
Each layer exposes its services through public interface to the upper layer and dedicated segments of modules within it. The SQL Server database interacts with Services and Client Tools layers over TDS protocol. Infrastructure layers certainly exposes some API accessible to the Supporting Services sublayer, but unavailable to the SQL Server Databases and hence to the custom applications.
Introducing well-thought-out layering into application provides several important benefits:
- Separation of concerns – the system is functionally well-structured, less complex due to more transparently and coherently managed dependencies between its modules and cohesive module responsibilities.
- Increased modifiability – modules providing similar functionalities are grouped together and modules have cohesively assigned responsibilities. Furthermore, system layers may be modified independently without impact on upper layers unless their public interfaces (APIs and assumptions concerning services and quality attributes do not change).
- Increased portability – Each layer may be implemented in different technology and deployed separately.
- Simplified design and its analysis – thanks to less complex dependencies between modules.
- Supports incremental development and simplifies project management – each module knows the services of which other modules it may use. This fact simplifies the allocation of development tasks to developer teams and managing dependencies between them.