Applied Architecture Patterns on the Microsoft Platform

By Richard Seroter, Ewan Fairweather, Rama Ramani and 2 more

In Detail

Every day, architects and developers are asked to solve specific business problems in the most efficient way possible using a broad range of technologies. Packed with real-world examples of how to use the latest Microsoft technologies, this book tackles over a dozen specific use case patterns and provides an applied implementation with supporting code downloads for every chapter.

In this book, we guide you through thirteen architectural patterns and provide detailed code samples for the following technologies: Windows Server AppFabric, Windows Azure Platform AppFabric, SQL Server (including Integration Services, Service Broker, and StreamInsight), BizTalk Server, Windows Communication Foundation (WCF), and Windows Workflow Foundation (WF). This book brings together - and simplifies - the information and methodology you need to make the right architectural decisions and use a broad range of the Microsoft platform to meet your requirements. Throughout the book, we will follow a consistent architectural decision framework which considers key business, organizational, and technology factors.

The book is broken up into four sections. First, we define the techniques and methodologies used to make architectural decisions throughout the book. In Part I, we provide a set of primers designed to get you up to speed with each of the technologies demonstrated in the book. Part II looks at messaging patterns and includes use cases which highlight content-based routing, workflow, publish/subscribe, and distributed messaging. Part III digs into data processing patterns and looks at bulk data processing, complex events, multi-master synchronization, and more. Finally, Part IV covers performance-related patterns including low latency, failover to the cloud, and reference data caching.

Expert assessment and implementation guidance across 13 Enterprise scenarios

Approach

The book consists of a set of business scenarios and corresponding solution critiques. Each "use case" chapter is made up of a problem description, assessment of implementation options, and the selection of the ideal solution candidate. We then construct the solution using the chosen Microsoft technology.

Who this book is for

This book is for architects, developers, and managers who need to improve their knowledge of the Microsoft application platform. This book will appeal to anyone who wants to get up to speed on selecting the most appropriate platform for a particular problem. Consultants and executive leadership will also find significant value in this book. A good understanding of the general Windows platform and development technologies would be helpful.

• Language: English
• Publisher: Packt Publishing
• Release date: Sep 7, 2010
• ISBN: 9781849680554

Richard Seroter

Richard Seroter is a solutions architect for an industry-leading biotechnology company, a Microsoft MVP for BizTalk Server, and a Microsoft Connected Systems Advisor. He has spent the majority of his career consulting with customers as they planned and implemented their enterprise software solutions. Richard worked first for two global IT consulting firms, which gave him exposure to a diverse range of industries, technologies, and business challenges. Richard then joined Microsoft as a SOA/BPM technology specialist where his sole objective was to educate and collaborate with customers as they considered, designed, and architected BizTalk solutions. One of those customers liked him enough to bring him onboard full time as an architect after they committed to using BizTalk Server as their enterprise service bus. Once the BizTalk environment was successfully established, Richard transitioned into a solutions architect role where he now helps identify enterprise best practices and applies good architectural principles to a wide set of IT initiatives. Richard maintains a semi-popular blog of his exploits, pitfalls, and musings with BizTalk Server and enterprise architecture at http://seroter.wordpress.com. The authors have provided a website with further information about the book here: http://appliedarchitecturepatterns.com/

Book preview

it.

Chapter 1. Solution Decision Framework

Decisions, decisions, decisions. Each and every day, architects and developers make choices, which range from where to store configuration data to whether their solution calls for real-time messaging or batch processing. Each selection brings with it a host of side effects that impact the solution's maintainability, security, performance, speed of development, and more.

Two significant aspects of any architecture decision are: what should be done and how should you do it. The focus of this chapter is to provide advice on the latter by outlining a thought process for making sound decisions. Do you need to deploy your servers globally or in one location? Should the solution employ an asynchronous communication pattern for data processing? These are just examples of solution aspects that result from an architectural analysis of the requirements. This chapter contains a framework to help you determine which architecture quality attributes you should evaluate for your solution. We will leverage this framework in subsequent chapters as we evaluate business problems and choose the Microsoft technology that best matches the requirements of the solution.

In this chapter you will learn the following:

The value of having a consistent, reusable decision framework

Where to find the input information for your decisions

How to organize your architectural assessment of the requirements

The need for a decision framework

There is no substitute for the hands-on experience of designing and building software solutions. The key is how you take what you have learned in each situation and apply these principles and lessons to subsequent projects. Recording and maturing a reusable set of decision criteria goes a long way towards establishing personal confidence in our architectural decisions. Each project should not be a blank slate. Rather, we should be leveraging our experiences and the experiences of others and reuse them so that we can surface key issues, prioritize our feature set, and establish which trade-offs we will need to make early on. While we cannot know every detail or requirement before starting to craft a solution, we must still make critical decisions that have significant impact on the direction of the solution architecture. This is all the more a reason to make consistent, well thought-out decisions.

There is nothing magical about a decision framework. In our case, the recommendation is to do the following:

Gather all the facts that you can. See the next section (Sources of Input to the Framework) for ideas on where to obtain the data points necessary to make informed decisions.

Look for the hard architectural decisions. What is the big picture? What are the critical aspects that we need to tackle right away? An example of this is determining whether or not your strategy is to copy data between systems, do real-time lookups, or leverage a shared data source. Broad data-sharing patterns shape how you build your system and this is an example of a weighty decision that impacts how we lay out the rest of the solution.

Capture and evaluate alternatives. It has been said that if you only have one solution to a problem, then you are not thinking hard enough. Every significant decision point should have multiple possible alternatives that reflect the interests of the project or organization as a whole.

Weigh the strategic importance of feature requests. All desired solution capabilities are not created equal. If I work in an environment where we have limited in-house development resources and place a premium on system maintainability, then I will value products with standard support tools over products that have a more robust, but custom feature set. Amplify what the solution must do and avoid being distracted by nice to have capabilities.

The list of solution criteria we have in this chapter is by no means exhaustive. Instead, it is meant to provide a baseline for you to customize with your own experiences and organizational priorities. Following a framework strategy of gather information, inspect for impact, assess alternatives, and weigh importance will help you become successful regardless of how big or small your specific list of solution criteria is.

Sources of input to the framework

Where do we get the data points necessary to make informed architectural decisions? There are four key sources that will shape our understanding of the business problem: functional requirements, non-functional requirements, derived requirements, and organizational direction.

Functional requirements

The functional requirements of a solution dictate what the resulting system should be able to do and include scenarios that summarize the user's expected experience with the system. Functional requirements could address the type of data entities the system interacts with, how the system behaves when a user needs to invoke a particular calculation, or the order of steps to complete a business process. Functional requirements are typically gathered by a business analyst and are crucial in determining how a system should be architected. A software solution is worthless if it is architected beautifully but does not meet the business need. Staying focused on our client needs will ensure that we build a practical and architecturally responsible solution.

In order to ensure that our functional requirements help and do not hurt our effort to architect a solution, we must remain diligent and not allow system requirements to masquerade as business requirements. For instance, if we see a business requirement that says that customer profile information from System A should be copied via file transfer every night to System B, then that should raise a red flag. That business requirement is dictating system design and does not answer what the business need actually is. The proper business requirement would be The system shall enable users of System B to view up-to-date customer information originating from System A. As architects, we can choose multiple implementation solutions (for example: shared database, data transfer, real time lookups) that can both satisfy that requirement and fit into the overall design patterns we have laid out for the project. While there may be relevant reasons for technical requirements (for example, security constraints) to get included as functional requirements, often these technical requirements are better stated as non-functional