Ron Jacobs

Modeling Change

If you have heard anything about "Oslo" (the codename for the future application platform) you have probably heard that Oslo is about 2 things, models and services.  Today I met with a group of smart guys here in Sydney where we had a chat about Models and the pain of versioning.

Everybody agrees that the only constant is change.  We know that data will change, schema will change, workflows will change, business rules will change, service contracts and data contracts will change.  We have to manage the change.

The platform infrastructure we use has semantics it applies when dealing with change.  As I mentioned in my last post, the point where the pain hits us is when new behavior encounters old state.  For example, what does the DataContract Serializer do when it encounters state that doesn't quite match up?  There are rules that it uses to deal with this.  The rules are documented but they are implicit.  You don't see them, they are not modeled but they exist never the less.

It occurred to us that if you are creating models of entities, workflows, services etc. that the modeling tool should be able to suggest a model for change.  For example, if you add an activity to a workflow.  The modeling tool can look at the delta between the previous version and your new version and suggest a model for what it will do when it encounters state from the old version.  The model could be something like, it will load the prior state and resume execution where the workflow left off when it was persisted.

Suppose you decided that this wasn't what you wanted.  What if the "change model" was itself a workflow that would execute when new behavior encountered old state?  If this were the case, you could modify this change model workflow to do what you wanted it to do. 

Suppose you are modifying a system that has 100,000 in-process workflows stored in the persistence database.  You might choose to do a batch migration process where you load them one by one and run the change model to move them forward to the new model.  Or you might choose to leave them as they are until in the course of normal processing they are loaded and then the change workflow model applies.

The meta-point is that change happens, we must deal with change, no single strategy can adequately deal with all the changes that will need to take place.  We can suggest a default, we can allow people to extend or replace the default but if we do, we ought to make the change a first class citizen of the model universe we are building.

Behavior Change and State

Last post I was thinking about change and how one plans for change in the life of an application.  I became particularly interested in this after hearing from customers about the pain of versioning and how little we help them with this in the platform.  One trend that makes this even more painful is the idea that the platform can manage state for your application automatically.  The prime example of this is how Windows Workflow (WF) can automatically persist a workflow.

The vast majority of applications manage their own state.  In a typical N-Tier architecture, applications have a data layer that takes on this responsibility and provides a layer of insulation against change.  If the mean old DBA decides to change the database in some way, our friend the data layer can absorb the impact of such changes without them rippling throughout the entire application.  In fact the idea of every external interaction having a layer between it and the rest of the application is such a good idea that it is often used for services as well.  On the sending side a service agent can provide a place to contain logic that is needed for invoking an external service.  On the receiving end a service facade can be used to deal with boundary issues.

There are some principles we need to keep in mind about Behavior and State when thinking about change over time.  While not absolutes, I believe these principles to be true in general

Behavior and State are linked temporarily

You create an object, it has behavior which was built at compile time.  State on the other hand is built up at runtime.  It is either collected from a user, function calls or read from a durable store.  Eventually your object has both behavior and state that is required to fulfill it's task.  For some moment in time the two state and behavior are bound together.  Your application is designed to restore the world to this moment in time at some future point as well.

State lives longer than Behavior

The business process that your object supports outlives your object in time.  The time scale of the real world is much slower than the machine.  Instead of micro or milliseconds we operate on the scale of minutes, hours, days, weeks, months.  The state that helps us get our work done is mostly kept in durable storage so we can recall it, act on it and store it again.

Behavior Changes More Often Than State (schema)

Yes, state changes, but the schema of state changes less often than behavior.  You fix a bug, you modify a business rule, these changes occur with greater frequency than changes like adding a field to a table.

Behavior Changes often require State Migration

You changed a business rule.  Does this change affect state?  Possibly.  You might need to run the business rule again on orders placed in the last week.  You added a new field, in the database this field is now blank.  You might now need to run a process that will lookup or calculate a value for this new field in order to make the record valid.

The Place of Vulnerability

