Phil and Dino Esposito have been talking about the RESTful aspects of the upcoming ASP.NET MVC framework.

REST – It's All About the Resources

You can read about REST in a PhD thesis, but I think Tonic captures the essence of a RESTful architectural style from the perspective of a web application developer:

• Everything useful is a resource, not a file, not a CGI script, a resource, an abstract concept of something useful that the client wants to grab hold of.
• Resources are located by URLs, URLs are cheap and form the universal addressing system of the Web.
• Clients can issue a standard number of HTTP methods upon an infinite number of resources and receive something useful in return.
• Representations of resources are sent back to the client, a representation is just a way of turning the abstract concept of a resource into something more concrete, like a HTML page or a XML file. One resource can have many different representations.

One could treat each customer of the company as a resource. Locating a customer is as easy as formulating the proper URL, while the standard HTTP verbs (GET, POST, PUT, DELETE) will identify what sort of operation we wish to perform. Witness an URL like:

http://Astoria/northwind /Customers[ALFKI]

This is what we'll see in ADO.NET Data Services (Astoria).

Proponents of REST (the RESTafarians) have made a lot of noise over the last few years in the SOA and WS-* space. Why? In short because SOAP and the WS-* standards are now large bodies of work that spawn large toolsets – not everyone wants or needs the complexity.

Not Just For CRUDdy Data Services

When building a web site, we don't debate the merits of RPC versus REST, but we do debate the merits of friendly, hackable, and predictable URLs (like https://odetocode.com/articles/aspnetmvc/) versus scary, opaque, and unanticipated URLs (like https://odetocode.com/articles.aspx?c=5F9C-2FZ). We say the friendly URL is RESTful –while the other URL is still just scary.

REST has a place in web applications then, and not just in data services. However, I don't think we want to start our web applications with a resource modeling session.

Besides – I think friendly URLs are a byproduct of the new framework, and not, as Dino hints, its raison d'être.

The C Is For Control

In traditional web forms, ASP.NET maps incoming requests to the file system. Employee.aspx, for example, is a form we could use to list employees, update employees, delete employees, and create new employees. Employee.aspx is both the view (aspx) and the controller (code-behind) - and the two are inexorably bound.

The catch is that the "controller" does not have control in this scenario. The controller is tightly coupled to a single view - and can only act in response to the view's lifecycle events. The "view as addressable resource" model just doesn't work for MVC, no matter how you spin the story.

The MVC framework is, I believe, about putting control in the hands of a web developer. Control over the routing of HTTP requests to components. Control over selecting the view. Control over state management, and control over the outgoing HTML. Breaking the "one URL for every view" paradigm is necessary for MVC, and coincidently gives a developer total control over the addressable resources in an application.

In other words - RESTful URLs are possible because the framework uses a true MVC model, and not vice-versa.

I can't believe how easy it was...

Last week the bottom third of the display on my X60 tablet became distorted and wavy. Applying a gentle pressure to the bottom left corner would fix the display. Something was loose, obviously, and I can't just sit around all day squeezing my tablet.

At 9:30 A.M. Monday, I opened up a support case on the ThinkPad's EasyServ site. I was mentally prepared to give up my tablet for 8 weeks, and have my request lost in the pneumatic tube system that dispatches repair orders to an IBM facility where spider monkeys are trained to jab violently at broken hardware with Phillips screwdrivers until a banana appears.

By11:00 A.M. on Thursday, my tablet was back and working perfectly! The standard warranty covered both the repair, and the overnight shipping between Maryland and Memphis, Tennessee.

In a world where customer service consistently disappoints - three cheers for Lenovo and IBM for exceeding expectations. They've earned themselves a repeat customer.

The Blog Is Good, Too

Matt Kohut displays an Atwood-esque enthusiasm for hardware at Lenovo Blogs Inside The Box. Take a look inside the Bejing Desktop Testing Lab, see pictures of a Ruggedized PC, read the usability studies behind Battery Indicator Light Behavior, and drink in the honest tone of "Junk" in the Preload. 

