• They are not clear on what they want 
• They should first define their requirements and then move forward with this 
• Our marketing team would accept just everything that client wants without pushback 
• Frequent changes will destroy the design

.. all pointing that we developers are unhappy and someone there is not doing the job correctly.

Times have changed and we are agile. Change is reality; business is changing every second. Think as if you have your own business - would you not like to make changes as you go, may be your vision changes with market, may be you want to do something different based on your competitors or based on some new innovative ideas and so on.. When your customer is asking for a change, it means a lot to them. It means a lot to the value to end-users that will be offered by the product you are eventually helping them to create. By buying into this change you are helping a wider community.

Agile methodology is all about accepting the fact that - change is constant. Agile helps to manage change. Does agile then mean that we keep changing things? I guess no. We should definitely reason and demand that why there is a change. We should evaluate and suggest the client if the change is not for good or if there are better alternatives. However, we should also understand that why someone wants to change and if this is genuine change, then we should embrace it.

Ten tips for Clients and developers involved:  

1. Reasons for change should be conveyed. People should buy into the idea. It also will help you validate and understand implications of the change and also invite other cheaper/better ways to have that incorporated. 
2. Frequent changes means that something could be going wrong. May be vision has a problem. May be execution strategy is not concrete, may be this is not the right time to start… And yes, implementing a change does costs something. 
3. A change control board (CCB) consisting of client stakeholder (Product owner and others) and vendor management/arch/lead responsible for change management should be trusted.
4. Change needs time to implement, this should be scoped well and included in the plan.
5. Developer’s can fix a problem as a hack or can provide proper desirable fix. If time will not be provided to implement the changes, changes can still be done but will involve hacks. Hacks will deteriorate the overall quality making system costlier and difficult to change as month’s passes by.
6. Design a flexible architecture which meets the current spec out requirements. Don’t overdesign and do accept the fact that design will change.
7. You can minimize the efforts by using appropriate design patterns, by following design principles.
8. Follow agile, follow refactoring, follow TDD… They will ease changing code.
9. Enjoy changing code, see how your design handles the change, you will definitely learn new ways of refactoring and also newer ways to design your next system.
10. Refactoring is fun. Once you achieve it and then when you see cleaner code you feel happy about it. And once change is delivered and it’s making difference in end-users life, that’s the real reward you get.

Next time you are facing a change, do question it and once answered, embrace it with affection. Change is good.

A traditional approach to initiating change within a company is to task a senior manager or even hire an outside consultant to scrutinize the existing processes, identify the problems and propose new solutions. Leveraging an outside point of view is often a logical approach because employees tend to get stuck in their own habits and can’t see the forest for the trees. However, this ‘top-down, outside-in’ approach can often lead to resentment among the workforce, resulting in a lack of cooperation that will inevitably render any proposed changes null and void. 

This may sound like an odd analogy, but ‘Save the Children,’ an international organization that provides aid to impoverished children, actually faced a very similar problem in 1990 when it opened an office in Vietnam. Resentful of having a foreign organization on its soil, the Vietnamese ministry gave ‘Save the Children’ representatives Jerry and Monique Sternin only six months (and minimal staff and resources) to ‘solve’ the problem of malnutrition among millions of children. Faced with a virtually impossible task, the Sternins decided to try something no one else had before: they asked the Vietnamese people themselves how to solve the problem. 

The Sternins enlisted the help of the mothers at a local village to identify children who were bigger and healthier than average and to discover what the families of these children were doing differently. Working together, they found that the parents of the healthy children were serving smaller meals more frequently and using different ingredients that had more proteins and vitamins. The Sternins and the village mothers used this knowledge to collaboratively design a program to combat malnutrition that, six months later, improved the health of 65% of that village’s children. The program eventually spread to other villages, where it has helped over 2 million Vietnamese children to date. 

So why were the Sternins so successful? Because they searched for the bright spots and cloned them. The mere existence of healthy children provided a ray of hope to the village mothers, who then provided the momentum necessary to change their village’s cooking and eating habits. The Sternins’ role as ‘outside expert’ was to simply ensure that these women were able to conquer malnutrition on their own. According to Jerry Sternin, “The traditional model for social and organizational change doesn’t work. It never has. You can’t bring permanent solutions in from outside.” 

This idea of modeling new process on past successes stems from a theory called ‘positive deviance,’ which examines the behavior of outliers to discover how they found a better way of doing something than others in their same situation. Although initially used as a term for sociological change, it’s clear businesses can also benefit from this ‘bottom-up, inside-out’ approach. While Agile emphasizes retrospectives, it’s important that in addition to identifying what goes wrong in a process, teams should also focus on what goes right. Find those processes that are working and duplicate them. Learn what your most productive team members are doing and have them train others. Talk to your most delighted clients and apply those lessons to others. In other words, to foster permanent change, clone your successes!

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