If there is one place in our application where we will feel pain around versioning it is in the place where the new behavior encounters the old state.  Whenever we have code that attempts to read state we must have a plan for what to do when we face this situation.  Increasingly the trend has been to want platform infrastructure to manage this for us automatically.  The typical way this is done in the past was to serialize the state to a stream of some kind.

While this sounds great on the surface, problems occur when the new behavior encounters this old state.  Usually at this point de-serialization fails because it doesn't know what to do with this old state.  Worse yet, if you cannot manually fix up this old state or successfully migrate it to the new state format you face the possibility of loosing data.

It seems to me that at this place of vulnerability, platform infrastructure needs to be very extensible.  This ought the place where you can modify, extend or replace platform behavior.

What do you think?

Living through "The Change"

Funny how it happens, but things change don't they?  Our applications, as perfect as they are when brand new, grow and change over time and like teenagers, sometimes these changes are quite painful.

Over the past few weeks we have been speaking to customers about their dreams and wishes for our children (WCF and WF).  These youngsters are just toddlers really but we all have high hopes for them.  One thing we heard repeatedly and loudly from you was that you need help with versioning and some said that we put no thought at all into this.

As I thought back about my past years at Microsoft I realized that for the most part you are correct.  Even though every app will have to live through a change, we platform builders give precious little thought to how we can help you live through this.  I recall the experience of COM+ where we added a feature to disable a COM+ app to COM+ 1.5 because customers pointed out that there was no reliable way to change the dlls associated with the app without actually unplugging the network cable.  How do you build a platform and have nobody actually think of such things?

In fact, if you are building an application, you should be planning for a change as well.  It seems to me there are several types of changes that we need to consider.

Add Something New

Your app is running along just fine, working the way it should when someone asks you to add something.  None of the existing functionality will be changed, just some new "stuff" will be added to it.  This should be the easiest type of change.  It involves the following steps

1. Build the new functionality
2. Test new and old together to make sure nothing breaks
3. Test the deployment in a simulated production environment
4. Deploy application with minimal disruption to production system

Of course, the simplest way to deploy an application is to shut everything down, deploy it, and bring it back up.  My guess is that this is the most common method of deployment of applications, with the second most common being to bring one node of a production cluster at a time down while the others keep operating.

Change Something That Already Exists

Your app is running but there is a problem.  It might be a bug, or it might be some missing functionality that somebody needs.  The solution is to change the app in some way.  It might involve a simple bug fix or something as radical as a complete redesign of the internal implementation.  I am not speaking of replacing an old system which is in my view something else entirely.  This type of change is more difficult but here is what you must do.

1. Make the change
2. Test the change (unit or functional testing)
3. Do integration testing with every other system that integrates with this one to insure that no previously working integration is broken
4. If the change affects the user experience in some way, document the changes, do user testing and plan for training and increased support needs during change rollout.
5. Create a deployment strategy and test it in a simulated production environment
6. Deploy the application with minimal disruption

Remove Something The Already Exists

Some portion of your application functionality is going to be deprecated.  You want to remove some useless appendage of data or functionality.  Like an appendix, the easiest thing to do is to leave it alone if it isn't causing a problem.  However, if you must remove it you will need to do the following

1. Analyze the effect of removing the thing especially with regard to historical data and reporting and user experience (are people using that thing for some purpose you are unaware of?)
2. Remove the thing
3. Test the app thoroughly to determine if the missing thing is going to cause a problem
4. Do integration testing with every other system that integrates with this one to determine if the missing thing will cause an integration problem
5. If the change affects the user experience in some way, document the changes, do user testing and plan for training and increased support needs during change rollout.
6. Create a deployment strategy and test it in a simulated production environment
7. Deploy the application with minimal disruption

Summary

Wow, in the process of thinking about this thing called change my thinking is evolving already.  Someone who is likely to successfully change an application will probably have the following traits

• They have developed their application with high test coverage (TDD anyone?)
• They have a well defined integration boundary with the app by providing integration "contracts" not only with web service endpoints but also for data integration via files or ETL type integrations.  This makes it possible for them to test the integration to determine if the integration contract is broken in some way.
• They have a planned deployment strategy from the very beginning and are able to test it in a simulated production environment (including data)

