Sometimes I wonder... Other times I know.
Monday, December 05, 2005
 
Transparency and markup
Recently, we've been discussing the pros and cons between offering markup (xoml) versus "code-spit" as the default workflow project templates. By code-spit, I mean the currently default project templates which generate the activity tree in the InitializeComponent(). The markup templates can be accessed through "Add New Item"..

Inevitably, someone will question the "transparency" of the code-spit approach. The argument being that code-spit is imperative code and as such, you lose the ability to inspect it for meaningful analysis (to answer questions like: where are the workflow persistence points? what will cause compensation of a chunk of workflow? how and where does the application perform messaging?)

Most developers believe that markup (XML/XOML/XAML) implies transparency.

In WF, we think of transparency as the ability to answer these questions by inspecting the application definition, where the application definition is the serialized activity tree. The WF runtime doesn't care about what serialization this format is... it could be serialized in XOML, BPEL, CodeDOM, or a CLR constructor - as long as the runtime can construct the activity tree out of the serialized format, all is good. Stated another way, the runtime is agnostic of serialization format.

The transparency is achieved by describing the program structure in terms of activities.

If you're authoring workflows in via "code-spit", the two files you'll see are the ".cs" and the ".designer.cs". The latter contains the the InitializeComponent()where the workflow tree is defined. All user code is defined ".cs"..

In you're authoring workflows via "markup", the .xoml file contains the equivalent InitializeComponent() serialized to xml and the user code still resides in the ".xoml.cs".

Stated another way, a workflow which is written in "code-spit" and comprised of activities with no code handlers is as "transparent" as a workflow defined completely in markup (with no handlers).

So, transparency is not a factor in choosing a default authoring project template.

I'm very interested in hearing what approach workflow developers would prefer... would you like the default project templates to be markup or "code-spit"?

Friday, December 02, 2005
 
James moves on...
Or should I say "up"?

James Conard has taken a up a management position and is now back-filling his Windows Workflow Foundation evangelism job. Congrats James!

For those who are interested, his old position is now available. But I should warn you, James did an awesome job so there are some big shoes to fill!