Date: August 21, 2005
Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part IX...
Creating the Physical Design (Part A)
Date: August 21, 2005
The aim of this series of articles is to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so it is following Microsoft’s recommended approach and, in particular, looking at the requirements of the related Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures'.
We’ve looked at the following thus far:
Article I: phase 1 of the process, the envisioning phase.
Article II: started on phase 2 (gathering and analysing requirements) focussing on business requirements.
Article III: continued with phase 2, focussing on user requirements and issues surrounding globalisation and localisation of your application.
Article IV: finished off phase 2, focussing on operational and infrastructure requirements
Article V: phase 3, developing specifications.
Article VI: phase 4, creating the conceptual design.
Article VII: phase 5, creating the logical design (application architecture).
Article VIII: phase 5, creating the logical design (logical data model)
In this article we turn to phase 6 with a look at creating the physical design. The physical design we’ll split into two, with the latter looking at deployment and maintenance issues as well as the database design and the former physical design of the main application itself. Just to complicate matters we’ll further split the latter into two articles as we have considerable ground to cover.
The logical design expands on the conceptual design by addressing the solution’s structure without defining exact technologies or class implementation, for example. The physical design follows this blueprint but defines specific servers, technologies, operating systems, constraints, methods and properties of the business services that were designed in the logical design.
After the physical design comes implementation. The specification of the physical design is used by those in the developer role during solution implementation. The physical design should be as thorough as possible leaving nothing to question. If done successfully you should be able to answer yes to some (all) of the following questions:
We'll take a look at aspects of creating the physical design. Many of these areas will have been considered in earlier phases; now we get more detailed as the physical implementation needs to be considered. I’ll try not to overlap too much.
Logging is the process of storing information in a consistent manner so that it can be referenced later for purposes such as auditing the information. Most common destinations for this information are the Windows eventlog, a DBMS or a custom log file.
The major drawback of Windows event viewer is that the application resides on a single accessible machine and is not easily moved. However, you can use Windows Management Instrumentation (WMI) to alleviate this issues – see 'Deploying and Maintaining the Application' (the next article).
Database logging is a good centralised solution for logging, but lacks event viewer’s level of reliability and does not provide built in interfaces to perform advanced actions against the logs. However within a DBMS you can easily define a bespoke event log schema that better matches your requirements.
Custom logging is unlikely to be desirable. Any solution is likely to be less capable than the provided alternatives being normally a custom formatted text file, and why reinvent the wheel?
Auditing is actually the process of analysing the information but has come to refer to the activities of logging and analysing the logged information.
Tracing is a flexible form of logging/ auditing offered by ASP.NET allowing the developer to write messages to the trace.axd file or to the web page directly. The system.diagnostics namespace includes the trace and debug classes, which are used to write specific messages to listeners, the function of which is then to direct these messages to a specified output medium.
A proper exception handling process includes:
The framework used to apply the exception-handling process should be separate from the Business Logic Layer.
.NET ExceptionsAll exceptions derive from the Exception base class using the System namespace. A number of predefined exceptions derive from the Exception class which in turn derives from the base exception class. Custom Exceptions can be defined via the ApplicationException class which derives from the base exception class.
The exception handling process should be well thought out and always include fallback handlers to ensure that the exception is logged and resources have been released.
.NET supports structured exception handling which should be used where possible. This allows you to try executing a piece of code you know has the potential to fail, catch specific exceptions that might occur and then perform any cleanup using the finally block (executed whether an exception was thrown or not). When using multiple catch blocks you must catch more specific exceptions first, working down to the most general.
When an exception is caught you can choose to log it and throw it again or continue processing if the exception was expected.
.NET also has the capability to catch unhandled exceptions for logging purposes and resource allocation before the exception is ultimately thrown to the user either via the web.config or global.asax files. Via web.config (default redirect property) you can redirect the exception to a custom handler page and can also specify IIS exception codes to be handled for finer granularity. Global.asax allows you to react to the exception as an event, allowing definition of any cleanup code within the global.asx file itself.
You are likely to want to leverage existing functionality to save time and money via Enterprise Application Integration (EAI). This may be in the form of the use of a specific product e.g. BizTalk server or in using existing facilities to liaise with legacy applications, e.g. DTS (Data Transformation Services), XML Web Services and the integration of .NET services and legacy applications (interoperability). Considering each of these areas in turn:
DTS is a SQL Server related tool for importing, exporting, and transforming data between one or more data sources that support OLEDB. DTS solutions are created as DTS packages which in their simplest form can perform the following actions:
When deployed as jobs the packages can be scheduled to run at specified intervals or at particular times.
XML Web Services were designed from an integration viewpoint to allow the transfer of XML data through HTTP in a loosely coupled fashion. They have gained broad support amongst competing platforms because of their platform independent integration characteristics. There’ll be more on Web Services later.
Interoperability enables you to call unmanaged code via COM and Win32 APIs or vice versa. .NET automatically performs the following interoperability functions between managed and unmanaged code:
A Runtime Callable Wrapper (RCW) acts as a proxy when calling unmanaged COM objects from within .NET. A COM callable Wrapper (CCW) performs similarly to the RCW, but is used when a call is made from a COM component to a .NET component.
The old maxim applies: a chain is only as strong as its weakest link. Security schemes in .NET are referred to as policies. Policies can span multiple tiers and can be more or less restrictive at any layer. Zones are used to span policies that span multiple tiers. When designing your policy consider the following advice:
Authentication is the process of validating users and verifying their identity. As user interaction is commonly required authentication is most commonly initiated in the USL. In a traditional web application you can authenticate the user at the GUI and send the user’s token to the BLL for auditing purposes then call the database with a general connection based on a user role. There is good support for the authentication process in ASP.NET, supporting Windows, custom or Passport authentication. The limitations of some methods of Windows authentication should be borne in mind.
Authorization determines whether the authenticated user has the necessary permissions to undertake the requested action against the specified resource. Authorization is traditionally enabled via role based security and ACLs.
Also in .NET is code access security. Code access security can prevent assemblies from performing tasks they were never designed to do and can prevent calls from components that are not allowed to access the assembly. When determining whether a caller has rights to access an assembly, you can check the following:
USL authorisation is supported via the ASP.net config file.
At the BSL, relying on role-based security is encouraged. The User.Identity class can be used to obtain the user token and the PrincipalPermission class can be used to validate role membership. Code access should also be considered.
At the DAL, use of a single service account simplifies authorisation.
Finally, use SSL or data encryption in general when the data being transmitted is sensitive, particularly if this is being transmitted on the Internet.
In the next article we’ll continue this consideration of aspects of the physical design.
Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que
http://msdn.microsoft.com/architecture/