Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part IX...

Creating the Physical Design (Part B)

By: Chris Sully Date: August 27, 2005

Introduction

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 the last article, IX(A): we started looking issues surrounding phase 6, creating the physical design, which we'll continue now, in part B.

Business Services

This is the code for the solution, containing constraints to support the business rules. You may decide to employ some or all of the following:

1. Business components: used when functionality must be reused over several business processes or when robust actions and calculations must be performed against data access and APIs.
2. Business workflows: needed when you are managing multiple steps and long-running transactions. BizTalk server is the recommended platform for designing the proper workflow.
3. Business entities: entities, which represent business concepts, define real life business relationships and data.
4. Service interface: enables service agents to access your BSL through a channel such as HTTP or TCP/IP.

Looking at 1,3 and 4 in more detail:

Business objects should be reused and methods accordingly broken apart whenever code might prove useful later. Business components can be tightly coupled or loosely coupled. The loosely coupled effect is achieved when implementing a workflow or service interface over the BSL. Business components should:

• Be invoked by the USL, the service interface or other business services
• Be the root of transactions
• Validate input and output
• Call the DAL to perform actions against the database
• Call external services through service agents
• Call other business components and instantiate workflows
• Raise an exception to the caller if anything happens in an atomic transaction

Consider whether you require transactional business services. If yes, look at Enterprise Services and consider the following:

• Remoting channel restriction: HTTP and DCOM-RPC are the only channels supported.
• Components must be strong named.
• Components need to be self registering or a special deployment step needs to be taken.
• The Enterprise Services model is available for security, as well as .NET based security.

Business entities are data representations of actual objects in your company. Typically, entities are representations of your database table structure, but they do not usually conform to one specific table. Instead, they are denormalised and represent a small entity schema. Often it is wise to design your business entities to be stateful objects containing a DataSet or an XML representation available throughout the object’s lifetime.

Business entities should access the database via the DAL, which handles cleanup and any special auditing features. Business entities are a low level entity view and are meant to be aggregated to perform specific functions; transactions are not recommended at this level. Business entity design recommendations include:

• Entities should map to data relationships. If a custom entity is needed, first verify that the data cannot be obtained by aggregating two entities in the business component member of the BSL.
• When constructing business entities, deriving all common logic from a base class is considered best practice.
• Maintenance of state should be in DataSets or XML, not collections or structs.
• Implement interfaces that expose common characteristics of all business entities.
• Business entities should enforce all constraints and validations needed for a specific entity.
• Display validation rules to callers, but do not allow them to change any rules. A validation rule could be an XSD schema applied to the XML.

An example: business entities for an ecommerce site can consist of Order, Customer, Product etc. Shopping cart is not a business entity; rather it is a component because it aggregates the product customer and order entities to define the cart.

Business service interfaces provide functionality to a remote caller via the BSL. Because the USL is being bypassed alternative security must be provided and only the required functionality should be exposed. Design capabilities for your service interface are:

• Service interfaces can provide caching, mapping and schema transformations. Services implementing business logic are not recommended.
• Services should be designed with interoperability in mind; so they should support industry standards and provide the most accepted transfer method that is sure to be supported in the future.
• When business components are deployed on a server separate from the service interface you might consider giving the service interface its own security policy for authentication and authorisation.
• Services can be transactional.
• You might consider providing a transparent service so that changes made at the BSL to business components are automatically available through the service.

Web Services are the most common way to implement a business service interface.

Your application's performance and reliability are heavily affected by your network infrastructure. In the business services layer in particular there are related opportunities for response times to dwindle.

Latency is the time taken for data to move from point A to point B. Bandwidth is a related, but different issue. Some best practices to avoid latency are:

• Don't use objects such as the DataSet as these are not ideal for transferring large amounts of data because of their inbuilt memory space. Use the DataReader or XML instead.
• 'Chatty' calls should be avoided. Use chunky RPC to perform multiple steps in one call. You should use this method whenever a call is made between .NET and COM, remoting or XML Web Services, even if the components are on the same physical machine, as proxies are involved.
• If possible, do not pass reference-based objects through tiers. Attempt to create a scheme that relies primarily on value based or serialised objects such as strings and integers.

User Services

The USL must provide precise events, validation and exception handling to facilitate the UI. The USL should call only the BSL (unless there isn’t one in your selected architecture). USL best practices include:

• Should not perform transactions
• Should call only the BSL
• Should capture events from the user and allow the use to interact with it based on roles
• Should validate input and provide a explanation and options when an error occurs
• Can cache result sets
• IDs and other mapping attributes should not be displayed to the user

The presentation layer consists of UI components (UICs) and UI process components (UPCs). UICs are simple interfaces that enable users to interact with the application. UPCs are similar to UICs but they follow a process. They are common in wizard type functionality.

