When thinking about a cloud migration (hybrid or otherwise) – a key rule is that you are guaranteed to have failures – at many aspects, and those cannot be exceptional conditions, but rather the normal design and expected behavior. As a result, you app/services/API/whatever needs to be designed for failure. And not only how your loosely couple your architecture to be able to handle these situations, but also, how the response isn’t a binary (yay, or a fancy 404 ); but rather a degraded experience, where your app/service/API/whatever still performs albeit in a deprecated mode.

Things that can throw one off, and is food for thought (not exhaustive, or on any particular order):

• Managing state (when failures is guaranteed)
• Latency – cloud is fast, but slower than your internal data center; you know – physics. :) How are your REST API’s handling latency, and are they degrading performance?
• “Chatiness” – how talkative, are your things on the wire? And how big is the payload?
• Rollback, or fall forward?
• Lossy transfers (if data structure sizes are large)
• DevOps – mashing up of Developers, and Operations (what some call SRE) – you own the stuff you build, and, responsible for it.
• AutoScale – most think this is to scale up, but it also means to scale down when resources are not needed.
• Physical deployments – Regional deployment vs. global ones – there isn’t a right or wrong answer, it frankly depends on the service and what you are trying to do. Personally, I would lean towards regional first.
• Production deployment strategies – various ways to skin a cat and no one is right or wrong per se (except, please don’t do a basic deployment) – that is suicide. I am use to A/B testing, but also what is now called Blue/Green deployment. Read up more here . And of course use some kind of a deployment window (that works for your business) – this allows you and your team to watch what is going on, and take corrective actions if required.
• Automate everything you can; yes its not free, but you recoup that investment pretty quick; and will still have hair on the scalp!
• Instrument – if you can’t measure it, you can’t fix it.

Again, not an exhaustive list, but rather meant to get one thinking. There are also some inherent assumptions – e.g. automation and production deployment suggests, there is some automated testing in place; and a CI/CD strategy and supporting tools.

Bottom line – when it comes to cloud (or any other distributed architecture), the best way to avoid failure is to fail constantly!

If you need uniqueness and non-deterministic, especially on the context of security or crypto then you need to think about a few things. For example the frequency, non-uniform distribution, and not using a pseudo random number generator (such as Mersenne twister ) and not a linear congruential generator .

I am interested to know what tools have you guys used? I want to use the tools to find the low hanging fruits and know off the 80% of things and then we manually look at the more interesting aspects, which the tools don’t (or can’t) pick up. Ideally, I would like this as an add-in to Visual Studio, which can run as part of a build and depending on how one configures it, can get to a gated check-in and/or work-items being created in TFS which then can be assigned and tracked. What I am thinking is to complement the likes of FxCop, the built-in Visual Studio tools. There was TeamReview which I had looked at some point in the past, but we never got it running successfully. I have not had a chance to see it since then. Someone has also attempted some of this via this , but it does not seem to go anywhere. Surely, there someone has already build this which we can look into?

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn’t change
6. There is only one administrator
7. Transport cost is zero
8. The network is homogeneous

CEP is generally used when we implement real-time systems (of course that is not the only area where CEP is used). Real-time does not mean concurrent or for that matter high-performing system.

Of course there are correlations, but at the same time they are fundamentally different paradigms.

This weekend, I am researching Optimisation Algorithms – both Deterministic and Probabilistic. Specifically interested in Swarm Intelligence (which are a type of Monte Carlo algorithm) and in that in Ant Colony and Particle Swarm routing are the main ones I am researching.

1. Part of the overall solution, some smart client is deployed and installed on the desktop and a web only approach is not possible. The main rational being that a smart client can work in a disconnected mode which of course with a web application is not possible.
2. Underlying infrastructure needs to be in place to support this. Infrastructure is not specifically networks and servers, but also both the operational environment and the user’s environment and machine. The operational environments need to allow things such as: data caching, local storage of user data, user profile details, etc.
3. More robust exception management process – this is not only about handling errors but also understanding the fact that the application is in a disconnected state and needs to do things differently.

When designing an occasionally connected application, there are two design approaches that one can take - data centric or service oriented.

1. Data Centric – Applications had a RDBMS of some sort installed locally and use the built-in capabilities of that RDBMS to propagate and sync data including resolving any conflicts.
   1. Server publishes data, which a client subscribes to and is copied locally. The conflict resolution (as changes can be both on the server or client) needs to be agreed upfront.
   2. Generally the database’s built-in conflict resolution is used – this makes it simpler for the application as one does not need to build this in the application.
   3. As there is only one data repository, the data convergence is guaranteed between the client and the server.
   4. Both the client and the server are tightly coupled.
   5. As a database needs to run locally, machines with small footprints or devices such as mobile phones will not be able to run this.
   6. If deployment is an issue then there is more work required here.
2. Service-Oriented – Applications use the SOA paradigm and store information in messages which are queued (when disconnected) and send to the server when connected for processing.
   1. The client can interact with any service required and focuses on the service requests instead of the local data i.e. are loosely coupled.
   2. No local RDBMS required; of course some state information would still need to be saved.
   3. Better when needs to interact outside of the firewall (e.g. Internet or Intranet)
   4. Deployment is still required, but is simpler.

For Data centric application, from a design perspective the following aspects should be factored in:

1. Application needs to be aware of the merge-replication schemes that are implemented as the application needs to optimise for data updates and conflicts.
2. As a result, ACID properties are not used for transactions; instead a pub-sub model is implemented.

On the other hand, for Service-oriented apps, the application design should address the following:

