MSDN Utopia : Application blocks

Design: Architecture Frame Considerations (Part 2)

Salva Patuel — Tue, 10 Feb 2009 19:58:00 GMT

In this second instalment we are going to review another set of frames. This guideline should help you to understand what is involved on each one of them as well as considerations and known patterns.

You can find the first part following this link.

The second part looks like this:

The following guideline can help you to identify the key issues on each area of the frame and some recommendations that we usually share with our customers in the ADC team (Application Development Consultant ). Note that this list is not exhaustive and are general suggestions that can help you on your design process.

Configuration Management
The message here is clear, we need to move configurable options to a configuration file so the user can change it without recompiling the application. Yes, is quite clear but the problem is that developers usually overlook how this information is accessed and secured. We have seen many times user names and passwords on these files without any security! Not only have that, with time these configuration files grow to unmanageable levels that jeopardized the application execution.

Key Issues:

· Lack of or incorrect configuration information

· Sharing configurations around farms

· Not securing sensitive configuration information (exposing passwords/identities)

· Lack of security around the configuration files

Consider the following guideline:

· Use IIS sharing configuration features in order to deploy configuration files over a farm.

· Consider using least-privileged process and service accounts.

· Categorize the configuration items into logical sections, this method can help you secure different areas (features like configuration delegation in IIS are very helpful in this scenario)

· Encrypt sensitive information in your configuration store

· Restrict the access to your configuration information

· Provide a separate administrative application to deal with configuration files.

Pattern	Brief
Provider	Implement a component that exposes an API that is different from the client API in order to allow any custom implementation to be seamlessly plugged in.

Coupling and Cohesion
When you are designing components for your application you should ensure that are highly cohesive and loose coupling is used across layers. Coupling refers to the dependency between components and cohesion relies on the functionality that the component provides.

Key Issues:

· Incorrect grouping of functionality

· No clear separation between objects

· Tight coupling across layers

Consider the following guideline:

· Design for loose coupling between layers.

· Consider using abstraction to implement loose coupling between components.

· Consider using common interface definitions

· Use dependency inversion to decouple dependencies, depending on abstractions rather than concrete components.

· Divide your application functionality into logical layers; if you are dealing with customers you shouldn’t include your message binding properties on the same object.

· Design for high cohesion. If a component says “Customers” it should provide only customer functionality.

· While loose coupling requires more code, the benefits include a shortened dependency chain and simplify the building process.

Pattern	Brief
Composite view	Combine individual views into a composite view.
Inversion of Control	Populate any dependencies of objects on other objects or components that must be fulfilled before the object can be used by the client application.
Template View	Implement a common template view, and derive or construct views using the template view.
Two-Step View	Transform the model data into a logical presentation without any specific formatting, and then convert that logical presentation into the actual formatting required.
View helper	Delegate business data-processing responsibilities to helper classes.

Data Access
Separating the data access layer (DAL) is an important decision that improves the application maintainability and extensibility. This will allow you to easily change the repository or the logical structure of your data model without affecting the application functionality. It is recommended to implement an entity model to translate physical designs into business ready entities.

Key Issues:

· Per-user authentication and authorization when not needed

· Chatty database calls interfaces

· Data access code embedded with business logic

Consider the following guideline:

· Avoid coupling your application model to the database schema. Use abstraction models like the entity framework.

· Enforce data integrity in the database, not through data layer code.

· Move business logic to the application layer, avoid long stored procedures as they make applications harder to migrate and control.

· Open connections as late as possible and release them as early as possible.

· Avoid accessing the database from different layers, the DAL should be the only component that knows anything about the repository.

Pattern	Brief
Active record	Include a data access object within a domain entity.
Data mapper	Implement a mapping layer between objects and the database structure that is used to move data from one structure to another while keeping them independent.
Data Transfer Object	An object that stores the data transported between processes, reducing the number of method calls required.
Domain Model	A set of business objects that represents the entities in a domain and the relationships between them.
Query Object	An object that represents a database query.
Repository	An in-memory representation of a data source that works with domain entities.
Row data gateway	An object that acts as a gateway to a single record in a data source.
Table data gateway	An object that acts as a gateway to a table or view in a data source and centralizes all of the select, insert, update, and delete queries.
Transactional Script	Organize the business logic for each transaction in a single procedure, making calls directly to the database or through a thin database wrapper.
Table module	A single component that handles the business logic for all rows in a database table or view.

Exception Management
It is important to track all the application exceptions to make the system more reliable and to properly capture application defects. A crash can be very costly for customers and is not something that you want to re-experience in order to get more information. A proper exception management should provide you with enough information when the fault occurs, this should include as much information as possible in order to reproduce the scenario.

Key Issues:

· Unstable state exposure

· Revealing sensitive information to the user

· Using exceptions to control logic flow

· Inaccurate/non-existence logging information