Ahem…. Ahem!

Well, when I thought of writing about this topic, was not sure where to start, but it has to be from somewhere. I love to introduce this word from the day it entered in my life. Probably you are wondering how come a word entered in someone’s life.

Don’t give pain to your brain; Let me tell you it is the word “Refactoring”

That was initial days of my new project; one fine day we got code from client, which he had developed from some other vendor. The moment I saw the code, my first reaction was; how can a person write code bitter to this extent? Literally, it was written very badly, even a good college student can write better piece. This was the point when I thought, is there something I can do with this code to improve it? And the answer was “Refactoring”.

Refactoring!!! This word has most influence on my mind in past few months. I had gone through many articles, books and all whatever I have access to. I found this quite interesting and very useful for software developers. Especially for those, working in large teams, long term project or uses agile development where the project design changes more frequently.

The very first thing to understand is that “Refactoring” is not solution of all software ills. Refactoring is a disciplined technique for restructuring an existing code, altering its internal structure without any change in its external behavior. It consists of a series of small transformations, which essentially preserves program’s behavior. Each transformation does very little, but a sequence of transformations produces a significant change.

One general perception I observed in most of the people, who think that refactoring always splits the code and creates more number of classes. This is not always true. There are some transformations which are opposite to this. They remove classes and minimize hierarchies.

I deliberately don’t want to introduce you with refactoring techniques here. I believe you can easily find them out on so many places via web search. Here, my objective is to talk about the concept behinds the refactoring idea and its relevance to developer’s life. One thing I really want to stretch upon is “Performance with respect to Refactoring”.

I had many discussions, where people try to compare the refactoring and performance; especially when some refactoring transformations make visibly negative impact on the performance. To make the program easier to understand, we generally make changes that result into program to run more slowly. I agree that software should not be too slow; otherwise they are not going to be accepted by end user. But here the point is; do not mix the performance with refactoring. You should not try to achieve both in one go. Even In classical software development approach the performance optimization is always comes at later stage. So first write tunable software and then try to tune it for sufficient speed during optimization.

With the study of thousands of projects, it is found that there are only 5-10% software which really having performance issues and out of this small bucket almost 95% project falls into category where the performance is hampering due to only 10% of code. These are known as hot-spots. So rather than optimizing the whole code in the project, during entire life cycle, why not we optimize only that 10% of code, moreover only if there are priority performance issues.

There are two types of development approaches -

First, most of developer follows. They try to write optimize code all the time they do coding. They are not much bother about refactoring and writing code that is easier to understand /maintain in future. Their main attention goes with efficiency and optimization of code. Here what happens is; as the project grew, it gradually becomes difficult to add more features and change the existing ones. The code is not that tunable in nature.

Second, go with refactoring, all the time you write code. In this case even if you project grew, the code will remain more maintainable, easier to understand and more extendable. This helps to do faster development. Even if some performance issues arise, you will be in well situation to figure those hot-spots and apply performance optimization techniques to get desired increase in the performance.

I think it’s time to signoff. If I still continue to write, it would be difficult for readers to digest in one go.

Hope you had a good time in reading.

Good bye

]]> http://blogs.globallogic.com/refactoring-refactor-your-thoughts-before-code/feed http://blogs.globallogic.com/hosting-a-aspnet-web-application-in-a-web-farm http://blogs.globallogic.com/hosting-a-aspnet-web-application-in-a-web-farm#comments Mon, 28 Jun 2010 16:12:25 +0000 dhejov http://blogs.globallogic.com/?p=958 Once the traffic on any website goes beyond what could be handled by single stand alone server the natural progression is to port the website into a web farm or web garden. There is a good article that explain the difference between web farm and web garden here (http://www.dotnetfunda.com/articles/article713-difference-between-web-farm-and-web-garden-.aspx ).

Few of the key points that need attention when porting an ASP.NET web application to a web farm are:

1.       ViewState Machine Authentication Code Validation or ViewStateMac Validation

2.       Session State Management

3.       Caching

Viewstate Machine Authentication Code Validation

 “EnableViewStateMac” is a security feature provided by asp.net to ensure data integrity. ViewState mac is nothing but the encrypted version of the encoded viewstate stored in the hidden variable on the page. When the property is set to true the framework will validate the viewstatemac return from the client to ensure that no data tampering has occurred. ASP.NET uses the machine key to perform the encryption and decryption.

