Charteris Community Server

Excel Services ODC - Data Refresh Authentication Error

colinn — Tue, 26 May 2009 11:50:57 GMT

Just thought I'd blog this as I had trawled the web and come up with all sorts of complex answers.

The scenario - a Windows Authenticated SharePoint site running Excel Services but anytime a user refreshed a data connection through a browsable Excel workbook they got a data access error.

Most of the advice on this suggested implementing a Single Sign On solution through an SQL solution or Kerberos.

I couldn't help thinking there must be a simpler way - fortunately there is!

When creating the odc in Excel on the Save Data Connection File and Finish click on the the Excel Services "Authentication Settings" which is trying to hide itself at the bottom of the screen. Then select 'None' for the setting.

Now the blurb along with the 'None' selection suggests that it will use the 'data connection' id which I found a bit confusing (like many things I could list here, but that's for another time!)

What the blurb means is that it will use the Unattended Service Account found in the Excel Services Settings in the Shared Services Provider (it's at the bottom hiding again like it don't want to be used).

So when it comes down to it a single radio button click - much easier than implementing SSO!

Del.icio.us Digg It Share on Facebook Stumble It!

Central Admin SSL

colinn — Wed, 15 Apr 2009 15:56:32 GMT

Steve Smith and Spencer Harbar (again - oh no I've become his groupie!) were discussing Best Practice around setting up Intranet, Extranet and Internet sites - far too detailed to relay here I'll stick a link up when the slide deck becomes available -

However, one area they discussed in detail was what should be on SSL and they recommended that if nothing else uses port 443 then Central Administration. I hadn't given it much thought but now that its been highlighted to me there is certainly one compelling reason for this. A rogue user could cause catastrophic damage to a farm if they got hold of the Central Admin password, so even in an intranet environment why would you have these credentials flying around unencrypted?

Del.icio.us Digg It Share on Facebook Stumble It!

Lockdown

colinn — Wed, 15 Apr 2009 15:55:47 GMT

I haven't done much on the Internet Content Management side lately which is my way of getting in my apologies/excuses for not knowing about this feature (call it expectation management - I won't ask what your expectations were).

Another great session hosted by Andrew Connell and Spencer Harbar on publishing sites highlighted the use of the ViewFormPagesLockdown feature (click on 'lockdown mode' for the info). This little feature will stop anonymous users from accessing application pages such as page libraries and view site content. Which is very useful (and apparently not enabled on many big Internet facing SharePoint sites!).

Del.icio.us Digg It Share on Facebook Stumble It!

Like A SharePoint Cowboy

colinn — Tue, 07 Apr 2009 16:20:56 GMT

Sorry for the Glen Campbell reference - couldn't resist, I'm getting help with it.

I promised some more on Eric Shupps excellent presentation on Custom Site Definitions. There's a guide on Mr Shupp's blog on how to build a Custom Site Definition. There is also a good diagram of how a Solution Package breaks down.

The Cowboy is also going to put up a VS2008 base solution for a a site definition and I'll pop that link up when I get it

Del.icio.us Digg It Share on Facebook Stumble It!

A Love, hate, Hate, HATE Relationship

colinn — Tue, 07 Apr 2009 12:38:08 GMT

Given the tag line I'll bet you guessed this post is going to have a SharePoint Designer theme. I was in a brilliant talk by Eric Shupps (the SharePoint Cowboy) on branding and custom site definitions (more of which in a later post) when he reminded everybody that SharePoint Developer is now available as a free download and what it was and was not good for:

PROS:

Design Surface
Simple Deploy
Extensive layout control
Utilise with minimal programming skills
Versioning

CONS:

Can only use on a single site collection at a time
Requires unghosting
Limited options for advanced functionality
Not portable

So looking at the list why would you use it? Especially since unghosting means that the modified page is held in the database instead of being cached!

The answer is not often but there are occasions where it is useful:

Prototyping master and layout pages
On small sites where performance is not an issue
Where you want to empower Power Users and allow them to make small modifications to a few pages

For most things the site definition route should be taken, more of which later.

Del.icio.us Digg It Share on Facebook Stumble It!

The Anti-Practice

colinn — Tue, 07 Apr 2009 08:29:07 GMT

Since this is a Best Practices conference there has been much discussion of what not to do. However, there seems to be divided opinion on what to call... well the opposite (see what I mean). I've heard 'Poor Practice', 'Bad Practice', 'Worst Practice' but my favourite was coined by Natalya Voskresenskaya - the Anti-Practice - suitably apocalyptic.

Del.icio.us Digg It Share on Facebook Stumble It!

Stranded in the Mid-Atlantic

colinn — Mon, 06 Apr 2009 16:58:17 GMT

There's been a lot of Twittering in the ether of late regarding just where Spencer Harbar's accent has migrated to. It's obviously bothering him because before he even started his talk on SharePoint Farm Misconceptions he had apologised for any lingual fluidity that might occur.

Spencer was discussing common SharePoint Farm myths particularly around the "Magic Numbers" published by Microsoft. As many of you will know most of these get revised frequently, infamously the number of site collections a farm could support stood at 50,000 in 2007, the latest figure is 150,000. These numbers are just an indication of how far Microsoft pushed SharePoint. The latest studies can be found on technet. There is one immutable number though 2GB that's about it for document size.

In large farms with vast content design of the data storage is proving to be more vital than any perceived SharePoint "Magic Numbers". A good case study can be found here and you might be surprised at how few SharePoint servers were required to handle this huge amount of content.

The key point of Spencer's talk was you have to test you can't trust the literature. Limits will be determined, as you would expect, by the usual key factors of usage, network traffic, server specification etc and each farm or collection of farms is going to be different. There was also the intriguing idea of the Agile Farm - you should plan your initial SharePoint topology with the view that it will change as the provision is expanded to new user groups and functionality is enhanced. An absolute truth but probably not one faced up to in many projects - back to Joel's key point of overcoming denial.

As for Mr Harbar's accent, well I've heard him speak on a few occasions now both in person and on web casts and I couldn't detect any difference but then I was concentrating more on what he said than how.

Del.icio.us Digg It Share on Facebook Stumble It!

Registration and Keynote

colinn — Mon, 06 Apr 2009 12:02:25 GMT

I was going to start by sticking in a picture of the Queen Elizabeth II conference centre but I'm not sure if I really want to inflict that on you - I'll see how my mood develops later in the day. All I can say is at least when you're in it you don't have to look at it.

Anyway enough aesthetics laced with architectural snobbery you're here for the SharePoint bits right?

Joel Oleson gave the keynote complete with Monty Python clips (for reference The Holy Grail bunny sequence, SharePoint being the bunny) and tourist bating union-jack themed head gear. To summarise Joel gave 10 Steps to a Successful SharePoint Deployment:

Overcome denial - it's not easy, it's not just a case of installing the product; start simple with quick gains.
Create a Plan - if you don't know where you're going then you won't know when you've arrived.
Get an executive level sponsor with a clear vision - you may not implement their full vision but again it's good to know where the road might lead.
Build the Dream Project Team

Designer
Business Analyst
Site Collection Admin
Content Admin
SharePoint Admin
SharePoint Dev

Build services not stuff - this will generally be a balance between Commodity (out of the box) and Application hosting. How much of each will ultimately depend on the balance of time and resources
Define clear policies and standards - let's call this governance but there's a balance to be found between IT Control and User Empowerment
Invest in a Scalable Information Architecture
Don't forget or ignore Change Management
Adoption is what counts
The 'KISS' principle - nope nothing to do with aging glam rockers - Keep It Simple Stupid!

For me the first three points felt most relevant. There is still a major misconception out there that SharePoint as an application akin to Word or Excel, "Lets stick the disk in let the users loose on it and see what happens."

Then you do the numbers and inform them of how much doing a SharePoint project with proper planning and governance will cost.

And the look you get?

Well it's like the conference centre, not pretty...

Del.icio.us Digg It Share on Facebook Stumble It!

SharePoint Best Practise Conference

colinn — Sun, 05 Apr 2009 18:21:05 GMT

The conference kicks off in London tomorrow and there seems to be plenty to interest anybody with even the vaguest, passing intimation of an interest in any of MOSS' myriad of forms.

The first of these was held in Washington DC last year and demand was such that a couple of others followed quickly. This is the first (and according to the official blurb) only one that will be held in Europe this year.

The full agenda can be found here

Of the different streams probably ITPro holds the most interest for me but I'll be dipping into other sessions depending on me colleagues choices.

Anyway I'll blog here what nuggets come out...

Del.icio.us Digg It Share on Facebook Stumble It!

SharePoint and Databases

alistairl — Mon, 23 Mar 2009 11:37:06 GMT

Something that you will learn to realise with Microsoft Office SharePoint Server 2007 is how important it is to have a handle on the SQL Server aspects of your farm installation. Ok, if you install everything on a single box and use Express edition you don’t really care about SQL much but try to do anything more adventurous and your SQL Server infrastructure will take a bit more thought.

Explorer a bit further and there are a few points regarding network protocols and port numbers that are important to understand too. My background in web development with an added dash of DBA work means I am very interested in this, but it can be easy to forget the basics.

For instance (forgive the pun), I had a reminder recently of how little you learn if you only have to deal with the default situation. For instance, in a lot of cases your separate SQL Server will be available to use on the default instance and default port number, but do you know what to do if you cannot use either? In the case of instancing, remember that you can qualify the server name with the instance i.e. SQLSERVER\Instance. And in the case of port numbers, remember it is SQL Server and not IIS you are talking to so the syntax is to separate the server and port number with a comma, not a colon. So to slightly extend our very small example, the database details for an instance on a non standard port would be “SQLSERVER\Instance, 9999”.

Another thing to remember with any kind of service is that the request by a client of a server can be more of a “conversation” by the end of a sequence of events between agreeing that the two parties can talk to actually getting down to the nitty gritty of exchanging the information at the centre of the discussion. When looking at SQL Server and instancing, we need to be aware of the SQL Server Browser Service which provides SQL clients with instance details. In particular, as each instance requires its own port number, the reserved port of 1434 accepts UDP connections from clients asking for the port number of a particular named instance. Of course you can connect if you have all of the information to hand, but if you try to connect to a particular instance with incomplete parameters then the SQL Browser service may come in to play. And if the service is not running or firewall rules block connections on that port, then the connection will not work. For a better explanation of this technology that came in with SQL Server 2005, look at SQL Server books online on the SQL Server Browser Service.

Del.icio.us Digg It Share on Facebook Stumble It!

Smart Client architecture

deniss — Fri, 20 Mar 2009 07:14:00 GMT

Recently I had a chance to develop an application in the core of which laid a model called a Composite Smart Client. In the next few posts I would like to share my experience and opinion related to this technology.

Composite Smart Client model is actually another form of more general model defined by term Smart Client. In this introductory post I’ll overview more general term first and move to Composite Smart Clients in the next post.

The term Smart Client is dedicated to highlight the differences between the typical "Rich Client" and “Thin Client” applications and the next generation of client applications. To understand the need in Smart Clients let’s have a look at the pros and cons of both the existing architectures:Rich Clients:Pros:- Rich user experience- Offline capable- High developer productivity- Responsive and FlexibleCons:- Tough to update- Tough to deploy- “DLL” hellThin Clients:Pros:- Easy to update- Easy to deploy- Easy to manageCons:- Network dependency- Poor user experience- Complex to developSmart Clients sit in between these two architectures, incorporating the best their features.So, as a result we have the application with the following typical characteristics:

Utilize Local Resources
Rich user experience is achieved by utilization of local resources. It means everything from hardware to software resources available on client’s machine.
Connected
Smart client applications are never standalone and always form part of a larger distributed solution. This could mean that the application interacts with a number of Web services that provide access to data. Often, application may have access to specific services that provide deployment and update services.
Offline Capable
Because they are running on the local machine, one of the key benefits that smart client applications offer is that they can be made to work even when the user is not connected. Even when the client is connected, the smart client application can improve performance and usability by caching data and managing the connection in an intelligent way.
Intelligent Install and Update
Smart client applications can be deployed and updated using a variety of techniques, like downloading over HTTP, on demand deployment by clicking on the URL. Applications can be updated while running. Exact approach depends on the technology used to develop an application.
Client Device Flexibility
Often, there will be multiple versions of the smart client application, each targeting a specific device type and taking advantage of the devices unique features and providing functionality appropriate to its usage.

.Net Framework provides number of capabilities to build applications with Smart Client architecture.

Another popular sub type of Smart Client applications is the Composite Smart Client Application model, where many applications combine to form a coherent solution. Such solutions can be formed by coupling together desktop applications, or by providing a generic "shell" application that houses multiple lightweight applications combining to form the solution. This model has proven to be extremely useful in situations where the user has to deal with many applications to do their work.In the next post I’ll discuss technique of building Composite Smart Client Applications in .Net and how it was used in ITV.

Del.icio.us Digg It Share on Facebook Stumble It!

ASP.NET MVC in production

gopalk — Tue, 17 Mar 2009 19:07:46 GMT

Is ASP.NET MVC ready for production use?

ASP.NET MVC Beta version was the first one to come with an explicit go-live licence. We went live with our first ASP.NET MVC website in December, based on ASP.NET MVC Beta and the results have so far been very impressive. The beta was of high-quality and very stable during development. With the release candidates its only got better and hopefully the release version isn’t too far away. In my opinion releasing the source code and keep the community involved via Codeplex, forums and blogs has played no small part in keeping the quality of this framework high.

The website has performed very well since then under some pretty intense load. So in our case, ASP.NET MVC is certainly proved itself ready for production use. Here I have tried to compile a list of ASP.NET MVC tips, advantages and pain points based on my experience with ASP.NET MVC.

Tips for MVC

Before using ASP.NET MVC think about your UI requirements. Are you counting on a third party UI library? If you are thinking of using third party controls that use postback or viewstate then ASP.NET MVC may not be for you! Although bear in mind that it is possible to have ASP.NET webforms page within an ASP.NET MVC web application.
Decide on client side and server side validation strategy early : ASP.NET MVC doesn’t have validation built in, it only provides support for it via ModelState. You’ll need to decide on a server side validation framework e.g. Enterprise validation block, data annotations, Castle Validator etc. You’ll also need to decide on a client side validation framework e.g. jQuery validate plugin.
Understand controller lifecycle and ActionFilters: Understanding the lifecycle of the controllers and about ActionFilters will help you create controllers and presentation logic correctly and with minimal code. It will also help you move the cross cutting concerns like authentication, authorization etc out of your presentation logic. See my previous post for this.
Have base class hierarchy for controller and views to provide required functionality: Don’t derive from the Controller class directly for your controllers, but create a custom base controller where you can provide functionality common across all controllers. I have found this useful for Views and Model classes as well.
Move routes out of code into configuration: Having to recompile every time you add a new route is a pain, move the routes out into a web.config or an external file. This is easy to do as ‘defaults’ parameter on RouteCollectionExtensions.MapRoute no longer expects anonymous types, an object of type RouteValueDictionary can be passed in.
You can use URL rewrite module along with routing: It is possible to use regex url rewrite module along with MVC. This will kick in before MVC receives the request and MVC will receive the modified request. This is useful for cases where you want to use regular expressions as as regex routes are not currently supported by MvcRouteHandler.
Keep Views as dumb as possible: Remember Views are supposed to be so dumb as to require minimal testing, so keep it that way.
Keep controller as lean as possible: Having too much code in the controller is a sign that you are perhaps missing a Service facade class.
Anything involving viewstate or postback will not work within a ASP.NET MVC page: Support for ASP.NET webforms controls is limited e.g. ViewState and Postbacks aren’t supported. Test any controls you plan to use early on with ASP.NET MVC. There are other options like MVP if you absolutely need a server control not supported by MVC but want the testability benefits of ASP.NET MVC. ASP.NET webforms page can be used within an ASP.NET MVC web application.
RouteData is very useful – If you want to get hold of any route related data associated with the current request. It is accessible within Controller and Views and it can be used to retrieve current action name, controller name, route name etc.

Why MVC?:

Separation of concerns – separation of concerns in dividing the UI (View) from presentation logic (Controller). The domain model is separated from the above two as well, but that’s a common practice even if you are using ASP.NET MVC webforms.
Testability –The controller receives user input, acts on user input, supplies ViewData to the View and presents the View to the user. This clear input and output model means that controllers are very testable.
Extensible – Extensibility is a big feature of ASP.NET MVC. Some of the many extensibility hooks within ASP.NET MVC are:
- RouteHandler – The default ASP.NET MVC route handler is MvcRouteHandler. A custom route handler can be used if you want customized route handling logic for a particular route.
- ControllerFactory – Create your own controller factory if you want to instantiate your controller using an IoC container, or choose one from here http://www.codeplex.com/mvccontrib
- ViewEngines – Views are normally located and processed by WebForms ViewEngine infrastructure, but there are custom ViewEngines available like nVelocity etc.
Control over HTML – ASP.NET MVC allows fine grained control over the HTML generated, great if you don’t like all auto generated HTML related to viewstate and server controls in ASP.NET webforms.
REST – ASP.NET MVC provides SEO friendly and RESTful URL’s
MVCContrib – Last but not the least, a great resource, provides lots of community contributed content for MVC.

That said ASP.NET MVC is still very new and naturally has a few areas that need a bit of work:

Grouping of controllers – ASP.NET MVC doesn’t provide a way to group controllers into ‘areas’, which is quite important for a large project. There are a few solutions from the ASP.NET MVC community for this, including one here: http://blog.codeville.net/2008/11/05/app-areas-in-aspnet-mvc-take-2/
View and ViewData issues– ViewData container object is not strongly typed, this results in a lot of defensive coding within the View in reading values from this container. This also causes any possible type mismatches not to come to light until runtime. Using strongly typed views can help this issue to an extent, so can using Generics base ViewData setters and getters like this:

       SetViewData<T>(“keyname”, T data);
    

End to end validation framework – An end-to-end validation framework is missing. This at the moment means defining validation rules both at the server side (e.g. via Enterprise validation block) and client side (e.g. via jQuery) separately. The new xVal framework aims to address this issue: http://www.codeplex.com/xval
Repeater controls – Simple rendering controls with templating capability such as Repeaters etc are sorely missed in ASP.NET MVC. An possible solution here: http://haacked.com/archive/2008/05/03/code-based-repeater-for-asp.net-mvc.aspx
Self contained controls – At the moment user controls in ASP.NET MVC are not fully encapsulated i.e. the code required to load the ViewData for the control must be called from every controller that presents the control. Subcontrollers aim to address this: http://www.codeplex.com/mvccontrib
IIS6 install a bit messy – Installing MVC on IIS6 involves setting wildcard mapping and needs to carefully planned and tested early on. Make sure to disable wildcard mapping from any sub folder that only contain only static files for performance reasons. More info here: http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Regex support for the routes – At the moment routing system doesn’t support regex based routing. A possible solution here : http://blog.sb2.fr/post/2009/01/03/Regular-Expression-MapRoute-With-ASPNET-MVC.aspx
Asynchronous processing – While there is no out of the box support for asynchronous processing within ASP.NET MVC, here is a possible solution: http://blog.codeville.net/2008/04/05/improve-scalability-in-aspnet-mvc-using-asynchronous-requests/
Dynamic loading of routing – Routes are right now added from within code and there is no support for storing routes within an external data store, although such a functionality can be easily added. Many possible solutions available for this including this: http://mnour.blogspot.com/2008/11/mvc-routing-using-custom-configuration.html

Given the ASP.NET MVC framework is relatively new, these shortcomings are quite understandable. Furthermore most of the above issues also have community contributed solutions and workaround, so none of them pose a major impediment to the use of ASP.NET MVC. The framework should also improve and add features that are currently missing with newer releases. It remains to be seen how the vast server controls market for ASP.NET webforms responds to ASP.NET MVC. I think that this will be quite important for the widespread adoption of ASP.NET MVC. Overall, in my opinion, ASP.NET MVC provides us with a new reliable, testable and extensible framework for web development which is well worth trying out.

Del.icio.us Digg It Share on Facebook Stumble It!

SharePoint Deployment Planning Services

alistairl — Thu, 12 Feb 2009 16:50:23 GMT

I am part of a team within Charteris that is qualified to deliver consulting under the SharePoint Deployment Planning Services (SDPS) program from Microsoft. “What is SDPS?” I hear you cry, “Why should I care?”.

The idea of SDPS is to help Microsoft Software Assurance customers with getting the most out of Microsoft Office SharePoint Server by allowing them to claim a number of days time with a SharePoint consultant. Registered Microsoft Partner Organisations deliver the consultancy, and this has to follow a prescriptive plan for content and deliverables.

I think it is a great idea for a number of reasons, for one thing you don’t pay the consultant – Microsoft does (of course, you pay for Software Assurance so you do pay in a way), but for another it is a great way of catching up with the current version of SharePoint and a great structured way of finding out what is in there and perhaps carrying out a proof of concept. And from a consultant perspective, the support material coming from Microsoft for SDPS is excellent and up to date. We have a content refresh coming up in March which is going to further strengthen the quality of the material delivered to you as a customer.

SDPS delivery comes in 1, 3, 5, 10, and 15 day engagements and from a consultant perspective we have a prescribed set of deliverables from each. Some are for the bigger engagements, but some come with all sizes and reflect the content of the days. As you may have guessed (the clue is in the name) the primary aim is to plan SharePoint Deployment, and to this aim the engagement will feature consideration of business needs, how SharePoint can answer these and the plan moving forward. The 1 day engagement focuses on the business value of SharePoint and how this might fit to your needs, and at the other end of the spectrum, the 15 day engagement includes this, and labs, proof of concept work and a lot more deliverables.

I recently conducted a 3 day SDPS Engagement in Edinburgh with a Legal Firm. The Firm had considered SharePoint 2003 in the past but wanted to get up to date with SharePoint 2007, and relate this to their business needs. As I dealt primarily with the IT Team, I tailored the agenda to demonstrations of the product and balanced this between covering the functionality of SharePoint with maintaining questions and answers. This is another aspect to remember with SDPS, although the deliverables and materials have a strong prescriptive element, the aim is to maintain the quality and this can happen while tailoring the delivery to the specific needs of the customer. For a 1 day engagement this can even mean that your engagement will take place over a series of live meetings – great if you can’t get your team in one place, we are all busy these days.

I find SDPS engagements quite rewarding because they are a great opportunity to get out there with SharePoint and help customers to understand all of what SharePoint can do, but also very importantly – to approach it with the proper planning that is appropriate for an Enterprise Application.

Del.icio.us Digg It Share on Facebook Stumble It!

Some of those SharePoint Prerequisites to Remember

alistairl — Thu, 12 Feb 2009 11:33:42 GMT

A recent visit I made to install SharePoint for a production extranet reminded me of the importance to plan ahead and make sure that the prerequisites for successful installation and operation are in place before a visit. The big difference between development and production is the flexibility of the environment and the control you have over it. I would suggest this is the case because things like change control don’t necessarily exist (at least formally) on your Virtual PC environment that sits on your laptop on which you have local administrator rights!

It is also easy to take for granted that a server will have internet access, or to take for granted that the local machine you are using to Remote Desktop to the production environment has a high speed network link. You are reminded how important planning ahead is when you have to wait for several hundred megabytes of install media and service packs to trickle over a slow management link, while you watch the progress meter guessing how many hours you have to wait.

So I brought together my notes to get a quick shortlist of the things to have in place before a successful site visit:

Install Media – now that virtualisation is so prevalent, iso images are very easy to mount against a virtual machine. The thing to remember to do is to get the iso image over to the production environment in advance of the install. In our case we brought the files together on the web front-end (WFE) machine.
Product Key – you don’t get very far before you need to enter that product key for Microsoft Office SharePoint Server (MOSS) 2007, so have it handy for when you start the install.
.NET Framework Redistributable Packages – you need .NET Framework 2.0 and .NET Framework 3.0 for a successful installation, and make sure you get the full distributable for the correct platform (x86 or x64) and not the bootstrapper. Get the bootstrapper for either will lead to disappointment when you discover you cannot download the rest of the components on your production server.
Service Packs etc – there are several important service packs that should be in place – check with those that manage your windows server platform. But, in summary, remember to be up to date with Windows Server, SharePoint 2007 SP1 and after, and the appropriate .NET service packs. And in the case with our install, that means having the appropriate redistributable files copied to the correct place.
Parameters for outbound email – if you are using email alerts etc then you will need the name or ip address of an smtp server to relay messages through, something you may need to prearrange with whoever owns the relay. There are also the sender and reply-to email addresses to have to hand.
Port Numbers – this is important for a production environment where you cannot assume that there will be routing between the machines or that ports will be open for inter-server communication. Change control to get ports opened in firewalls can take some time, so it does well to establish at planning stage which services will be used. To install SharePoint with a separate SQL Server database connected to over tcp/ip will require a port to be opened, normally 1433. If you plan on restoring or making backups, then you will need to open ports to allow the WFE and SQL Server servers to access the backup files. For file share you need UDP ports from 135 to 139 and TCP ports from 135 to 139, or for direct hosted SMB without netbios you need port 445 (both TCP and UDP). If you plan to use outgoing email then you need to open the port for SMTP, which is by default port 25. This also assumes that routing is in place for your users to connect to the WFE, to allow server management, and routing for Active Directory.

Note that the notes do not incorporate any idea of the order of events, which should be obvious but may be the matter of another post.

Del.icio.us Digg It Share on Facebook Stumble It!

How does ASP.NET MVC work – Part 2

gopalk — Wed, 11 Feb 2009 07:41:21 GMT

In the last post we saw how an ASP.NET MVC request gets routed through to the MVC framework through the ASP.NET framework. We also saw that the MvcHandler class is the HttpHandler responsible for servicing an ASP.NET MVC-request. A simplistic view of the order in which routing and MVC classes come into play is like this:

UrlRoutingModule -> MvcRoutingHandler -> MvcHandler

So at this stage our request has got an HttpHandler assigned in the form of MvcHandler. Moving ahead in the HttpApplication event processing, the fulfilling of a request takes place when the ProcessRequest method on the MvcHandler gets invoked.

MvcHandler

Within the ProcessRequest method, the original HttpContext is wrapped into an HttpContextWrapper instance. HttpContextWrapper implements an abstract class called HttpContextBase.

Loose coupling: Within an ASP.NET MVC controller, HttpContext is referenced not directly but via this abstract HttpContextBase class. As evident, this enables loose coupling between your controller class and the HttpContextWrapper instance and thus improves testability by allowing you to easily mock your HttpContextBase class when performing unit tests. This loose coupling also extends to other objects like Request (referenced to via HttpRequestBase) and Response (HttpResponseBase). These abstract types are defined within a separate assembly System.Web.Abstractions.dll. This opens up the possibility of using them outside the MVC framework!

Compare this to a traditional WebForms Page, where the Page class references the HttpContext via a direct reference, and the HttpContext object is also sealed. So it’s difficult to mock HttpContext for testing purposes, thus making a WebForm page difficult to test. This is one clear advantage of ASP.NET MVC over traditional WebForms.

At this point we have two classes that carry information about the request. These are RouteData and HttpContextWrapper (Packaged up into RequestContext and assigned to MvcHandler earlier during the PostResolveRequest stage of the UrlRoutingModule). RouteData is a dictionary object containing key value pairs related to the matching route. The information RouteData will contain will typically be controller name, action name, route name, default parameter etc matching the current request. These are extracted from the parameters passed into the RouteCollection.RegisterRoute calls made in Global.asax:
```
   1: routes.MapRoute(
```
```
   2:     "Default", // Route name 
```
```
   3:     "{controller}/{action}/{id}", // URL with parameters 
```
```
   4:     new { controller = "Home", action = "Index", id = 1 } // Parameter defaults
```
```
   5: );
```

RouteData can also be used from within the Controller (via ControllerContext) and View (via ViewContext) to get the current route name, action name, controller name etc. Thanks to RouteData dictionary, at this point MVC knows the name of the controller and the action to be invoked.

ControllerFactory (DefaultControllerFactory)

Further in the ProcessRequest method, a controller must be located to fulfil the current request. To do this, a controller factory is acquired first. By default in ASP.NET MVC this is an instance of DefaultControllerFactory. In typical ASP.NET MVC fashion there is an extensibility point here too.

A controller factory must implement IControllerFactory interface and a custom controller factory can be registered to override the DefaultControllerFactory in Global.asax.

   1: protected void Application_Start() {
   2:     ControllerBuilder.Current.SetControllerFactory(<Your controller factory>);
   3:     ...           
   4: }
One of the reasons you would want to register a custom controller factory is, if you want your controllers to be instantiated by an IoC (Inversion of Control) container and injected with dependencies like Loggers etc dynamically. There is some more information on how to create a custom controller factory for ASP.NET MVC here: http://www.pnpguidance.net/Post/SetDefaultControllerFactoryIControllerFactoryASPNETMVCFramework.aspx

The MVCContrib project on Codeplex makes available controller factory classes with support for various popular IoC frameworks like StructureMap, Castle Windsor, Unity Framework and Spring.NET: http://www.codeplex.com/MVCContrib

IController (Controller)

Once an instance of the controller is retrieved from the controller factory, Initialize method is called on the controller. This is an important part of the controller lifecycle which provides access to the request and is a good place to initialize properties on the controller.

IActionInvoker (ControllerActionInvoker)

Next the Execute method is invoked on the instance of Controller class and RequestContext is passed in as an argument. This sets off the controller lifecycle. An object of type IActionInvoker rather than the controller itself controls the order in which various methods on the controller and filters are executed.
```
   1: bool IActionInvoker.InvokeAction(ControllerContext controllerContext, string actionName)
```

(ControllerContext is composed of the RequestContext and Controller instance.)

Notice the separation of concerns and yet another point for extension. A custom implementation of IActionInvoker can be assigned to the Controller if we want our action invoker to do things a bit differently. The default implementation of IActionInvoker is ControllerActionInvoker class, and does quite a bit behind the scenes as we’ll see below:

First parameter values are obtained for the parameters on the action method. This is done by a ModelBinder. A ModelBinder is responsible for converting the data in request (i.e. form parameters, querystring parameters etc) into parameter values that an action method accepts. Of course, this is yet another extensibility point in the framework where a custom ModelBinder can be assigned to an action method via the use of attributes (Note the influence of AOP (aspect oriented programming) in the framework). The default ModelBinder is used if a custom ModelBinder is not specified. More information here on creating custom ModelBinders: http://www.singingeels.com/Articles/Model_Binders_in_ASPNET_MVC.aspx

Now the various filters are executed. Simply put, filters are interceptor methods that can execute before and after the action method execution. They allow you to separate cross cutting concerns or non-action-specific code from the code in the action method (Notice the nice use of AOP). There are different types of filters:

Authorization Filter – IAuthorizationFilter interface
Action Filter – IActionFilter interface
Result Filter – IResultFilter interface
Exception Filter – IExceptionFilter interface

Authorization Filter is the first set of filters to be executed. Processing can be halted within this stage by cancelling the action. This can be done by setting the cancel property on AuthorizationContext to true.In the code below, the further processing of the action is cancelled, the RedirectResult is executed which should result in a redirect to Login action. An authorization attribute can be implemented by deriving from AuthorizeAttribute (which implements IAuthorizationFilter) and applying the attribute to an action method. The Controller class itself implements IAuthorizationFilter, so the easiest way to implement an Authorization Filter is to override the OnAuthorization method inside your controller class.
```
   1: public override void OnAuthorization(AuthorizationContext filterContext)
```
```
   2: {
```
```
   3:     filterContext.Cancel = true;
```
```
   4:     filterContext.Result = new RedirectResult("/Home/Login");
```
```
   5: }
```

Action Filter – OnActionExecuting: If the processing isn’t cancelled above, then the OnActionExecuting method on the action filter collection is executed. Again as with Authorization Filter, Controller itself implements IActionFilter interface, so an OnActionExecuting method is available to be overridden within the controller class. This is another point where execution of any further action filters and the action itself can be cancelled by setting the result property to an ActionResult of your choice.
Action method itself is invoked with the parameters supplied by the model binder.
Action Filter – OnActionExecuted: After the execution of the action method, OnActionExecuted method on the action filter collection (including the OnActionExecuted method on the controller) is executed. In this method you can get information on any exceptions that were thrown during the action method execution via ActionExecutedContext.Exception. Here you have a chance to handle the exceptions and stop further propagation of the exception by using the ActionExecutedContext.ExceptionHandled property.
Exception Filter – OnException: An exception filter must implement IExceptionFilter interface. As with other types of filters, it can be applied as an attribute. The controller implements IExceptionFilter interface and provides access to its functionality via OnException method that can be overridden within the controller class. This is called if an exception is thrown anywhere during action or result execution. An exception thrown in the Action can be handled in OnActionExecuted to stop it from being propagated up to this stage. Similarly as will be explained later on, an exception thrown during result execution can be handled inside a ResultFilter OnResultExecuted stage to stop it from getting here. ExceptionFilter offers you the final chance to handle exceptions before the exception is thrown up to Global.asax. HandleErrorAttribute is an exception filter provided out of the box with the framework to help with exception handling within the controller.
Result Filter - OnResultExecuting: This step occurs before the ActionResult is executed. A result filter must implement IResultFilter interface and the Controller class offers an implementation via the OnResultExecuting and OnResultExecuted methods. The request will only get here if there are no unhandled exceptions in the action method and the OnActionExecuted stage.
ActionResult execution – This is the stage where the ActionResult is executed and the http response determined. ActionResult is just an abstract class and is extended by specific type of action results like ViewResult (for HTML output), JsonResult (For Json output), RedirectResult (an HTTP redirect), ContentResult (for text output) etc. This is another extensibility point, which allows a custom ActionResult implementation. See an example here: http://blog.maartenballiauw.be/post/2008/05/ASPNET-MVC-custom-ActionResult.aspx

IView and IViewEngine

Rendering a view – When the return type from the action is that of a ViewResult there are two interfaces, IView and IViewEngine that get involved. IViewEngine interface defines the contract for locating a view or a partial view. IView defines the contract for rendering the view. By default the framework uses WebFormView and WebFormViewEngine which process .aspx based views. A custom view processing infrastructure can be implemented by creating custom views/view engines. The MVCContrib project on codeplex provides several ViewEngines including those based on XSLT, Brail and nVelocity. Some more information on creating a custom ViewEngine can be found here: http://www.singingeels.com/Articles/Creating_a_Custom_View_Engine_in_ASPNET_MVC.aspx

Result Filter – OnResultExecuted: This is the last step executed within the controller and occurs after the result has been executed and http response produced. If any exceptions are thrown during the result execution, then you’ll have a chance to handle the exception here. If not the exception is bubbled up towards Exception Filters (see Exception Filters - OnException stage).

After this stage the http response would have been produced and the control is transferred back to HttpApplication to carry through the rest of the lifecycle. This concludes our journey through the request processing occurring within the ASP.NET MVC framework.

This follow-up post explained the passage of a request through the ASP.NET MVC framework and describes how the request is processed through the various stages within. Hopefully it gives a good idea of the ASP.NET MVC lifecycle and extensibility points within it.

Del.icio.us Digg It Share on Facebook Stumble It!

Scrum and Outsourcing

davidmy — Mon, 09 Feb 2009 11:51:00 GMT

Software development projects are increasingly utilising resources which are located offshore exclusively as well as in conjunction with on-shore (or near-shore) resources. The reasons for the increased usage of offshore resources span from the attractive reduced resource costs to the ability to scale the development teams quicker and easier.

At the same time more and more software development projects are employing Agile practices and in particular Scrum in order to deliver a fit-for-purpose software solution to budget and on time.

The most frequent reason for employing Scrum with an offshore development team is to reduce the likelihood of the end deliverable being nothing like that expected or required; a common problem of offshore development using the Waterfall methodology.

Prima facie Agile and offshore development are concepts which do not sit well together, at least with the traditional purist Agile commentators. The fundamental reason for this premise is because one of the key tenets of all Agile software methodologies is the importance of communication between the various resources which are involved in software development project.

Furthermore Agile methods pay particular attention to face-to-face communication in attaining a high-level of effective inter-team communication. The Agile manifesto states "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Of course the utilisation of offshore resources either minimises or precludes the face-to-face communication.

However it should be noted that this is merely one of the tenets of Agile methodologies and after a closer examination it transpires that many Agile practices either with or without small variations can be effectively employed with offshore teams, achieving the same goals as when employed with on-shore resources.

As with the all methodologies the success or failure depends largely on choosing which practices to employ and which practices to employ but in a more appropriately modified form, and which ones are should not employ as they do not fit well to the particular project or project team.

Much of the contents of this blog are based on articles on employing Scrum with offshore resources, as well as my personal experiences over the past 6 years of working with offshore teams employing various delivery methodologies in five different countries.

The remaining content of this blog will examine various aspects of Scrum and how the Scrum practices could be employed effectively when offshore teams are being utilised to deliver a software development project, be it with some modifications.

Communication

As per the Agile manifesto communication is one of the most important components which can often make or break a project. Its importance cannot be overstated, to the extent that many identify this as being the most critical success factor of any project.

Multiple forms as opposed to increased frequency of one type

Working with team members which are geographically distant from each other, increases the importance of employing effective communication measures within the project team. Face-to-face meetings, emails, instant messaging, wikis, SharePoint and Skype are just a few different forms of communication that could be employed, and often the combination of these communication mechanisms is more effective than increasing the frequency of just one (i.e. having more than one status meetings per day). Whichever forms are selected their usage should be encouraged at the outset of the project and closely monitored during the project, in order to identify which ones are the most effective for the particular project team.

Face-to-face communication

In my experience it is more important to employ various forms of communication as opposed to increasing the frequency of communication when offshore teams are involved. Traditional communication methods such as face-to-face communication are important and should be utilised where possible by offshore team members visiting the hosting country and local resources visiting the offshore countries. In particular the project kick off should involve one or more local resources visiting the offshore country in order to ensure the objectives of the project are clearly understood and also to build up trust.

These initial meetings should be longer than those visits which occur during the project in order to allow enough time to communicate the requirements and purpose of the project and to explain how the project will be delivered. In addition it is an excellent opportunity to address questions from the offshore team, identify any resource issues and potential cultural obstacles than need to be overcome.

Face-to-face communication should continue throughout the project ensuring that there is a local presence in the offshore location or vice versa at all times. Without the continuous face-to-face communication, you risk not achieving one of the tenets of Scrum, self-organizing decision making. For a team to decide things like designs, system architecture, working practices, they have to be able to discuss and debate as a team. Such discussion and debate requires trust and camaraderie, both of which are normally built through day-to-day interactions with onshore resources. Over email, conference calls and other remote forms of communication this process is significantly slower and often not achievable using only remote forms of communication.

Daily Status Meetings

Agile methods promote regular short daily status meetings for the entire team, often stand-up meetings lasting no longer than ten or fifteen minutes. Carrying this over to remote groups is important, although in my experience the duration of such meetings need to increase potentially to thirty minutes in order to address the status and issues of the entire team which may represent more than a single working day (taking into account time zone differences).

With time zone problems it's important for both sides to give and take in picking the time for calls ensuring that the participants gain the most benefit from the calls. Whatever time is selected it is of paramount importance that this time be strictly adhered to in order to maintain the momentum and consistency of the calls.

Depending upon the size of the offshore team and on-shore team it is sometimes more beneficial for having all team members present for the meeting yet having only key resources contributing to the call, although not necessarily the same people on each call. Although this does not strictly adhere to the purist’s view of the daily status meeting, it is more effective than having too many contributors which often diminish the effectiveness of the call.

Proxy Scrum-Master

A Scrum Master is akin to the project manager in the Waterfall methodology but there are some distinct differences between the role of Project Manager and Scrum Master. The latter does not normally manage the team deliverables at a micro level. Instead, the Scrum Master is responsible for ensuring that each sprint stays on course, that no new features are added to the sprint (without a compensating effect being employed), that code inspections happen, and ensuring everyone plays by the rules. The Scrum Master’s duties does not end when the daily status meeting finishes, it is important for the Scrum Master to be available throughout the working day and to interact with the team outside of the status meetings.

This proves a very difficult challenge when geography and time zones are part of the project team, as is almost invariably the case when offshore resources are employed. In order to address this issue, I have found the appointment of a “Proxy Scrum Master” covers those times when the Scrum Master is unavailable. This individual is the Scrum Master’s representative and has the same responsibility as the Scrum Master for the local team. Of course the Proxy Scrum Master and the Scrum Master must operate under the same rules and goals in order for this dichotomy of roles to work effectively. In addition the Proxy Scrum Master should be appropriate in terms of their experience and knowledge of Scrum and managing teams.

Of course the purist view of Scrum is that the team members should be empowered and self-managed, however in practice the level of self-management should be limited when offshore teams are employed as there are even more way in which the team members could end up working against or over each other than when only on-shore resources are being used. Some (including myself) question how much the notion of the team self-managing themselves is realised in practice (or even whether such a notion has a place in practice at all regardless of the team’s geographical location).

Offshore and on-shore development combination

Continuous Build and Source Control

Employing continuous builds is a good practice for any development team which has been proven to significantly add value by identifying integration issues at the earliest most opportunity. When combining on-shore and offshore resources, it is an even more important and effective means of reducing integration headaches. Even with the best defined and communicated interfaces, integrating at the end is a dangerous and often costly path to follow.

Continuous Integration which spans geographical locations often runs in to problems, namely annoyingly slow check-out and check-in times as well as the reduced opportunity to take back ups. It is therefore very beneficial at the outset of a project to ensure that the configuration of the source control software is suited as much as possible to the remote operations. A series of tests should be carried out to ascertain the reliability and performance of remote operations, in order to estimate the cost to the project and also to identify whether or not multiple repositories are required. In a successful global Agile environment, onshore and offshore teams will work on the same code base by setting up replicas that get merged both ways daily.

I have been involved with more than one project where geographically local repositories were utilised, along with a single repository to merge the various geographical repositories (the latter being the effectively the master repository). This “Delayed Continuous Integration” does dilute somewhat the effectiveness of the Continuous Integration practice however it is the better of two evils when faced with an un-workable single repository option.

Minimize geographical inter-dependencies

Utilising geographically local repositories and a hierarchical continuous integration process is often forced upon team using offshore resources as mentioned above. This may not be a significant issue where the product features developed by local and offshore resources have few or no inter-dependencies.

As a general rule when the entire solution is being developed by a combination of offshore and on-shore resources, inter-dependencies between features should be kept to a minimum and if possible avoided completely. This will prevent the frequency of “toe-stepping” and undesirable delays whilst one team waits for another to complete their work. This should be considered during the planning for each Sprint, and in particular when apportioning features where the deliverable development is via a combination of on and offshore resources.

Daily Build

The practice of daily builds when employed with offshore teams allow for continuous and early views of the output of the offshore team. On the projects I have worked on where this practice has been employed the daily build has been delivered at the end of the offshore day, with a list of the features that have been implemented in that build.

The local team (in particular the testing resources but also the end users) should review the daily build in order to identify deficiencies and deviations from the specification relating only to the features included within that build. This often formed some of the discussion in the following day’s status update meeting, but also served to be very influential in assuring the quality of the deliverables. These early views ensure that the deliverables are fit for their purpose, and also offer confirmation that the requirements of the Sprint’s features were fully understood and implemented.

Documentation

In general Agile methodologies downplay documentation on the basis that in many instances a large part of documentation effort is wasted or adds only a nominal value. Once offshore resources become part of the project make-up documentation becomes more important in terms of its quantity and also level of detail, as a result of the face-to-face communication being significantly diminished. It is one of the necessary additional and often hidden costs of employing off-shore resources.

There are two schools of thinking relating to documenting for teams where the development resources are exclusively offshore;

The first (minimal documentation) being that a local resource produces at most a high-level design document (in addition to a requirements document) and the offshore team produce a low-level design document (the latter of course hopefully being representative of the former). This document exchange provides some assurance that the offshore team understand the requirements and the high-level design.

The second approach (Detailed Design Documentation) involves a local resource producing a design document (again in addition to a requirements document) at a detailed level, in order to ensure that the team understand the requirements and adhere to the overall architecture objectives. Although there is no document exchange, this approach should incorporate a design review meeting between local and offshore meetings to clarify any ambiguities and to discuss possible improvements to the design.

The offshore team composition will largely determine which approach is most suited, with the “Minimal Documentation” approach requiring offshore resources that are experienced with reasonable domain knowledge, whilst the “Detailed Design Documentation” approach is more suited to mixed-experienced teams with limited domain knowledge.

Some view the second approach as a Scrum anti-pattern as it significantly limits the freedom of the offshore resources, however it is often required in order to ensure fit for purpose deliverables. The first approach is certainly more attuned to the Agile way of thinking; however it does demand the type of offshore resources which are not always available.

From experience the level of detail required when offshore resources are involved is significantly higher and the language used must be more carefully selected. Both are required in order to ensure the understanding of the requirement that each feature represents. As a result I tend to prefer the “Detailed Design Documentation” approach but at the same time creative thinking is encouraged through other means such as the design review meeting.

Cultural issues

Probably the most difficult element of introducing Agile methods into any organization is the cultural change it causes, to the extent that it is often the main problem organizations have with adopting Agile methods and often results in many failed adoptions.

Agile methods involve a change from the command and control model (senior people make the decisions and less senior carry out those decisions) to a model where development team members have more autonomy. In western organizations this is a big problem; however the problem is more significant for organizations in Asia and ex-Soviet countries, as in these environments people are more often than not discouraged from asking questions of their seniors, pushing back or warning of unachievable deadlines.

Such a change of culture with non-western resources is thus even more of an uphill battle in comparison to western organizations, and can take a significant amount of time, effort and patience to achieve. However once the summit of the hill is reached and a good co-operative relationship is established with the offshore resources, the Agile way of thinking is generally well received and appreciated.

Setup Costs

There are various types of setup costs which are involved in setting up an off shore development team, many of which apply regardless of the development methodology employed. I have detailed below many of these costs (it should be noted that this is not in any way an exhaustive list) ensuring that any costs that are particular to setting up a development employing Scrum are included.

The first of which can be categorized as infrastructure costs which include:

· Purchasing the necessary hardware (servers for test and build environment)

· Continued network connection between the offshore and onshore locations

· Software costs (for test and build environments and any other software required to handle the off shore development)

The second kind of setup costs (which are often less tangible and difficult to estimate) can be categorized as Process and Relationships costs, which include:

· Travel costs for onshore resources travelling to the offshore location

· Travel costs for offshore resources travelling to the onshore location

· Communication costs (e.g. international telephone calls etc...)

· Process documentation and presenting (onshore resources will perform this activity)

· Knowledge transfer of domain knowledge (continuous due to likely resource turnover)

· Increased management costs for onshore team (will impact the Scrum Master)

· Increased number of test cycles involving onshore resources

· Relationship management costs

Summary

Scrum can be employed successfully in teams where some, many or even the majority of resources are located offshore. I make this assertion based on two recent projects which were delivered on time and to budget with Scrum being employed (although I have also experienced one project which was both late and over budget in similar conditions although I am not convinced the methodology was the core reason for these results). The end deliverables were as per specified and the end-user buy-in was more significant than that in many other projects I have been involved in where offshore developers were employed.

For me the most important consideration when employing Scrum with offshore resources is that it should not employed without modifying and/or tuning some of the practices to be more suited to working with geographically split teams. This tweaking (or lack thereof) can have a fundamental effect on the end result.

Technorati Tags: Scrum,Agile,Outsourcing,Software Development

Del.icio.us Digg It Share on Facebook Stumble It!

Virtual Earth & Windows Mobile - "Nugget" Talk - NextGenUG - Oxford Branch - Wednesday 4th February 2009

rogerw — Tue, 03 Feb 2009 13:05:00 GMT

Another Chance To See....

I gave a talk to the Oxford branch of the NextGenUG in January 2009 on the subject of Location Based Programming with Windows Mobile & Virtual Earth. Unfortunately the demo failed because of networking issues/config and as a result I ran out of time to fully explain the code sample.

Weather and traffic conditions permitting, I am hoping to do a reprise of the last 15-20 minutes of my talk as a "nugget" at the February meeting of the NxtGen User Group, Oxford Branch. The aim this time is purely to focus on explaining the integration of Windows Mobile code and Virtual Earth Web Services. In short I want to show a working demo and re-explain the code and concepts fully in a focussed way.

The date of the next meeting is Wednesday 4th February 2009. It will be at the RM offices in Didcot from 7PM. Further details of the location and timing are here at the NxtGenUG site.

Del.icio.us Digg It Share on Facebook Stumble It!

Nxt Gen User Group Talk - Location Based Programming - The "Demo Gods" Were Frowning

rogerw — Tue, 03 Feb 2009 12:59:00 GMT

A few weeks ago (Tuesday 13th January) I gave a presentation to the Oxford Branch of the NxtGen User Group on Location Based Programming with Windows Mobile. If you are interested, you can find the slides in PDF form for the talk here.

This presentation was one of those occasions however, where things just don't go as planned. The problems occurred during my final demo, which hoped to show how to use Windows Mobile to call Virtual Earth Web Services 1.0. The other previous demos were running entirely locally on my laptop and generally the "demo gods" were with me - so these went OK.

Demos and Demons - Connectivity Woes

However this final demo with Virtual Earth, required stable internet access for the web service connection and this was the root of my problems. Due to network authentication issues when connecting to the event location WiFi, prior to the start of the talk (I tried many times to access this), and the requirement of Virtual Earth Services for https access, this wasn't going to be straight forward. In the end I had the nervy and surreal experience of using a Windows Mobile 6.x software Emulator, virtually "cradled" via Windows Mobile Device Center on my laptop and connected to the internet via a real Windows Mobile 3G device connection of only 2 bars signal strength! Not a time for the faint hearted.

As ever, everything was working perfectly before the session, during the break, and before the demo itself. None of that mattered however as nobody saw it and the demo failed to work when required! Every call to the Virtual Earth Service kept throwing WebExceptions when the Virtual Earth token was requested via the first service call. It soon became obvious that the networking setup was failing to access the internet or resolve the required address. It appeared to think I was looking for a local web resource on my host machine. Internet Explorer Mobile in the emulator was also failing to connect to public web sites. In the heat of the demo, I appeared to be doing nothing different compared to previous successful attempts. The emulator was "cradled" and my host laptop could see the web but the emulator couldn't.

Apologies

Time was running out, so in the end I had to skip the demo. I felt this took the edge off the presentation, so my sincere apologies to all who were there and missed out on the final demo.

Investigations & Repercussions

When I got home this was still bugging me, so I did some further intense investigation. It appears there was a difference in the behaviour of the Windows Mobile 6.1 emulators depending on the sequence of the setup and the type of network connection in use although my results weren't always consistent. The issues0 appear to relate to two areas:

Whether following the "cradle" action the device is set up with a sync profile on your host machine. If not you should use the "Connect without setting up the device" option. This appears to finally enable the network option even though the emulator thinks it is cradled and the network connection property in the State Notification broker shows it as enabled.
The connections setting in the emulator itself and whether the connection is set to "My Work" or "MyISP" in the Network / Advanced settings. Depending on your network proxy or firewall settings this may cause issue. In my case I suspect this changed when I switched from WiFi to mobile based connectivity.

The Road To Connection Success

The correct sequence to get internet connectivity for a mobile development application from Visual Studio appears to be:

Ensure that your Windows Mobile Device Center (Vista) or Active Sync (XP) is set to accept connections on "DMA". Otherwise emulators appear to fail to be detected and cradled.
Using the Device Emulator Manager ( Tools / Device Emulator Manager in Visual Studio) "Connect" to the chosen Emulator e.g. "USA Windows Mobile 6.1.4 Professional VGA Emulator" . This emulator should start if not already running.
Ensure the Emulator network configuration is set to emulate a Network card via the relevant checkbox. In my case this was an NE200 PCMCIA Adaptor.
"Cradle" the emulator via the Device Emulator Manager. This should start the Windows Mobile Device Center or ActiveSync. Ensure that the connection is finalised via the "Connect Without Setting Up My Device" option.
Check the Network connections are set correct via the Windows Start / Settings / Networks / Advanced options. Ensure the drop downs are set correctly. In my case this is to "My Work Network".
Check the internet connection on the emulator by browsing to a known web site URL.
Deploy the application which requires internet connectivity.

Another Chance To See....

Anyway, weather and traffic conditions permitting, I am hoping to do a reprise of the last 15 minutes of my talk as a "nugget" at the next NxtGen Oxford Branch talk on Wednesday 4th February 2009. It will be at the RM offices in Didcot from 7PM. Further details of location and timing are here at the NxtGenUG site.

Del.icio.us Digg It Share on Facebook Stumble It!

How does ASP.NET MVC work?

gopalk — Tue, 20 Jan 2009 06:56:00 GMT

If you’ve looked at the ASP.NET MVC framework, you might have wondered how it fits within the rest of the ASP.NET lifecycle. To understand it though, the ASP.NET request lifecycle needs to be understood first.

What happens when an ASP.NET request is made?

The answer depends on the version of IIS being used. In IIS 5.0 / 6.0, ASP.NET support was accomplished using an isapi extension i.e. aspnet_isapi.dll. In IIS 5.0 / 6.0 there is a distinct handover of the request from IIS to .NET before any managed code can respond to the request. This is achieved by mapping certain extensions like .aspx, .asmx etc to aspnet_isapi.dll extension by using application mapping within IIS manager interface.

But in IIS 7.0 (running in integrated mode) things are different. IIS 7.0 integrates the ASP.NET runtime with the core web server and there is no specific handoff needed from IIS to ASP.NET. Thus for a managed HttpModule to execute, the request doesn’t have to be routed to ASP.NET first. A managed HttpModule can be added via IIS manager itself and can be made to execute for both managed and native requests. Similarly a managed HttpHandler class can be mapped to specific extensions directly via IIS manager (which stores the configuration in applicationHost.config file.) or via the web application’s web.config file.

So what happens when a request gets through to ASP.NET?

1. ApplicationManager and HostingEnvironment classes are created. ApplicationManager class manages Applications and their AppDomain for all the applications on the hosting process. ApplicationManager can be used to do cool things like hosting ASP.NET in your custom process, see here: http://www.west-wind.com/WebLog/posts/4976.aspx . This is also the stage when any necessary compilation of code in App_Code folder occurs.

2. HttpRequest, HttpResponse and HttpContext objects are created and populated. At the end of this stage these objects are usable.

3. Now the current HttpContext is assigned to an instance of HttpApplication (or instance of Global.asax if exists). At the same time any HttpModules (inherited from parent app or defined in web.config) are initialised. The HttpApplication class defines a set of stages/events that get executed one by one and carry the processing forward in distinct steps. Note that the HttpModules that have been initialised will attach themselves to one or more of these lifecycle events defined on HttpApplication instance.

4. HttpApplication lifecycle events fire in succession:

Note that the list of lifecycle events on HttpApplication is extensive and the objective here is not to analyse the entire lifecycle, so I’ll skip the parts that are not directly relevant for this exercise. For an extensive look at HttpApplication lifecycle elements look here:

IIS7: http://msdn.microsoft.com/en-us/library/bb470252.aspx

IIS5/6: http://msdn.microsoft.com/en-us/library/ms178473.aspx

The first relevant event in the HttpApplication lifecycle that we need to look at is MapRequestHandler. Now this step is new in .NET 3.5 but an equivalent step (without the corresponding event) existed before .NET 3.5. It is in this step that an HttpApplication selects an HttpHandler to service the request. Now the selection of HttpHandler will be based on web.config or inherited configuration. The HandlerFactory set in the configuration will be used to acquire an instance of the Handler which is then assigned to the context.

So for example, if a request is for an ‘aspx’ file, in the MapRequestHandler stage, HttpApplication will map ‘.aspx’ request to PageHandlerFactory. GetHandler method is then invoked on PageHandlerFactory which returns an instance of the appropriate Page class (Page is basically an HttpHandler and implements IHttpHandler interface). This is then attached to the Handler property of the context class.

Let’s skip a few more steps and go to the ProcessRequest stage. By now the request (To be precise the HttpContext object encapsulating the request.) already has an HttpHandler assigned to it as seen earlier. The request is now processed here by invoking the ProcessRequest method on the HttpHandler.

Wasn’t this about MVC?

In MVC, there is no concept of a Page as in a traditional webform page, i.e. the web page requested doesn’t exist on the disk as a file. Instead it’s served up by a special method (‘the Action’) on a special class (‘the Controller’). This is quite a dynamic routing arrangement as it needs to respond to varying URL’s. And if you do not want to use a special extension (like .mvc) for these MVC requests, then you can’t really use an HttpHandler entry in web.config/IIS. (There does exist a handler for .mvc in web.config if you want to use .mvc extension for your MVC requests.)

So, how does ASP.NET know how to route requests to MVC? The answer lies in web.config. There is a new http module added to modules collection in ASP.NET MVC projects

This was originally a part of MVC framework but since has been released as a separate assembly. The other part in this routing magic is played by Global.asax RegisterRoutes method.

routes.MapRoute("Default", "{controller}/{action}/{id}",new { controller = "Home", action = "Index", id = "" });

MapRoute is an extension method on RouteCollection class that can be used to define possible routes. In the background this method sets the routes you define to be handled by MvcRouteHandler class.

The UrlRoutingModule attaches itself to PostResolveRequestCache and PostMapRequestHandler events of the HttpApplication instance and overrides the default behaviour of MapRequestHandler stage. UrlRoutingModule does this by searching the RouteCollection for a route matching the request. If it’s found, the associated RouteHandler is retrieved from the RouteCollection. In our case this is an MvcRouteHandler instance. An instance of MvcHandler is retrieved from MvcRouteHandler and assigned as the handler for the current context. Nice thing to note is that RouteCollection is one of the points where the MVC framework can be extended. This can be done by defining a custom RouteHandler corresponding to the routes (instead of the MvcRouteHandler). There is some good information here on how to this.

http://msmvps.com/blogs/luisabreu/archive/2008/07/23/the-mvc-framework-the-mvcroutehandler.aspx

As a side note, also note that UrlRoutingModule will by default ignore any requests that match a file that exists on the disk. Thus if a request for WebForm1.aspx is received and it happens to exist on the disk then route lookup will be skipped for this request. This behaviour can be changed (at your own peril!) by setting routes.RouteExistingFiles = true ;

Now there might be a case where a custom handler needs to be defined within our MVC web application (For integrating third party products/user controls). This may not exist on the disk and will trigger a route table lookup and a 404 if no matching routes are found. To avoid this, RouteCollection can be instructed to ignore this specific path in the following way.

routes.IgnoreRoute("<your route>");

So in this post we saw how a request was routed from IIS through to the MVC framework and along the way, an extensibility point was identified. From here it needs to be routed through to the right action on the right controller class, but that could be the topic of an entirely new post!

Del.icio.us Digg It Share on Facebook Stumble It!

Asp.net 4

deniss — Mon, 22 Dec 2008 09:44:00 GMT

In this post I would like to share some information related to Asp.net 4 after visiting recent DDD 7 conference, reading some online resources, and attending Charteris Tech Day event.

In development of Asp.net 4 Microsoft tried to set up new ground in openness and community involvement. For this purpose they were using their codeplex (www.codeplex.com/aspnet) site heavily where all the interim work and unofficial releases of different products can be found.

So Aps.net 4 will contain many products with open source background.

Asp.net 4 will be released as a part of .Net 4 and VS 10. VS10 will support multi-targeting and Asp.net in particular maintains a high compatibility bar with 3.5. So if you’ll be upgrading from 3.5 to 4.0 it shouldn’t break your applications.

Let’s move forward and see which new features and improvements MS announced in the new version of Aps.net

Standards support (improved Web forms): MS claims that Asp.net 4 will be the best platform for standards work. Support for CSS standard is improved and it would be possible to have much better control of it. HTML standards support is improved as well.

Web forms related improvements:

- Client IDs: Developers can manage control IDs that affect rendered client IDs. It would be possible to specify ID you want for the control.

- CSS: remove the need to use CSS adapters (they were used to change control’s rendering mode to use CSS instead of table-based layout). This will be a part of mainstream Asp.net features.

- URL routing: This feature comes from MVC framework and will be available for Web Forms as well.

It allows you to use search engine friendly URLs. This is very helpful feature for online e-commerce applications where you need to have URLs in the format similar to this one: www.store.com/categories/manufacturer. So it would be possible to do this without using third party URL rewriting tools (like Helicon rewrite for instance) or ISAPI filters which usually contain files with rules which is difficult to maintain.

- View-state: It would be possible to have granular control of view state which is much more flexible and allows you to do the following:

- Disable view-state on page, enable on specific controls

- Disable view-state on control, enable on child controls

- Grid view/ List view work better without view-state - fixed concurrency problems in these controls when view states is turned off

Support ‘Pattern-based’ development models: MVC, TDD

MVC framework allows you to build web applications with Model-View-Controller architecture. MVC is a very ‘pattern-oriented’ framework and it’s particularly good for test driven development. It provides good separation of data, logic and views. This framework was available for download on codeplex site for quite a long time and it will be shipped as part of Asp.net 4 now. This means that all parts of Asp.net like membership, roles, providers, Request and other core functionality will be accessible inside MVC applications. Another Microsoft’s intention behind this step is to open Asp.net for a different audience like Php, Django and Ruby on Rails developers.

MVC also supports URL routing feature.

AJAX support will be implemented for MVC as well allowing partial rendering of the page and JSON support.

The common scenario might be the following:

ASP.net ajax makes a call to controller, it returns JsonResults and updates independent regions on the page using jQuery By doing this it's possible to build simple service for client’s page. jQuery allows to draw user's attention to the part of the page where change happened by applying visual effects.

Improvements in the ‘core’ Aps.net

The only significant improvement I’m aware of for now relates to caching mechanism.

There are alternate cache providers for Asp.net and one of the things Microsoft was doing in ‘core’ for 4.0 is taking the asp.net cache and make it something that’s provider based, so it’s possible to replace it with your own. Products like Velocity can be easily integrated in applications.

Ajax:

Ajax control Toolkit is a part of the strategy - it will be a part of Asp.net 4 with new controls added. There will be controls that feel like server side controls. This means that you have data source on the client side page, template controls like repeater and you can have it firing events like sorting etc.

jQuery will be released as a part of Asp.net 4 with IntelliSense support in VS10.

Data and Dynamic Data:

Dynamic Data is building on from .Net 3.5 SP1 and will be included as part of .Net 4.0 and subsequently as a part of Asp.net 4.0

Asp.net Dynamic Data is a framework that lets you create data-driven Asp.net Web applications easily. It does this by automatically discovering the data model at run time and determining UI behavior from it. For instance, Dynamic Data can use LINQ to SQL model or Entity Framework model. A scaffolding framework instantly provides a functional Web site with CRUD operations for data manipulations. This scaffolding can then be easily customized using metadata, templates, or by creating standard ASP.NET pages to override the default behavior. At the same time existing applications can easily integrate pieces of the scaffolding logic with their existing pages.

In Aps.net 4 Dynamic Data approach is implemented in MVC framework as well. It will be possible to use Grids and other controls in MVC that support reach functionality.

In Asp.net 4 there is a lot of core functionality that was added to existing data controls.

Support for abstract data-layer:

Currently there are several types of data sources supported by Asp.net: LINQ data source, Entity Framework data source, Object data source. The negative side of Object data source is that it doesn’t give you access to IQueryable. So during development of Asp.net 4 the intention was to building some kind of abstract data layer which means that you can write your own business classes and they will return IQueryable. Dynamic Data wise it would be possible to take one of these data sources go against it and scaffold your own business objects.

Support for many-to-many relationships will be implemented for Dynamic Data as well. This is currently supported by Entity Framework only.

Del.icio.us Digg It Share on Facebook Stumble It!

New Windows Mobile 6.1.4 Emulators and Latest P & P Guidance for Windows Mobile Developers

rogerw — Thu, 04 Dec 2008 01:00:00 GMT

Those of you you who are Microsoft .Net and Windows Mobile Developers may be interested in two recent announcements from Microsoft.

New Windows Mobile 6.1.4 Emulator

Microsoft has recently released a new version of the emulator images fro Windows Mobile 6.1. These new versions are primarily designed to showcase the latest version of Internet Explorer 6. This has better AJAX and Javascipt support, Flash Lite support, touch support and multiple zoom support. The aim of the emulators is to provide testing support for applications using Visual Studio 2005 and Visual Studio 2008.

The 6.1.4 emulators come in Standard and Professional variants and you can download the emulators from here.

Patterns and Practice Mobile Architecture Pocket Guide

Something else that has slipped out relatively quietly from the Microsoft Patterns and Practice team last week is the Mobile Architecture pocket guide. I've only got part way through it currently but it appears to be a good concise summary (well 150 pages worth) in a single place of all the design elements and issues to consider when developing a Windows Mobile solution. Everything from screen resolution to security is covered. A recommended read so far...

You can download the PDF from CodePlex at the this location

Del.icio.us Digg It Share on Facebook Stumble It!

MOSS 2007 as Web Content Management for Internet-Facing Web Sites - Tech Ed EMEA 2008 Developers

alistairl — Wed, 03 Dec 2008 10:53:00 GMT

In my day I have had a fair bit to do with Internet-Facing Web Sites and the challenges of drop dead deadlines and culture clashes that these kinds of projects tend to bring. Anyway, enough of me, this session appealed to me as a catch up on the world of content management as Microsoft sees it. PDC 2003 was notable to me for its complete lack of mention of Content Management Server and this was borne out in the following months when it was announced that MSCMS was to become part of Microsoft Office SharePoint Server.

At the time this was a bit of an annoyance, out in the web world we were interested about standards compliance and cross browser support. On top of straightforward W3C markup compliance was accessibility which at the time was a bit of a challenge even for plain old asp.net, let alone an Intranet tool like SharePoint. But since then Microsoft Office SharePoint Server has been through a big release and a whole lot of experience has been gained by implementing the product in a number of different configurations. This session at TechEd aimed to make sure that everyone was up to date with the web content management capabilities of the current product.

First of all we had a quick introduction to our presenter, needless to say Andrew Connell knows a thing or two about MOSS, is an MVP for Office SharePoint Server and has a book out on SharePoint Publishing. We were going to cover the broad gamut of web publishing on topics such as Web Content Management, Page Layouts, Branding Publishing Sites, the Content Query Web Part and Forms Based authentication. Then a "watch this space" announcement about a really good sample site. By the end of the year we would have a site that would be a good demonstration of the web capabilities of MOSS 2007 - and it would not use the BlueBand master - at least we hope not. The sample site will be for the familiar fictional AdventureWorks company, I look forward to it becoming available.

So how did we get here, well a few years back Microsoft decided to consolidate their Electronic Content Management strategies and centred these around MOSS 2007. This is when document, web and other materials produced off the back of collaboration and work came together under the Office banner and we immediately had to widen our heads to take it all in. But focusing on our particular area of interest, the Web Content Management (WCM) facilities in MOSS 2007 are the successor to those in MCMS 2002. And a bit like MCMS, you aren't restricted to using WCM on public websites, you are welcome to use them internally too.

We then got in to the nitty gritty of what Publishing sites look like from the inside. They follow the standard site collection / site shape of the SharePoint way of doing things and pages are held in a Library. This does hit one issue with site owners wanting to rearrange their URL into something "nicer" but we were warned off http rewriting with some neat regex. Do the performance metrics on this approach and you will see how much processor utilisation it takes. Andrew recommended pushing the URL issue off to your ISA / Firewall box instead which will handle this a whole lot better and make sure your application box is concentrating on serving web pages.

Then on to a bit of presentation fun with the "ABCs" of WCM and SharePoint. In our case we would be looking at Authoring (web based of course) Branding (developer and designers working together) and Controlled Publishing (Consistent business rules for approval).

Web based authoring used to be quite revolutionary in the old days when Microsoft didn't even own what came to be MCMS, but these days we even have a choice of companies that will host a blog and not ask us to install one piece of software or install a plug in to our web browser. But to cut a long story short, you can use your browser to author content for a SharePoint publishing site.

Branding is a very very important issue when it comes to considering Microsoft for WCM. I'll hold on my final judgement as to whether AdventureWorks will be the sample site to move things on, but MOSS has a similar problem to that of MCMS in that you cannot and should not use what comes out of the box to evaluate its capability for WCM and similarly you should not let that anywhere near a public website. Yes, you can perhaps "get away" with it on an Extranet, but even with that you should really speak to your marketing and account management team first. But face it, if you are on a project that can fund a MOSS infrastructure then it should also be a project that has decent representation from brand owners. The "good" news is that MOSS 2007 is based on the principles you have learned for ASP 2.0, so all that hard work learning how to lay things out using CSS and master pages is well learned, but there are also differences. You have a huge amount of CSS that comes with MOSS, and a whole load of content placeholders to know all about too.

Andrew was good enough to explain what he was meaning by certain terms, which was a good presenting point. Although I would reckon that everyone in the audience would be able to create html markup and deploy it to a web server of any flavour, I think that less would have experience of a large website deployment. When you have to deal with a project team with Internet security people all the way through to graphic designers and copywriters then it is important that you as a developer can bring together the separate elements of brand and content while keeping in mind the WCM and infrastructure requirements. Branding is the so-called chrome or design, whereas content is is text and images that vary quite often.With an eye to infrastructure we want to make sure that the approach we take will work across load balanced web servers, and can be deployed in a repeatable fashion without developer input. Branding should be able to accommodate changing content without developer input, which is really the spirit of MOSS web publishing.

How to implement branding and content management in MOSS is a choice based on a number of factors, including the skill set of your team and how you approach disaster recovery. Some approaches may be simple in plain IIS, but they mean that deployment is a two part process of MOSS and your separate items. Others are easy to do on one box, but a pain to move, such as some of the techniques using SharePoint designer. Above all, make sure you consider the maintenance factors when choosing an approach.

Then for a bit of light relief, Andrew demonstrated the new Adventureworks demonstration site and how it illustrated that you can implement a site that "Doesn't look like SharePoint". From what we have been told it has been implemented as a proper reference site (but looks good too) so we should be allowed to take some principles from the implementation such as using Field Controls for versioned content, but Web Parts for functionality. I'm really looking forward to getting hold of it and pulling it apart to see what is inside.

Key Facts:

Session Code: OFC202

Speakers: Andrew Connell

Track: Office and SharePoint

Rating: 9/10

Attendance: 300 is (90% capacity)

Del.icio.us Digg It Share on Facebook Stumble It!

TechEd EMEA 2008 - Day Four - Windows 7 and more

Jon Grant — Mon, 17 Nov 2008 15:47:00 GMT

On Thursday I attended the second part of a two-part session on Windows 7 and what's new for developers. The vast majority of these features are aimed at desktop application developers (e.g. Adobe, Mozilla, and Microsoft themselves) and personally I'm looking forward to a lot of them as they will mean some great productivity enhancements. However, Microsoft are also committing to reducing the memory and processor footprint in Windows 7 and driving up battery life, and are strongly encouraging their third party developers to follow suit. Hopefully this means good news for portable devices, and could ironically mean that Windows 7 is better in the device market than Windows Vista.

Another session I went to was comparing the various development models supported by Windows Embedded Compact. CE 6.0 supports a number of application programming models - including Win32, MFC, and .NET - and there are a number of factors you should consider when deciding which one to use. The basic upshot was that for most apps, .NET is the right choice, however Douglas Boling raised some interesting points and it's worth checking out his presentation.

Del.icio.us Digg It Share on Facebook Stumble It!

TechEd 2008 EMEA - What's in Your Portfolio - Ideas? Projects?

rogerw — Mon, 17 Nov 2008 13:50:37 GMT

As part of my quest to better understand Microsoft Visual Studio Team System (VSTS) I continued my journey through the software product life cycle and attended a session VSTS and the product life cycle. As part of this session I came across a product called Microsoft Office Project Portfolio Server that I was previous unaware of.

Microsoft Office Project Portfolio Server has several functions. Firstly, it acts as a capture tool for business initiatives and ideas - depending on the level of granularity, these are effectively business and functional requirements. Once entered, these can then be reviewed against the stated business strategies. Using clever algorithms, Microsoft Office Project Portfolio Server then ranks and prioritises ideas and initiatives. High level costings and resources can then be applied. Once recorded decisions can be made to accept to initiate projects.

Make no mistake this is not MS Project with a suggestion box! This is a tool for senior executives to initiate and assess projects against defined business strategies. These can be any kind of projects not just software projects.

The clever bit here is the integration to other parts of Team Systems. Once a project is accepted the Portfolio server can integrate with Foundation Server and create full blown projects. These can then be structured and expanded by project managers using MS Project. If it's a software project, software professionals can then do their stuff and interact via Visual Studio.

The other clever part is the ability to feed moderated high level project status data back up through to the senior executives. Whilst all the task completion activities still goes through project managers for approval, using a classic "traffic-light" status approach, senior executives are able to get an instant high level view of how a project is doing at all times.

Even if you just want to use portfolio for capturing business ideas or strategic requirements or even just the output of simple brainstorming MS Office Project Portfolio Server is well worth checking into. As with the rest of team system depending on the scale of you organisation the price point may be the only issue.

Interested? You can find details of Microsoft Office Project Portfolio Server at: MS Office Project Portfolio Server

Del.icio.us Digg It Share on Facebook Stumble It!

Project Velocity

davidmy — Mon, 17 Nov 2008 10:11:07 GMT

One of the last sessions I attended last week at Tech Ed was on what Microsoft has dubbed “Project Velocity”, which was one of the very few products discussed during Tech Ed that was new.

What is “Project Velocity”?

It is Microsoft’s first foray into the world of distributed caching, a market which thus far only has two main players (Memcached and NCache). Microsoft has said thus far that this will be “free” although it was far from certain whether it would remain this way after version 1 was released. It certainly will be interesting if it is “free”, in particular for the other main players in this area charge for their offering!

What is a distributed cache?

A distributed cache is a highly scalable in-memory application cache that is spread across multiple servers. Just like a normal cache its usage can glean significant performance gains by avoiding unnecessary calls to data sources. As the implementation of web farms has become more of a norm the beneficial of an ordinary cache has been diminished, as the cache is only populated on one server whilst the consumer can request data from any of the servers in the farm. Thus the cache is only 100% effective when all the servers in the farm have had their cache populated. In addition to this because they are most likely going to be populated at different times, their disparate cache expiration could lead to stale data or inconsistent data across the web farm. This issue is resolved by a distributed cache as the cache is shared across the entire farm and is consistent in terms of the data content regardless which server the consumer makes their request to.

So what would “Velocity” be used for?

There are three main uses for “Velocity”:

a) Caching fairly static data that is frequently accessed (e.g. a Product Catalog)

