Date: August 14, 2005
Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part VII...
Creating the Logical Design (application architecture)...
Date: August 14, 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.
In this article we move onto phase 5, creating the logical design (application architecture). Phase 5 we’ll split into two articles with the first looking at application architecture and the second the logical data model.
I’ll be skimming through the content mostly just mentioning areas you should be considering, assuming that the reader is a reasonably experienced developer and that they will be au fait with much of the detail.
Key issues are:
Looking at each:
Web or Windows?
Issues for consideration:
n-tier
Typically: GUI, User Services Layer (USL), Business Logic Layer (BLL), Data Access Layer (DLL) as well as the data store itself.
Aspects of the requirements that might cause you to choose a simpler architecture than ‘standard’ n-tier are:
Interaction with legacy or 3rd party applications
If this is required you should plan for a logical module to serve as the interface between your own code and the foreign code. There are also products to manage the interface which may be appropriate e.g. BizTalk Server or COMTI. You also have XML to facilitate communication.
There are lots of new features in .NET to take advantage of, e.g. tracing and logging classes. Also important is Windows Management Instrumentation (WMI). This is the Microsoft implementation of the industry standard Web-Based Enterprise Management (WBEM) and Common Information Model (CIM). Its purpose is to allow monitoring and control of distributed machines and distributed applications.
In .NET WMI, though the System.Management namespace, you can establish one or more managed events. This is referred to as instrumenting an application. An example of an event you may want to instrument is detecting two consecutive password rejections. Alternatively you can generate a call to the WMI layer of the application.
Three main goals:
Consider using the Microsoft exception management application block as indicative of best practice.
Some items that may need addressing are text (use resx files), string manipulation, fonts, currency, numbers and dates. Note that these considerations don’t just necessarily affect the USL.
Recommendations for consideration in UI design are:
For more information see my article on user assistance and accessibility (http://www.dotnetjohn.com/articles.aspx?articleid=75)
Key areas:
Key concept: your solution is only as secure as its weakest link.
This is effectively creating the logical data model – see the next article.
This is where the majority of ‘rules’ governing how an application works are stored. A common strategy is dividing the business layer into two parts:
The idea is that data objects are populated and passed round the application, carrying state with them. In this way, business rules can receive these stateful objects as input parameters. This method provides maximum flexibility and scalability, but at the cost of some extra complexity.
Ideally these business classes and components will be designed to be reusable though they rarely are in actuality. However, they may be used my more than one USL.
Another aspect is caching, the intelligent use of which can improve application performance significantly.
Typically the USL is separated into 2 logical sub-layers: the GUI (what the user sees and interacts with) and the code that orchestrates how the entire GUI interacts. So how should the USL be implemented?
The key decision remains Windows or Web. Most of the time it will be fairly obvious. Sometimes it won't. Sometimes you'll require both.
Should I create a services based architecture? What is a services based architecture? It means creating a small, narrow message-based interface specification and sending messages based on this specification. Services should usually be coarse-grained. That is, services should wrap a substantial body of application logic, delivering value that justifies the latency cost of a network request. Similarly, services should expose coarse-grained interfaces: rather than exposing many interfaces that each manipulate small amounts of state, services should expose fewer interfaces that allow a single request to perform a complete query or update. Would services meet your requirements?
Web app: session, application, cache, viewstate.
For a Windows app data is local so managing state is not such an issue except when it comes to updating remote data stores. You need to give matters a little more thought with a web app.
That is 'pause execution and wait until the result is returned' or 'proceed with processing with the result returned when the call is completed'. The choice is mainly about improving perceived performance by hiding (commonly) network latency. Also remember that sometimes you need to wait for the response to undertake the next step of processing in which case asynchronous calls are not appropriate!
In the past you had COM and DCOM. Now you have SOAP, XML, Web services, COM (still) and .NET remoting. Dig a little deeper and you have HTML, HTTP, UDP, OLEDB and RPC. Looking at each of the main players:
COM
Interaction with COM is accomplished with the help of .NET Interop Services (system.runtime.interopservices namespace) and marshalling. Interop marshalling is best when limited to simple, native data types. The more complex the data type the worse the performance. In particular avoid variants.
Communication from .NET is achieved via runtime callable wrappers that act as a proxy around the COM components allowing .NET to talk to it as if it was a .NET component.
COM callable wrappers are used to expose .NET objects to the COM world.
COM+
Utilising COM+ is much as it was before as COM+/Enterprise Services has not yet been integrated fully into the .NET world, but calling COM+ features from .NET is supported.
XML
This comes down to a matter of ease of implementation versus the lesser performance of transferring big streams of XML data.
XML Web Services
Although some security issues still need to be worked out, Web Services seem to be the front runner for future Enterprise Application Integration (EAI) and Business to Business (B2B) communication, possibly even assuming the role Enterprise Data Interchange/ Electronic Funds Transfer (EDI/EFT) previously held.
.NET Remoting
Rarely receives the same coverage as Web Services but when you own both ends of the connection remoting can improve performance dramatically. Designed from scratch for .NET is has the feel and performance of DCOM.
DataSets and other miscellaneous objects
Native .NET structures and collections may also be used if your components are accessible to each other through early binding, i.e. on the same machine. Plus you have the ability to bind these objects easily to UI controls.
Once you’ve completed your logical design you should validate it against the PASSMADE requirements, as follows:
Performance
Any obvious performance bottlenecks? Could caching/ asynchronous processing assist?
Availability
Using both asynchronous processing and a services style architecture might improve availability if this is key.
Security
Have you performed threat modelling including an analysis of issues arising from authentication, authorisation and
encryption?
Scalability
Your design should include some way to monitor your application’s performance against a user load.
Maintainability
Have you documented your design properly? Have you segmented the application components properly to allow multiple
people to work on it simultaneously?
Accessibility
Focussed largely, though not exclusively, on the USL.
Deployability
Have you limited the number of dependencies you require for your application? Have you avoided where possible using
COM components that require registration? Have you investigated whether an XCOPY solution is feasible?
Extensibility
Does you design allow easy extension of the application if required?
You should also validate the logical design against use cases, user personas and usage scenarios. The previously agreed use cases are your contract with the business stakeholders so are key considerations.
You may also choose to provide a proof of concept deliverable to allow you to try out the tricky bits and minimise risk. This can be expensive but can also be invaluable.
Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que
http://msdn.microsoft.com/architecture/
MSDN