UI examples include Web forms, Windows forms, console apps, mobile forms or any combination thereof. Considering each in turn:

Windows Forms are a good choice for offline applications; they manage intense state or access to client system resources that might require administrative privileges. Not intended for Intranet/ Internet-based applications (though be an appropriate choice in certain scenarios), but are ideal for distributable software applications where the processing is implemented in part or in full on the client side. Windows forms are stateful and can provide multiple forms simultaneously.

They can be used as full-blown desktop UIs, embedded HTML or as an application plugin. They can also be run over the Internet similar to ActiveX controls and Java applets as long as the .NET Framework is installed on the client.

• Use data binding for synchronisation across multiple open forms
• A child form should not contain hard coded relationships between itself and its parent as this limits future re-usability
• Structured exception handling is essential
• User input validation is essential
• When creating custom user controls, clearly label the methods that can be called and make private the methods holding no benefit to the user or those that could possibly cause unanticipated results (encapsulation)
• Wire events to methods that will perform the requested task; do not put too much logic in the event handler as you might need to reuse this logic later in the application

Web Forms provide an excellent platform for developing Internet and intranet applications that scale to platforms .NET does not support. The web is a stateless medium but ASP.NET offers state management and caching features. Recommendations are:

• Implement a custom error page in the web.config file and a global.asax file to catch unhandled exceptions
• ASP.NET controls should be used for validation (client and server)
• Design custom controls to hide properties and methods that have no value to the caller
• Use Viewstate for page specific data; use session and application state if traversing multiple pages
• When a user is completing a process that requires several steps, build a UPC that specifically calls the required actions from form to form, as opposed to just redirecting the user
• Do not store event functionality inside the event handler
• If not using Viewstate, turn it off to eliminate the overhead

ASP.NET also provides an extensive framework for globalisation. Though the use of satellite assemblies, ASP.NET can change the content depending on the user’s language and culture preferences.

Mobile devices became easier to develop for with the introduction of the mobile Internet toolkit. Mobile controls request the device type and then automatically convert the tags to render properly in the calling device. Some points of note:

• You will need to test the rendered site in each target emulator
• State will be an issue if you need to support multiple versions of WAP enabled phones. The only true way to maintain state across all versions of WAP enabled phones is via the query string though even this has issues
• Don't clutter the screen – you may not have much room to play with
• Coding for Windows CE PDAs is very similar to coding for IE

The User service facade is typically .NET classes that can be called or inherited from that provide the UI for your site, e.g. an extended datagrid.

Caching result sets and reference based objects can significantly improve performance. The Cache object has application scope and can be access programmatically or is available as page caching and fragment caching of page parts.

Enterprise thin-client applications serving a substantial number of concurrent users usually implement a web farm architecture. Particularly important then is security. As well as using SSL, best practice is to implement a firewall between the Internet, the USL, BSL and database server(s). This practice puts the USL and BSL in a demilitarised zone (DMZ), where they are outside the company firewall but have an open port into the network. Solutions that implement business logic on a machine separate from UI logic should implement this DMZ, which allows for a 3-layer firewall approach. Solutions that implement business logic and UI logic on the same physical machine can still implement a 2-layer firewall.

Data services and components

Your data source may be a data service or service agent (Web Service).

Data access components must be built to perform specific communication with the data source and provide a consistent interface for business services. They are typically stateless and simply abstract the obscurities of the underlying data source. Each data access component should access a maximum of one data store for the purpose of maintainability. If stored procedures are available, they should be used.

Some physical design considerations:

• Locking schemas should be implemented through a custom component
• Non-transactional data caching should be implemented through a custom component
• Data routing should be implemented for larger systems that use multiple database servers
• Do not invoke other data access components, instantiate transactions or attempt to maintain state in the DAL. These are the jobs of the BSL.
• Return only data that is needed
• Implement a standard to call stored procedures that perform insert, update, add and delete functionality
• A database base class that defines commonalities, such as connection strings and pre-call and post-call creation and destruction should be inherited.
• The data access logic can perform decryption if the record is stored encrypted in the data source

Service agents may be Web Services, remotable components or abstract APIs. The DAL should encapsulate the agent's underlying obscurities. Data access components that call service agents can also carry out the following additional functionality:

• Perform basic validation on data received from the service
• Data caching for common queries
• Perform authorisation of the caller
• Encryption and decryption
• Logging

Managing and configuring state

Several options exist: ViewState, hidden fields, querystring, cookies, application state, session state, database sessions.

Next

That concludes our overview of issues involved in the physical design per se. However, in the next article we’ll look at the related and critical issues of deployment and maintenance.

References

Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que

http://msdn.microsoft.com/architecture/