How can I handle exceptions in my code?

Very few developers get exception handling right the first time. It’s all too common to find code like this:

try
{
   // do something that may cause an error
}
catch (Exception ex)
{
   // handle any exception here
}

This is rarely the correct strategy. There are some circumstances in which you may need to catch every exception, but you should avoid doing so whenever possible.

Solution
Here are some guidelines that I’ve found useful when dealing with exceptions in my own code:

The golden rule of exception handling: unless you have a good reason to catch an exception, don’t!
It’s okay to catch exceptions in exceptional conditions. Exceptions are supposed to be exceptional, as the dictionary definition for the word (uncommon, unusual) indicates. When in doubt, let the calling routine—or the global exception handler—deal with the problem. The exceptions that are the most difficult to troubleshoot are those that don’t exist, because a developer upstream from you decided it was a good idea to consume the exception, leaving you with nothing but a broken application and no visible symptoms. Once you’ve had to troubleshoot one of these monsters, you’ll vow to never catch exceptions blindly again. So, always remember: when in doubt, do not catch any exceptions.
Catch the exception if you can correct the problem that it implies.
For example, if you try to write to a file that’s marked as read-only, try removing the read-only flag from the file. In this case, you’d handle the exception and fix the problem, so you should eat the exception. It doesn’t exist, because you fixed it.

Catch the exception if you can provide additional information to the user.
For example, if your application fails to connect via HTTP to a remote web site, you could provide details about why the connection failed. Was the DNS invalid? Did it time out? Was the connection closed? Did the site return 401 Unauthorized, which implies that credentials are needed? In these cases you want to catch the exception, and re-throw it as an inner exception with more information. This is a very good reason to catch an exception, but note that we are still re-throwing it.

Catch specific exceptions, but let the rest pass through.
Avoid catching System.Exceptionwhenever possible; try to catch only the errors that are specific to a given block of code, and let the truly unusual rest become unhandled exceptions.

Of course, there will be times when you’ll want to bend these rules for completely legitimate reasons—but at least consider the rules before you break them!

Also, if you need to re-throw an exception, be careful how you do it. Always re-throw the exception using the throw keyword with no parameters, like so:

try
{
  command.Execute();
  TransactionManager.Commit();
}
catch(Exception exception)
{
  TransactionManager.Rollback();
  throw;
}

Remember that the stack trace is created at the time you throw the exception, so using the throw keyword on its own like this (rather than using throw exception) preserves the stack trace of the original exception.

How can I handle errors in my web site?

This is one of the first questions you should think about when you set out to develop a web application. ASP.NET doesn’t provide you with a global exception handling strategy out of the box. Fortunately, it does provide several different approaches for handling global exceptions in code. Each approach comes with its own advantages and disadvantages.

Solutions
The three options you can use to handle exceptions are:
? using the built-in health monitoring support
? setting exception handling settings in a global.asax and in the Web.config file
? using the HttpModule class

Let’s look at each in turn.

Handling Exceptions Via Health Monitoring

One of the easiest ways to implement a global exception handler is to use the built-in ASP.NET health monitoring support.

Check the Event Log

In the absence of any other unhandled exception strategy, ASP.NET 2.0 does in fact log unhandled exceptions to the event log. It’s not my favorite place to dig around for errors, but it’s better than nothing.

To enable automatic email notifications of unhandled exceptions via health monitoring, simply add this section to your Web.config file

Web.config

<healthMonitoring enabled="true">
<providers>
<add name="MailProvider"
type="System.Web.Management.SimpleMailWebEventProvider"
from="webserver@example.com"
to="you@example.com"
subjectPrefix="Unhandled Exception: "
bufferMode="Critical Notification"
/>
</providers>
<rules>
<remove name="All Errors Default"/>
<remove name="Failure Audits Default"/>
<add name="All Errors Default"
eventName="All Errors"
provider="MailProvider"
/>
</rules>
</healthMonitoring>

For this code to work, you’ll also need to set up System.Net.Mail SMTP email support in your Web.config. Here’s a representative section that enables the most basic SMTP settings for a server named localhost:

Web.config

<system.net>
<mailSettings>
<smtp>
<network host="localhost" />
</smtp>
</mailSettings>
</system.net>