So viewstatemac generated on a particular server in the farm will not work on a different machine as the machine key will be different. Available solutions are:

Solution 1: Disable ViewStateMac validation

We can do this by setting the web.config property “enableViewStateMac”  = “false”.

<system.web>

    <pages enableViewState =“false“/>

</system.web>

This is not a recommended approach as this can lead to security holes in your application.

Solution2: Matching Machine Key on every server

We can edit the machine key on every server in the farm to ensure that they match.

We can use the visual studio to generate a machine key. Please refer the following to know how:

http://support.microsoft.com/kb/312906

You can also use the following link to generate a machine key:

http://aspnetresources.com/tools/machineKey

Session State Management

For session state management to work in a web farm we need to ensure that session state mode is “OutProc”.  ASP.NET provides two different “OutProc” session state management options namely:

1.       ASP.NET State Server Service

2.       Microsoft SQL Server

Which one of these options to select completely depends on the nature of the application and nature of the data that is stored in session. Irrespective of our choice we need to ensure that all the data stored in session are serializable for “OutProc” session management to work.

One more critical issue we need to address while using “OutProc” session management is to ensure the application path is identical in the IIS metabase on each server. Please refer to the following link to read more about this requirement:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q325056

Caching

Unique instance of Cache runs in application scope of an appdomain. This implementation makes it impossible for using the default asp.net cache in web farm.  As these Caches instances run independently for each instance of the web application there is no default mechanism available to achieve synchronization among them. We can either write a custom solution that will provide as an “OutProc” cache (http://forums.asp.net/p/1077042/1588690.aspx ) or will have to use a distributed cache like NCache by Alachisoft.

Hope this would help you to port your asp.net web application to web farm with ease. Please share your comments in case I have missed points.

Before we start our journey I would request the reader to be patient enough to reach the end of the blog and not to draw a conclusion in the middle of it.

So what did I mean when I said “Agile the revolution”? Let us go back to the days when waterfall was considered as the de facto approach for executing software projects. People use to spend months and months on the analysis phase and more months on the design phase producing lot of documents in the due course and finally some code. The worst part was to seen the project failing after all this time and effort just because of all the wrong assumptions and predictions made during the design phase. This brought together a revolution which lead to the birth of completely new software development process “The Agile”.

Let us try to compare the same to any of the revolution that we have come across in the history of the mankind. The story begins with the existence of a government which exploited the citizen or to the least played blind eyes to the obvious problems that existed in the society. The state of anarchy grew to an extent that people revolted and toppled the so called government. Now what do we have, a completely lawless society. When we walk further down the roads of history we will find that soon some new group of people came together and put together new set of rules or constitution but this time based on the hindsight of the past.

So if we look closely the phase just after the revolution there was a small phase which leads to higher degree of anarchy. Closely examining the phase will make us realize that it was during this phase when the very ideology that inspired the people to revolt was blindly followed. So what is the moral of the story? The very ideology which brought about the revolution cannot be practices in its purest form on a normal course.

Before we go further with our discussion let us all try to summarize on what the software revolution was against:

1.       Counterproductive and irrationally long design phase.

2.       Piles and piles of document which would soon turn into some sought of relic.

Now let us step back and ask these questions:

1.       Don’t we need designing to develop a world class software product?

2.       Don’t we need documentation of the software product we are developing?

Don’t run for cover yet. Let us put the very first reason for the revolution under the microscope and try to derive our conclusion. Revolution was not against the process of software modeling per say but against the counterproductive way it was done. Upfront modeling was the real culprit that made the entire modeling process a victim. I cannot agree any more with Eric Evans (author of the book Domain-Driven Design: Tackling Complexity in the Heart of Software) when he said “The worst model I build was on the day one of the project and the best model I build was on the last day of the project”

What was he trying to convey? Software solutions are manifestation of the actual domain for which the solution is laid down. So how can we model a system to manifest a domain which we are least aware of as in day one of the project? Any attempt to derive a model on day one will fall victim to all wrong assumption and prediction about the future of the domain. But then due to all the frustration the desperation against the counterproductive software modeling phase which brought about the agile revolution there is a slight element of anti-model in it.

I am sure anyone who have spend enough time with software development agree that solving a problem without proper direction and guidelines will only lead to more problems. So what we need is not a complete no-modeling software development software process but rather a more productive and flexible modeling approach. Before I explain any further on the need of a model let us try to see the second evil which triggered the revolution.

Piles and piles of documents which would soon turned into relic. I am sure anyone who has been on those waterfall projects will recollect the nightmare of spending weeks reading those document to understand what they are needed to do and still find themselves as “Alice in Wonderland”. Now a pinch of reality “Can we survive with no documentation?” Most common argument I hear is minimal documentation but then how little is minimal documentation. One other interesting comment I here is “Code should be self documenting”. As soon as a developer is enlightened with this single line of software oracle they start decorating there code in all possible means.

Let us take a simple example of imaginary financial software module which calculates the principle at the end of every month. Basically there is a starting principle from which based on the monthly installment paid some amount will be deducted. But then for every 6 months which the customer has paid the loan without any default they will receive a small bonus which will again be deducted from the principle to finally derive end of the month principle. Now the developer who was assigned the user story came up with following classes:

·         Principle

·         Installment

·         DeltaDeduction

Now delta deduction is the amount that will be deducted based on the bonus earned over the period of 6 months.  Now no matter how well the DeltaDeduction class is commented it will be a source for uncertainty for anyone reviewing the code. First question will be “What should I relate the DeltaDeduction class to in the domain”. Rather if the developer would have named it as something like “NonDefaulterBonus” it would be have been self documenting even when it was not decorated with lot of comments.

Now even to name our classes correctly we need to understand the domain that we are working in and have some model of the same in our mind.

We need to realize that the end goal is not to complete a user story but to deliver a shippable piece of software with a tolerable degree of bugs.

Another common excuse made regarding the modeling is “We know we need some modeling to be done but cannot find time”.

So when did software development become a 100m sprint where all we care about is time. Software development without adequate modeling take us to the very software anomaly which is called as “Big Ball of Mud” (http://laputan.org/mud/ ).

“Co-owning the code” is another very religiously followed principle in agile. I am very sure where this is coming from. If you remember the old days when certain piece of the code is completely owned by one single person. It became completely impossible to make any change in his/her absence. But then does just co-owning the code solve this problem. Let us take a scenario consider a user story which span two modules A and B. The developer who is implementing the user stories works with the team which own the module A. Now to implement the user story he/she need to modify the module B. Risk is that the modification will be done without understanding the actual motivation that went behind the design of module as he/she was not part of the team which co-owned the module B. So the ownership cannot be code -centric but rather should be a domain context centric. Such contexts are called as Bounded Context in Domain Driven Design or DDD.

“Re-factor when your code starts smelling”. Again this is inspired by the fact that many of the waterfall project failed due to ignoring the known issues in the project which acted as time bombs which finally called upon the doomsday for the project.

In reality all large system are not well designed and investing the time and effort to re-factor every bit of the system to adhere it to all know design principle will not yield the expected benefit. The idea is to identify the core modules that the business relies on the most and keeping it clean all time. It is also very beneficial to identify the axis of frequent change within your project and re-factoring it enough to accommodate more changes. There are always going to be certain module of the software which would look more or less like Big Ball of Mud. But as we said before investing time and effort to get these modules re-factored might not yield the desired return. But again left unattended will make the chaos in these modules to creep into rest of the modules.

I am sure most of you are familiar with the Trojan horse story. Modules which are not well designed and re-factored are similar to the Trojan horse. If left unguarded the enemy (bad design) will creep into our castle (code). So how do we deal with such scenario? If the Trojan’s had put the horse in a fenced premise with a strong gate and a gatekeeper the enemy would have failed in their plan. So how do we build wall around these “Big Ball of Mud”. DDD offers a beautify pattern call the Anti-Corruption layer (ACL) that will mask the chaos from infusing into the rest of the software module.

So in short what need is not a completely no-design and no-documentation software development process rather a smatter way to model the domain and implementing the model in our code in such a way that it requires little documentation to be explicit.

I idea of this blog was to set the stage for my next blog “Introduction of Domain Driven Design” in which I will explain how DDD will allow you to achieve high degree of agility and still enjoy the benefit of having domain model in place. Most importantly I will also cover how DDD allow modeling and agile go hand in hand.

Although not officially Agile, Pixar’s entire process is empirical and employs an iterative and incremental approach to foster creativity, optimize predictability and control risk. Filmmakers meet every day to analyze the few seconds of film animated the day before and to gather feedback from the senior creative staff. Similarly, Agile software teams use Daily Standup Meetings to improve communication, identify and remove impediments to development, highlight and promote quick decision-making, and update the entire team on a project’s progress.

Pixar also realizes that mistakes are essential to long-term success. As Lee Unkrich, director of Toy Story 3, says, “We know screw-ups are an essential part of making something good. That’s why our goal is to screw up as fast as possible.” The very architecture of Agile ensures that projects fail early on so that teams can correct any errors before a lot of time and money have been invested. It also provides stakeholders with multiple opportunities to decide whether a project will succeed in the long-term or if it’s more strategic to go in a different direction.

Core to Pixar’s essence is its belief that just because something hasn’t been done before doesn’t mean that it cannot be done. Pixar does not just make films that perform better than the standard fare. It makes its films differently. Leveraging the practices of inspect and adapt, Agile teams also focus on addressing the unknown and unearthing what it is that customers actually value. They strive to deliver products that are outstanding in usability, quality and elegance by optimizing the development process (i.e., reducing waste, solving existing problems and relying on the collective wisdom of the team).

Contrary to the popular practice of assembling a cast of freelance professionals to work on a single project and then dismantling the team when the project is over, Pixar realized early on that creating new teams for each project prevents filmmakers from ever really learning how to work effectively together. Also, hiring talent on a short-term basis does not inspire loyalty to the project or even trust in fellow team members. Pixar rocked the boat by hiring its talent long-term to work on projects across the studio, as well as involving people from different disciplines to solve problems collaboratively. This practice is similar to creating cross-functional software development teams, as advised by Agile methods.  The resulting synergy improves the entire team’s overall efficiency and effectiveness.

If we are to learn from Pixar’s success, we need to challenge the status quo, encourage long-term relationships, and create a work environment where everyone feels they are part of something extraordinary. As software developers, we can follow this same roadmap by adopting Agile principles of building long-term teams, constantly communicating, freely expressing ideas and catching errors early in the cycle. With strong team values and a fluid development process, there’s no reason we as software developers can’t be as creative and successful as Pixar Animation Studio.

Sources:

Animating a Blockbuster: How Pixar Built Toy Story 3
Jonah Lehrer
http://www.wired.com/magazine/2010/05/process_pixar/

How Pixar Fosters Collective Creativity
Ed Catmull
http://hbr.org/2008/09/how-pixar-fosters-collective-creativity/ar/1

The Pixar Story
Leslie Iwerks Productions

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

The blog assumes that you have a basic understanding of Windows Azure platform and ASP.Net. The section below will provide overview on design / architecture changes involved for different components of a Web Application.

Important Note: This blog contains contents from different materials available on Internet from several sites. Purpose of this document is to gather those contents in a concise format at one place and provide inputs from our experience working with ASP.Net applications and Windows Azure CTP wherever required.

ASP.Net Web application Migration

Following headings details several aspects of a typical Web Application that will undergo changes.

Web Site to Web Application conversion

Only Web Applications (and not Web Sites) can be associated as Web Roles in the Windows Azure Tools for Visual Studio.  If you have a Web Site and are willing to convert it to a Web Application, Visual Studio provides a conversion tool.

App.config/Web.config changes

Because the web.config is part of the deployment, any change to the file also requires a re-deployment.  If you use a build system that targets your dev/stage/QA/prod environments automatically and can provide the correct settings in the web.config for you, this might mitigate the problem.

Alternately, you can move your settings to ServiceConfiguration.cscfg to allow for run-time update. You can also leverage RoleEnvironmentChanging and RoleEnvironmentChanged events if you want to be able to change default behavior of recycling the role on any config change.

.Net Full trust configuration

By default applications run under partial trust environment in Azure. To enable full trust for applications running in Azure, simply add the enableNativeCodeExecution attribute to your role in the Service Definition file and set the attribute value to true. This unlocks a number of compelling scenarios such as

• To allow using native code via spawning processes or Platform Invoke (P/Invoke)
•  Certain .NET libraries, including libraries in the .NET Services SDK, require full trust and can now be used in Windows Azure
• Inter-process Communication via Named Pipes: If you application spawns processes, you can communicate among them via named pipes.

Caching / State Management Migration

You will also need to make sure that you don’t have assumptions about the state of the machine you are running on – in the Windows Azure world, your service could easily be moved to a new VM.  For example, you cannot use in-process session state in an ASP.NET application that you plan to host within Windows Azure. Other considerations are as under:

1.       ASP.NET cache is not shared across instances.

2.       Memcached – a caching product can be used quite straightforward way for caching session state.

3.       Cookies, hidden fields - any client-side providers basically work fine.

4.       Velocity - not yet available for Windows Azure

5.       To store state, ASP.NET membership / profile providers for SQL Azure and Azure storage are available on Codeplex.

Forms Authentication Migration

Two options are available for Forms authentication migration:

a)       SQL Azure as the backend: Only requires you to change your connectionString, no other change is required.

b)      Azure Table Storage: You will need to use TableStorageMembershipProvider and TableStorageRoleProvider.

