+3  A: 

Yet another acknowledgment that using XML in capacities other than exchange format sucks big time.

Service "definitions" in WCF have been declarative from day one. However, separating interface definitions from service definitions (by this I mean ServiceContractAttribute et al) is, IMO, good thing. However, using XML as a programming language really sucks.

I personally feel quite explainable attacks of pure terror when looking at these XML docs.

Anton Gogolev
A: 

There's a part of Windows Workflow Foundation that isn't much discussed (outside of Microsoft), that may clarify this for you.

If you create a Workflow project, and look in the toolbox, you'll see a large number of "boxes and lines" that you can drag onto the design surface. You may get the impression that you are meant to create your workflows from this set of tools. That is not the case.

You are expected to author custom activities specific to your problem domain. These are meant to be connected by the various out of the box activities. These are likely to be fairly high-level activities - things like "evaluate insurance policy" or "record patient stay".

A declarative workflow (or service) will be declaring how to put together the problem-specific activities you have available to you.

John Saunders
"declaring how to put together" - but only in the sense that a method body in C# "declares" how to implement the method. And note the appearance of the word "how", which is what declarative programming is supposed to avoid. What is the line between declarative and imperative, given that the workflow activities carried out by a service are typically imperative steps (however chunky) and so have to operate in an imperative sequence, and glued by imperative out-of-the-box WF activities?
Daniel Earwicker