b) Session data (e.g. ASP.Net session)

c) Caching data that is accessed frequently but changes are not very frequent (e.g. user’s security permissions)

The current CTP version and Version 1 will only be appropriate for the first two because there is no way to notify of changes to the cache (i.e. push notification) and there is no way to update the cache should the underlying data be changed (i.e. via SQL Dependency). The push notification and SQL dependency support will not be in Version 1 but is in the plan for Version 2 according to the Velocity team’s project manager (although no dates have been mentioned for Version 2).

Fairly static data like a product catalog with a finite expiry date is perfect for Project Velocity as the distributed cache can make this data available for all servers in the farm as soon as it is populated by the first call (or pre-populated by a preparation call).

The most compelling usage of Version 1 will be for session data. The usage of in-memory sessions to store data in between calls has decreased as the usage of web farms have increased, because the only way to make it work is for the sessions to be sticky, which diminishes the positive performance effects of a web farm as the user will be routed to the same server for all request within a session, regardless of the utilization of that server. A session provider has been included within Velocity enabling it to be used as an ASP.Net Cache provider, and thus enables the distribution of the ASP.Net session and its data across all the servers in the web farm.

This certainly will reduce the number of calls to data sources as much session-oriented data can be persisted in memory, with high availability (as one machine going down will not result in the session data being lost) and no single point of failure.

Release Roadmap

CTP 2 - released fairly recently.

CTP 3 – scheduled release end of 2008/early 2009 Q1.

Version 1 – scheduled release is March 2009.

For more information including documentation and downloads see: http://msdn.microsoft.com/en-us/data/cc655792.aspx

Del.icio.us Digg It Share on Facebook Stumble It!