Now some of you should be screaming at me at this point because I have neglected one very large topic.  That is the topic of state.

Applications consist of behavior and state.  If you plan only for changes to behavior but neglect to deal with changes in state you are asking for trouble.  If your application consists solely of data that lives for milliseconds and only in memory you probably don't have to worry much about this but most applications consist of state that is created, modified, reported on and archived over a long period of time.  Changes to the behavior of the code that touches this state must be considered.  I'll save that for my next post...

What do you think?

Where are your big pain points with versioning?

AdventureWorks REST API Version 4 updated for Architect Connections Orlando

I've added support for conditional get in client side code with WCF (this is the only working sample of this you will find anywhere).  I also fixed the code to invalidate the server cache when the collection of customers is modified in some way.

The demo code is here

The slides are here

More to come from Architect Connections

 

Death at the hands of the Demo gods or PowerPoint glitch? You decide....

At Tech-Ed Israel I tried a technique I got from Juval Lowy with PowerPoint for the first time.  What Juval does is he clicks on an icon of Visual Studio to start it with the correct solution already loaded.  After sitting through his class I thought that I would give this a try.  it took a little work (and help from Juval) to figure it out but here it is.

You get a picture file of the icon you want to place on your presentation.  Drop the picture on the slide but don't add a hyperlink.  I know, you thought (as I did) that the way to run a program from PowerPoint was with a hyper link.  No my friend, what you need is to add an action.

With PowerPoint 2007 you can find the action on the Insert toolbar.  Now when you have an action you will see this dialog.

This allows you to run a program - wohoo!  So I setup a link to a Yahoo Search that I wanted to show in my presentation.  I tested it and everything was good (or so I thought..)

The day of the presentation when I clicked the link I got nothing.  IE cannot open the page etc.  I was so flustered I thought it was the show network.  Today as I am rehearsing for the same session at DevConnections in Orlando I realized what happened.

The shortcut is supposed to be this

C:\Program Files (x86)\Internet Explorer\iexplore.exe http://search.yahooapis.com/WebSearchService/V1/webSearch?appid...

And it was that after I put it in, I tested it and it worked, but then... I saved the file as a pptx file. When I loaded it again for the session I got this link instead

C:\Program Files (x86)\Internet Explorer\iexplore.exe http:\search.yahooapis.com\WebSearchService\V1\webSearch?appid...

Aarrrgh! My link is totally screwed up. PowerPoint has replaced every "/" with "\" and after the http: changed "//" to "\".  Had I read the link more carefully in the browser I would have found the problem but instead convinced that my machine was hosed, I rebooted in the middle of my talk.

Why didn't you just use a hyperlink you ask?  Seems like that would be the right solution.  The only problem is that the hyperlink always opens behind the presentation window.

So now what?

Now I'm going to use the Hyperlink and then switch to the IE window that popped up behind my presentation.  It is a drag but better than death at the hands of the Demo gods... 

My first WCF REST Talk at Tech-Ed Israel

How did it go?  Well... my demos tanked a couple of times...  I had to reboot the machine.  The A/V guys kept wanting me to change resolution on the screen because it was fuzzy.  The screen was small for the room so it was hard to read the code from the back.  But other than those things I'd say it was pretty good.  Who knows how the evals will go...  Sometimes people get really tweaked by these things and take it out on you.

I found the problem with one of the demos and fixed the code.  So I've uploaded it again.  This is the link to the updated code.

My RESTful Client / Service Sample

I worked right up to the wire here at Tech-Ed Israel.  I have to speak in just 2 hours so I'm calling it done for now.  This sample code demonstrates a RESTful Service API over the AdventureWorks database.  The code is not something you can just download and hit F5 with.  You will need AdventureWorksLT installed and I was running the Web Site in IIS so I could get Fiddler to work with it.  But if you just want read the code here it is...

Building and Managing the Magic of Software - My talk in Athens with Bill Gates