Due to popular demand, here are some answers to the questions.

Well, not answers exactly ... just some pointers to the get you in the right direction...

1. Are there advantages to building workflows using only XAML? Are there disadvantages?

See Keith Elder's blog on "Leveraging Workflow Foundation", particularly the section on storing workflow definitions in the database.

Also, see Matt Miler's Templates for Windows Workflow XAML activation projects

2. What are the pros and cons of using an ExternalDataExchange service versus going directly to the WorkflowQueuingService?

Sam Gentile: Windows Workflow 102

3. When are attached dependency properties useful in WF programming?

See: Dependency Property Notes

4. What behavior does the default scheduling service provide?

Hosting Windows Workflow

5. How can my code participate in a database transaction with a workflow instance?

Advanced Workflow: Workflows and Transactions

6. Why would I use a tracking service?

Follow the links in Tomas Restporo's WF Tracking Services Explained.

7. Describe a scenario where the WF runtime will cancel an executing activity.

I'd be looking to hear, for example, what happens inside a Listen activity. Also, see Matt W's Implementing the M of N Pattern in WF

8. Describe a scenario where I'd need to spawn a new ActivityExecutionContext.

Matt Milner: ActivityExecutionContext in WF.

9. Tell me why I'd use a compensation handler.

Guy Burstein explains the essence: Compensating and Fault Handling.

10. Tell me about the following activities: Replicator, Parallel, and Policy.

Advanced Workflow: Replicator Tips and Tricks

Kirk Allen Evans: Understanding ParallelActivity in WF

Sahil: Composite Activities in WF.

WF: Rules and Conditions

A few people have asked me what "hard core" WF questions to ask a job candidate.

For advanced topics, I like open-ended questions. Not all these questions have a right or wrong answer- but they should give you an idea of the candidates WF experience, and how they'd design and implement software with WF.

1. Are there advantages to building workflows using only XAML? Are there disadvantages?
2. What are the pros and cons of using an ExternalDataExchange service versus going directly to the WorkflowQueuingService?
3. When are attached dependency properties useful in WF programming?
4. What behavior does the default scheduling service provide?
5. How can my code participate in a database transaction with a workflow instance?
6. Why would I use a tracking service?
7. Describe a scenario where the WF runtime will cancel an executing activity.
8. Describe a scenario where I'd need to spawn an ActivityExecutionContext.
9. Tell me why I'd use a compensation handler.
10. Tell me about the following activities: Replicator, Parallel, and Policy.

A candidate who can run the table on these 10 questions knows their WF stuff.

My desktop computer continued to deteriorate this weekend. Not only could I not maintain an RDP connection into the desktop, I also started having problems synching my phone, copying files across the network, and general performance problems.

On a hunch, I disabled Windows Firewall and all these problems disappeared. Since I am behind a hardware firewall, I'm not concerned about the security implications.

Not sure why this happened – but the firewall rules on this machine numbered over 400 in the private profile (Start -> Search for firewall advanced). Other machines I've checked have ~200 rules.

Perhaps the software firewall was overloaded...

The New ASP.NET Framework

ScottGu gave a demo of the new MVC framework for ASP.NET at the ALT.NET Conference. Here are some notes and thoughts I had after watching ScottHanselman's recording.

The framework should go live in the spring of 2008. The framework is not a replacement for ASP.NET WebForms, but provides an alternative paradigm for building web applications. The new framework still works inside of the ASP.NET runtime - meaning all of the wonderful infrastructure pieces like the configuration system, provider model, SQL cache invalidation, health monitoring, and master pages continue to exist. Like the ASP.NET AJAX extensions – it sounds like we'll only need a new assembly to start the party.

