MVP for Windows Azure

On January 2, 2012, I was awarded the Microsoft Most Valuable Professional (MVP) for Windows Azure. It is really an honor to be recognized as a Windows Azure MVP for my country. I will definitely continue to shower the developer community with my passion for technology and crazy ideas to build applications - particularly now focusing on Windows Azure. :)

Windows Azure is now ISO 27001

I am just going to parrot this from the Windows Azure Team Blog. Windows Azure is now ISO 27001 certified and more importantly it complies with the ISO/IEC 27001:2005 ISMS requirement standards. This is a good start and a great milestone to gain the confidence of ISO 27001 companies (like my current) to leverage on Windows Azure.

The next step would be to see SQL Azure getting certified. Getting SQL Azure certified will be the most important key point to address the data concerns of most companies when moving into Cloud solutions. Looking forward to see that happen.

MVC and Layered Architecture

Throughout the years of promoting Layered Architecture on .NET, I have occasionally came across the question on how to integrate the Model-View-Controller (MVC) Architecture into Layering. MVC provides clear separation of data and UI logic concerns coupled with the benefits of high testability. Layered Architecture provides a scalable, extensible, maintainable and highly adaptable distributed design for applications. With such advantages from both architectures, who can resist them? :)

Back then, there weren't any sophisticated MVC tools in Visual Studio, the closest was the Smart Client Software Factory (SCSF) and Web Client Software Factory (WCSF), but both were using rather complicated implementations. But today, VS 2010 provides us with ASP.NET MVC web application templates which effectively raises the need to answer the integration question even further.

Before I discuss the integration ideas, I would like to first share with you my personal perspective of the MVC architecture. Firstly, MVC is an out-dated (but good) architecture. Many sites will tell you that MVC is not new and it has been around since SmallTalk. Why I say it is out-dated is because it was not designed for today's service-oriented distributed architectures (something that can be fixed when merged with Layering).

Secondly, I view MVC as a "micro-pattern" for developing UI applications and Layering as a "macro-pattern" that can house multiple micro-patterns (not just limited to MVC). Therefore, I truly believe that MVC can be integrated into Layering to leverage on modern day distributed environments.

Finally, I felt that the out-of-the-box ASP.NET MVC templates in VS2010 are encouraging a monolithic approach. Ok, I admit that I think most of the OOTB VS templates are *evil*, simply because their focus is on RAD and promoting the adoption of a specific technology without looking at the complete architecture. Some developers have already realized this and have started to decouple their Data Layers to a Data Service, but that still leaves them with a "client/server application" at best. Do take note that all these problems I highlighted are not the fault of the developers but more on the project templates.

I shall reserve my ideas to fix those templates to another post, but right now, I will provide the high-level concepts of merging the two architectures to get the best of both worlds. There are two models which I have came up with and I will start off with the first one which I conveniently termed it as the Bridged Model.

If we dissect both architectures, we can easily identify components of similar responsibilities regardless of the term that is used. In MVC, the Model is used to ferry data, the View is used to display/capture data and the Controller is used to process logic and co-ordinate the flow between Views. In Layered Architecture, the Business Entities are used to ferry data, UI Components are used to display/capture data and the UI Process Components are there to co-ordinate the UI (and connect to the service back-end) - Notice the similarities?

In the Bridged Model, the key to connecting both architectures lies in the Controller component of the MVC and the UI Process Component (UIPC) of the Layered Architecture. By connecting the Controller to the UIPC, we treat the entire MVC portion as a UI layer (or component) sitting on top of the UIPC. This strategy has the benefit of making the Controller more lightweight as most of the application and service-communication logic is delegated to the UIPC. It is also good for multi-UI platform applications which may allow Desktop, RIA and mobile clients to share the same UI processing logic.

If you are integrating a MVC web application to an application with existing UI components calling a service back-end, then the Bridge Model will make most sense.

While the Bridge Model works in connecting the two architectures, it may seem less elegant if we only have a single UI platform. In that case, we may not want the performance overhead of the Controller-UIPC relationship and to remedy it, we can adopt the Integrated Model.

In the Integrated Model, the Presentation Layer components are being replaced completely with the MVC components. The responsibility of the UIPC is unified into the Controller, eliminating one level in the UI and therefore, improving the performance of the application.

Whether to use the Bridge Model, Integrated Model or not at all, is depending on your choice and the projected application growth. If you are dead-sure that your application will not grow, then the monolithic approach presented by the OOTB templates will work just fine. Otherwise, if you share the same thoughts like me i.e. "All applications has the potential to grow, no matter how small they are", then it may be wise to look at the integration models from the start.

