SharePoint 2010 Site Home Page

In SharePoint 2010, if you add a new page called "Home" (Home.aspx for the real file name) to your website, it automatically becomes the default home page of your "SitePages" directory. If you open the URL "http://yoursite/SitePages", it will lead to the new home page "Home.aspx".

If you intended to hide the original default page "http://yoursite/SitePages/Forms/AllPages.aspx", this is fine, of course. You just have to remember that it breaks the link "Site Pages" on the "All Site Content" page, or anywhere else for that matter. When you click on "Site Pages", instead of showing your site pages, it will now hop over to your "Home.aspx".

 

 

 

 

Problems When Renewing a Multi-domain SSL Certificate on IIS 7

Last weekend, I needed to renew my multiple domain SSL certificate on my IIS 7 server. The IIS manager just did not work right, and the process was a little complicated. So I would like to share my experience here, hoping that it will help others faced with the same situation.
First of all, how do I know which version of IIS I was running? When you are hosting multiple domains, the default IIS website home page is not likely going to be the IIS start page. So checking the default website home page usually does not work. I opened Windows Task Manager, and selected "Show processes from all users":

  

Then I right clicked on "w3wp.exe", and on its popup menu, I clicked on "Properties":

  

Then I clicked on the "Details" tab:

  

I see that the version number is 7.5…

Now about the SSL certificate installation.

First I installed my new multi-domain certificate by clicking on the "Server Certificates" icon in the IIS Manager Home pane.

The certificate is not applied to any of the websites at this point. I went to the "Bindings…" menu of each website, and edited the https port 443 bindings. I selected the new certificate for each website. I ran into a problem immediately. IIS started to shut down my sites, saying that the port 443 was in use. This is because the "Host name:" field for https binding is always read-only and always blank, even though I had a valid host header value for port 443 before. After the certificate selection, IIS actually changed the host headers to blanks! As a result, all my sites tried to respond to all requests on port 443.

At this point, I had to fix them from the command line. First, I navigated into the "C:\Windows\System32\inetsrv" directory, and then I ran the following command:

appcmd set site /site.name:"IIS Site Name" /-bindings.[protocol='https',bindingInformation='*:443:']

The "IIS Site Name" came from the left pane of the IIS manager. The "-binding" switch removes the binding that does not have a header value specified. Then I ran the following:

appcmd set site /site.name:"IIS Site Name" /+bindings.[protocol='https',bindingInformation='*:443:www.*******.com']

Here www.*******.com is the root of each website URL, in my case each has the form of www.*******.com.

That completed the renewal.

The Choices for Intra-System Data Communication

In the .NET world, WCF has been the de facto data communication standard for quite some time. When designing a distributed multi-tier software system, most software designers would choose to use WCF to connect the various subsystems. For example, in Figure 2 of my previous post, the communication between the website ("Website") and the backend service ("Service") is usually handled by WCF.

WCF client is very easy to setup. C# code can be generated with a few mouse clicks from WSDL provided by the WCF server. But it has several problems when used for this task:

1. Maximum WCF message size is pre-determined. When handling data of unpredictable sizes, it may hit a message size ceiling and stop working. The standard solution is not pretty: once you have determined that the maximum message size is the problem, you will need to re-configure it and the system will restart. If you go to a streaming solution, you will lose some very important WCF security features.
   
2. WCF messages are transmitted in XML over HTTP, so HTTP load balancers cannot easily perform some of its basic tasks such as retrying WCF operations. For example, if the XML contents of the WCF message command the service tier to create a new object, a retry without interrogating the service tier would end up creating redundant objects. In contrast, a RESTful communication layer can be easily understood by HTTP load balancers. The balancers would know which operations they can safely retry without interrogating the service tier.
   
3. The data objects that are transmitted to the recipients are "raw". Consuming these data objects will require a lot of work.
   
4. When running under IIS, it has all of the limitations of the HTTP server in addition to those of its own. For example, the maximum download limit that exists for other services still applies.
   

Software designers are moving to RESTful services for some very good reasons:

1. Its message sizes are only limited by the HTTP server that it runs on.
   
2. By staying with HTTP verbs that the HTTP load balancers can understand, load balancing is quite straightforward.
   
3. The payload is smaller for the same data objects.
   
4. When RIA service is configured as a RESTful service, the recipient can handle data objects as if they are local. Although one can use RIA service as a WCF service as well, but the RESTful approach is much more appealing.
   

There are other reasons RIA RESTful service should be the best choice for Intra-System Data Communication, but these should be compelling enough.

Software Architecture and Ease of Implementation

A complicated software system can be designed in many different ways. Even though there may be many design choices that will lead to the same system feature set, the same user interface, and even the same quality, these designs may require very different amounts of development effort. In other words, the cost of implementing these designs in terms of time and money can vary quite substantially.

