There seem to be two camps in the world of SOA - those who want to live somewhere near the top of the stack (using ASMX or Indigo's service-level "object mapping"-like technologies), and those who live nearer the XML messages themselves.

I'm firmly in the latter camp - and I've got two justifications.

But first, I'd better make clear a couple of assumptions. I am assuming that the benefits of service-orientated architectures lie fundamentally in the asynchronous exchange of well-defined messages to request well-defined semantic services from providers residing at well-defined end points. Secondly, I am assuming that we are talking about designing and building services, not consuming them.

I'll take each of those italicised points in turn:

• Asynchronous
• Addresses the issue of latency in transport and execution
• Improves scalability
• Requires consumers to assume that services are not instantaneous, encouraging appropriate design
• Messages
• Encapsulate information in a robust, structured fashion
• Designed for portability - from provider to consumer
• Define information domain for service providers and consumers
• Encourage well-bounded design
• Well-defined semantic services
• Explicit contract
• Should be defined by semantics, not by signature or implementation
• Providers
• Host services
• No particular implementation or deployment technology implied
• End points
• Well-defined means of exposing hosted services to consumers
• Abstract details of providers from consumers

None of these points require any particular implementation technology, platform, language or infrastructure, although, in general, we think of the WS-* standards, and stacks like ASMX or WSE over network technology like TCP/IP.

I've recently had to implement a message-passing application based on eBXML (don't ask!). eBXML is largely SOAP based, and requires a stack analagous to the WS-* bits; very similar in many ways, but completely incompatible. But susceptible to a service-oriented analysis nonetheless, and susceptible to the same arguments.

So, on that basis - on with the justifications.

Justification the first

In real-world service-orientated designs, there are two things which are critically important

1a) Getting the granularity of the services right

1b) Getting the granularity of the messages right

"Right" in this case can mean a number of things. Appropriately coupled, appropriate amounts of information being transferred, appropriate for reuse. It has got a lot to do with both the semantics of the service, the expected consumer model and the deployment model.

Abstracting away from the actual message design makes this much harder to get right, apart - possibly - from the expected consumer model. Unless the message payload is very simple (and the canonical calculator example is not very "real world"), then imposing an object-mapping on service designers seems overly (if not dangerously) restrictive, even if an object-mapping might ultimately be useful to a consumer (although that should be the consumer's decision).

This is not to say, then, that service consumers shouldn't be presented with an object mapping. It's just that providers and consumers rightly have a different view of the world, and the message-level design is more useful to the service builder.

Justification the second

Having got the service design "right", it is important to consider how a message-passing design impacts on the rest of your architecture. You have to assume that messages will get lost in the post, go missing, get routed to the wrong place. You have to assume that messages that you thought were lost will turn up unexpectedly weeks later. You have to assume that malicious individuals will try to route messages unexpectedly.

Not all of this is simply a "plumbing" problem. To sort out the real-world semantic implications of these kinds of async message exchange problems, you often need to involve end-users with domain knowledge to help sort things out; ideally these are not "sysadmin" type people, but real domain users who are prepared to deal with the semantic results of an infrastructure problem.

If you don't actually control or understand the actual message layer of your infrastructure, it is very difficult to come up with a sensible design for that part of your application. This isn't a problem that can be mitigated by a general, horizontal solution - it critically depends on the nature and intent of the messages.

In the eBXML example above, for instance, presenting views on the "missing" or "unexpected" messages, often aggregating several together for presentation to determine what to do (accept some or all of the implied semantics, modify, resend, carry out other function x,y or z...etc...etc...)

If you've lost (or never really understood) the granular nature of the services you define, implement and deploy, it is very hard to get this kind of resolution right. If you don't address these problems, then your applications will be brittle and prone to intermittent, difficult-to-resolve problems.

So, that's why I'm in a "design your messages, think about message interactions, and only provide object-mappings to consumers who need them" camp. Come and join me. I'm toasting marshmallows on a stick over here.

Gosh. Doesn't time just fly.

This morning I opened my desk drawer, and saw the shiny black PDC 2003 highlights DVD at the top of the pile. Minutes later, I was registering for PDC05 in September.

If you've not been to a PDC before (and I've only been to one, and can therefore speak with great wisdom and sagacity, oh yes), and you're wondering whether you can really justify going - then wonder no more! It really is a must-attend event. Go on, tell your boss I said so.

Although PDC03 was cool - because we got a first look at Avalon and Indigo - it really just hammered home the "you want to think about moving to .NET, and soon" message. There was plenty of groovy stuff, and the vision was exciting, but it wasn't (yet) a coherent story. You were "there at the beginning(tm)" but that didn't perhaps, fully justify the cost of attending in and of itself (although there were plenty of other things that did). So don't beat yourself up that you missed it.