And that’s it! Now every unhandled exception will automatically generate an email that’s sent to you. The email, shown in Figure 13.1, is not a paragon of great formatting, but it gets the job done.

And that’s it! Now every unhandled exception will automatically generate an email that’s sent to you. The email, shown in Figure 13.1, is not a paragon of great formatting, but it gets the job done.
Of course, ASP.NET doesn’t limit you to using email notifications—you can use any of the built-in health monitoring event providers to direct your exception information to one or more of the following providers:
?
EventLogWebEventProvider: This class writes events to the window’s event log for posterity. Writing exceptions to this class is enabled by default.
?
SqlWebEventProvider: This class writes events to your application’s database.
?
WmiWebEventProvider: This class publishes events to the Windows Management Instrumentation. Other applications can consume these WMI events in order to alert system administrators that an exception has occurred.
?
SimpleMailWebEventProvider: This class sends an email (for example, to a system administrator) in response to application health events.

? TraceWebEventProvider: This class publishes events to the System.Diagnostics.Trace object. This data can then be collected by a TraceListener for debugging purposes.
Conspicuously absent from that list is any sort of disk or file destination. You could write your own provider, but that defeats the no-code advantage of the health monitoring solution. Luckily, armed with the providers in the above list, we have several good alternatives to writing to a file. The official MSDN documentation for contains more information about these and other related classes.

Specifying Exception Handling in the global.asax and Web.config Files

The conventional way that you should implement a global exception handler is through global.asax and Web.config.
If your project doesn’t contain a global.asax file, add one by accessing the Add New Item menu and selecting Global Application Class. Then locate the Application_Error method in this file and modify it to capture the error:

void Application_Error(object sender, EventArgs e)
{
Exception ex =
HttpContext.Current.Server.GetLastError();
if (ex != null)
{
ErrorHandler.HandleException(ex);
}
}

Next, create a new static class called ErrorHandler and add to it a new method called HandleException that deals with the exception:

public static class ErrorHandler
{
public static void HandleException(Exception ex)
{
if (ex == null)
return;
Exception exceptionLayer = null;
if (ex is HttpUnhandledException)
{
if (ex.InnerException != null)
exceptionLayer = ex.InnerException;
}
else
{
exceptionLayer = ex;
}
StringBuilder sb = new StringBuilder();
while (exceptionLayer != null)
{
sb.AppendLine(ex.ToString());sb.AppendLine("------------------------");
exceptionLayer = exceptionLayer.InnerException;
}
Log(sb.ToString());
}
}

The code is relatively straightforward. We make a point of discarding the outer HttpUnhandledException—it’s a standard wrapper that comes with every ASP.NET exception. We have to peel that layer away to get to the InnerException (and its InnerException, and so on) that contains the real error.
Notice that, at this point in the code, I haven’t populated the generic Log method, so the exception isn’t being passed anywhere just yet. You could easily write your own Log method to send the exception via email, log it to a file, and so forth. But rather than write a whole lot of extra code, you might want to save some time by handing the exception off to the open source Log4net logging framework, which we’ll cover in the section called “What’s the best way to write a log file?” later in this chapter.

So we’ve satisfied our professional obligations as programmers, but what about those poor old users? It’s bad form to let them see the Yellow Screen of Death shown in Figure 13.2.

If we’re going to the trouble of implementing a global exception handling strategy behind the scenes, we might as well go the final mile and implement a friendlier user interface for users who are unlucky enough to encounter an exception.

Implementing a custom error page is as simple as editing Web.config and adding a customErrors element within the system.web section that points to your custom file:

Web.config

<system.web>
<customErrors mode="On" defaultRedirect="~/Error.aspx">
</customErrors>
?
</system.web>

As you can see, in this case, doing the right thing by users is very easy. They’re already disappointed because your web site has crashed—don’t make matters worse by scaring them with the awful default ASP.NET error page.

Handling Errors Via HttpModule

There’s nothing wrong with the methods we’ve discussed so far, but by far the most flexible way to implement global exception handling is to use the HttpModuleclass.
First, let’s create a class library project containing a new HttpModule:

public class ExceptionHandlingModule : IHttpModule
{
public void Init(System.Web.HttpApplication app)
{
app.Error += new EventHandler(OnError);
}
private void OnError(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
ErrorHandler.HandleException(app.Server.GetLastError());
}
public void Dispose()
{
// Nothing to Dispose() }
}

Clean Up After Yourself!
It’ s not relevant in this example, but it’s worth mentioning: if you’re planning to present a custom interface to the user via code that utilizes the Response.Write method or something similar, you must clear the existing error before continuing. The following line of code will take care of that:

app.Server.ClearError();

Compile that class library, and add a reference to it from your web project or web site. Then edit Web.config as follows to reference our brand new HttpModule:

<httpModules>
<add type="ExceptionHandlingModule,
ExceptionLibrary"
name="ErrorHandler" />
</httpModules>

The big advantage of this approach is that it doesn’t require you to make any code changes in the web site that uses it.
The compiled HttpModule, along with the error handling logic, can be delivered in a single DLL file. Simply add that file to the web site path, then modify Web.config, and you have a perfectly portable and reusable global exception handling strategy to use across all of your web sites.

How can I use a pre-built exception handling strategy?

The exception handling strategies we explored earlier all require some coding on our part to deliver a complete solution. Luckily, there’s a pre-built global exception handler that we can employ to avoid doing all that extra work—it even uses the flexible HttpModule model.

For a robust, global exception handling strategy that you can easily plug into a web site, look no further than the ELMAH (Error Logging Modules And Handlers) solution.2
Add a reference to the ELMAH binary in your web site or web application project. To enable ELMAH, edit your Web.config file and add a custom configuration section that instructs ELMAH on how we want it to handle errors

ELMAH supports a number of logging configurations, including the use of a SQL Server database, a MySQL database, and an XML file, but for this example we’re going to use the in-memory database. We’ll also want an email to be sent asynchronously when an error occurs.

Since we’re sending mail, we’ll need to add the SMTP configuration block for System.Net.Mail to our Web.config file

Once this code is in place, fire up your web site and trigger an exception. I often find it useful to include a hidden method for generating an exception on any deployed web site, so I can periodically check and make sure the global exception handling is working properly.

Although ELMAH doesn’t provide an interface for the unfortunate user who’s experiencing the exception, it does provide an excellent web interface for developers to view exceptions. Simply browse to http://localhost:nnnnn/elmah/default.aspx (where localhost and nnnnn are replaced by your server and port number, respectively). From here you can browse through all the exceptions that have occurred in your web application

The interface lets you view details for each individual error. You can also subscribe to the RSS feed for this page, so that you can monitor your site’s errors in the RSS feed reader of your choice.
Since we opted to use the in-memory logger, rather than a more permanent one, we can only view exceptions that have occurred since our application was last started. But this is usually enough for troubleshooting purposes, as we always have the exception email to fall back on.

What’s the best way to write a log file?

One of the most popular solutions for logging debug information and exceptions is the log4net framework.3 This open source logging framework is part of the popular log4j Java logging framework, yet, despite its popularity, many developers still struggle to get log4net to work properly within the context of an ASP.NET web site.
In this solution, I’ll step you through the task of setting up the log4net framework. We’ll use the best-practice technique of creating a separate configuration file, rather than dumping the log4net settings into Web.config.

Solution
First, add the log4net.dll reference to your web application or web site project.

With this file in place, we need to set up a log4net configuration file. While it would be possible to specify the log4net settings in Web.config, this is not the most desirable place to locate these settings. Any update to Web.config causes the AppDomain to recycle, which causes a performance hit as the sessions are dropped, cache is cleared, and pages are recompiled. So even a small change to a log4net setting would effectively restart the entire web site.

However, if we put our settings in a separate log4net configuration file, log4net will attach a FileSystemWatcher to that file and reload the logging settings any time that file changes, without reloading the AppDomain.

While this is a matter of preference, I like to put my log4net settings in a file named log4net.config

This sets up a RollingLogFileAppenderto receive logging messages. As you might have guessed by the name, the RollingLogFileAppender logs messages to a file, rolling over to a new file every day, week or month, depending on your settings. For a more in-depth understanding of these settings, refer to the configuration section of the log4net manual.4

Now we need to tell log4net where its configuration file is located. We can do this in two ways. For Web Application projects, you can use an XmlConfiguratorattribute within AssemblyInfo.cs

Exception and Error Handling

When an exception occurs in your ASP.NET application code, you can handle it in a number of ways, but the best approach is a multi-pronged one:
? Catch what you expect:
? Use a Try/Catch around error-prone code. This can always catch specific exceptions that you can deal with, such as System.IO.FileNotFoundException

? Rather than catching exceptions around specific chunks of code at the page level, consider using the page-level error handler to catch specific exceptions that might happen anywhere on the page.

? But prepare for unhandled exceptions:
? Set the Page.Error property if a specific page should show a specific error page for any unhandled exception. This can also be done using the <%@ Page > directive or the code behind the property.
? Have default error pages for 400 and 500 errors set in your web.config.
? Have a boilerplate Application_OnError handler that takes into consideration both specific exceptions that you can do something about, as well as all unhandled exceptions that you may want logged to either the event log, a text file, or other instrumentation mechanism.

The phrase unhandled exception may be alarming, but remember that you don’t do anyone any good catching an exception that you can’t recover from. Unhandled exceptions are okay if they are just that — exceptional. For these situations, rely on global exception handlers for logging and friendly error pages that you can present to the user.

Why try to catch an exception by adding code everywhere if you can catch and log exceptions all in one place? A common mistake is creating a try/catch block around some arbitrary code and catching the least specific exception type — System. Exception. A rule of thumb is, don’t catch any exception that you can’t do anything about. Just because an exception can be thrown by a particular method doesn’t mean you have to catch it. It’s exceptional, remember? Also, there are exception handlers at both the page and the application level. Catch exceptions in these two centralized locations rather than all over.

Handling Exceptions on a Page

To handle exceptions at a page level, override the OnError method that System.Web.UI.Page inherits from the TemplateControl class (see Listing 24-5). Calling Server.GetLastError gives you access to the exception that just occurred. Be aware that a chain of exceptions may have occurred, and you can use the ExceptionGetBaseException method to return the root exception.

Page-level error handling

protected override void OnError(EventArgs e)
{
  System.Exception anError = Server.GetLastError();
  if (anError.GetBaseException() is SomeSpecificException)
  {
       Response.Write("Something bad happened!");
       Response.StatusCode = 200;
       Server.ClearError();
       Response.End();
   }
}

Handling Application Exceptions

The technique of catching exceptions in a centralized location can be applied to error handling at the application level in Global.asax, as shown in Listing 24-6. If an exception is not caught on the page, the web.config is checked for an alternate error page; if there isn’t one, the exception bubbles up to the application and your user sees a complete call stack.

Application-level error handling

protected void Application_Error(Object sender, EventArgs e)
{
     System.Exception bigError = Server.GetLastError();
     //Example checking for HttpRequestValidationException
     if(bigError.GetBaseException() is HttpRequestValidationException )
     {
                    System.Diagnostics.Trace.WriteLine(bigError.ToString());
                    Server.ClearError();
      }
}

Unhandled application errors turn into HTTP Status Code 500 and display errors in the browser. These errors, including the complete callstack and other technical details, may be useful during development, but are hardly useful at production time. Most often, you want to create an error handler (as shown previously) to log your error and to give the user a friendlier page to view.

If you ever find yourself trying to catch exceptions of type System.Exception, take a look at the code to see whether you can avoid it. There’s almost never a reason to catch such a non-specific exception, and you’re more likely to swallow exceptions that can provide valuable debugging. Check the API documentation for the framework method you are calling — a section specifically lists what exceptions an API call might throw. Never rely on an exception occurring to get a standard code path to work.

Http Status Codes

Every HttpRequest results in an HttpResponse, and every HttpResponse includes a status code. The following table describes 11 particularly interesting HTTP status codes.

Status Code Explanation

200 OK Everything went well.
301 Moved Permanently
Reminds the caller to use a new, permanent URL rather than the one he used to get here.
302 Found Returned during a Response.Redirect. This is the way to say ‘‘No, no, look over here right now.’’
304 Not Modified
Returned as the result of a conditional GET when a requested document hasn’t been modified. It is the basis of all browser-based caching. An HTTP message-body must not be returned when using a 304.
307 Temporary Redirect
Redirects calls to ASMX Web services to alternate URLs. Rarely used with ASP.NET.
400 Bad Request
Request was malformed.
401 Unauthorized
Request requires authentication from the user.
403 Forbidden Authentication has failed, indicating that the server understood the requests but cannot fulfill it.
404 Not Found The server has not found an appropriate file or handler to handle this request. The implication is that this may be a temporary state. This happens in ASP.NET not only because a file cannot be found, but also because it may be inappropriately mapped to an IHttpHandler that was not available to service the request.
410 Gone The equivalent of a permanent 404 indicating to the client that it should delete any references to this link if possible. 404s usually indicate that the server does not know whether the condition is permanent.

500 Internal Server Error
The official text for this error is ‘‘The server encountered an unexpected condition which prevented it from fulfilling the request,’’ but this error can occur when any unhandled exception bubbles all the way up to the user from ASP.NET.

Any status code greater than or equal to 400 is considered an error and, unless you configure otherwise, the user will likely see an unfriendly message in his browser. If you have not already handled these errors inside of the ASP.NET runtime by checking their exception types, or if the error occurred outside of ASP.NET and you want to show the user a friendly message, you can assign pages to any status code within web.config, as the following example shows:

<customErrors mode ="On" >
     <error statusCode ="500" redirect ="FriendlyMassiveError.aspx" />
</customErrors>

After making a change to the customer errors section of your web.config, make sure a page is available to be shown to the user. A classic mistake in error redirection is redirecting the user to a page that will cause an error, thereby getting him stuck in a loop. Use a great deal of care if you have complicated headers or footers in your application that might cause an error if they appear on an error page. Avoid hitting the database or performing any other backend operation that requires either user authorization or that the user’s session be in any specific state. In other words, make sure that the error page is a reliable standalone.

Any status code greater than or equal to 400 increments the ASP.NET Requests Failed performance counter. 401 increments Requests Failed and Requests Not Authorized. 404 and 414 increment both Requests Failed and Requests Not Found. Requests that result in a 500 status code increment Requests Failed and Requests Timed Out. If you’re going to return status codes, you must realize their effects and their implications.

The following are some critical-thinking questions that architects should think about before getting into architecture description:

• What is the scope of the architecture?
• Who are the intended audiences for the architecture description?
• What architecture style should be used for architecture description?
• What approaches and methodologies should be adopted?
• Are there any helpful tools?

· A validated architecture does not guarantee the quality of the resulting system. How can downstream design decisions undermine the architecture’s ability to meet its quality objectives?

· How can the introduction of evaluations help your organization adopt a standard method of architectural description?

• Why are you doing an estimate?
• Do you know the relative levels of effort of project phases and tasks in your organization?
• What factors do you have available?
• Do your organization’s time- and expense-tracking numbers feed back into your estimation mechanisms?
• After you have built an estimate, can you explain where your numbers come from?

• What are the sources and sizes of document sets and streams to be analyzed? How large is the topic space or knowledge schema? How dynamic is it?
• Will there be any formal knowledge-representation or document-organization schemes? Will these be homegrown and stored in the database? Will more formal knowledge-representation schemes be considered? What repository will store derived information?
• Are there experts who will read, validate, refine, and calibrate various intelligence-gathering and inference processes over time? Are these experts threatened by the use of an automated system?
• Should the system process be primarily automatic and self-sustaining? If not, will responsibility be centralized or distributed?
• Will the end results of your queries be knowledge about the states of documents (term frequency and trends, regular expression conformance, term proximity and co-occurrence counts, vector-representations of author keywords, and so on)? Alternately, will the end results be concerned with the inferred probabilistic states of the world, as inferred from the documents (the likelihood that a given off-label usage will result in injury or penalty to Contoso)?
• Which is desired: a point solution or a more general infrastructure? What is a realistic end goal by which to define project success?

· In what parts of your architecture do you employ asynchronous communication? Why? If not, why not?

· Do you treat distribution boundaries different from logical boundaries, in your architecture? If so, in what way are they different?

· How would you test the scalability of an architecture? When would be the earliest that you could perform such a test?

· When one is architecting solutions, why is it important to think about maintenance?

· How did “soft skills” affect the outcome of this story? Why are they important for an architect?

· Which elements of this story demonstrated the value of business, instead of technical knowledge? Which characters held this knowledge?

To benefit fully from leveraging software architectural and design patterns, an architect must always try to answer the following questions:

· What is the problem that I am trying to solve?
Understand conceptually the problem that the solution is intended to solve. Software architecture begins at the conceptual level, and it is imperative that architects have an understanding of the big picture. The ability to articulate the solution succinctly in nontechnical terms is a good indication that the problem space is understood.

· How has this problem been solved in the past?
In any software solution, there is a good chance that a similar problem has been solved in the past. Research how this problem has been solved, and leverage the design to solve the new problem.

· How might the solution be extended in the future?
The intent of many patterns is to provide a level of extendibility for a solution. If the solution’s requirements for extendibility are understood, it might be beneficial to leverage those patterns early on in the design.

User Experience

· Remember: There is always a UE. What can you do to make it positive?

· Are you following the UI standards? Should you follow the standards?

· Is there a way to increase the system’s responsiveness?

· What are your users’ key tasks? How easy is it to perform them? How can you make it easier?

· What operational requirements does a service directory satisfy?

· Should JMS services have WSDL definitions? If so, why?

· What is the difference between orchestration and choreography?

· When you are choreographing services, will you need to add transaction semantics (for example, rollback)?

· Where are your developers resorting to copy-paste reuse?

· How much better is the code from the top 20 percent of your developers than from the bottom 40 percent?

· How much time is spent on problems stemming from poor communication between domain experts and developers?

• Why is it important to understand different architecture styles?
• Would a pipe-and-filter style be better for an online-transaction processing (OLTP) or a warehouse application? Why?
• What is meant by synchronous and asynchronous topologies?

· Is there any difference between an Enterprise Service Bus and an Enterprise Message Bus?

· Are there any real issues in today’s hub-and-spoke integration architecture? If we were to replace the architecture with an ESB, how much of these issues would be solved?

· Can we buy an ESB from some market one fine morning that can then straightaway solve all our integration headaches?

· Bakker, Loek. “Goodbye Hub-and-Spoke, Hello ESB? Integration Architecture with BizTalk 2004.” .NET Developer’s Journal. September 12, 2005.(Accessed January 24, 2007.)

· Fielding, Roy Thomas. “Architectural Styles and the Design of Network-Based Software Architectures.” Dissertation (Ph.D.), University of California, Irvine. 2000. (Accessed January 24, 2007.)

· Gavin, Lee, et al. “An EAI Solution Using WebSphere Business Integration (V4.1).” IBM Redbooks. July 28, 2003. (Accessed January 24, 2007.)

· Keen, Martin, et al. “Patterns: Implementing an SOA Using an Enterprise Service Bus.” IBM Redbooks. July 25, 2004. (Accessed January 24, 2007.)

· Keen, Martin, et al. “Patterns: SOA with an Enterprise Service Bus in WebSphere Application Server V6.” IBM Redbooks. June 6, 2005. (Accessed January 24, 2007.)

· Martinez,Frank. “Reliable Messaging in a Services Network.” Enterprise Architect Web site. June 2, 2005. (Accessed January 24, 2007.)

· “Microsoft BizTalk Server 2006: Business Process Management (BPM).”Microsoft BizTalk Web site. 2007. (Accessed January 24, 2007.)

· “Mule: Open-Source ESB and Integration Platform.” Mule Web site. 2007. (Accessed January 24, 2007.)

· “Patterns and Best Practices for Enterprise Integration.” Enterprise Integration Patterns Web site. 2007. (Accessed January 24, 2007.)

· “Service-Oriented Business Integration.” Java Technology and Business Integration Web site. 2007. (Accessed January 24, 2007.)

· Van de Putte, Geert, et al. “Using Web Services for Business Integration.” IBM Redbooks. April 14, 2004. (Accessed January 24, 2007.)

• “An Introduction To Domain-Driven Design” at http://msdn.microsoft.com/en-us/magazine/dd419654.aspx.
• “Domain Driven Design and Development in Practice” at http://www.infoq.com/articles/ddd-in-practice.
• “Fear Those Tiers” at http://msdn.microsoft.com/en-us/library/cc168629.aspx.
• “Layered Versus Client-Server” at http://msdn.microsoft.com/en-us/library/bb421529.aspx.
• “Message Bus” at http://msdn.microsoft.com/en-us/library/ms978583.aspx.
• “Microsoft Enterprise Service Bus (ESB) Guidance” at http://www.microsoft.com/biztalk/en/us/esb-guidance.aspx.
• “Separated Presentation” at http://martinfowler.com/eaaDev/SeparatedPresentation.html.
• “Services Fabric: Fine Fabrics for New-Era Systems” at http://msdn.microsoft.com/en-us/library/cc168621.aspx.

Resulting Context

Using a gateway to provide a single point of access to an external resource has the following benefits and liabilities:

Benefits

• Reduced coupling. The gateway encapsulates access to the external resource. Applications that use the resource no longer require information about how to access that external resource.
• Reduced application complexity. Individual applications do not have to implement the communication protocols required to communicate with the external resource. In addition, the gateway can implement some of the error handling that each application would otherwise have to perform.
• Improved integrability. The gateway provides a single point of access for the external resource. This facilitates integration with external resources such as an Enterprise Resource Planning (ERP) system, a Customer Relationship Management (CRM) system, or another similar system.
• Improved security. A single point of access represents a single point of control. You can use this single point of access to implement security policies and to bridge between different security realms. It also allows you to meter access to the external resource and to implement business rules that control access.
• Improved performance through optimization. The gateway provides a logical place to optimize the communication protocol for use with the external resource. Optimization might include batching similar requests or caching results.

Liabilities

• Reduced performance through overhead. The gateway replaces direct communication, adding an intermediate layer. This translates into increased latency compared to direct communication.
• Increased maintainability effort. A gateway extends your integration solution with another component. This translates into additional implementation, configuration, testing, deployment, and management work.
• Dependency of the gateway interface. Designing the gateway requires foresight about the interactions between the applications and the external resource. If you have to change the gateway’s interface in a way that breaks compatibility, you have to change all the applications that access it.
• Reduced availability. All access to the external resource passes through the gateway. From an availability perspective, the gateway represents a single point of failure.

Testing Considerations

Using a gateway improves testability on both sides in the following ways:

• Applications access the external resource solely through the gateway. A mock gateway can receive messages, return predefined responses, and exercise error handling logic. In other words, you can test the system without accessing the external resource.
• Because the external resource receives requests from the gateway, you can test the gateway by relaying requests to the external resource independent of the applications.

Security Considerations

Accessing an external resource through a gateway has the following security implications:

• A single point of access facilitates enforcement of a uniform security policy. However, it also represents a central point of attack.
• A gateway allows bridging between different security realms. For example, a gateway can mix different security context management policies, such as impersonation on one side and consolidation on the other. However, the gateway only provides a place where the mapping between the two can be handled. You must implement the mapping separately.

Operational Considerations

A gateway represents a single point of access and may cause contention among the applications that communicate with the external resource. You should monitor access to the external resource and act proactively when the first signs of contention appear. This single point of access also helps you to meter access to the external resource, to monitor the external resource, and to audit the external resource.

Related Patterns

The Gateway pattern described here relates to the following patterns:

• Implementing Gateway with Host Integration Server 2004 This pattern uses the Global Bank scenario to show how you can use Host Integration Server 2004 to implement Gateway.
• Gateway [Fowler03]. Martin Fowler discusses Gateway in the context of enterprise applications. He also covers the relationship with Façade and Adapter [Gamma95]. Fowler’s Gateway is fine-grained at the object level. However, in the context of integration, Gateway is coarse-grained at the platform level.
• Messaging Gateway [Hohpe04]. Messaging Gateway wraps message-specific method calls, exposes domain-specific methods, and encapsulates access to the messaging system. Hohpe and Woolf also explain how to create composite gateways by using gateway chaining. A composite gateway permits you to use a gateway that encapsulates a single aspect together with other gateways to deal with several aspects.
• Remote Proxy [Buschmann96].Gateway can be regarded as a refinement of the Remote Proxy pattern. Remote Proxy deals with distributed components in the general sense and provides the interprocess communication (IPC) mechanisms for communication with remote objects. Gateway is designed for integration solutions and therefore assumes that the integration infrastructure is available.
• Service Interface [Trowbridge03]. Service Interface exposes functionality as a service and provides an entry point for inbound requests. In effect, the control flows in the opposite direction compared to Gateway.

Resulting Context

The Gateway implementation described here results in the following benefits and liabilities:

Benefits

• Reduced complexity. The gateway encapsulates data and protocol translations required to use the account management system.
• Reduced redevelopment efforts. Business logic that already exists on the mainframe transactions does not have to be redeveloped in the .NET Framework environment.
• Reduced need for retraining. .NET Framework developers do not have to become familiar with CICS or COBOL to use the existing mainframe transactions.

Liabilities

• Increased maintenance effort. Host Integration Server 2004 is an additional system that must be maintained.
• Lack of support for two-phase commit transactions when using .NET Framework client libraries. The .NET Framework client library used in this scenario does not support two-phase commit transactions. Many organizations rely on two-phase commit transactions for day-to-day operations, so this configuration may not suit them. Instead, they would have to use a COM type library that does support two-phase commit transactions.

Tests

To fully test the deployment of TI in this scenario, you must have access to a mainframe computer that is running the proper CICS transactions. However, you can use the TI host-initiated processing capabilities to simulate this access. For instructions on how to configure this simulation, see the Host Integration Server 2004 online documentation at http://www.microsoft.com/biztalk/en/us/host-integration.aspx.

List of Patterns and Pattlets

Reporting is repeatedly identified as the highest BI requirement. However, it’s important to remember that different categories of business users have distinct reporting needs:
• Managed reporting is needed to distribute prebuilt reports across an organization on a daily, weekly or monthly basis, often providing flexible prompting so users can run variations of reports themselves without the need to recreate the reports.
• Ad-hoc reporting is a critical aspect of enabling end-user self service, giving business users instant access and interactivity with information to create their own ad-hoc reports. This type of reporting must be simple to use, with a dragand-drop interface, and information must be presented in the context they
understand.
• Analytical reporting allows business users to slice and dice information so they can easily understand the “why” behind critical issues, trends, and opportunities, with the ability to drill down further for detailed information.
• Dashboards help measure business performance and quickly communicate complex information to business users in compelling visual formats, so they have a clear picture of how the business is doing.
• Production reports provide high-quality detailed information such as invoices or statements, and these reports are highly formatted.
• Operational or transactional reports typically have detailed information from transactional systems, so ensuring secure and controlled data access is key.

Midsize organizations rarely have just one data source. As applications are purchased and deployed, the sources and formats of data grow exponentially.
Data may come from transactional systems, enterprise resource planning (ERP) solutions, data warehouses, old legacy systems, or from online analytical processing (OLAP) sources. Data needs to be accessed from multiple sources, even when you have a data warehouse, to address all the information needs and requests from business users.

Let’s go back for a moment to the three questions that drive performance:

“How are we doing?”

“Why?”

“What should we be doing?”

Answering these key questions requires multiple integrated capabilities.

If you happened to be searching for “pizza” on Twitter Search yesterday or are following the @mswindows Twitter account, chances are you witnessed the kickoff of #WinWin7. The Windows Outreach Team kicked off 7 weeks of Windows 7 by sending 7 piping-hot pizzas to 7 lucky Twitter followers.

And it won’t stop there.

Throughout the next 7 weeks, @mswindows will be giving away prizes all based on the number 7 (for Windows 7). Winners must take part in the challenges and are encouraged to invite friends to join in on the fun which all culminates on launch day - October 22nd.

Make sure you’re following @mswindows and tell them Brandon sent you. Oh and watch for the official #WinWin7 hash tag too.

Speaking of the Windows Outreach Team, how about meeting the supporting cast? You may have seen them on some of your favorite blogs and forums and didn’t really know who they were. Let’s change that.

Jeff D, Cody G and Ron S, are a savvy team tasked with reaching out to users and creating a real resource within the communities on the Web.

Along with Josh T on the @mswindows account, these team members bring a wealth of knowledge (both consumer and even a bit on the “techy” side) to the table. Anywhere from gaming to watching your media across your home network, these guys have been there and tried out the fixes and know what works and what doesn’t. You can bet on them to offer advice and an open ear, not a sales pitch and a bottom line – oddly enough, none of them wanted to be a snake oil salesman growing up.

So, keep a lookout for the team on some of your favorite blogs and forums and feel free to say “hi” or just ask a question. They’ll be sure to help get you on the track to whatever it is you need.

If you have any questions for the Windows Outreach Team, just send a tweet to @mswindows. Or leave a comment here too of course.

NOTE: The Windows Outreach Team also runs the Windows Live Twitter account @windowslive too.

If you haven’t already, you need to check out this very amusing video put together by the Internet Explorer Team on the History of the Web. Check it out!