Being an "MVC framework", the software features the Model View Controller pattern. MVC and its many permutations have been (and continue to be) principal patterns in many application frameworks and development environments. There were several mentions of Rails (both the Mono and Ruby types), and at least one reference to Django (the Django book is a good read to get into the framework's mindset).

The framework will provide:

1. Mechanisms to enforce a clean separation of concerns
2. An API designed for testability
3. A pluggable and extensible technology stack

Separation of Concerns

ASP.NET WebForms map an incoming URL to a single .aspx file. Although one can use an HttpModule or VirtualPathProvider to change this behavior, the majority of ASP.NET web applications use this default behavior. In practice, this approach tends to produce code-behind files with intermingled presentation, data access, and business logic. This approach also tightly couples URLs to the physical arrangement of .aspx files in the file system.

The new MVC framework offers a loose coupling between incoming URLs and the view that will ultimately render HTML. ScottGu describes a flexible and pluggable URL dispatching engine that can handle clean and procedural URLs like:

https://odetocode.com/articles/show/450

or

http://www.pluralsight.com/classes/register/appliedsilverlight

The URL dispatching engine examines incoming URLs, routes each request to an instance of a controller class, and invokes a method on the controller (the action).

Controllers

Controllers in the new framework support test first and controller first development styles. In other words, you can implement a controller sans any views, and fully test the controller's ability to utilize application logic and services to respond to a request.

The framework provides a low-level interface definition you can implement to claim absolute power over controller policy, but also provides a hierarchy of concrete controller classes to build upon.

When the controller is ready, it can call RenderView(string viewName, object viewData) to generate the appropriate user interface response. Thanks to generics, this boundary can also be strongly typed.

Views

Views render HTML, but views are not web forms - there is no page lifecycle, postbacks, or viewstate in this framework.

In general, views are simple templates. Templates are concerned only with presentation. To enforce a separation of concerns, many template engines do not allow a template to change the value of a variable or call into application logic, but the ASP.NET framework will allow code blocks and data-binding. The view never references a controller, and the controller never references a view - so testability and a separation of concerns prevail.

Designed For Testability

One of the current difficulties in writing unit tests for code running inside an ASP.NET environment is the pervasiveness of sealed classes like HttpContext.The MVC framework features an interface based API with IHttpContext, IResponse, IRequest, etc.

There is a mock view engine and, I believe, mock implementations of IHttpContext and the like to make testing easier.

At the beginning of the discussion Scott mentioned that the framework will include inversion of control containers, although I don't recall this feature appearing in the presentation.

A Pluggable Architecture

It sounds as if every major service in the MVC framework is pluggable – the view engine (throw in Brail), the dependency injection framework (throw in Structure Map), the URL dispatcher, the controllers, and more.

Look For the CTP Soon

The new framework appears to marry mature paradigms from outside the world of ASP.NET with the high performance and robust infrastructure of the ASP.NET runtime. Look for a CTP by the end of the year.

Before I start my tale of woe, I just want to point out that I've tried disabling the autotuning feature on Vista machines, but this doesn't fix the problem.

I have a relatively clean desktop machine. The desktop is a host for several virtual PCs, and runs Vista.

Remote desktop connections to the virtual PCs hosted on this desktop are solid, and the connections never drop. The virtual PCs run XP and 2003 Server.

But ... remote desktop connections to the desktop itself stall every 5 minutes. Sometimes the RDP connection drops entirely - other times it's just a matter of waiting 10-20 seconds for the connection to reconnect.

Each time this happens I lose a little more hair.

Even stranger - while a connection to the desktop is stalled, a connection to a virtual PC hosted on the desktop is still working great. I can even ping the host machine and see a 2ms response time.

This behavior leads me to believe that:

1. There is nothing wrong with the RDP client
2. There is nothing wrong in the networking stack or hardware of the desktop.
3. There is something wrong with the terminal services service on Vista.

I'm hoping SP1 will fix the issue, and do so before I go bald.

Anyone else see similar behavior?