What about 05? I'd be willing to bet that we don't quite have a coherent future story at PDC05, either. But I reckon it will be mostly coherent, and the apps that we build in 2007-8 will recognizably be of the same breed as the technology presented at the conference.

Also, there's important stuff of the "very nearly here and now" that was only touched on at the last PDC. Team System is probably the most significant, but in-depth sessions on .NET 2.0 technologies are going to be as important (if not more important) than the futurology.

And that's only the stuff that we know about. PDCs have always seemed to have a surprise. (Even if it was only the surprise of "What? That's it?!" Hailstorm PDC in Orlando, 2001 ) Oh - and there's every opportunity that you can induce a diabetic coma by partaking of the donuts.

But - what if you don't get to PDC? I really hope that MS UK repeat the fantastic job they did in '03, running a local "Not the PDC". While I get to go and be threatened by bored immigration officials at LAX, the folks in my team in the UK don't, and they benefitted enormously from the "home grown" conf-ette last time around.

Well - the woe still exists in VS 2005 Beta 2... And it is still intermittent. The occasional appearance of the classic "open the solution having closed it with a designer window open" problem. You see the (kinda to be expected) error window indicating that some dependencies are missing - but the designer round-tripping still deletes the code referencing the "missing" components.

(Note - I think that VS.NET Beta 2 is otherwise a work of genius. Just the rename-refactoring smart-tag makes it worth the entry price)

Last week I posted about Component.Dispose(). MS have now resolved the bug I reported. Their reasoning is essentially that:

1. Component.Dispose() contains code vital to the design time environment and shouldn't therefore be mungable by the user.
2. Hard links between designer/user code are strongly discouraged (so they can't just split them across the two files, as for InitializeComponent)
3. The Disposed event provides a user-accessible means of performing your clean-up.

I agree with (1). (2) and (3) make me uncomfortable.

It doesn't surprise me that they were left with InitializeComponent in two halves; and clean-up is the flipside of intiialization, so why don't they look the same to the end user? If the Disposed event is the way to deal with clean-up, why didn't they create an Initializing event to handle bootstrapping?

I've made a couple of posts in recent months on when to avoid using threads, and why it is so difficult to use them correctly. But I haven't really posted anything about when when we will really gain any benefit from multithreading. There are several conversations on this subject around at the moment, and we were also having a discussion in the office, so I thought I'd distill my thoughts into this entry.

First, the parameters for this discussion have changed in the last twelve months. Until recently, I'd have said that there's nothing intrinsically "multithreaded" about the average user's PC. They tended to have a single processor, executing instructions in what amounts to a one-at-a-time scheme (ignoring implementation details like pipelining). Windows, on the other hand, very kindly gives us an environment which looks like it is executing more than one instruction at the same time.

It isn't, of course. It is faking it, and the overhead to create that environment is huge. (Probably huger than it needs to be, but I think we're stuck with that legacy. Longhorn has some stuff to help improve matters, in terms of execution guarantees, but still...). Thread context switches can take forever...almost literally, although on the whole they take order of a few 100s of usec or so. But a few 100usec - that's a heck of a long time in the modern world. And if that's an overhead on top of our actual processing work, how come we ever see any benefit from multithreading?

Well, it turns out that most of the time our processors just aren't doing anything much at all - except servicing a bunch of context switches amongst threads blocking and waiting for something to happen.

But, as I mentioned, things are a bit different now. Oh yes. We've got *multiple* processors (or processing units masquerading as separate processors in the case of Intel's rather nifty HT technology). And they're *all* mostly servicing a bunch of context switches amongst threads blocking and waiting for something to happen.

Oh, Brave New World.

So, how can we take advantage of all this idling?

Well - if we've got an operation we want to carry out that can be decomposed into several independent, parallel operations, each of which involve waiting for something to happen where we're *not* using the processor very much (such as local disk IO - loading a big file for instance; or network traffic - like talking to a remote database or service), then each of those subtasks is a good candidate for being pushed out onto a separate thread. Making several database or web-service calls, and then processing the results. Each database query or web service call could be executed on a separate thread, and then the results aggregated by the controlling thread when all the results are in. Of course, there's the cost of setting up and tearing down multiple connections, and that might swamp your actual execution time, so you should still measure before implementing this kind of optimization, but the potential benefits can be huge.

But there comes a limit where the cost of scheduling the threads + the actual work being done on the threads equals the amount of processing power we have available. At that point, it is no longer beneficial to spawn another thread, because there isn't any more processor grunt available, and - worse - we're going to have to pay that extra context-switching overhead.