• Application has to implement asynchronous communication.
• Overall solution needs to keep all the network interactions simple and cannot be complex.
• Application needs to add data caching capabilities
• Application needs to implement robust connection management (e.g. Manual vs. Automatic)
• Implement a store-and-forward mechanism such as using MSMQ.
• Application needs to implement a robust data and business rule conflict manager.
• Interacting with CRUD like Web services.
• The application and the work can be logically broken into “chunks” to allow one using a task-based approach.
• The application should be able to handle both forward and reverse dependencies which in turn could be complex business logic.

As a high level guide, a data centric approach should be used when:

• One can deploy a database instance on the client.
• The application can function in a two-tier environment.
• One can tightly couple the client to the server through data schema definitions and communication protocol.
• There is a need for built-in change tracking and synchronization.
• One wants to rely on the database to handle data reconciliation conflicts and minimize the amount of custom reconciliation code that needs to be written.
• There is no need to interact with multiple disparate services.
• Users are able to connect to a database directly through a LAN/VPN/IPsec.

And, a service oriented approach should be taken when:

• One wants to decouple the client and server to allow independent versioning and deployment.
• There is a need for more control and flexibility over data reconciliation issues.
• The delivery team has expertise to write more advanced application infrastructure code.
• There is a need for a lightweight client footprint.
• The applications can be structured into a service-oriented architecture.
• There is a need for specific business functionality (for example, custom business rules and processing, flexible reconciliation, and so on).
  • Note: One might also need to look at a few good rules engine if this is the case.
• One needs control over the schema of data stored on the client and flexibility that might be different from the server.
• The application needs to interact with multiple services using different communication technologies (Web services, Message Queuing, RPC, etc.).
• There is a need for a custom security scheme.
• The application needs to operate outside of the firewall.

I am already using MOOS , so one option is for me to continue to use that - however this is for another part of the application and it might be easier for me to use something else (still need to think it through a little more).

These are the requirements (these are must haves!). Also if it makes a difference I am using CDT for this project.

• Needs to be able to run on Ubuntu 9.04 (and higher)
• Needs to be Open Source (cannot be commercial)
• Needs to be able to store messages “offline”
• Needs to be able to run on TCP with minimal dependencies. It would be nice not to have a whole bunch of underlying dependencies.
• Preferably be easy to use (as a consumer) - I don’t have much time to read through loads of documentation just to get my head around the underlying object model and how to use it.
• C++ support (if it was not obvious until now)

I did a little research online and came across the following, and wanted to get some feedback:

• ActiveMQ - seems like it has good C++ support via CMS (C++ Messaging Service).
• Amazon SQS -  not sure how good the C++ support is. If there is no library per se that I can use, then writing things around REST APIs might be more painful. Also I suddenly have a dependency to be able to go to the public internet. Also it is not free (though there is a free 100K messages / month).
• MQ4CPP - seems quite amateurish (kudos to the guy writing it though - seems like an interesting project to pick up when once has time).
• RabbitMQ - I know some guys used this at work (though that was using it in .NET); nothing for C++, but there some C experimental code ; overall does not inspire confidence (in the context of C++).
• OpenAMQ - seems quite interesting and also has a C++ API based on its WireAPI.
• Anything else??

At face value it seems like this is down to ActiveMQ and OpenAMQ. Just looking at the quick samples between the two ActiveMQ seems like more C++ friendly and easier to use compared to OpenAMQ . Of course this is just the first impression and I could be completely wrong - it is not like I have had a chance to play with this (yet anyways).

Does anyone have any experience and feedback on this matter? Feel free to comment on this post, or tweet me.

Whilst MOOS’s roots are in robotics ( MRG ) and embedded systems, I wonder if I can extend it to use it some of the grid computing scenarios. Maybe implement a pMapReduce or pHadoop? Or perhaps a .NET implementation. Hmm, just need some time. If you need a robust, cross platform communication layer then check out MOOS .

But as are aware Rational tools are very pricey and I was on the look out for something reasonable. Most people have heard of EA (no, not the game company) which is a decent tool and not too expensive (at least the Desktop edition).

Of course if you are stingy like me and want something completely free then check out StarUML which is an open source UML/MDA platform and is pretty decent. When you work with it enough you will find some annoying things - most of which has workarounds. There are one or two things it just cannot do, but I only have been using it for a few months now and am quite impressed. Is it better than the likes of EA or Rose, nope but it is pretty damn good for the price.

1. If you think you need multi-threading, you’re wrong
2. If your specification says “you need threading”, see Rule 1
3. (For advanced users only) If you think you need multi-threading, you’re probably wrong.

You’ll be able to engage in the technology debate with thought-provoking in-depth sessions from customer and partner architects along with members of the UK Microsoft Architect Council such as Avanade, Capgemini, Conchango and Solidsoft.

The agenda is split into seven tracks covering Enterprise, Real World, Identity, Lifecycle, SaaS, Collaboration and Dynamic Systems; the main content sessions will be 75 or 150 minutes in length to accommodate the different formats and levels of interaction that may be required.

There will be an emphasis on architectural ‘investigation’ through the use of small focus groups, as well as a structured networking clinic where individuals from similar vertical business backgrounds can discuss and work through a particular problem domain.

On a different note, been out and about on a few days of holiday with family visiting, but its good to be back now. :)

Well for those new to webservices, there are two options that you can choose when encoding your wsdl messages.

So, how do they look like. If I “borrow” and example from Sun , if below was your original class in Java:

package com.examples.xmlstring; import java.rmi.Remote; import java.rmi.RemoteException; public interface IStringService extends Remote {     public String sayXMLHello(String xml)         throws RemoteException;     }