Often people ask me "Have you ever met Bill Gates?"  Well, the answer is no, I have not met him.  But recently I was in Athens where I gave a keynote speech at an event there where Bill Gates was the other speaker.  If you have heard about "Oslo" the code name for our next version of the .NET platform you might enjoy seeing this video of my presentation there.

AdventureWorks Security and webHttp endpoint behavior

Yes... these are the two devils that kept getting in my way today.  I'm going to tell you exactly what I found out about these two things since my fruitless web searches got me nowhere but some poor soul who follows me one day may find this blog post.

AdventureWorks

Everybody knows about the Northwind database but apparently the SQL team didn't like it too much.  A few years back they came out with the AdventureWorks database (in several flavors) including a trimmed down AdventureWorksLT database for sample applications.  They did a very nice job on the design of this thing and unlike the Northwind database security is clearly in force.

I have never tried to write code with the AdventureWorks database so I tracked down the Codeplex project where you can install the SQL 2005 version of AdventureWorks.  Of course if you are installing on SQL 2008 the MSI does everything you need.  But if you install on SQL 2005 you must manually attach the database files.  Since I'm running on Windows Vista I had to run SQL Server Management Studio Express as Administrator to do this.  That worked great but then when I ran Visual Studio or my App I was getting "Access Denied" whenever I tried to connect to the AdventureWorksLT database.

Finally after a great deal of searching I found the "Walkthrough: Installing the AdventureWorks Database".  This has good instructions for granting permission to ASP.NET to use the database.  I also added my account to all the grant statements as well.  That way I can access the DB even when I'm not running VS or my app as Administrator.

Then I had a load of fun writing my first real LINQ to SQL code.  Wow - this stuff is fantastic and unlike a lot of our stuff I didn't have to read a book or take a class before I could use it.

<webHttp />

Next week I'm giving a talk on RESTful services at Tech-Ed Israel and I'm frantically working on my demo code.  There are a number of pretty simple things in WCF that support this and many of them are clearly documented.  However this one little devil, the webHttp endpoint behavior was not one of them.  Yes, it is documented here, but every sample and slide deck I looked at neglected to mention this thing. 

The samples didn't use config files because they wanted to show the use of the config free WebServiceHost.  Great, but I wanted to host my service in IIS so I can't use that (or so I thought until I found Steve Maine's blog post about the WebServiceHostFactory - beware however that the full name changed since Steve's post.  In the RTM release it is System.ServiceModel.Activation.WebServiceHostFactory).

I built my service, I decorated the interface with WebGet and UriTemplates but whenever I tried to invoke my service via the RESTful API, nothing.  It just didn't work.  Normally if WCF detects a configuration that would not be valid it blows you up (as Juval says).  In this case I wonder how the webHttpBinding can possibly work but I digress.

As the end of the day was approaching and I was just about to give up, I was reviewing the MySpace guy's implementation of REST Chess and I noticed that little tag in the app.config file.  

Wohoo! My service now works with the RESTful URI!  Now I can focus on the HttpModule to support URL re-writing tomorrow and get busy playing some games tonight.

Fighting Through It

Some days it seems that it is just one battle after another, the first time to do "x", the first time you do "y".  Each new thing is just another obstacle of learning to overcome.  Unfortunately the information you need is often just out of reach... but don't give up.  Yes, it should be easier to get this stuff done, but in the end that's why you get paid the big bucks.

See you next time...

Why the wait?

I wasn't planning on writing a blog post now but... since Windows Explorer has given me a moment I decided to take this time to ask the question "Why?"

I've just uploaded a couple of files to a SharePoint site and I thought that I ought to organize the directory a bit by creating some folders and moving the documents into them.  This of course would be a breeze on a local hard drive.  On a network share not bad, but in SharePoint... a royal pain.

Consider what happens when you right click to bring up a context menu from a Windows Explorer window that is exploring a SharePoint site. 