Take note that although I used Web Application in the context of the discussion, these concepts can be equally applied to any type of MVC application i.e. the SCSF implementation of MVC/MVP.

LASG = A framework?

I was approached by a developer to comment about the usage of some frameworks in his project. After providing my comments, I told him that I do not use the frameworks that he had mentioned and he immediately said, "Oh! I forgot, you only use LASG". I was stunt for a moment. Probing further, I managed to discover how LASG was being perceived (somewhat wrongly) by some developers in the community.

Firstly, I discovered that the developer had compared LASG with MVC (some had previously compared it with ADO.NET Entity Framework). MVC and EF are both "code-frameworks" that share the same goal as LASG which is to simplify software development but uses a completely different category of approach. I would say, MVC and EF are what (true and real) code-frameworks should be.

LASG is not a code-framework but only a simple (humble) automation tool. It does not contain any APIs or Application Blocks that requires a developer to learn or use. It is just a combination of project templates and code-generators that simplifies development tasks. These tasks can very well be hand-coded if one wishes to do it. Therefore, I feel that getting started with LASG is (should be) much simpler and easier as compared to learning a code-framework.

To prove a point, you can completely disassociated LASG from your Solution and Project templates at any time and your code will still compile and run. You can uninstall LASG from your machine after you have generated all the code and your code will still compile and run. [Warning: If you disassociate LASG from your projects, you will not be able to re-associate it back. Hey! It has feelings too you know! :p].

I also understand that this confusion is also partially my fault. For the veterans who knew me previously, I wrote a RAD framework called Paladin and to accelerate the adoption, I developed a simple code-generator on top of the framework. That was the time when people proclaimed that Paladin was a code-generator but I refuted and said it was a framework. Now almost 10 years after that, I created something simpler like LASG and people now have the perception that it was something complex like my previous attempt. *HeHe*

So, is LASG still a framework? If I follow Microsoft Patterns & Practices' (or the industry) terminology, LASG is somewhat like a software-factory - a very basic one I would say (All great things start with a baby step). Afterall, it does provide guidance and recipes to build software and you can adapt it to any compatible code-frameworks (if you are creative enough). If we must have the word "framework" attached to it, I will call it an "Architecture Framework".

Still confused? Why don't you download it first and then tell me? ^_^

Sharing Code Between .NET and Silverlight

Recently, I have some time to look into the solution for sharing code between .NET and Silverlight again. It was an annoyance which everyone of us (including developers around the world) discovered, where we can't reuse our .NET classes in Silverlight. Any attempt to add reference to our .NET assemblies will land us the following error message:

"You can only add project references to other Silverlight projects in the solution."

If you are developing layered or multi-UI applications that involves Silverlight, then you would have encountered this error. This is not really a bug but actually is by design since both Silverlight and .NET don't share the same runtime. This is indeed bad news for those of us who try to follow proper architecture design practices since we are unable to share our entity classes.

If you packed everything to one WCF service, then you shouldn't have any problems because the "Add Service Reference" option in Visual Studio would have generated replicas of the entities into the Silverlight project. However, if you have separate services i.e. a WCF service to handle standard calls and a Workflow Service that runs workflows and both requires the same set of entities, then you will immediately run into issues because the replicas generated on both service references will not be compatible.

There is currently no out-of-the-box intelligent solution for this issue. This is a tooling limitation - I blame it on svcutil.exe. Most developers after several futile attempts will just try to manually replicate the entity classes to their Silverlight projects. This will solve the add reference issue but will introduce code inconsistencies should the entity classes are updated in future.

Fortunately, Visual Studio provides us with the "Add As Link" feature to allow us to share the same code files across multiple projects. However, this is somewhat a pain as well since we need to keep the projects synchronized when we add/remove items.

By luck, I came across this handy Visual Studio Extension - Project Linker which was part of the PRISM project. This neat tool allows us to "link" Visual Studio projects together keeping them fully synchronized so that we can have projects that share the same code base but target different platforms. It was originally designed for sharing code between WPF and Silverlight. You can also check-out the documentation here - very useful when you need to "unlink" projects ;)

So there we have it. Not a very elegant solution but at least it helps reduce the redundancy and ensure synchronization of our code.

Layered Architecture Solution Guidance 1.0.0.4

Just released the Layered Architecture Solution Guidance 1.0.0.4. If you have installed it, Visual Studio 2010 should prompt you for an update. There isn't much changes in this release other than numerous bug fixes. The most important fixes are with the Layered Azure Application and Layered Silverlight 4 Application.

The Layered Azure Application template has been updated to use the Windows Azure SDK 1.6. The Layered Silverlight 4 Application will now correctly generate the namespaces for the MainPage.xaml and App.xaml files. Previously, the project templates will create projects that would fail on execution.

