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.
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.