1. Explorer goes into a coma while it waits for something.  I can only guess it is contacting the remote server to decide just what it is going to be able to show me in the context menu.
2. The wait cursor spins for so long that you give up and go do something else.
3. When the enumeration is finished, explorer detects that the window no longer has focus so it doesn't show the menu.
4. Perplexed you try again - instead of showing the same menu that it just paid a great deal to build - you go back to step 1 and start all over again.

I understand - explorer just wants to show me what I'm allowed to do.  However, in order to protect me from trying to do something I'm not allowed to do, it is willing to make me wait 20 or 30 seconds while it queries a remote server.

A Better Way

Let's think about this problem from an architectural and user experience point of view. 

Context

A user has requested a context menu by right clicking on a window that is displaying content from a remote system.

Problem

How do we provide the user with a context menu without putting the UI into a coma for so long that the user gives up?

Forces

1. The remote system could be accessed over anything from a gigabit speed high bandwidth, low latency connection to a low bandwidth, high latency connection.
2. The security authorization of the user on the remote system could be changed at any moment
3. The list of commands that the user is allowed to invoke on the remote system is not fixed but it is not infinite either.  One could guess at the commands that would be allowed because they list is commonly the same for most cases.

Solution

As we consider an optimal solution the following principles should apply

• Try to show the user the commands they are allowed to do if possible, but don't make the user wait
• Never, ever allow the user interface to go comatose by blocking the UI thread
• Inform the user of a long running operation and always allow the user to cancel the operation
• Cache work done on remote servers for some reasonable amount of time

If working on a high bandwidth, low latency connection build the menu on the first click

If you are on a low latency connection this will happen so fast it won't really matter to the user.  The trick is deciding on just how good your connection is.  If you are not sure then follow the next steps in this pattern.

When the app creates a connection to a remote resource, cache a "best guess" menu.

The commands allowed on the remote resource are fairly common.  In the case of explorer they are the typical file handling commands.  From the client point of view you know almost everything you need to know to display the menu with the exception of the current security authorization.

If you cache your "best guess" you could display a command that the user is not allowed to do.  Is this optimal?  No... but it is better than making the user wait.  In the event that they try to do something that they are not allowed to do the request gets an error from the remote system.  Is that bad?  Sure, but we should point out that this can happen even if you check the authorization before you show the menu because the authorization can change at any moment.

When the app executes a remote command, add a request to enumerate the authorizations for future requests

Once you have decided to make the remote call, why not be a little proactive and add a batch of requests?  Now you can have the server specifically enumerate the commands that the user is authorized to execute.  Replace your "best guess" cached menu with a menu based on the server response.

When making a remote call, always use async IO

Yes it makes the programming model a little more difficult but please don't put your app into a coma - keep it alive, alert and pumping messages by doing async IO.  Show the user what you are doing with something like a status bar message and please add a way to cancel the async request. 

Keep in mind that there really is no way to cancel an async request - this is just an illusion.  What you are saying is that when a request is canceled you will simply ignore the result when it is returned.

Conclusion

I finally got the folder created by going back to the SharePoint Web UI and creating it there.  Then I did drag/drop to move the files from Explorer.  It worked but it took a very, very, long time and even the drag/drop operation resulted in explorer querying the remote server prior to changing the mouse pointer.  The effect of this was that I had to do drag/drop by faith.  No I did not see the mouse pointer change to indicate the operation, however since the Mouse Button Down and Mouse Button Up operations were in the message queue when explorer finally got around to processing them it did indeed work.

What a pain... we can do better my friends, you can do better, for the users, for the experience of great software.

WCF Deployment Challenge - Phase II deploy to IIS on local machine

I'm once again comparing the ASMX experience to the WCF experience.  In this phase I'm simply going to deploy the Hello World type service to IIS on the local machine and compare the two.  I'm using IIS 7 on Windows Vista SP1 for my test environment.

WCF Deployment

I had previously installed IIS on Vista by doing the minimum, just checking the IIS box and accepting the defaults.  When I went to publish my site from VS2008 I click the "..." button and see that there is an option to publish to the local IIS.  Unfortunately I have not installed enough options to make it work.  I need the IIS 6 compatibility layer installed as well.  This should take a few minutes....