The rpc encoding for that looks like this:

<binding name="IStringServiceBinding" type="tns:IStringService">     <soap:binding transport="http://schemas.xmlsoap.org/soap/http" **style="rpc"**/>     <operation name="sayXMLHello">         <soap:operation soapaction=""/>             <input>                 <soap:body encodingstyle="http://schemas.xmlsoap.org/soap/encoding/" **use="encoded"** namespace="http://www.examples.com/wsdl/StringService"/>             </input>             <output>                 <soap:body encodingstyle="http://schemas.xmlsoap.org/soap/encoding/" **use="encoded"** namespace="http://www.examples.com/wsdl/StringService"/>             </output>     </operation> </binding>

And the document encoding looks like:

<?xml version="1.0" encoding="UTF-8"?>     <env:envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://www.examples.com/types">         <env:body>             <ns0:sayxmlhello>                 <string_1>Hello World</string_1>             </ns0:sayxmlhello>         </env:body> </env:envelope>

I think in the end the real thing to keep in perspective is who and what will be consuming this? If your clients are primarily MS-based (COM/.NET) then you are better off with literal encoding, on the other hand if its primarily J2EE client then you are better off with the other one. But, more interestingly if you don’t know (or in other words can be both), then which road to take?

The hype surrounding Web services has generated many common misconceptions about the fundamentals of this emerging technology.

Web services are frequently described as the latest incarnation of distributed object technology. This misconception, perpetuated by people from both industry and academia, seriously limits broader acceptance of the true Web services architecture. Although the architects of many distributed and Internet systems have been vocal about the differences between Web services and distributed objects, dispelling the myth that they are closely related appears difficult.

Many believe that Web services is a distributed systems technology that relies on some form of distributed object technology. Unfortunately, this is not the only common misconception about Web services. In this article, I seek to clarify several widely held beliefs about the technology that are partially or completely wrong.

Fundamental Errors: At the International World Wide Web Conference in May 2003, a smart and gifted Internet architect I will call Peter asked me, “Don’t you think Web services will fail like all the other wide-area distributed object technologies that people have tried to build?” I was baffled. How could someone like Peter still view Web services as distributed object technology? Yet, he is not alone in his stubbornness: many developers, architects, managers, and academics still see Web services as the next episode in a saga that includes Corba, DCOM, and remote method invocation (RMI). Web services are distributed systems technologies, but that is where the common ground ends. The only possible relation is that Web services are now sometimes deployed in areas where distributed object applications have failed in the past. Within the distributed technology world, it is probably more appropriate to associate Web services with messaging technologies because they share a common architectural view, although they address different application types.

Given that Web services are based on XML documents and document exchange, we could say their technological underpinning is document-oriented computing. However, exchanging documents is very different from requesting an object’s instantiation, requesting a method’s invocation on the basis of the specific object instance, receiving that invocation’s result in a response, and releasing the object instance after several such exchanges.

I frequently encounter about a dozen other statements that fall into the same basic category. I hear people say, for example, that “Web services are just remote procedure calls for the Internet,” or “You need HTTP to make Web services work.” Before addressing several of the more common misconceptions, we should define a Web service in its purest form in order to begin with a clear model.

The application blocks that comprise the Enterprise Library are the following:

• Caching Application Block. This application block allows developers to incorporate a local cache in their applications.
• Configuration Application Block. This application block allows applications to read and write configuration information.
• Data Access Application Block. This application block allows developers to incorporate standard database functionality in their applications.
• Cryptography Application Block. This application block allows developers to include encryption and hashing functionality in their applications.
• Exception Handling Application Block. This application block allows developers and policy makers to create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications.
• Logging and Instrumentation Application Block. This application block allows developers to incorporate standard logging and instrumentation functionality in their applications.
• Security Application Block. This application block allows developers to incorporate security functionality in their applications. Applications can use the application block in a variety of situations, such as authenticating and authorising users against a database, retrieving role and profile information, and caching user profile information.

Different applications have different requirements and you will not find that every application block is useful in every application that you build. Before using an application block, you should have a good understanding of your application requirements and of the scenarios that the application block is designed to address.

You can also get some more information on Tom’s blog .

Testing .NET Application Blocks covers many testing areas that were used during testing and verification of the various application blocks provided by Microsoft’s patterns & practices group, such as functional, globalization, performance, integration, and security. The guide uses code examples, sample test cases, and checklists to demonstrate how to plan and implement each type of test; the guide also recommends tools to use to run the tests. It covers test considerations to be taken into account when customizing these application blocks or integrating them with your own applications.

Because this guide focuses on testing NET application blocks, its scope does not include user interface (UI) testing or database testing. Although the guidance is developed within the context of Microsoft patterns & practices application blocks, it still applies to testing .NET code in general.

[Listening to: Nach Deutschland - The Bourne Supremacy - The Bourne Supremacy (02:40)]

But, in real life, neither of these issues are really ideal. How best to deal with situations where e.g. a sales person who is on the road could not (or does not) connect to the network to synch up and the person in the office updates the record? How do you deal with those situations. One solution is to update only the changes fields, and the rest are either rejected or the user needs to manually confirm each change and pick which ones take precedence. This along with the fact that in real life data can be segregated to some extent on a user level would suffice? Another thing to dwell upon, for most Mobile applications (especially disconnected), going the SOA way is what makes more sense. Since each time you sync up or submit something (if its on gprs for example), your client running on the device should just consume the service and really cannot be bothered by any more details than that (more on this on another post soon).