This claim itself is not very hard to understand. The million dollar question is: how do you design a system so that it can be implemented quickly, easily, reliably, and completely?

Again, at the top level, this is not a very hard question. Some answers would come to mind right away: the KISS principle, canonical forms that can be reused, advanced algorithms that cut down complexity, utilization of existing solutions, etc.

There may not be an exhaustive list of answers to this question. Here, I would like to start with one of the most important: designing the system with your development team in mind. If the design cannot be carried out by your development team quickly and reliably, it is not a practical design, and it is not a good design. Ease of implementation of a design does not mean it is easy for your architect to carry out the design work or how easy it would be if your architect were to write the code; it is supposed to be easy for your development team.

What is taking so long?

Let us start with a basic "CRUD system" that performs the basic operations of "create(C)", "retrieve(R)", "update(U)", and "delete(D)" on a data object with a dozen various attributes from a database:

Figure 1 Basic 3-Tier System
 

If you ask a programmer on your development team to implement such a basic system with Microsoft MVC .NET or ASP .NET using EDM from scratch, he should be able to complete it in no more than 10 minutes. If you ask the star programmer on your development team, it would be even quicker. Even if you demand detailed data validations on all attributes with localization, it would still take no more than half an hour.

Of course, in practice, a system is never this simple. For security and scalability, additional tiers are needed:

 

Figure 2 Distributed Multi-tier System
 

Here, the part of the system that is responsible for binding the view to the data object, namely the website or the presentation tier, is separated from the rest of the system by a remote access connection to the service tier. This separation provides mainly the following benefits:

1. A compromised website will not expose the data tier directly to the intruder.
2. Multiple websites and multiple service servers can be load balanced.

The connection between the service tier and the data tier is abstracted so that it can be either local or remote, depending on the data source. This separation provides mainly the following benefits:

1. Data format complexity is hidden from the service tier. Complete different data sources can be used the same way.
2. Multiple database shards can be used for load distribution.

After this seemingly simple change, if you ask a programmer on your development team to implement the same "CRUD" operation again, the time it takes will increase from half an hour to two weeks or even longer!

Unfortunately, this separation of responsibilities is not the end of real world design escalation. In many cases, more complicated delegates instead of functions are needed to further increase system flexibility. The system described in Figure 2 will change like a chameleon depending on the object that is being operated on. Now if you ask a programmer on your development team to implement the same "CRUD" operation again, the time it takes will increase to half a year or more, or perhaps never!

Can we keep it simple?

It is the architect's responsibility to stay with design patterns that a programmer on your team can understand. In Figure 1, binding an EDM entity to an HTML control is something that every programmer can easily do with Visual Studio scaffolding. Can we handle the data binding in Figure 2 the same way, and get it done with the same speed?

The answer is yes, of course. A good example is Microsoft RIA service. It hides the complexities of remote object handling in WCF, and exposes a programming interface to the object in question that can be treated exactly like it is local. If the architect can design the system this way for each implementation task, your implementation speed will increase tremendously.

A service like Microsoft RIA not just takes programmers back to a familiar pattern. It provides many other benefits:

1. A canonical form requires virtually no programmer training.
2. It is much less error prone.
3. It provides data validation and presentation localization features that could otherwise be challenging to your programmers.

The list can go on further. But we can sum it up by saying that a pattern that is familiar to your programmers will allow them to get their jobs done quickly, easily, reliably, and completely.

Some may argue that Microsoft RIA service is only one example. There must be other cases where this example does not apply, right?

It is a devil's staircase

With a devil's staircase, if you put a small section of it under a microscope, you will find that it looks just like section that you were looking at earlier without the microscope. With the stretched version of the "CRUD" system in Figure 2, if you zoom into a small section of it, you will still find patterns like the one in Figure 1:

Figure 3 3-Tier Input/Output Pattern
 

These simple patterns can easily be implemented by programmers on your team. If we design with these simple patterns to build bigger simple patterns at the next level, the entire system will be implemented quickly, easily, and reliably.

Over design/Under design

Microsoft RIA is a great service. It should serve as an example for architects who are trying to implement systems depicted in Figure 2. However, it does not solve the problem of over design or under design. Because software architecture is a devil's staircase, its complexity can grow exponentially. By following the simple 3-tier input/output pattern, one can easily see this exponential growth in action. An over designed system will become impossible to complete mathematically. At that point, a copy-paste solution that spread linearly might seem wasteful, but it will be the only sensible thing to do: your programmers cannot even count 4 billion patterns before your deadline if your patterns are 32 levels deep. A number 32 may seem small until you put in the exponent!

Microsoft RIA would have been a perfect service if it were implemented for a single class of software applications. However, using it without EDM is extremely difficult. So it is under designed as a general purpose service. In the past I have developed a system that allows you to access data RIA service even if the data is not from an EDM data source. It is used in the Online Business Pro software system that I developed.