Consider the following guideline:

· Do not reveal sensitive information in exception messages and log files. I have seen many websites showing the full stack when an error occurs!

· Let exceptions flow if they are unexpected, catching everything without proper logging may provide a false end user experience that can lead to corrupted entries.

· Design an appropriate exception propagation strategy.

· Send the information back to a central repository when possible to analyze trends when large user based is expected.

· Log information on common repositories, like log files, event logs or external web services.

Pattern	Brief
Exception Shielding	Prevent a service from exposing information about its internal implementation when an exception occurs

Layering
Proper layering design allows you to separate the functionality into different areas of concern. This will help you to group functionality and components that will make your system more predictable and able to scale out. Layers should have a well defined communication flow, for example, layer A can talk with layer B but not the opposite scenario.

Key Issues:

· Incorrect grouping of components within layers

· Not following layering and dependency rules

· Not considering physical boundaries

Consider the following guideline:

· They should be used as logical groups, for example, user interface, process layer, application layer, data layer.

· Components within a layer should be cohesive.

· Consider physical boundaries when designing layers

· Use interfaces to define each layer, this will allow proper communication and different deployment models.

· If you are running web applications consider using message-based interfaces to provide a stateless user interface.

· Provide a facade pattern to the process and application layers.

Pattern	Brief
Remote Facade	Creates a high-level unified interface to a set of operations or processes in a remote subsystem to make that subsystem easier to use, by providing a course-grained interface over fine-grained operations to minimize calls across the network.

The next part will complete the set of considerations, watch this space!

Design: Architecture Frame Considerations (Part 1)

Salva Patuel — Mon, 01 Dec 2008 13:53:00 GMT

At Microsoft we are working hard in putting together the different components that are involved deciding the architecture approach. One of these components is the architecture frame, which together with the architecture style and application type creates the architectural baseline for modern design. This guideline is targeting architects and not developers, therefore the topics and recommendations cover high level decisions.

One of the most common situations when we sit down during reviews is that the team starts choosing the technology first without analysing what they really need. They usually end up in a model that fails to deliver value to the business and trigger a set of failures around the qualities of service. In order to avoid this, a proper review of the architecture frame can help architects and developers to foresee potential problems and chose the right technology and pattern based on the real execution context. The frame is pictured below with the section covered in part 1.

Authentication & Authorization
This area is one of the most misunderstood concepts in the frame, as many architects confuse these concepts as they security has been a complex area to understand. Remember that the authentication process validates the user credentials and the authorization involves the roles and actions that the user has on the system. Designing a good strategy on this area helps to improve the security and reliability of the application.

Key Issues:

· Lack of authentication across trust boundaries, as this leaves your application vulnerable to spoofing attacks, dictionary attacks and session hijacking.

· Granular or improper authorization can leave your application expose to vulnerabilities like information disclosure, data tampering and elevation of privileges.

Consider the following guideline:

· The most important consideration is performing a STRIDE analysis that may help to identify risks.

· Identify your trust boundaries; authenticate and authorize users and calls across trust boundaries. Some calls may need to be authenticated on the client and the server (mutual authentication).

· If your system involves multiple applications based on different user subset consider using a single sign-on strategy

· Do not store passwords in plain text; instead consider using hash codes or proper encrypted algorithms.

· Do not transmit passwords in plain text.

· Protect resources based on identity, groups or roles.

· Use role based authorization for business decisions.

· Use resource based authorization for system auditing.

· Use claims based authorization when you need to support federated environments or complex rights models.

· Consider using a trusted subsystem for access to back-end services to maximize the use of pooled connections.

· If the presentation and business layers are on the same machine and you need to keep the original caller’s ACL permission consider using impersonation. On the other hand, if they are on different machines consider using delegation. Note that this may affect performance.

· Implement IP filtering to protect your business layer.

· Consider the implications of using different trust settings for executing service code.

· Ensure that secure protocols such as SSL are used with basic authentication.

· Use secure mechanisms such as WS security with SOAP messages

· Run services under the most restrictive account that is appropriated

Pattern Map:

Pattern	Brief
Data Confidentiality	Use message-based encryption to protect sensitive data in a message.
Data Integrity	Ensure that messages have not been tampered with in transit.
Data Origin Authentication	Validate the origin of a message as an advanced form of data integrity.
Exception shielding	Prevent a service from exposing information about its internal implementation when an exception occurs
Federation	An integrated view of information distributed across multiple services and consumers.
Replay protection	Enforce message idempotency by preventing an attacker from intercepting a message and executing it multiple times
Validation	Check the content and values in messages to protect a service from malformed or malicious content

Caching
This is the developer’s favourite, we have seen many applications implementing caching patterns without considering why and where it is needed. Poorly designed caching strategy can lead to degradations on performance and responsiveness; on the other hand, good caching design can really speed up responsiveness and contributes to the concurrency and efficiency factor.

