I headed over to building 33 yesterday for the Microsoft SOA and Business Process Conference to host a Q&A session with some other people from the Connected Systems division (Clemens, Shy, Lee and Joe). We had a pretty decent audience, and I wanted to repost the questions that I got here and answer them.
Will Speech Server (or SharePoint, or other hosts) let me run activity x?
The other big host to talk about right now is Office, in SharePoint. The answer, in true consultant fashion is that it depends. It will really be left up to the implementation of the host as to what behavior they will allow. For instance, the SharePoint host will not allow the addition of additional services. This has been done for performance, stability and security reasons. SharePoint is also very particular about the activities it will allow to be executed, using the concept of a white-list in order to mark activities as able to be run. You can imagine that allowing a code activity could be a very bad thing in SharePoint, and thus, it is not allowed.
These are all hosts for WF, their behavior is chosen to optimize for the scenario to be used in. Similarly, you may have the same constraints, which you can enforce in your host, or maybe you have none of them, in which case, you don’t need to implement any of them.
Is the WF Rules Engine a Rete Engine? (with follow on: If not, why not?)
No, the WF Rules Engine is not based on a Rete algorithm. Check out Don’s blog posting here. There are a few relevent paragraphs I will repost here.
There are plenty of resources out there that describe what the Rete algorithm does and why it is so often used in Rules engines. At the end of the day, Rete is an optimization. You don’t need a Rete engine to implement a forward-chaining rules engine; however, the Rete optimization may improve the runtime performance of a Rule Set. That’s what optimizations do. In particular, Rete reduces the number of predicate evaluations by remembering the most recent value and re-using it on subsequent re-evaluations.
I certainly concede that there are many examples of Rule Sets that contain a lot of common predicates. In those cases, a Rete-based Rules engine like BRE will crush a non-Rete engine like WF Rules. However, in cases where there are few common predicates, the reverse has also been demonstrated: WF Rules and its non-Rete execution mechanism will crush Rete-based BRE.
My point is simply that Rete is an optimization strategy that is not necessarily appropriate for all Rules-based solutions. For WF Rules, we placed much more importance on how much you can express in your Rules, how easy it is to express it, and how well it integrates into Windows Workflow Foundation and the .NET framework.