Several of the Tech Ed speakers (myself included) have donated an hour of our time to charity, and you can help!

Go to http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5587400881 and bid for your speaker of choice.

The idea is that you'll get an hour of valuable time you can use to get questions answered or problems solved, and the money will go to a good cause.

Virtual PC (and/or Visual Server) are the most wonderful things to happen in a long time - especially if you use any beta software or do any system configurations that might damage or corrupt a real system.

But getting these things to run fast, especially on a laptop, can be a serious challenge. Here's a checklist of things I've been doing recently to get decent performance.

1. Make sure to uninstall/reinstall VPC and SP1 after upgrading the host Windows XP to SP2
2. Make sure to install/reinstall the VPC add-in software on the guest OS after upgraded to VPC SP1
3. Put your vhd and vmc files on different physical hard drives (not just partition)
4. If possible, put your vhd files on a different physical hard drive (not just partition) from your host OS system drive
5. Before starting VPC, do the following on the host
   1. Stop SQL Server
   2. Stop IIS
   3. Stop any virus scanning software
   4. Stop Messenger or other IM software
   5. Close all apps
   6. Close or stop any other items in the system tray or via the Services manager - anything you can stop that doesn't crash the host is to your benefit
6. Grant your VPC the most memory you can afford. After doing step 3, I'm able to grant 640 meg to the VPC on a 1 gig host machine.
7. The more memory on the host machine the better. 2+ gigs of RAM rocks!
8. If you need to put the host in standby, close VPC entirely first. Not just VPC instances, but close the VPC console itself. There are bugs with VPC that cause display failure issues when the host comes out of standby
9. If your VPC mouse pointer ends up with a black box around it (in LiveMeeting or other projection software), go to your video settings under the Settings tab, Advanced button and turn hardware acceleration down one notch

I'm sure there are other tips and tweaks, but doing these helps a whole lot with VPC happiness!

It is clear to me that Service Oriented Architecture has gone about as far as it can go in a vacuum. And Service Oriented Programming continues to evolve somewhat randomly as vendors and/or standards bodies see fit (WSE, Indigo, etc).

So there needs to be more rigorous thought apply to Service Oriented Design. If we assume the SOA concepts of autonomous entities communicating via contract-defined messages over negotiated channels. And if we assume we’ll have programming tools that provide contractual synchronous and asynchronous communication vectors, then we can move ahead and work on thought models for designing services and systems composed of services.

Note that there are two very different aspects here. One is how to create a service, the other is now to build systems where services interact. The inside view and the outside view. And the rules and concepts are very different for each.

In that vein, here's a good/interesting article on SO design from Rich Turner at Microsoft. He’s taking the inside view and discussing some high-level design concepts for how you might build an autonomous service that still requires other services to function. He’s proposing a couple thought models that might be useful in design efforts – exactly the kind of dialog that is required to move SOD forward.

Personally I think that a number of the object-oriented design concepts behind CRC cards (class, responsibility, collaboration) apply equally well to services. In such a scheme, Rich’s relationships (constellation or fractal) would be listed as collaborators from a service.

I’m convinced that at least the first side of a CRC card, where the class (now service), responsibility and list of collaborators (other services) are a good design tool for services. Some of the other sides (like the list of behaviors) aren’t so useful, since a service is an atomic procedure and thus by definition has exactly one behavior. Still, applying those parts of CRC that do work is very helpful.

Over the past few weeks I've given a number of presentations on service-oriented design and how it relates to both OO and n-tier models. One constant theme has been my recommendation that service methods use a request/response or just request method signature:

   response = f(request)

or

   f(request)

"request" and "response" are both messages, defined by a type or schema (with a little "s", not necessarily XSD).

The actual procedure, f, is then implemented as a Message Router, routing each call to an appropriate handler method depending on the specific type of the request message.

In concept this is an ideal model, as it helps address numerous issues around decoupling the client and service, and around versioning of a service over time. I discussed many of these issues in my article on SOA Covenants.

Of course the devil is in the details, or in this case the implementation. Today's web service technologies don't make it particularly easy to attach multiple schemas to a given parameter - which we must do to the "request" parameter in order to allow our single endpoint to accept multiple request messages.

One answer is to manually create the XSD and/or WSDL. Personally I find that answer impractical. Angle-brackets weren't meant for human creation or consumption, and programmers shouldn't have to see (much less type) things like XSD or WSDL.

Fortunately there's another answer. In this blog entry, Microsoft technology expert Bill Wagner shows how to implement "method overloading" in asmx using C# to do the heavy lifting.

While the outcome isn't totally seamless or perfect, it is pretty darn good. In my mind Bill's answer is a decent compromise between getting the functionality we need, and avoiding the manual creation of cryptic WSDL artifacts.

The end result is that it is totally possible to construct flexible, maintainable and broadly useful web services using VB.NET or C#. Web services that follow a purely message-based approach, implement a message router on the server and thus provide a good story for both versioning and multiple message format stories.

Indigo, btw, offers a similar solution to what Bill talks about. In the Indigo situation however, it appears that we’ll have more fine-grained control over the generation of the public schema through the use of the DataContract idea, combined with inheritance in our VB or C# code.