Key Issues:

· Caching invalid content

· Caching sensitive data

· Incorrect choice of caching store

Consider the following guideline:

· You should use caching to optimize reference to lookups and avoid network round trips.

· Do not cache volatile data.

· Try to load the cache asynchronously to avoid call delays.

· Consider ready-to-use objects when storing them in the cache instead of raw database data.

· If you need to cache sensitive data use encryption as a simple memory dump can reveal it.

· If your application is deployed in a farm avoid using local caches that need to be synchronized, instead consider using transactional resource manager or a product that supports distributed caching.

· Do not depend on data still in your cache, as it may have been removed.

Pattern Map:

Pattern	Brief
Dependency Cache	Use external information to determine the state of the data stored in a cache.
Page Cache	Improve the response time for dynamic pages that are accessed frequently

Communication
This area covers how the components on different layers will communicate with each other, the mechanism depends on the deployment scenario but the key issues are usually similar.

Key Issues:

· Incorrect choice of transport protocol

· Chatty communications

· Failure to protect sensitive data

Consider the following guideline:

· When crossing physical boundaries consider using message based communications, on the other hand, for crossing logical boundaries you should use object based communication.

· If you are not concern about the order of the messages consider using asynchronous communication to unblock processing or UI threads

· Consider using message queuing to queue messages for later delivery to cover network interruptions. Remember that that this pattern supports transacted message delivery and supports reliable once-only delivery.

· Consider net pipes for inter-process communication, TCP for local networks and HTTP based protocols for external links.

· Determine how to handle unreliable or intermittent communication.

· Validate endpoint addresses in messages.

· Decide if a message communication needs to be two-way or one-way

Pattern Map:

Pattern	Brief
Intercepting Filters	A chain of composable filters that implement common pre-processing and post-processing tasks.
Pipes and Filters	Route messages through pipes and filters that can modify or examine the message as it passes through the pipe.
Service Interface	A programmatic interface that other systems can use to interact with the service.
Duplex	Two-way message communication where both the service and the client send messages to each other independently, irrespective of the use of the one-way or the request/reply pattern.
Fire and Forget	A one-way message communication mechanism used when no response is expected.
Reliable sessions	End-to-end reliable transfer of messages between a source and a destination, regardless of the number or type of intermediaries that separate endpoints.
Request Response	A two-way message communication mechanism where the client expects to receive a response for every message sent.
Channel Adapter	A component that can access the application's API or data and publish messages on a channel based on this data, and can receive messages and invoke functionality inside the application.
Message bus	Structure the connecting middleware between applications as a communication bus that enables them to work together using messaging.
Messaging broker	A component that connects messaging systems and replicates messages between these systems.
Point to point channel	Send a message on a Point-to-Point Channel to ensure that only one receiver will receive a particular message.
Pub/Sub channel	Create a mechanism to send messages only to the applications that are interested in receiving the messages without knowing the identity of the receivers
Command Message	A message structure used to support commands
Event Message	A structure that provides reliable asynchronous event notification between applications.
Competing consumer	Set multiple consumers on a single message queue and have them compete for the right to process the messages, which allows the messaging client to process multiple messages concurrently
Durable subscriber	In a disconnected scenario, messages are saved and then made accessible to the client when connecting to the message channel to provide guaranteed delivery.
Idempotent receiver	Ensure that a service will only handle a message once
Message dispatcher	A component that sends messages to multiple consumers.
Messaging gateway	Encapsulate message-based calls into a single interface in order to separate it from the rest of the application code.
Messaging Mapper	Transform requests into business objects for incoming messages, and reverse the process to convert business objects into response messages.
Polling consumer	A service consumer that checks the channel for messages at regular intervals.
Selective consumer	The service consumer uses filters to receive messages that match specific criteria.
Service activator	A service that receives asynchronous requests to invoke operations in business components.
Transactional client	A client that can implement transactions when interacting with a service.

Composition
This part of the frame is very important an it has a significant impact in the user experience. The composition is the process used to define how the user interfaces are structured in order to provide a consistent look and feel.

Key Issues:

· Cooperating UI modules are coupled by dependencies making development, testing and maintenance more difficult.

· Dependency changes between modules forces code recompilation and module redeployment.

· Dynamic UI layout update and dynamic modules loading difficult due hardcoded dependencies.

Consider the following guideline:

· Use abstraction patterns when possible to avoid issues with dependencies between components.

· Consider creating templates with placeholders, a good approach may be using the template view pattern to compose dynamic screens to ensure reuse and consistency.

· Consider composing views from reusable modular parts like user controls. The composite view pattern is a good approach to build a view from atomic component parts.

· Avoid using dynamic layout as they are difficult to maintain.

· If you need to allow communication between presentation components consider using the pub/sub pattern, this will lower the coupling between components and improve testability.