For details of Claims and Federated authentication, please see http://azuresecurity.codeplex.com/wikipage?title=Web%20Application%20Scenarios&referringTitle=Home.

Send Email from Cloud Application

SMTP service is not available within cloud. You can open TCP connections outside the Windows Azure cloud, so you can use an external SMTP server to send mail.

File System in Azure

A Windows Azure drive acts as a local NTFS volume that is mounted on the server’s file system and that is accessible to code running in a role. The data written to a Windows Azure drive is stored in a page blob defined within the Windows Azure Blob service, and cached on the local file system. Because data written to the drive is stored in a page blob, the data is maintained even if the role instance is recycled. For this reason, a Windows Azure drive can be used to run an application that must maintain state.

The Windows Azure Managed Library provides the CloudDrive class for mounting and managing Windows Azure drives. The CloudDrive class is part of the Microsoft.WindowsAzure.StorageClient namespace. See the Windows Azure Managed Library Reference for more information.

Once a Windows Azure drive has been mounted, you can access it via existing NTFS APIs. Your Windows Azure service can read from and write to the Windows Azure drive via a mapped drive letter (e.g., X:\).

COM  Support in Azure

COM is not supported in Windows Azure unless your components can be XCopied. The cloud machines do not have COM runtime installed. Currently the only native code supporting in Windows Azure is standard C++ library and standard Win32 API.