But, still seems quite fragile with lots of areas for failure. What are you thoughts? Is there a better way to do this that would make it more robust?

HTTP Handlers:

The “handlers” are nothing but assemblies (class libraries) that implement IHttpHandler and IHttpAsyncHandler interfaces. Essentially, ASP.NET maps each http request to a http handler. The handler in turn enables processing individual url’s or groups of url’s with similar extensions such as .aspx, .asmx, .ascx, .disco, etc. The handler can be synchronous or asynchronous, the earlier does not return until it finished processing and the latter typically launches a separate process.

When you inherit from IHttpHandler handler, you need to implement both the ProcessRequest method (which processes the individual http requests) and the IsReusable property (which specifies if pooling is supported or not). If you have a more complex set of logic then you should look at inheriting IHttpHandlerFactory, as that allows finer control and you can create different handler based on your need. E.g. you can create a separate handler for GET and PUT.

When you are finished building the handler (essentially compiling your assembly), you need to register it to use it. To register a handler essentially you copy the assembly in the bin folder of where you web app is running and create a section in the web.config. (I’ll have a sample in a bit in this post). You might also want to ensure that the HTTP handler’s extension is registered with IIS.

General process of Building a Handler:

1. Implement the IHttpHandler interface
2. Handle the ProcessRequest method and IsRuseable property.
3. Deploy the assembly
4. Register the handler

Below is an example of a handler that processes request for the files with the extension “.desigeek”. Note, that you do not need to have a physical file present with that extension.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