Concurrency and Transactions
Designing good concurrency and transaction models is a key part of the architecture as it directly affects performance (specially concurrency). Identifying the right requirements in order to select optimistic or pessimistic models can be a critical decision. There are plenty of documentation and best practices around this area but from the architectural perspective we should worry about the general issues that are system may face.

Key Issues:

· Nonexistent or poor protection for concurrent access to static data

· Deadlocks caused by improper locking

· Not choosing the right data concurrency model.

· Long running transactions that hold locks on data

· Using pessimistic/exclusive locks when not necessary

Consider the following guideline around transactions:

· Wrap business critical operations in transactions

· Use connection based transactions when accessing a single data source

· Don’t be afraid of using transaction scopes to manage transactions on multiple data sources.

· Avoid holding locks for long periods.

· If transactions are not an option consider the use of compensation methods to revert the data to the previous state.

Consider the following guideline around concurrency:

· Remember that static data is not thread safe.

· Updates to shared data should be mutually exclusive; this will prevent two threads from attempting to update the data at the same time.

· Locks should be scoped at a very fine grained level, the idea is to lock only when is necessary and release it as soon as possible.

· If you need to update static fields use the check-lock-check pattern as other thread may have changed the value between your check and your lock.

· Never apply a lock to a type definition or the current instance. Using these constructs can lead to deadlock issues that are difficult to locate. Use private static objects as locking reference instead.

· Consider the use of the synchronization support provided by collections when working with shared ones.

Pattern Map:

Pattern	Brief
Capture transaction details	User DB objects such as triggers and shadow tables to record changes to all tables belonging to the transaction.
Optimistic offline lock	Ensure that changes made by one session do not conflict with changes made by other session.
Pessimistic offline lock	Prevents conflicts by forcing a exclusive lock
Coarse Grained lock	Lock a set of related objects with a single lock
Transaction script	Organize the business logic for each transaction in a single procedure, making calls directly to the database or through a thin database wrapper.
Implicit Lock	Use framework code to acquire locks on behalf of code that accesses shared resources.

On the next blog entry we are going to explore the second subset of considerations using the architecture frame.

You can find part 2 here.

Windows Mobile Briefing Sessions (6.0 / 6.1)

Salva Patuel — Mon, 28 Apr 2008 19:59:00 GMT

If you have missed one of my sessions during the EMEA Windows Mobile Briefing you can find the recordings of our last Finland event. During this event I was covering also the first session and we had a large attendance, upon the demo using the orientation aware control didn't work :) (I had cut and paste the application blocks instead of copy and paste!) but we had a lot of fun. For the material and demos please check my other post here: http://blogs.msdn.com/salvapatuel/archive/2008/02/24/emea-windows-mobile-tour.aspx

Session 1 - Ready, Set, Go! | Silverlight presentation
This first session sets the scene for the day and kicks off with a quick look at the mobile developer landscape. Among other things, we will see what resources are available to the device programmer and how the pieces fit within the bigger Windows desktop and server platforms. A key piece is an overview of the recently released Windows Mobile 6 operating system. The session wraps up with a look at and demos of the brand new Visual Studio 2008 development environment which promises even better integration and powerful new features for device developers.

Session 2 - Windows Mobile in Practice | Silverlight presentation
Features are great but we live in the real world. This session takes a realistic scenario and shows how Windows Mobile 6 and the upcoming .NET Compact Framework 3.5 can be leveraged to provide a compelling Proof-of-Concept in very few lines of code. See a wide variety of features being demonstrated, from location awareness to making phone calls programmatically. The session will provide an understanding of how everything can be tied together in an end-to-end solution.

Session 3 - It's the Business | Silverlight presentation
Enterprise solutions are increasingly being mobilized for the new technically-savvy workforce. However, these solutions need industry-strength quality and features that will support the complex requirements these organizations have. This session will begin by looking at SQL Server Compact Edition, the sophisticated data storage solution that allows data synchronization with back-end databases. We then show how you can leverage industry design patterns and application blocks to provide a lower-risk, tested approach to solve common problems. Finally, a quick review of the Microsoft Dynamics mobile offerings will round off the options available for enterprise use.

EMEA Windows Mobile Tour

Salva Patuel — Sun, 24 Feb 2008 21:24:00 GMT

Thanks everybody for attending to my sessions at the EMEA Windows Mobile Tour, I hope you have enjoyed the sessions.

As promised, find here the decks and the demos that I have presented:

· Applications block 1

· Applications block 2

· Applications block 3

You can find a word documents on Demos to help you set up the demos, feel free to contact me if you have trouble with them.

For Microsoft Patterns & practices please click here . For codeplex mobile projects please go here

If you are looking for mobile images for the emulator using 6.1 check here

Please feel free to leave feedback about the sessions and suggestions about what we can include on future ones.