1.       COM Applications - typically have a dependency on the registry and won’t be able to update that when running in the cloud. Instead use registration-free COM+ with manifest files.

2.       To call a 32-bit DLL use a WCF host process

3.       Host external processes (EXEs) in a worker Role

Migrate WCF service to Cloud

Following considerations must be take into account for hosting a WCF service in Azure:

a)      Base Address: When hosting in Azure, ensure that the base address is the public load balancer address (for example http://wcfazure.cloudapp.net) as opposed to the address of the particular machine instance that Azure has allocated for our service.

b)      Partial trust: In Partial trust support, few of WCF features will not work. In order to access features that require full trust in the Azure fabric, your role needs to specifically opt in to full trust.

c)       Proxy Generation: Out of the box, using Add Service Reference or svcutil to generate a proxy to a service hosted either in the development fabric or the cloud fabric will fail. The WCF team has issued a patch that can be applied to the user machine in order to work around this issue. To configure a WCF service to use the patch, you need to configure the behavior from your service by setting <service behaviorConfiguration=”LoadBalancedBehavior” /> when you declare your service.

d)      Address filter mismatch: At runtime, WCF services may return the following error: The message with To ‘http://127.0.0.1:81/Service.svc’ cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher.The error can be corrected by applying the following attribute to the service class, [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