That's why we use *thread pools*. We limit the number of threads that can execute at once, based on a heuristic which estimates the average amount of processing vs. blocking we're doing on any given thread. .NET has a couple of thread pool implementations internally, like the one we use when doing Delegate.BeginInvoke()/Delegate.EndInvoke(). While heuristics used for the built-in pools are not going to be ideal for *all* situations, they're probably right enough for most. We should have strong, metric-based evidence if we think we need to change those rules, by implementing our own pool, or using the new 2.0 APIs which let us tweak the threadpool limits.

9/10 apps say they prefer the system defaults. By those ratios, mine probably isn't the one, and yours probably isn't either.

But don't forget that starting/using other threads is not the only option. For example, back in the day, we used to have the idle processing in MFC apps... (We've still got it now in .NET, but this cooperative multi-threading has fallen out of favour, mainly because of uncooperative usage models!)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_idle_loop_processing.asp

How did this work? well, the main UI thread spends most of its time blocking waiting for a message to arrive, because something needs repainting or the user moves the mouse or whatever. But it spends a looooong time blocking, and a very short (but intensive) time dealing with the message. So, MFC's message loop implemented a call to an OnIdle() method. We could (quickly) do a bunch of background work and it would appear to happen "in the background", without interrupting the main business of the UI thread. Actually, there was no special "multithreading" magic going on. We were just calling a bit of code "between messages", taking advantage of that huge amount of idle time. But it *looked* like multithreading magic, by making *better use* of the time we spend just waiting for something else to happen. And no locking problems, either. Of course, you have to be cooperative to make a cooperative scheme work, and that's often where this falls down.

So, to sum up.

1) Multi-threading is useful if the total amount of actual processing work you want to do at any moment is within the capacity of your processing units, otherwise you're just adding overhead and it would be better to queue the work on a single thread and blitz through as fast as possible

2) Multi-threading is useful even on a single processor machine *because* most operations involve a lot of hanging around waiting for non-processor-intensive activity to occur (like network traffic, IO etc)

3) Multi-threading is useful if you've got multiple operations that must appear to the client to occur concurrently - like UI responsiveness and "anything else"

4) Thread-pools are a technique used to help keep your multi-threaded activities within the bounds of common sense. Mess with the built-in common sense at your peril.

5) Using idle time effectively doesn't necessarily mean starting another thread. There are other patterns available.

What's the big deal about Visual Studio Team System? After all, we've got NUnit, NAnt, CVS/Subversion/SourceSafe(yak),Bugzilla,MS Project...

One word - integration. MS' killer secret to success.

I've just spent a couple of days planning our next software iteration. The team has spent time triaging candidate bugs in our bugzilla-based database, making risk assessments, implementation plans and estimates. I've worked those into our iteration project plans (for release on two project branches, with 3 SKUs of each), correlated them with deployment plans from the applications team, used my magic linking macros to hyperlink from project to bugzilla and back. (I'll be glad when we complete a hire for a new Program Manager, and this isn't my problem any more! )

The most time consuming parts of all of this are just boilerplate: transferring data from one system to another. Even with an internal investment in integration, it still requires a lot of manual overhead. We'd have to spend a small fortune in developer time to get these tools to play seamlessly together.

VSTS promises that integration "out of the box". But what about the existing investment, and the transitional costs?

I'm thinking hard about what the right decisions are going to be for my business, what my return on investment will be short, medium and long term. I'll keep you posted on what we do, and why.

FxCop has an excellent rule which encourages you not to do this kind of thing:

if( foo is Bar )

{

    ((Bar)foo).DoBarStuff();

}

but to do this kind of thing instead.

Bar bar = foo as Bar;

if( bar != null )

{

       bar.DoBarStuff();

}

The rationale for this is that example one involves two casts, whereas example 2 involves just the one (and a simple reference test for nullness).

The snag is that FxCop moans at us when we do this with a value type.

The difference is that you can't use the as operator to determine the type of a boxed valuetype, and if you try the "cast and test" approach, you are no longer dealing with a test for nullness, you're catching an InvalidCastException, which is (usually) even more painful than the double-test.

I think that FxCop is being somewhat agressive here, and the is...cast approach is appropriate for value types. Unless you folks have a better idea?

IanG (thanks for the plug!) pointed out that I was being v. lazy by not posting the handy macro code I alluded to earlier, which closes the designer windows.

So here it is. Paste it into a new macro project.

Imports EnvDTE

Imports

End Sub

End Module

This just enumerates all the open windows in the IDE (including the toolbars) and works out whether any of them are IDesignerHosts, and closes them, giving you the option of saving them as you go along.

I've included a couple of commented-out lines that use DTE.ExecuteCommand(), to tag on something else after closing the designers - the two most useful are Build.BuildSolution and Debug.Start (equivalent to...well...building the solution; and the build/run command bound to F5)