Thursday, March 25, 2010

Silverlight 4 Hands On Lab

Silverlight Data and Controls Series

Hands On Lab for Silverlight 4

After the Mix 2010 Conference there has been a lot more excitement for Silverlight 4 and RIA Services. If you want to start to learn Silverlight 4 and RIA Services this is what I would recommend. First go the Silverlight website and review some of the learning materials there - there is a ton of good stuff there (

However most of us require a more hands to actually learn something. I recently found that the Swiss MSDN Team published a very detailed Silverlight 4 Hands On lab here -

This lab is absolutely great in that is over 100 pages of step by step labs that taught me the following:

  • How to create a Silverlight and RIA Service Project.
  • Created a simple Entity Model and wired up a grid.
  • Incorporated both Server and Client side filtering of data in the grid with RIA Services and LINQ.
  • Added a Busy Indicator and DataPager controls to the grid.
  • Added custom formatting and sorting to grid columns.
  • Added an AutoComplete control to filter the grid.
  • Added persistence to the grid to perform CRUD operations. Plus added concurrency checking to the grid.
  • Created a data form for master and detail data to support for CRUD operations
  • Implemented server side validation attributes to domain classes and created custom validation classes.
  • Added custom lookups into the data form.
  • Created a custom Data Transfer Object (DTO).
  • Created custom domain methods.

There were several other labs which I did not complete on:

  • New printing capabilities of Silverlight 4.
  • Add right click menu items
  • Using the clip board.
  • Using COM Interop to send data to Excel.

Creating Lab Environment

I really found the labs a great way to learn Silverlight 4.

This lab was built for Silverlight 4 with Visual Studio Beta 2. As you know with the announcements at the Mix Conference, you can now use Silverlight 4 with Visual Studio 2010 RC. Plus a new RIA Service RC was also released. To get started doing this lab do the following:

Modifications to Lab

Since this lab was published there have been some changes and not all things worked. There were a few small things that you will have to differently to complete the lab. This is because RIA Services RC release changed up several things.

Page 21 – Use System.ServiceModel.DomainServices.Client instead of System.Windows.Ria. Reference -

Page 41 – Use the following for Code Snippet 7 instead of what is provided:


<riaControls:Parameter ParameterName="city" Value="{Binding ElementName=shipCityBox, Path=Text}" />



Page 45 - Data Conflict Detection – This section was seems to be out of place, skip it and complete later.

Page 63 - Snippet 12 – Need to modify the code slightly.

return new ValidationResult("Maximum freight cost for UK exceeded.", new string[] { "Freight" });

Saturday, March 20, 2010

RIA Services RC Changes for Visual Studio 2010 RC

There were a lot of announcements that came out of the MIX 2010 Conference around Silverlight 4. One was that RIA Services now has a Release Candidate. I have a project that will be utilizing Silverlight 4 with RIA services. I had some functional design stuff that I had built with Silverlight 4 and RIA services with Visual Studio 2010 Beta 2 because until the MIX conference that was the only way.

Well a couple things stopped working when I tried to go to Visual Studio 2010 RC with new release of Silverlight 4 that works with VS 2010 RC and RIA Services RC.

I found this reference that described the changes for the RIA Release Candidate that you need to be aware of. Please go here and read through the changes -

Some important things you should be aware of:

  • Several of the assemblies changed names.
  • There was a bunch of refactoring and classes have moved between different libraries.
  • Working with the ValidationException class has changed up a little and will require some modifications.
  • There were several changes to the DomainDataSource which broke with my old code.
  • There is a conversion wizard upgrade RIA service built in VS 2008 to VS 2010.
  • And several more…

SharePoint 2010 Logical Architecture


In the previous blog in this series I introduced the new service architecture of SharePoint 2010. There are several changes and understanding these changes will drive both the logical and physical topologies of SharePoint 2010. When I refer to the logical topology, this means the logical organization of SharePoint services that will be used to satisfy the business needs. The physical topology is the installation and configuration of those services. The goal of both topologies it to provide a solution that is:

  1. Scalable
  2. Secure
  3. Maintainable
  4. Has high performance
  5. Fault tolerant

In this blog I will take these themes and apply them to various way in which SharePoint 2010 can be configured to support the logical topology. I will go into the physical topology in the next part.

SharePoint 2010 Changes

The biggest change in SharePoint 2010 is the flexibility you now have with the configuration and re-use of services. In the initial blog about services, I identified several rules that you should know which will directly apply to how the logical architecture of SharePoint 2010 would be done. Here they are again:

  1. Multiple instances of the same Service Applications can be initiated within a farm.
  2. Service Applications are shared across Web Applications within a farm by Service Group.
  3. Some Service Applications can be shared across multiple farms while others cannot.
  4. Service Groups can logically contain Service Applications that reside in other farms.
  5. Web Applications have the flexibility to use multiple instances of the same type of Service Application (regardless of which farm hosts that service).
  6. Service Applications can have its data partitioned and only accessible to specific subscribers.
  7. Service Groups can be used to logically scale for performance, security and scalability.

In the following sections I have indentified some common scenarios for configuration of SharePoint 2010 logical topology based on these rules. It will not be possible in this blog to go over every permutation these rules.

As well best practices for the configuration of these services is still not very well known other than the information is being provided to us by Microsoft and our experiences with SharePoint 2007. However you should be able to take these examples and use them as a way to start doing some early planning for implementation SharePoint 2010.

Side Note – If you are familiar with some of the logical topology diagrams that are provided by Microsoft they usually include Application Pools in those diagrams. I have decided to exclude that from these diagrams to make understanding the logical topology simple. Albeit understanding how the Applications Pools are incorporated into the topology is extremely important (security and fault tolerance). Usually when architecting a SharePoint topology I start with understanding how I want to organize service to achieve the best possible performance, security and redundancy. Once I have that organized, I will then use Application Pools to help attain those tenants.

Single Farm Single Service Group

This first topology depicts a standard SharePoint farm that has a single service group that is shared across all types of sites. Any time new sites are added within this farm, they will have access to all of the services that are available in the Default Application Group.

Untitled 1


  • Most simple architecture to implement.
  • All web applications added into the farm have immediate access to all the available services.
  • All services are grouped together and can be managed centrally.


  • Does not allow for isolation of data used within the services. This means that all websites have access to each other’s data.
  • Cannot create dedicate services for specific web applications.
  • Will not scale well because publishing and collaboration would be occurring in the same farm.


  • This is an initial place to start as your configuration for SharePoint 2010. It can always be scaled or reconfigured to support more demand.
  • It would be recommended to make sure that each service that can be partitioned be made partitioned. Service partition is introduced in the first part of this series. This is important because it not possible to partition a service after has been created. If services are partitioned from the beginning you have the ability to create some isolation of data between site collections.
  • These sites could all be installed on a single web application but that is not recommended. It is better to created dedication Web Applications for each running within their own application pool. This provides long-term scalability.

Single Farm Multiple Service Groups

This second example is a reconfiguration of the previous farm; the difference is that multiple Application groups have been created. There is a Default Application Group which has some of the core Service Applications that can be used by all the sites. Some sites, however, will have dedicated services. You will want to have dedicated services for scalability, performance and security reasons and this will be covered later on from a physical perspective.

Untitled 2


  • First thing that is interesting about this configuration is you see the Managed Metadata Service is configured into each application group. One interesting thing we will see with SharePoint 2010 is better ability to manage the Information Architecture, a key ingredient for Governance. We now have the ability to create reusable Information Architectures across sites and farms as well as created dedicated ones.
  • Second you will notice that Search has been centralized as part of the default application group and has been made a resource to all the sites. This is because it is a resource intensive process and it is not likely you will be creating dedicated search farms for a specific site. Note that FAST search cannot be used in this manner. FAST can either be used behind the firewall or outside but the same servers cannot be used for both.
  • Third application services have been distributed and dedicated. For instance Excel Services, BCS, Access Service, etc. are broken out.


  • Supports the ability for multiple goals to be met in the same farm.
  • Provides the ability to have better isolation of services. This provides the ability to have a granular implementation that better support scalability, performance and security.
  • Allows for divisional, department, or program administration.


  • Complex configuration to manage.
  • Requires more Governance and administration.
  • Will require more hardware/virtual resources to host.


  • This configuration is good for a small SharePoint implementation within a department, division or business unit.


In this farm configuration we have broken it out and created several independent SharePoint farms that still use central services farm.

Untitled 3


  • Sites have been separated into dedicated farms based on usage such as public internet, extranet, internet and intranet.
  • Each farm has dedicated application groups of services that specific to their use.
  • All the farms have access to shared services in central services farm.


  • There is a clear separation between the sites by placing them in dedicated farms. This is very important because publishing farms and collaboration farms have been separated.
  • Organizations can be segregated from each other and prevents the initiatives of one from interfering with the initiatives of another.
  • Farms can be configured with service groups that are specific to their needs.
  • Central services can still be shared across farms where it makes sense.


  • A more complex configuration that requires more considerable time to administer and govern.


  • This is an enterprise farm configuration.
  • This configuration should be implemented when a company has the need to optimize administration and hosting at the enterprise level.
  • This configuration is needed when data and services need to be isolated but there is still opportunity for reuse.

Multi-Farm with Application Service Partitioning

This farm configuration introduces service partitioning into the pervious diagram. Service partition is introduced in the first part of this series. It is recommended that all services be partitioned when they are initially set up, even if one partitioned is only used. It is not possible to change a service to allow for partitioning after it has been started in an un-partitioned state.

Untitled 4


  • In this diagram you will see in Farm A both the Managed Metadata and Business Connectivity Services have been partitioned. Others could have but just selected these for discussion. Now Farms B through E and utilize partitions that are just for them and they will have isolation.
  • Notice in Farm D we were able to remove those services from the configuration. This makes the management of that farm less complex.
  • Notice in Farm E we kept the Managed Metadata service. There is nothing from stopping that and can still be considered completely legitimate. For instance the administrator in Farm C does not have access to Farm A, and all they are using from Farm A is a partition of Managed Metadata that all the farms are using. If that is the case, they may want to still have a Managed Metadata service in Farm C so that they can make tactical additions to the Information Architecture.


  • Provides even more granularity and isolation of data management within SharePoint 2010.


  • Again an even more complex scenario for managing services for an enterprise farm.


  • Using service partitioning must be a strategy considered when setting up an enterprise SharePoint 2010 farm.

Hosted Partitioned Farm

The last farm configuration I will introduce to you is the concept of a completely hosted farm. This is a very interesting scenario because you were not empowered to do this very well with SharePoint 2007. Some SharePoint service companies provided SharePoint hosted solutions but given what was available in SharePoint 2007. Now with SharePoint 2010 and Microsoft Azure those limitations have been removed.

Untitled 5


  • This scenario should not just be considered for providing SharePoint 2010 hosted solutions by a services company. A company itself can consider creating a solution like this for creating on demand solutions for provisioning full farms in a rapid fashion.
  • This scenario would also make sense for a parent company that has many subsidiary companies that they want to service in an economical fashion.
  • As you will notice this approach heavily uses service partitioning. The goal is to make the farms as lightweight as possible.


  • Utilizes many of the enterprise best practices discussed so far.
  • Since partitioning is utilized, there is isolation of data between farms.
  • Governance and administration is centralized into a single location and is not spread across farms.


  • Because all services are centralized, it is not possible to create customizations at the farm level. This means that if a farm has a special functional, performance or security requirement it may be hard to support that requirement.


  • If you are creating a hosted solution and the expectations can be set ahead of time this is a good approach. However this is very hard to do and more often than not there will be requirements that will require dedicated services within the farms. It is ok to set out with this in mind but you must remain flexible to support an architecture like the one in the previous section.

What’s Next

In the next part of this series we will continue this line of discussion but for the physical topology of SharePoint 2010. We will focus on what is a small, medium and large farms.