I went to Control Panel / Turn Windows Features on or off and then I added ASP.NET and IIS 6 Metabase and Configuration Compatibility.

Ok - deployed but when I browse to it I get an 404.3 not found.  IIS 7 is cool because it tells me more about why this request failed.  I see that the request was handled by the StaticFile handler which means that it went to the wrong place.  There must be more config to be done.

 

A quick search of MSDN for WCF and IIS turned up the just the article I needed to make this work.  All I had to do was go into the Windows Features on off wizard again and find the .NET 3.0 components and turn on WCF Http activation.

ASMX Deployment

Well.. what can I say.  This just worked.  When I setup IIS on my machine I enabled ASP.NET which made ASMX just work.  Another major obstacle to WCF adoption right there.

Conclusion

I have to give the deployment win to ASMX.  Especially when it comes to hosted scenarios.  If you go to any ASP.NET hosting provider you know your service will work.  With WCF you need to check to be sure they have enabled HTTP activation.  I'm not sure what the state of this is with Windows Server 2008 - I suspect it is better but I'll find out with the next challenge.

What do you think?  If we want to make it better, easier and faster to deploy WCF what should we do?

How about this...  When you go to deploy on a server have a tool that can interrogate the server to tell you if the deployment will work or not and what you have to do to make it work.

WCF Deployment Challenge

Join me as once again I tackle the learning curve of WCF with a deployment challenge.  Today - WCF vs. ASMX deployment.

Note: As the new WCF evangelist I have to say that WCF is clearly the future of web services.  In fact, the WCF team owns the ASMX stack and is maintaining it but the future direction is headed the WCF way.   You should know that.

The challenge:

1. Create and test a simple Hello World service on the dev machine
2. Deploy it to an intranet server
3. Deploy it to a hosted internet server

I want to learn what it takes to do this with ASMX and WCF.  Let's see how successful we can be. 

Round 1: Create and test a simple Hello World service on the dev machine

ASMX

This is a snap.  I start VS 2008, choose File / New Web Site / ASP.NET Web Service and hit F5.  Now I can test my service through the browser interface.  Hello World!

Time to successfully testing my newly created service on the local machine? 2 minutes.

WCF

Same process here, VS 2008 then File / New / Web Site only this time I choose WCF service.  Project opens... I hit F5 and... I get a page telling me to build a client app and generate a proxy using svcutil.exe.  Oh great...  What about WCFTestClient?  I'm going to give it a go instead.  If you are not familiar with this beauty check it out.  You can find it at C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\WcfTestClient.exe.  In fact I added it to my external tools in VS so I can quickly launch it.

I copied and pasted the service address from the page telling me to build a client.  This is the argument to the WCFTestClient so in my case the command would be

WCFTestClient http://localhost:40520/WCFService1/Service.svc?wsdl

Time to successfully testing my newly created service on the local machine? 3 minutes.

And the winner is?  ASMX

Yes - it is a minor victory to be sure but a victory never the less because after you hit F5 you don't need anything else.  You don't get a page telling you to build a client (that page really ought to provide you with a link to the WCFTestClient app - that would be a victory for sure.

3 things that we really ought to do better with that little page (and yes I sent this feedback to the product team just now...)

1. Tell people to use the WCF Test Client - this is way better and faster than writing your own test client. 
2. Tell people to open a VS 2008 command prompt - if you run svcutil or WCFTestClient from a plan command prompt that isn't going to work.  Of course you should know that but sometimes people get stuck on dumb stuff like this.
3. And we ought to include links to the documentation for these utilities right on the test page.

Conclusion

Ok... let's just admit that you ought to be learning and using WCF.  Some things about it are a little harder than they were with ASMX.  But with great power comes great responsibility right?  I'm clearly no expert on WCF (yet) but I'm planning on becoming one so why don't you join me in this quest.

What I've learned so far about REST with Yahoo Services

Well - I finally finished my Yahoo Services sample.  After I poked around on their site a bit more I found their search SDK.  I have to say I think mine is better of course :-).  I didn't put the Asynchronous Programming Model in the code after all.  I figure if you really want to do it, you can always call HttpWebRequest/Response on your own.

