How is "workflow" different from "visual programming?"

Is there something intrinsic about "workflow" that needs to be surfaced to folks or would any visual programming language do? I'm not finding any commercial products in my web searches, but I know that there have been some "integrated component"-style programming languages where you lay flow and logic out from a set of components on a toolbox. Is Windows Workflow Foundation one of those that MS just happens to be doing or is there something important about "workflow" that interests folks?

I think that the workflow is not for the developer, it's more for the final user or to customize the final product.

eg: In my ERP system, you can configure if you want a pre-order before the purchase order, before the Purchase invoice *or* you can configure (for your company) only to have to enter the purchase but sending an email to some guy.

Hey Chris,

To my mind workflow != visual programming. Workflow a declarative description of a process, of a set of activities and their relationships. Workflow is about the semantics of moving from one activity to the next (activation semantics), the flow of data between those activities.

Now, it just happens that workflows are better designed using visual primitives. However, the two are not coupled.

Hence, I vote for workflow != visual programming.

In fact, in one of our research projects, we developed a language for imperative, object-oriented visual programming (not workflow... we had defined different semantics for the arcs and what was "travelling" on them).

Just my 2c.

Regards,
.savas.

Chris,
I have been working on something quite similar to "a visual programming" system for last 3-4 years. Think of it as a Visual Studio but with a flow-chart instead of C# code. It does pretty much all what a simple IDE/debugger would do. Breakpoints/single stepping/watch windows/extensible toolbox/extensible programming elements/subroutines/you name it.

Industrial implementations of a "Workflow" resembles more like a state machine than a simple sequential flow.
Get an event -> Do an Action -> Save your current state -> wait for indeterminable periods of time(could be from 1ms to months) for an event to occur -> Wake up and restore state -> Do an action ->...and so on

So you "can" implement a "workflow (in the industrial sense)" through visual programming. But it takes a different mindset on the part of the "tool developer" and the "tool user" to make it really work as a true workflow.

I have been looking quite a bit into Workflow Foundation to see if it has that mindset. What do you think?

Look for Softwire. They had some VB6 add-in for visual programming. I think it is free now (and that may say something about CASE tools)

How many programming languages allow the current position in the execution flow to be saved out to some persistence mechanism such as a DB, and reconstituted later on (possibly on a different machine in your server farm) when it's time to progress to the next step?

I gather this is possible with WWF. (It's a question that has come up every time I've seen WWF shown in front of an audience so far, and the answer has always been "yes" so I *hope* you can do it...) It's not common in most programming languages.

But I'm not really sure what you mean by a "visual programming language". Is Visual Basic a visual programming language? I'm guessing probably not for the purposes of this discussion, as I don't see an obvious parallel between the visual workflow design in WWF and any of the visualness in VB. But since I don't really know what you mean, I could be wrong... What constitutes a 'visual' language? I don't know many myself...

The only truly visual programming language I'm at all familiar with is one I wrote the IDE for about 15 years ago. It was a flowchart-based programming language for controlling robotic hardware. It did basic flow control, multi-threading, looping, subroutines. And it was definitely visual - it didn't actually have a text representation at all, so the only way to edit it was visually!

So, is there stuff WWF does that my language didn't do? Well the most obvious thing that springs to mind is that my language was very application specific and consequently not remotely extensible. (It's pretty much the opposite of the semantic-free idea that Don talks about when presenting WWF.)

But for me, that's not the most interesting different. I think the answer to the question isn't so much what WWF makes possible, as the style of the approach it offers. Would any visual programming language, whatever that might mean, do? Well, if it's a sufficiently powerful language, then yes. But you may as well drop the word 'visual' from the conversation - any suffuciently powerful programming language will be able to do what WWF does...

(After all, it's not like WWF is intrinsically visual either - you can program it without the use of the visual editor. You're not required to use xoml either.)

The thing I find most interesting about WWF is that it gives me a pre-built set of idioms for expressing stuff at a much higher level than normal code. Most interesting applications have flow and logic that works in bigger chunks than programming languages tend to work with, and it's hard to have that structure expressed clearly in the code. I think this is one of the reasons we've seen a lot of interest in DSLs lately.

WWF looks to me like it could offer a place to put that structure without me needing to invent a new DSL for each project. (And of course it also lets you provide the fine level of detail stuff that classic code is good for, inside of the chunks that make up a workflow.)

The 'visual' aspect is not really relevant to what I find interesting. It's nice to have, because that's how I'd be inclined to represent this aspect of a system on a whiteboard, and often end up with diagrams of this sort in design specs. But what's much more interesting to me is not the visual representation, but that fact that there's a *code*-like artifact that represents important high-level aspects of a system's design that used to be a part of the design with only a vague representation in the code.

Our company makes a product called LabVIEW (http://www.ni.com/labview), which is a data flow language. This is different from a workflow system, although there are similarities. Instead of flowing from state to state, your data flows from operation to operation. Also, unlike the Windows Workflow, it is a full language in itself.

However, like Windows Workflow, it has a state diagram option where you can describe the flow of logic. And again, like WW, you drop into the states to do the actual coding.

Sorry about the size of the URL, but this is a page with several screenshots so you can see what it looks like.

http://zone.ni.com/devzone/conceptd.nsf/webmain/F34045D2CC5357F486256D3400648C0F

gerdvilzk zhkoew hoqfktv idyzg vkrwtzml jilmfy reiphq

scphfli ruie dsyt xbdca givk iqbmwt qgyfxi http://www.rbquc.dqhctksmg.com

crpsif pdejtzxy vhagintfq wbltqmujd sbnxmdw pltgyesq rpfatmx [URL=http://www.ypsfugl.zatlpgm.com]utxlnim svzmef[/URL]

snvbxr wotpr tzng yphtdsnc zlmsha djpqamr vdesyjpzr [URL]http://www.qyihxs.eylb.com[/URL] wzcnhimg nihpkq

3ng3E3 Hi! Nice site! Where is a add to favorite button& ;)
http://www.mysite.com