The ConsoleHost project has also been dropped from automation in this release. This is to promote the use of WebHost as the recommended practice.

There is now an option to let the Momentum: DAC Gen to add the connection string to the WebHost web.config file automatically.

I had to push this version out to prepare for the enhancements planned for the next version.

Have fun and happy layering! ^_^

Tech Insights 2011

This is the first time that I have been engaged to speak in Tech Insights. This year, the event will be held at Monash University, Sunway Campus on the November 16th and 17th. Yups, that's tomorrow and the day after. I will be presenting two sessions on Windows Azure - one for each day. Both are architecture sessions (since I was specifically told to do architecture only *HeHe*)

For day 1, I will be presenting "Exploring Cloud Architectures" [Dev Track 2 - 1:30pm-2:30 pm] where I will be giving a very quick overview of Windows Azure and then dive straight into talking about how to migrate existing architectures (i.e. Monolithic, Client-Server, N-tier/3-tier, Message Bus and SOA) to Windows Azure. I will also discuss how scale-out is achieved on Windows Azure and illustrate some possible real-world hybrid architectures that leverages on Windows Azure, SQL Azure and Azure AppFabric. Finally, there will be a quick discussion on the cost and economics of leveraging Cloud solutions and also highlights on some possible architecture traps. This session will be informative for Brownfield scenarios.

On day 2, I will be presenting "Building Layered Azure Applications" [Dev Track 1 - 11:30am-12:30pm] which will feature Layered Architecture Solution Guidance (LASG) in the demos. I will be going through some key academic points on application architecture and then provide a brief explanation on the Layered Architecture design pattern (which was intentionally left out in day 1's presentation). The demo for this session will showcase how to use LASG to quickly build a simple layered application from scratch which can be deployed to both on-premise and the cloud. This session will be informative for Greenfield scenarios.

So, if you are free and are dropping by Tech Insights 2011, do attend my sessions ya. ;)

Silverlight with Controller & WCF

I have received many questions on how to wire-up a Silverlight UI to the WCF back-end in a Layered Application. I noticed most Silverlight applications being taught or structured today, are not properly layered. Most are following the Fat-Client 2-tier architecture style with business logic embedded in the Silverlight UI and data being hosted on a server (accessed via WCF Data Services).

While this sort of architecture serves its purpose as an application, it does not promote centralize/shareable business logic in the back-end. UI technologies are very volatile. Therefore, when UI technology changes, we do not want it to impact our business logic.

The first challenge in building a layered Silverlight application is of course the mindset. Once that is taken care off, the next will be to understand the challenge in the separation of concerns. In a layered application, the UI is divided into 2 component types - the UI itself and a Controller component. Many Silverlight developers face a challenge here due to the async nature of Silverlight calls to WCF.

This is caused by the Controller component which is responsible to communicate with the back-end. The existence of the Controller component causes a "disconnection" between the service calls and the UI controls.

In this post, I will attempt to provide a simple solution to address that challenge. Here's the scenario - Assuming, I have a method called ListEmployeeExpenses that takes an EmployeeID and lists out all the expenses that belong to an Employee. This method is hosted in a WCF back-end. On my Silverlight page, I have a simple Button to invoke the method and a DataGrid to display the results.

This is how I would do it:

1. In the UI.Process project, create an EventArgs class to hold the results from the WCF call. Example, I create a DataPopulatedEventArgs class.

public class DataPopulatedEventArgs : EventArgs
{
    public T Result { get; set; }
}

2. Next, create an Event and a method to raise the event in the Controller class.

public class ExpenseController
{
    public event EventHandler<EventArgs> DataPopulated;
    
    protected void OnDataPopulated(EventArgs args)
    {
        if (DataPopulated != null)
            DataPopulated(this, args);
    }
}

3. Now, let's put everything together in the method that calls to the WCF service. On the async completed event of the WCF service call, we create the EventArgs to hold the result and raise it with the DataPopulated event.

public void ListEmployeeExpenses(long employeeID)
{
    // Create proxy to WCF service.
    ExpenseServiceClient proxy = new ExpenseServiceClient();

    proxy.ListEmployeeExpensesCompleted += 
        delegate(object sender, ListEmployeeExpensesCompletedEventArgs e)
    {
        // Store the results from the call.
        var args = new DataPopulatedEventArgs<ObservableCollection<Expense>>();
        args.Result = e.Result;

        // Raise the event.
        OnDataPopulated(args);

        // Close the proxy.
        proxy.CloseAsync();

    };

    // Call the WCF method.
    proxy.ListEmployeeExpensesAsync(employeeID);
}

4. Finally, in our UI, we simply register to the DataPopulated event and bind the results to the UI Controls.

private void button1_Click(object sender, RoutedEventArgs e)
{
    // Create an instance of the controller.
    ExpenseController upc = new ExpenseController();

    // Register to the data populated event.
    upc.DataPopulated += delegate(object s, EventArgs args)
    {
        // Get the event argument.
        var dataArgs = 
            args as DataPopulatedEventArgs<ObservableCollection<Expense>>;

        // Bind to UI control.
        dataGrid1.ItemsSource = dataArgs.Result;
    };

    // Call the controller method.
    upc.ListEmployeeExpenses(6);
}

That's all to it! :) This is just one simple way to wire-up everything together. There are few other ways which I have experimented but this one seems to be the cleanest and have less code so far (not to mention easier to explain and maintain) ;)

Happy Layering your Silverlight apps!

Windows Azure Compute Emulator Hangs

The Windows Azure SDK 1.5 has a very annoying problem. I can't seem to deploy my project to the Compute Emulator. In fact, if I just create a new project and press F5, the deployment will also hang there with the status:

"Deploying service package to the Windows Azure compute emulator..."

After a while, Visual Studio will prompt the message:

"Role instances are taking longer than expected to start. Do you want to continue waiting?"

You can keep waiting but you won't be able to deploy it no matter how.

Doing a quick search landed me with this article. It mentioned this - "Identify any non-Azure service that is listening in the following ports: 12000, 12001, 12002, 808, 16001, or 15100."

Notice the port number 808? If you check your IIS Default Web Site bindings, port 808 is binded to net.tcp (for WCF activation.) Remove this binding and you should be able to deploy and test your Azure application in the emulator. Now of course if you have other WCF Services that use net.tcp activation on the machine like me, you are practically screwed. (You will need to change the port for those.)

I don't understand why is this port being used by the Windows Azure SDK? It is a default configured port in IIS Default Web Site for net.tcp binding but why the SDK uses it and causes itself to fail "out-of-the-box" ?

Layered Architecture Solution Guidance 1.0.0.3

Layered Architecture Solution Guidance 1.0.0.3 is now available. This release is slightly larger than the previous and I am glad I managed to get it done. Here's the list of changes:

General

Basic Layered Templates - There are now 3 new templates for building simple layered applications that do not require a services layer or workflows.

XML Comments - All code generators have been updated to provide an option to generate C# XML Comment placeholders or even default comments if desired. This option is turned on by default. Take note that the default comments generated are very brief and may not be as descriptive as how code documentation should be. Please feel free to change them.

Data Connections Setting - The Inertia: BE Gen and Momentum: DAC Gen have been updated to "remember" the previous SQL Server and database connection that you have chosen. You no longer require to re-specify your connection setting every time you launch these generators.

Partial Classes - Business Entity, Data Access Component, Business Component and UI Process Component classes are now generated as partial classes to allow easy extensibility.

Context Delete Menu - You can now right-click on the item to generate list to invoke a context menu to delete the items. 

Facebook Fan Page - All code generators have been updated to include a link to the Layered Architecture Sample facebook fan page. Remember to give it a "like" Ya! ;)

Collection Types - The Inertia: BE Gen and Momentum: DAC Gen have been updated to provide an option to select between generating entity collections as Generic Lists or Observable Collections.

Changes

• Added checks to prevent applying XMLAttribute to Nullable columns in Inertia: BE Gen.
• Added option to generate classes with property change notifications (with base class) in Inertia: BE Gen.
• Added option to re-arrange the order of data access methods in Motion: BC Gen.
• Added configuration code generation for Fault Handlers in Velocity: SL Gen.
• Added duplicate checks on adding endpoint configuration in Velocity: SL Gen. 
• Added support for creating Controller components directly from methods in Business Components in Impulse: UIPC Gen.
• Layered Azure Application template now automatically adds the Web and Web Host projects to the AzureService roles.
• Layered Azure Application updated to use templates from Windows Azure SDK 1.5

Bug Fixes

• Fixed issue with Update/Delete/Select methods being generated incorrectly with duplicates in Momentum: DAC Gen.
• Fixed issue with Motion: BC Gen randomly crashing when selecting Data Access Components.

The day of Ten Thousand

Today, Layered Architecture Sample for .NET has reached 10,000 downloads! I am glad that something like that which I did out of curiosity and self-learning during my own free time can been shared with people around the world. Personally, I felt that it is really difficult for a techie-girl in little Malaysia to have her work known across the globe.

I would like to thank everyone who have downloaded it and all the sites that had helped to evangelize for it. Love you all *Hugs*