I did put a set of unit tests in there.  After much pain in trying to get the unit tests to work against a mock service instead of the real thing I finally gave up.  The classes in System.Net are just not well suited to this.   You can't create most of them, and very few of them are based on an interface.  This means in order to use them with mocks you have to create wrappers and factories for everything.  I did finally get it to work but the result was serious code bloat.  I could have reinvented System.Net by the time I finished.

It does show how important it is to factor your interfaces and classes so that they are more testable.  Anything that touches an external resource (file, network, etc.) should be mockable.  That means you create an interface and then implement it in your class.  Allow the test to supply an implementation of the thing so it can work against mock data.

Of course, I have only just begun exploring REST.  Next up, I want to understand the security model.  Different sites have different models but I'll see what I can do with what they provide me.

Oh yeah - here is the Yahoo.Services sample.  And Yahoo... if you want this code... well let's just say the offer is on the table :-)

Implementing the Asynchronous Programming Model

After the fun I had yesterday building my Yahoo Services Search Proxy (see my previous post) today I decided to see if I could extend my proxy to support the Asynchronous Programming Model.

And what is more, I wanted to use the TDD process to do it.  That meant that I would have to stub out implementations of things like HttpWebRequest/Response etc.  It took all afternoon and when I got done I had created my own implementation of the APM both as a provider and consumer (a really great learning experience) but in the end I must confess that I began to wonder if it makes sense to add this to the proxy class.

Monday and Tuesday I was in Jeff Richter's most excellent Advanced Threading class where we covered many of the reasons why the APM is a beautiful thing.  To be honest with you I only thought I understood threading before.  Now I know there is so much more that I don't truly understand about it.  However, one thing I know for sure.  If you want to build highly scalable and robust apps you should be asynchronous as much as possible.  There are two styles of async for .NET.  One is the APM which is interface and callback based and the other is the Event Based programming model (EPM) which is designed for client side developers.

Jeff told us that he is not a fan of EPM but to be honest with you I think that many developers will never do APM (even though it isn't that hard to do).  EPM is much easier but as Jeff points out probably not suitable outside of a client side project.

The more I think about it... WCF implements the APM in generated proxies (with the /async switch on SvcUtil).  If they can do it... I can do it.  I have the guts of it working...  Now I just need to think through the design a little more.  My class will then implement both APM and EPM so you can take your pick.

Fun to be coding again... so much to learn.

Confessions of a RESTful newbie

Over the years various people have asked me what I thought about REST as a style for implementing services.  For most of that time I felt that it was something that I didn't need to know or care about.  However... those days have now come to an end. 

Since .NET 3.5 includes support for building RESTful services I've now taken it upon myself to become knowledgeable about REST and the practice of building and consuming RESTful services.  One of my teammates Justin Smith advised me that the best way to start is by consuming services from some of the big guys so I decided to take on the Yahoo services since they were one of the examples from the chapter in RESTful Web Services that I'm currently reading.

Of course Yahoo does have a very simple console type program that shows how to access their service but please... that is way too easy.  No... I wanted to create something much better like a Yahoo Services Proxy library with full support for asynchronous operations and unit tests that test this library without actually hitting the server.

It took me several hours last night and most of the day today but I've come up with something I think is fairly cool.  Right now it supports only the WebSearch service but others will be added as I have time.

Right now the service just delivers the Xml payload to you.  I considered writing some additional code to use XLinq and map the results onto strongly typed objects but then I thought... that doesn't seem too RESTful.  Who knows... I might add it anyway later on.

I'm curious what you RESTful types out there will think of this.  I built the proxy so it could be used in Web or non-web scenarios.  It includes a WinForms test client app and some unit tests.

You can download it here.  Yes I did build this with VS2008 and .NET 3.5 so it does have a sprinkling of Lambda expressions in various places.