WF, WCF and declarative services (or: what does Microsoft mean by “declarative”?)

I created this community wiki because some might think it’s open to discussion, while others might think that the question of using words means what they really mean (in other words, this is a question of opinion, is this a question opinions).

Here's a general SO question about declarative programming , which has some excellent answers.

But I threw this blog post from a Microsoft evangelist a bit.

One of the advantages of declarative programming is that you can specify what you would like to do, but not how.

It is still so good that it is exactly consistent with the accepted answer to the SO question. Actually.

But then check out the "Service Implementation" section.

You can just take a look at a few dozen lines of xaml code and determine how WCF Service is configured and how the corresponding workflow is.

After looking at some examples, let me briefly answer this by saying, "No, I can’t." But instead of easily abandoning this material, look at the documents .

It took some time, but, finally, reality caught up with satire ... but this is not important - of course, they are not seriously proposing to do this in order to expose something trivial as an addition. I also do not complain about the ridiculous verbosity and the strange idea that someone will ever write something like this manually - this is more like a compiler output than a human-readable language.

The puzzle for me is that it is declared as “declarative”. And yet the core of this is the assignment operator.

Here's more here :

Declarative services are defined declaratively in XAML and provide a different layer of abstraction. Basically, you create a service model by defining that you want a service, not how to do it. The entire service can be defined declaratively, including operations.

So, if we speak declaratively or declaratively three times, this makes it declarative. Gotcha. And if we say the magic phrase “what do you want to do, and not how to do it,” we can neglect the fact that in the very next sentence we will still indicate “execution of operations”, and therefore we will say exactly how to do it .

An example on this page:

<wma:Sequence> <wma:WriteLine Text ='[String.Concat(String.Concat(String.Concat(String.Concat("Add(", CType(op1, Object)), ","), CType(op2, Object)), ") called")]' /> <wma:Assign x:TypeArguments="xs:Int32" To="[result1]" Value="[op1 + op2]" /> </wma:Sequence> 

In other words, this whole thing (including a ton of junk that I cut from the WF example) is exactly equivalent:

 void Add(int op1, int op2, out int result1) { Console.WriteLine("Add(" + op1 + ", " + op2 + ") called"); result1 = op1 + op2; } 

So - a block of statements that must be executed in the order in which they appear, and have side effects. Of course, there are elements of workflow activity for the cycle (and you can write your own actions if WF does not already have your favorite imperative statement). Apparently, “rewriting code in an unreadable format” is the same as “adding an abstraction layer”.

I repeat, this is not insane, unreadable verbosity, which I am complaining about - this is the fact that in the implementation of the service there is clearly a mandatory Turing programming, so what is the point? Before you know this, we will move on to our workflows in the debugger, trying to figure out which assignment operator mutated this value or why the loop continues to rotate forever.

(The irony is that in C # this is a little more declarative, because we did not specify how the fragments of the string should be combined, which allows the compiler to generate fewer calls to the Concat method.)

So does something write in XML, makes it declarative (and also less readable)?

+6
declarative wcf workflow-foundation
source share
2 answers

Another confirmation that using XML in capabilities other than the exchange format is time-consuming.

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

I personally feel quite understandable attacks of pure terror by looking at these XML documents.

+3
source share

There, a part of the Windows Workflow Foundation, which is not much discussed (outside of Microsoft), can clarify this for you.

If you create a Workflow project and look at the toolbar, you will see a large number of “boxes and lines” that you can drag onto the design surface. You can create the impression that you should create your workflows from this toolbox. This is not true.

You are expected to create your own actions specific to your problem domain. They are designed to connect various activities. Probably, these will be rather high-level events - such as “evaluate the insurance policy” or “record the patient’s stay”.

A declarative workflow (or service) will announce how to collect the activities associated with a particular task that are available to you.

0
source share

All Articles