public class DesigeekHandler : IHttpHandler {
   bool IHttpHandler.IsReusable { 
      get { 
        return false;
      }  
   }

void IHttpHandler.ProcessRequest( HttpContext context ) {
    HttpResponse response = context.Response;  
    
    response.Write( "< html>" );  
    response.Write( "< body>" );  
    response.Write( "< h1> Hello from Desigeek custom handler. < /h1>" );  
    response.Write( "< /body>" );  
    response.Write( "< /html>" );
}

Register the HTTP handler by creating an entry in the web.config:

1
2
3

<httpHandlers\>  
 <add verb\="\*" path\="\*.desigeek" type\="MyHTTPHandler.DesigeekHandler, MyHTTPHandler"/>  
httpHandlers\>

Below is a sample of what the request would look like. Notice the URL requested is “foo.desigeek” (and there is no physical file with that name on the file system. The first screen-shot is of the web application (which basically is one label which is updated with the system time on PageLoad). The second one is where the handler kicks in.

HTTP Module:

HTTP modules are classes that can be configured to run in response to events that fire during the request for an ASP.NET resource (which can be serviced by any handler). An HTTP module is an assembly that implements the IHttpModule interface and handles events. ASP.NET ships with a number of modules out of the box e.g. SessionStateModule is used to supply session state services to an application.

If you check your machine.config you will there are a number of handlers that come with ASP.NET. e.g you might look at something like:

1
2
3
4
5
6
7
8
9

< httpModules>  
    < add name="OutputCache" type="System.Web.Caching.OutputCacheModule, .../>  
    < add name="Session" type="System.Web.SessionState.SessionStateModule, .../>  
    < add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule, .../>  
    < add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule .../>  
    < add name="PassportAuthentication" type="System.Web.Security.PassportAuthenticationModule .../>  
    < add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule, .../>  
    < add name="FileAuthorization" type="System.Web.Security.FileAuthorizationModule, .../>  
< /httpModules>

Basically you follow the similar process as HTTP handlers. Once you have created your assembly you deploy it to the bin folder and register your handler. The general process for writing an HTTP module is:

• Implement the IHttpModule interface.
• Handle the Init method and register for the events you need.
• Handle the events.
• Optionally implement the Dispose method if you have to do cleanup.
• Register the module in Web.config.

Here is an example which hooks into the BeginRequest and EndRequest events of HttpApplication and adds “DesigeekModule: Begin of Request“ and “DesigeekModule: End of Request“ to the response being send out to the client. The Init() function is where your register the hooks you want.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class DesigeekModule : IHttpModule  {
  
  //you register the events you are want to hook in this function
  void IHttpModule.Init( HttpApplication context ) {
       context.BeginRequest += ( new EventHandler( this.App\_BeginRequest ) );  
       context.EndRequest += ( new EventHandler( this.App\_EndRequest ) );  
  }

  private void App\_EndRequest( object source, EventArgs e ) {
      HttpApplication app = (HttpApplication)source;  
      HttpContext context = app.Context;  
      context.Response.Write( "DesigeekModule: END of Request" );
  }  
  
  private void App\_BeginRequest( object source, EventArgs e ) {
      HttpApplication app = (HttpApplication)source;  
      HttpContext context = app.Context;  
      context.Response.Write( "DesigeekModule: BEGIN of Request" );
  }  
  
  public string ModuleName {  
      get {
        return "DesigeekModule";
      }  
  }  
}

You register the HTTP Module by adding the following section in your web.config.

1
2

< httpModules\> < add name\="DesigeekModule" type\="MyHTTPModule.DesigeekModule, MyHTTPHandler"/>  
< /httpModules\>

When you run this (see the screen shots below), you will notice that when I goto the default.aspx I see the label with the date-time and the BEGIN and END strings. Another interesting point, if I get to one of my custom handler (e.g. foo.desigeek) then as shown below I get output from both the HTTP Module and HTTP Handler, which means there are many powerful things you can get by combining these.

Overall, the image below shows graphical representation of the process of a ASP.NET HTTP pipeline. The process starts with a request arriving at IIS. If the requested resource is configured to be handled by the ASP.NET ISAPI Extension, IIS dispatches the request to the unmanaged aspnet_isapi.dll ISAPI Extension. This ISAPI Extension passes off the request to the managed ASP.NET engine. It is important to note that during the request life cycle, one or more HTTP modules may execute, depending on what modules have been registered and what events they have subscribed to. Finally, the ASP.NET engine determines the HTTP handler that is responsible for rendering the content, invoking the handler and returning the generated content back to IIS, which returns it back to the requesting client. If you want to get creative and do some more processing, you can use the HTTP Factory. Remember, an HTTP handler factory is a class that is not directly responsible for rendering the content, but instead is responsible for selecting and returning an HTTP handler instance. This returned HTTP handler instance is then the one that is tasked with rendering the requested resource.

More Information:

• http://tinyurl.com/6qb4r
• http://tinyurl.com/4x8yt
• http://tinyurl.com/5wthn
• http://tinyurl.com/47cp2

The main issue is the “lapsed listener” problem. This occurs when objects subscribe to events and subsequently get out of scope. The problem is that the event subscriber doesn’t get garbage collected because the event is still holding a reference to it inside of the event’s invocation list. The event subscriber is still considered reachable from the GC’s point of view. As such, it doesn’t get collected until the event goes out of scope (which is usually at application shutdown) which means that the event subscriber is effectively “leaked”.

Moral of the story: when you implement an Observer pattern, it’s important to consider the relative lifetime of events and subscribers. If implemented naively, you’ll end up having objects that live a lot longer than you think they should. Unsubscribe() is your friend.

As Fabrice writes, .NET’s delegates and events are implementations of the Observer Design Pattern . But the current problem is one more reminder that Design Patterns should not be applied blindly .

If you write the following code, you’ll see that the object instance gets correctly released and collected:

1
2
3

StoopidObject object = new StoopidObject();  
GC.Collect();  
GC.WaitForPendingFinalizers();

If you write the following code instead, although there is no apparent reference kept to the Observer, the Observer instance will not be released:

1
2
3
4
5

Observer observer = new Observer();  
Subject subject = new Subject();  
subject.SomethingHappened += new EventHandler(observer.subject\_SomethingHappened);  
GC.Collect();  
GC.WaitForPendingFinalizers();

Guys from around the community came with various solutions. They call them Weak Delegates. Follow the links to learn more:

• Greg Schechter (real case study; schema’s will help you to understand the problem)
• Ian Griffiths and Xavier Musy (extensions and improvements)

More Information:

• http://tinyurl.com/56vu4
• http://tinyurl.com/5ss2d
• http://tinyurl.com/5jo5n

In the CLR certain conditions such as out of memory, stack overflow, etc can bring down an app domain (or process), this cannot be allowed in SQL Server 2005 when latter is acting has a host (for the CLR) as it will affect reliability and performance - couple of the key goals for SQL Server. Similarly unconditionally stopping a thread (e.g. via Thread.Abort) can potentially leave some resources in a “hung” state.

So how do we handle this? Well other hosts such as ASP.NET recycle the app domain in such situations which is OK because a web application is disconnected and not “long running”. On the other hand SQL Server can have long running batch jobs and rolling all that information back in mot cases is not an option. Our of memory conditions are pretty hard to handle even if you leave a safety buffer for memory. Since SQL Server manages its own memory and tends to use all available memory to maximise throughput this puts it in an even more difficult position. As a result of you increase the “safety net” to handle out of memory conditions you also increase the chances or getting in those situations.

The good news is that .NET 2.0 (which ships with Whidbey) handles these situations better than ver. 1.x and it notifies SQL Server about repercussions of failing each memory request. It would also facilitate running the GC more aggressively, waiting for existing procedural code to finish before starting to execute newer code and also aborting running threads if needed. In addition, at the CLR level there is also a failure escalation policy that would allow SQL Server to deal with those situations. Using this SQL Server among other things can either abort the thread causing the exception of unload the whole app domain.

If any resources fail then the CLR will unwind the whole stack and if there are any locks on them then unload the whole app domain as locks indicate there is some shared state to synchronise and most likely would not be consistent in that state. If the CLR encounters a stack overflow that is not caught by the application then it will unwind the stack and get rid of that thread.

Going back to the main goals, SQL Server will maintain transactional semantics. If an app domain is recycled then the main reason is probably due to reliability (even if at the expense of performance). As a note, all the class libraries part from the BCL that SQL Server will load have been ensured to clean up memory and other resources after a thread is aborted or an app domain is unloaded.

I will post on security and app domains at a later time.

What is a runtime host? Basically any process that loads the .NET runtime and runs code in that managed environment is a runtime host. The most common host is the Windows shell - when you double-click on a .net application, the host (i.e. the Win shell in this case), loads the runtime in memory and then loads the requested assembly. The host loads the runtime by calling a shim DLL called mscoree.dll whose only purpose in life is to load the runtime. This exposes two API’s called ICorRuntimeHost or CorBindToRuntimeEx. Till Whidbey the only parameters that can be passed to either of the API’s are:

• Server or workstation behaviour
• CLR Version
• GC Behaviour
• Enable sharing of JIT code across AppDomains

Till SQL Server 2005 there were two runtime hosts for the .NET namely ASP.NET worker process and IE each with their own priorities of the framework. When adding the CLR, to SQL Server the three main goals in ascending order were:

1. Security
2. Reliability
3. Performance

Its not surprising to see Security and Reliability a higher priority than performance. You don’t want your mission critical application to run in a non-secure environment that can allow for malicious code and allow hackers to get in. Also critical applications such as databases are quite often needed to sustain the five 9’s of requirement (99.999 % uptime) especially in the Enterprise environment. Lastly performance is important (hence it is one of the goals) as you don’t want to wait forever to get your result back, but that performance gain is not at the cost of a secure of reliable system.

SQL Server is a specialised host and not a “simple bootstrap mechanism”. To ensure the SQL Server goals some changes had to be made to the CLR which are incorporated in ver 2.0 (Whidbey). To allow the “new” hosts such as SQL Server to have hooks into the CLR’s resource allocation and management the .NET 2.0 hosts can use ICLRRuntimeHost instead of ICorRuntimeHost. The host then can call the SetHostControl() method which in turn delegates to GetHostManager() for things such as thread management, etc. Here is how it would look like:

Resource Management - SQL Server lazy loads the clr, so if you never use it then it is never loaded. Unlike the “regular” CLR hosts where the CLR itself manages the resources, SQL Server manages its own thread scheduling, synchronisation, locking and memory allocation. This is done by layering the clr’s mechanisms in top of SQL Server’s mechanisms. SQL Server uses its own memory allocation scheme, managing “real memory” rather than virtual memory. This allows it to optimise memory, balancing between data and index buffers, query caches, etc. SQL Server can do a better job if is manages all of the memory in its process.

SQL Server also uses its own thread management putting threads to sleep when not running. The is also called user mode scheduler . SQL Server internally uses cooperative thread scheduling to minimise thread context switches, as opposed to preemptive thread scheduling used by the CLR. This means that in SQL Server a thread has to voluntarily give up control as opposed to the CLR where the processes takes over control after a certain time-slice.

The hosting API’s in .NET 2.0 allow a runtime host to either control of “have a say in” resource allocation. The APIs manage units of work (called Tasks), that can be assigned to a thread (or fibre). The SQL scheduler manages blocking points, and hooks PInvoke and interop calls out of the runtime to control switching the scheduling mode. This allows SQL Server to supply a host memory allocator, to be notified of low memory conditions at the OS level and to fail memory allocations if needed. SQL Server can also use the hosting API to control I/O completion ports.

I’ll be discussing Exception Management, Code Loading and Security in this new host in later posts. Till then, if you want to learn in more details the either get the book mentioned earlier in this post or keep a lookout here. Also if you plan on installing the newly released Beta 2 then check out Bob’s post on some observations.

Exceptions are a very powerful concept when used correctly. An important cornerstone in the design of a good application is the strategy you adopt for Exception Management. You must ensure that your design is extensible to be able to handle unforeseen exceptions gracefully, log them appropriately and generate metrics to allow the applications to be monitored externally.

I work for a large Systems Integrator and we are also one of the largest global MS partners. A lot of the clients I am involved with have almost every technology/platform running somewhere on their network and a very small percentage are only Microsoft. So, if this is something proprietary which I as an Architect cannot “integrate” with other pieces of a complex enterprise application that maybe running on J2EE then why would I want to use this?

What happened to all the “No Application is an Island” push? Was it only a marketing ploy? The other question is, Rational (or now IBM) will be improving Rose/XDE to counter Microsoft’s threat to their dominance in this market, and if that does support UML then why would I not use that?

Thoughts?

• Keith Short
• R Ramesh
• Stuart Kent

Here is an excerpt from the site:

Building complex service-oriented solutions requires several architectural considerations including services and contract design, communications security, operations manageability and provisioning, and so on. Add to this, the time-honored issues architectural teams are mired with—architecting upfront with deployment in mind, ensuring design changes are propagated to code and vice versa, establishing seamless communication between design and development teams and design and operations teams.

Visual Studio 2005 Team Architect Edition addresses exactly these problems at the core with a set of Distributed System Designers that help reduce the complexity of developing and deploying service-oriented applications. A core deliverable of the Dynamic Systems Initiative (DS), these designers, leveraging the System Definition Model (SDM), allow senior developers and architects to define service-oriented applications that will be configured into systems for deployment. While application architects can visualize their service-oriented applications, developers can work with the generated code while keeping the code-changes synchronized with the visual design. In addition, the Distributed System Designers can be used to create diagrams or interconnected hosts that represent the logical structure of a data center for the purpose of communicating important information to the developer about the target deployment environment. The Distributed System Designers can also bind applications to these logical servers and validate them against the constraints of the application/data center prior to actual deployment.

• Applications
• Application hosts
• Network Topology
• OS and physical hardware or devices.

For each layer, the model describes the connections between systems and their configurations. By adopting a common model for all these layers, the model makes it possible for you to define and express requirements and policies across these layers. For example, an application can require a certain authentication mode or that other resources need to exist on the logical server that hosts the application. A logical server can also require that the application it hosts must support a certain authentication mode and that it disable specific features that present a security risk.

The SDM offers the following benefits:

• Provides a common language to describe the design and configuration of all aspects of a distributed system.
• Provides familiar abstractions that make it possible for developers and operations groups to communicate on common ground.
• Makes it possible for developers to communicate application requirements of the run-time environment.
• Makes it possible for operations groups to communicate application run-time, security, and connectivity requirements that result from the policies defined in the target deployment environment.

The SDM is intrinsically extensible and makes it possible for the addition of new abstract definitions at each layer.

White-Box testing (Glass Box/Clear Box/Open Box testing)

White box testing assumes that the tester can take a look at the code for the application and create test cases which look for any potential failure scenarios. You need to determine the suitable input data for testing of various APIs and the special code paths that need testeing by analyzing the source code for the application. One needs to ensure that the test plans need to be updated before starting with White–Box testing.

A failure of a white box test may result in a change which requires all the black box testing to be repeated and re-determination of white-box paths.

• Profile The Application Code Blocks. Profiling is the activity which allows you to monitor the behavior of a particular code path in run time when the code is actually in execution. Typically you would profile your code for one or more of the following:

  • Code Coverage. Profiling for code coverage with the help of a tool ensures that there is no redundant or dead code which never gets called for any execution path.

  • Memory allocation pattern. This helps you in studying direct and indirect memory allocations while executing a code path, detect and analyze memory leaks (for unmanaged code), etc. For example you can analyze in which GC generations (Gen 0, Gen 1, Gen2) the maximum objects reside or are there any side affect allocations taking place in a loop which are increasing the memory utilization significantly. This can help you optimize the memory utilization of the code block. You can use various tools such as CLR profiler, Intel Vtune, etc. for this purpose.

  • Contention and deadlock issues. You can analyze the code for deadlocks using tools like WinDbg which are a part of the Windows debugging toolkit.

  • Time taken for executing a code path. You can profile the time taken by the scenarios for which performance is critical. This may require custom instrumentation of the code path which may be distributed across physically different machines. There are also various third party tools available which help you measure the time taken for execution of a particular scenario.

    If the code needs to be integrated with web application one should also check out the Request Execution Time (ASP.NET\Request Execution Time) perf. counter. You can create a test harnesses such that the overhead of the harness is minimal and most of the processing time is spend within the code.

If during profiling you find that a particular condition needs to be tested under load such as potential deadlock issues or inefficient memory cleanup which is visible only under scenarios you can provide inputs on the type of metrics which should be chosen while load testing the code and what are the things you should be looking for when stress testing the code.

• Testing internal subroutines. You need to test the various internal functions to ensure that they are processing the right data without any loss or inconsistency and returning the expected output.
• Test various loops and conditional statements. You should test various types of loops such as simple, concatenated, nested loops etc and the accuracy of conditional statements in the code components such as relational expressions, simple conditions, compound conditions, Boolean expressions, etc.
• Testing various scenarios identified. Various potential scenarios should have been identified in earlier in the process of reviewing the implementation. You must test these scenarios by first analyzing the code and then submitting the inputs which tend to exploit the weakness in the code (if any).
• Security Testing. During the process of source code review if you identify that a particular code access security is not able to restrict undesirable access in the targeted deployment environment you should test this scenario by first analyzing the code and then simulating the deployment environment to identify any scenarios where the code block may expose sensitive information to hackers.

More Information - check out http://tinyurl.com/32ye3

When you are doing Functional Testing of your application or code, it can be of two kinds - Black Box and White Box. I am going to highlight some of the suggestions of MS on Black-Box here and have another followup post on the Whitebox testing.

Black-Box testing

The black box testing assumes no knowledge of code and is intended to simulate the end user experience. One can use sample applications to integrate and test the various components of an application for black box testing. This approach allows for testing of all the possible combinations of the end user actions. Some of the testing techniques which are covered in this are:

• Testing all the external interfaces for all possible usage scenarios. All the external interfaces that can be integrated by the end users with their applications.
  • Ensure the interfaces meet the requirements and functional specs. This type of testing ensures that the components in an application implement the interfaces required per the functional specifications. This also allows you to develop a test harnesses. You need to test for all the possible ways in which the APIs can be called by the clients of the code block. The usage scenarios include both the expected process flows and random inputs.
  • Testing for various types of inputs. The second step is to ensure that the interfaces are returning the expected output and are robust enough to handle invalid data and exceptional conditions gracefully. The input data can be randomly generated within a specified range expected by the application, outside the specified range or at the boundary of the range. Testing with data outside the specified range ensures that the application is robust and can handle invalid data and the error messages generated are meaningful for the end user. Boundary testing ensures that the highest and lowest permitted inputs produce expected output.
• Performance Testing. You execute performance related test cases from the test plan in a simulated environment which is close to the real world deployment. Performance testing is done to verify that the application is able to perform under expected and peak load conditions, and that it can scale sufficiently to handle increased capacity. There are two main aspects of performance testing with different end goals. You must plan and execute test cases for both these aspects as mentioned below:
  • Load Testing: Use load testing to verify the code behavior under normal and peak load conditions. This allows you to verify that the application can meet the desired performance objectives and does not overshoot the allocated budget for resource utilization such as memory, processor, network I/O etc. This also allows you to measure the measure response times and throughput rates for the application. Load Testing also helps you identify the overhead (if any) of using the application to achieve a desired functionality by testing applications with and without the code block for achieving the same end result.
  • Stress Testing: Use stress testing to evaluate the code’s behavior when it is pushed beyond the normal or peak load conditions. The goal of stress testing is to unearth bugs that surface only under high load conditions such things as synchronization issues, race conditions, and memory leaks.

The analysis from performance tests may serve as input to White Box Testing. You may need to do a code review of the suspected module to weed out any possible causes of issues such as a coarse –grained lock which is causing increased wait times for threads etc. The data analysis from performance tests provides useful inputs to the type of problems which surface under load conditions. These inputs help you focus on profiling a particular code path during white box testing.

• Security Testing. Security Testing is done by simulating the target deployment environments and tested for potential security attacks.
• Globalization testing. The design and implementation has already been reviewed for adherence to best practices for globalization. Here one should check for Globalization related test cases to ensure that the code block can handle international support and is ready to be used from various locales around the world. The goal of globalization testing is to detect potential problems in application design that could cause problems. It makes sure that the code can handle all international support and supports any of the culture/local settings without breaking functionality that would cause either data loss or display problems. To perform globalization testing, you must install multiple language groups and ensure that the culture/locale is not your local culture/locale. For example, executing test cases in both Japanese and German environments, and a combination of both, can cover most globalization issues.

For more information on performance testing check out:

• http://tinyurl.com/3eqmm
• http://tinyurl.com/35mpw

• Simplicity - It does not mean NOT writing 10 lines of code for something that can be done in 5 - but rather to make the extra effort to be concise but not to the point of obfuscation. It also means that your functions should not be spanning pages. Simplicity makes the code easier to manage and debug making it more reliable and hence bug free.
• Readability - This means that the others can read your code. It means you take the effort to write comments and explanations (for very complex things) in the code. It also means to follow your coding guidelines and choose variable and function names carefully
• Modularity - I like how Paul put this. This means your application is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleus, quarks and strings! Similarly, good programs build large systems from smaller ones which in turn are build on smaller building blocks. Just as atoms combine in novel ways, software components should be reusable.
• Layering - This means that internally your application resembles a layer cake (slurp, smack, drool). The app sits on the framework which sits on the OS and within the application you follow a similar paradigm. The higher layers should call the lower ones which in turn raise events back up. Lower layers should never know that the higher ones are upto.
• Design - This means read Dilbert! Invest the time to plan and design your application before you build it - much much cheaper in the long run.
• Efficiency - Means the application should be acceptably fast and economical i.e. it does not hog any resources. It loads and departs without a fuss. At a high level you need to be aware of your performance requirements.
• Elegance - This is like beauty - hard to describe but easy to recognise. Elegance combines simplicity, efficiency, brilliance and above all pride.
• Clarity - This is the “granddaddy” of good programming. The fundamental challenge of programming is managing complexity! All the other points mentioned above are ways to achieve clarity - clarity of code, clarity of design, clarity of purpose. You must understand and really understand what you are doing at every level. Bad programs less often a failure of coding skills than of having a clear goal which is why design is the key. If you cannot write it down, you cannot explain to others, you don’t really know whats happening!

I am a big believer of the principle of KISS (Keep It Simple and Stupid)! All the above points to that. In the real world there are very rate instances where someone has not tried to make this more complex than it needs to be (with yours truly being guilty of the same). But everyone learns (and so did I). The key is to remember KISS and that your design needs to be good. If the architect on the project is not making that clear (or doing it correctly), then he/she/them need to be told!

What do you think makes good code?

How do you measure a good Architect? - How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.

What is the difference between maturity and completeness? - In its first version, an architecture should be like a baby. It is whole and complete. It has ten fingers and ten toes. It has all its systems, but it is immature. You wouldn’t expect it to do certain things that you might expect a mature system to do. Of course, the definition of what is complete and incomplete, mature and immature, is subjective. But it is really important to distinguish between incompleteness and immaturity. I see the people make the mistake made all the time of building an incomplete system. It’s actually not a mistake that’s correlated to a development process, near as I can tell. You can have iterative, agile projects that produce incomplete results, and you can have waterfall or traditional kinds of projects that produce incomplete results.

“… explore alternative architectures to see what works best…” This is sensible advice. It is also virtually useless.

“… An architecture is like a carefully designed garden, and needs care and feeding….”

What is Entropy Reduction? - Entropy reduction means I am going to make whatever compromise I need to make to get the release done, and then I’m going to give the team the opportunity to go back and respond or recover from the compromises they made. It is a very different concept than refactoring. I think of refactoring as non-architectural, but rather very much in the context of normal work.

This is so true of one of my previous projects we were implementing in the New York office of the company I work for. Some of my colleagues who are reading this (and proving they don’t have anything better to do) are probably grinning ear-to-ear from this:
Another aspect of matching architecture to human needs is matching roles and responsibilities of the people building a system to the appropriate parts of the architecture. Some pundits say that everyone likes to do everything, but that’s not true. I suspect that a lot of people who write about architecture, although they are very smart, have never managed large teams. I’ve managed a 60-person team, and I personally know UI guys who would never get near a database, because they think databases are “stupid”. And I know many database developers who would never go near a UI. The last thing these database people want to do is the full architectural stack. They’ve spent their life becoming an expert at Oracle. And you know what? They are an expert at Oracle. They aren’t going to be an expert at UI design, and given what they would normally design for a UI, you wouldn’t want them to be touching the UI anyway. When you look at the stack in your architecture, and then you look at this mass of people on your team, the architecture and the people have to match. Otherwise you’ll have problems.

Determining the Appropriate Granularity of the Design? - When people talk about architecture, there’s rarely a corresponding discussion of the granularity of the architectural metaphors, components, or descriptions that are being employed. The appropriate granularity is a function of the number of people working on the software and the complexity of the software itself. If only two or three people are working on the project, then they can get pretty granular. As the software and team gets bigger in size, the granularity must become more abstract.

Overall, like I opened this post with, this more or less reflects my experiences and pretty much on the dime with the issues, suggestions and analogies discussed. What are your experiences? Do you disagree with something?

Real dependencies are the services that you need to fulfil your need, this is something that cannot be eliminated or reduced.

Artificial dependency on the other hand are the features you need to adhere to in order to consume the services you need. Typically these fall in the categories of platform dependencies, API dependencies, language, etc. Although artificial dependencies cannot be eliminated it can be reduced.

A loosely coupled application is on that minimise its Artificial Dependency.