The above operations and available templates for WCF Rest Services development in Azure are detailed at this link: http://code.msdn.microsoft.com/wcfazure/Wiki/View.aspx?title=KnownIssues&referringTitle=Home.

Windows Azure supports ASP.Net ASMX Webservices. Both asmx and WCF services runs under Web Role to be accessible over http.

Migrate only SQL Server to SQL Azure

1.       From application to connect to SQL Azure DB, just change the connectionString

2.       If you are using ASPNetSQLProvider then you need to create required tables in SQL Azure database (with the new scripts available from Microsoft)

3.       Migrate your database to SQL Azure as detailed in SQL Azure migration section

ADO.Net Data Services and Entity Framework Support in Azure

You have to use a local database to create the EF edmx file, but once that is done changing the connection string to the SQL Azure database using “Server” instead of “Data Source”; “Database” instead of “Initial Catalog”; and the “User ID”, “Password”, and Trusted_Connection=False” instead of “Integrated Security=TRUE” will allow you to develop directly against the SQL Azure database.

Data Access Layer Migration

Only changing connection string from SQL Server to SQL Azure instance will be required. However, if you want to utilize Windows Table Storage instead of SQL Azure, then you will need to rewrite your Data Access Layer.

Background Job Migration

The Worker Role is similar to a windows service. It starts up and is running all the time. Instead of a timer, it uses a simple while(true) loop and a sleep statement. When it ‘ticks’ it performs some kind of maintenance work.

Worker role usually needs some data to work with. This data can come from a number of places. For example, the AzureServicesKit has examples that show you how to communicate between a worker and a web role via the use of a queue.

An example of using Worker role will be: You could potentially create a Cloud Service with just a worker role that monitors a particular Live Mesh folder for photos, and when a new one is added, it checks for that metadata with the city name, and inserts latitude/longitude coordinates as additional metadata.

Migrating Database Schema

To migrate an existing SQL Server database to SQL Azure you can export the schema as a Transact-SQL script and then execute that script against SQL Azure as follows:

