"If you find yourself in a meeting with a mix of managers and programmers, here's one way to tell the difference between them: Look at what they brough to the meeting.

Did they bring a laptop computer? Score bonus points if the laptop computer is actually turned on during the meeting or if the laptop is special in some way (e.g., it has a wireless card or it's a Tablet PC). If so, then that person is probably a manager.

Did they come to the meeting empty-handed or with a spiral-bound notebook? If so, then that person is probably a programmer.

It's not an infallible test, but it works with surprisingly high accuracy." -- Raymond Chen

Hmm, maybe I shouldn't be taking my new Tablet PC to meetings...

One of the main talking points at Tech Ed was whether to use remoting or enterprise services to talk between service tiers. For the benefit of the guys at work I thought I'd try and collate some of the information thats available and draw some guidelines. I won't cover ASMX/WSE as I believe there is no argument there - for talking between services use ASMX.

Firstly, for an overview of the options for hosting objects and communicating with them, you can't beat Don Box's bullets:

• Services and Communications
• Services and Processes

Don however doesn't mention remoting as he is really against it. Rock Lhotka provides a view that includes remoting:

• Middle-tier Hosting: Remoting vs. Enterprise Services

These two articles from Richard Turner (a program manager working on "Indigo") give you the inside view.

• On the road to Indigo - Is .NET Remoting Dead?
• On the road to Indigo: Prescriptive Guidance for Today's Technologies

Finally, another good roundup is by Aaron Skonnard reviewing Richard Turner's Tech-Ed session:

• TechEd: SO Prescriptive Guidance (Richard Turner)

I think the general guidance from all these articles is that remoting is OK given the following rules:

1. Only use it between tiers on the same machine (Otherwise use DCOM/ES instead)
2. Don't use any of the custom stuff like formatters and sinks
3. Don't use it at the service boundary (Use ASMX instead)
4. You MUST use remoting to communicate between app domains in the same process
5. You may have to do some rework when Indigo arrives

Good as Tech-Ed was, this is one thing that I was a little disappointed by and thats the "Ask the Experts" stand. At first sight it looks promising - lots of Microsoft staff, mini white-boards and plenty of discussion. Unfortunately the reality isn't quite the same - most of the Microsoft staff are deep in conversation with each other and when you do manage to ask a question the answer is less than satisfactory.

Maybe I'm asking the wrong questions but I get the impression that the people staffing the stand are marketing personnel because their knowledge doesn't seem to run very deep. I was ready for a good conversation about threading models and scalability of Reporting Services but the person I spoke to fell at the first hurdle. He didn't think anyone else at the stand would be able to help either and gave me an e-mail address with a promise to find the answer I was looking for.

The same thing happened in Barcelona last year so my advice to Microsoft for next year is to ship some developers out from Redmond and not use marketing and support staff from the UK.

One of the sessions I went to last week was a talk by Don Box entitled "Service Orientation and the Windows/.NET Developer". I loved this session, especially as he got all the attendees to ask questions at the start, rearranged them and then spoke for 75 minutes to try and answer them in turn.

He is a fascinating speaker who uses a lot of colourful phrases to ensure you remember what he was saying. One I can't get of of my head is:

"Service Orientation is like teenage sex - Everyone is talking about it, but not many are doing it" - Don Box

Don actually ran out of time before answering all the questions, but he did promise to write it up on his blog. Here are the two he has done so far:

• Services and Processes
• Services and Communications

p.s. Don also pointed the way for next year.... Look out for "Business Agents"....

I have a couple of photos of the keynote, but I'm pretty awful with the camera so have a look at someone who is a lot better.

The Keynote.

What is the sound of 6000 people drumming?

The SmartPhone demo.

Brad and I are just sitting in the airport enjoying a coffee before the flight. It's been a hard week - getting up at 6am to ensure we were at the first session on time, six 75-minute sessions a day and some sort of event in the evening to make us late back to the hotel. Has it been worth it? Of course - the main points to take away are:

Don't use .NET remoting - its slow, won't interoperate and will be eventually deprecated.

Use ASMX and/or Enterprise Services instead - a lot of work has gone towards making them highly performant and scalable.

SQL Server 2005 is comming - its going to both make your life easier and, if you're an ISV, trample over your business model. Time to look for that next pardigm shift.

Microsoft are getting even more into the developer tools arena - enterprise source and project control, integrated testing and code coverage tools, also code checking and verification tools. I spoke to both Perforce and Compuware to try and get their point of view and see how worried they were.

Compuware trotted out the company line that they have always built on top of what Microsoft provides and will continue to do so.

Perforce were not quite so upbeat - their response was more of a "lets wait and see what Microsoft ships". They made the point that they have probably the fastest source control tool on the market and wonder if Microsoft can match it. They also showed me some new visualizations they are developing related to how the code changes over time - colouring lines based on how old they are. It looks a useful method to find out how a file has evolved.

Two words - "Database Mirroring"... Almost instant stand-by with very fast (~3 seconds) automatic or manual fail over. The client libraries also detect and fail over automatically too. To ensure this happens correctly a third server called the "Witness" provides majority logic to ensure that only a single side is up at any one time. I also get the feeling that Microsoft would prefer you to not attempt to use replication as a fail over solution as there are a number of issues to overcome - data loss, client fail over, recovery and the amount of custom code required to make it work properly. One thing you can't do on a mirror is use it. Kind of obvious really, but you can't even connect in a read-only mode.

Help is at and though - another interesting feature that will be available is a "Database Snapshot" which uses copy on write semantics to provide efficient views of a database at a point in time. A snapshot does not need to copy the database as it will reference the original database pages until they are modified. These snapshots can be created on mirrors which provide ideal access for reporting. Those that have all their data stored in a single database may want to think about splitting it into reporting databases and online databases. Basically, stick the information into a reporting database but keep the OLTP and application runtime data in another.

One last honourable mention is for SNAPHOT ISOLATION LEVEL - similar to Oracle's row versioning. But remember that tempdb is used to store the version information whilst a transaction is in progress.

Data Transformation Services been completely re-written for SQL Server 2005. The main difference is the separation of workflow and dataflow. But additional niceties include for/foreach looping, debugging, and OR constraints which mean daft hacks are not required. In fact modifying the package at runtime is impossible.

The new dataflow pipeline deserves a special mention as its no longer one row in one row out. The transform can consume data from multiple sources and send to multiple destinations in a single task - this allows for some interesting merging and splitting of data. Set operations are also supported - sort, aggregate,  split, multicast amongst others.

DTS has grown up and can play with the big boys. If DTS 2000 is not enough for your needs right now then consider waiting for SQL Server 2005 and not trying to implement yourself.

Our free 'gift' was an African drum. To warm everyone up for the key note they had a drum band lead the entire set of delegates in a mass drum session. So 45 rhythmic minutes later with arms about to drop off; the session started.