1.       Export a script from SQL Server Management Studio and set the appropriate export options. Because SQL Azure supports a subset of features found in SQL Server, you may have to make some modifications to the script before you are able to execute it in the cloud.

2.       Execute the script to create the schema in SQL Azure.

You can use the Generate and Publish Scripts Wizard to transfer a database from a local computer to SQL Azure. The Generate and Publish Scripts Wizard creates Transact-SQL scripts for your local database. The wizard uses them to publish database objects to SQL Azure.

Note: SQL Azure does not support user-defined data types, extended properties, Windows authentication, or the USE statement.

SQL Server Data Migration

You can transfer data to SQL Azure by using the following:

·         SQL Server 2008 Integration Services (SSIS)

·         The bulk copy utility (BCP.exe)

·         System.Data.SqlClient.SqlBulkCopy class

·         Scripts that use INSERT statements to load data into the database

SQL Azure Migration Wizard – from codeplex

The SQL Azure Migration Wizard helps you migrate your local SQL Server 2005 / 2008 databases into SQL Azure. The wizard walks you through the selection of your SQL objects, creates SQL scripts suitable for SQL Azure, and allows you to migrate your data. SQL Azure Migration Wizard does not catch all of the compatibility issues between different levels of SQL Server databases (i.e. level 80, 90, and 100). SQL Azure is based on SQL Server 2008 (level 100). If you are migrating from an older database (level 80 or 90), you should go through the upgrade process first (at least in the dev environment) and once on SQL Server 2008, then migrate to SQL Azure. Link for details about this tool is mentioned in References section.

Utilizing App-Fabric

Once the application is on cloud, it can communicate with other applications on cloud or On-Premises using Appfabric Service Bus. Appfabric also includes Access Control service that provides federated authentication.

Conclusion

Windows Azure promises to be an extremely interesting environment for developers, service providers and companies trying to develop robust, highly available service environments.

In this blog we covered migration of several components of a typical web application. A detailed whitepaper on ASP.Net migration along with its benefits/limitations, product management considerations is posted on GINI at: https://portal.globallogic.com/confluence/display/GINI/Migration+-+ASP.Net+application+to+Windows+Azure

SOAP is a protocol where as REST is an approach. So we can completely model my system for REST approach and then implement it using SOAP/WSDL, CORBA or any other technology.

So what do we compare SOAP to?

I would say right comparison will be SOAP vs POX (Plain Old XML). Let me not get into much detail of how each one is laid down on the wire. On a high level POX is a lighter and easy to implement approach whereas SOAP is a more powerful and more interoperable.

So why do people still compare SOAP to REST?

It is the difference in how you model the system when you are going down the REST approach from how you would model the system if you were to use SOAP (of course I know it is not an approach J )

Look at how you would model a system with SOAP in mind:

Now look how you will model it when using REST approach:

I hope I have made my point.  J

The seven principles of Lean thinking are (1) eliminate waste, (2) create knowledge, (3) build quality (4) defer commitment, (5) deliver quickly, (6) respect people and (7) look at the entire value stream. These principles stem from the Japanese concepts of Muda, Muri and Mura – three distinct forms of waste. As I’ll explain below, these concepts naturally translate to the software development process. Eliminating these three types of waste in the product development life cycle can result in significantly reduced costs, accelerated timelines and improved product quality. Not surprisingly, Lean goes hand-in-hand with Agile methodology.

MUDA: An activity that doesn’t add value or is unproductive

Extra Code or Features

One of the biggest sources of waste in software development is extra features. Only 20% of most software features are used on a regular basis, meaning that extra features ultimately waste resources. They also reduce the lifespan of the software since a more complex code base is difficult to maintain over the years. Although it’s intimidating to reduce the number of features in a development project, it pays off in the long-run. If a software team truly understands what the customer wants, it should be able to launch a product with just the right amount of features – no more, no less. Think about the iPhone. In many respects, it has less features than other Smartphones, but those features it does have are much more elegant.

Partially Completed Work

“Work-in-progress” is a silent killer because, until the work is completed, you cannot know if there are quality issues. Partially completed work might also get lost, become obsolete or tie up resources. Examples include unchecked source code, undocumented source code, untested code, etc. 

Delaying the Test Phase

Not testing a product until the end of the life cycle is the root cause of undiscovered risks. Sadly, this delay often leads to huge amounts of rework and heavy costs to the organization. These reworks can be identified and corrected by following an iterative approach to development and testing early in the life cycle. Remember, either the code is integrated, tested and accepted – or it does not count.

Defect Queues

Defects render a team’s work incomplete, and a defect tracking system is essentially a queue of partially completed work. Although you may assume that a defect in queue will be addressed, the real goal should be to eliminate the need for a queue altogether. By implementing practices such as test-driven development and continuous integration, a team can ensure that no defects are introduced into the system while writing new code. This practice, coupled with automatically integrating source code, will reduce or eliminate the introduction of waste into a system.

MURI: To overburden or be unreasonable

Unrealistic Expectations

We all set unrealistic goals every year as part of our New Year resolutions. Similarly, project managers tend to load their development teams to create a sense of urgency and make them work harder. Not surprisingly, this practice leads to brittle software, hard-to-maintain source code and delayed timelines. Being realistic about variables like available resources, time and ability will go far to prioritize product backlogs and avoid overstraining your development team.

MURA: Unevenness or Inconsistency

Lack of Standards, Tools or Best Practices

Ask five people to work on a similar task, and they will most likely all adopt different methods. Similarly, not having standardized development tools and methods will result in inconsistent product quality and cycle times. Software development assisted by automated testing, code review, build and deployment tools can help reduce inconsistencies and thus improve costs.

Sharing a core set of values and principles, Lean and Agile are deeply interwoven. Lean focuses on eliminating waste, optimizing cycle times and delivering only what the customer truly needs. Agile emphasizes working closely with the customer to deliver the right products at the right time. Lean is more applicable at an organizational level while Agile focuses on the development process itself. I believe merging these two approaches will result in a dramatic improvement in both how products are developed, the quality of these products, and the overall value chain of an organization.

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

Alan MacCormack, a professor at Harvard Business School, asked a software firm to identify a “good” and a “bad” project. The firm’s executives said that their “good” project was one where the specs were completed up-front, the design was optimized, it was executed efficiently and on-time, and the final product was very close to the initial specs. Alternately, the “bad” project went through constant change as the development team struggled to understand what the customer really wanted. The team had to respond to frequent changes, and the final results were very different from the initial specs.

MacCormack then rated the products from both “good” and “bad” projects based on market acceptance, quality and productivity. He found that the “good” product was a market failure while the “bad” product was a market success. It’s not surprising that the iterative development process created a better product. The real eye-opener was that the company’s managers thought that learning about the market and then building a product to satisfy it was “bad.”

Based on this experiment, MacCormack identified four software product development practices that spell SUCCESS:  

• An early release of the evolving product to the customer with a minimum set of features
• Getting early feedback from the customer and improvising the design
• An experienced team able to make the right decisions
• A modular architecture that is optimized for change rather than maximum performance

Another equally important measure of success is your customer’s delight with the product. We see plenty of average software products all around us, but we seldom see a valuable and elegant product that truly catches our attention. In 1984, Dr. Noriaki Kano published a paper on “Attractive Quality and Must-Be Quality,” in which he presented the Kano Model – a tool to identify how to create products that will delight the customer.

The Kano model showed that the threshold (or “must have”) features are those that must be present in the product for it to be successful. Improving the performance or amount of a threshold feature beyond a certain point would have little impact on customer satisfaction. After this, there are two options: either increase performance by adding new features or discover needs that the customer isn’t even aware of and meet those needs.

There is no substitute for developing a deep understanding of what customers actually value once they start using the software. Great products emerge from a team that truly understands both the business and the technology requirements.

Agile teams work in collaboration with customers towards a single, customer-perceived goal. They ask important questions outside of the requirements spec: why develop the product, who is the end user, why and how a particular feature will benefit the customer, how they work, etc. This collaboration occurs throughout the partnership.

At the same time, Agile teams continuously strive to reduce waste from the value chain: delays, extra features, extra code, partially done work, defect queues, etc. The team works in an iterative and incremental mode and seeks customer feedback on completed features at the end of each iteration. Such a collaborative environment eliminates the risk of misunderstanding the customer’s needs and business requirements.

You cannot simply assume that a project was successful because it was delivered on time and conformed to the spec. Agile teams, through close and effective collaboration with the customer, remain concerned for the overall market success of their products – not just for the successful delivery.

So how can you tell if your latest project was successful? Simple: ask your customer. It is the customer’s delight with the product – and the delight of their customers –that truly reflects the success of your project.

References:

1: Please look at Alan MacCormack’s work at http://agile2003.agilealliance.org/files/AlanAgileSoftwareJun03.ppt. This story is also covered in “Implementing Lean Software Development (Book)” by Tom and Mary Poppendieck

2: Kano model (April 1984): “Attractive quality and must-be quality” (in Japanese). Journal of the Japanese Society for Quality Control 14 (2): 39–48

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic