Web Service Service Software Factory and WF

Topics: July and December Releases Forum, Service Factory Modeling Edition Forum
Feb 6, 2007 at 1:33 PM

Are there plans to combine WF and Web Service Service Software Factory?? at the moment their architectures don’t seem to fit, because of WF's Workflow runtime requiring persistence!

I might be completely off the ball here because I only started looking into WF about 3 weeks ago, but some help here would be greatly appreciated.
Feb 7, 2007 at 1:58 PM
anybody out there??????
Feb 8, 2007 at 5:36 AM
Hey, sorry for the belated response. We have a huge conference going on in Seattle that is taking a lot of our time this week (that's why I'm back in the office at 9:30 at night).

The short answer to your question is "yes". We will do guidance for WF at some point. We don't have any details about it (like when or what form it will take), but we know there is a demand. We know the introduction of WF and the WF/WCF capabilities that are coming in the next version of Visual Studio will introduce a change in the way we architect Web Services. But honestly, we don't know exactly how yet. This is how you can help us ...

Tell us what the challenges are. How do you think the current architectural patterns break down in the face of these new capabilities. How are you planning to use these new capabilities? What are your challenges? I'm asking all of these questions because your answers will help form the resulting guidance.

Thanks. I'm looking forward to this discussion.

Feb 8, 2007 at 9:22 AM
Hi Donsmith,

9:30pm and still at work... go home man :-) no worries about the late reply, and enjoy the conference. I'm in South Africa, so I'm going to have to wait for the earth to spin a bit before you see this.

As for WWF and Web Service Software Factory, its nice to know that the issue isn't just me.

Firstly id like to say that the architecture of web Service Software Factory fits nicely into whats required for a new application that i'm working on.

I'm going to take the long winded route of explaining the situation, so that you can see how much i know and how I've kinda placed everything in my head.. whether its right or not is another story.

Ok.. here goes. The nature of Workflows in WF means that a work flow can excise for either the duration of one web request.. or "n" number of requests. The Workflow runtime together with the WF services makes this posable, because these components of WF can run for the lifetime of a workflow regardless of the number of requests, because of this they need persistence, and therefore in current WF examples Workflows are tightly coupled with the Web host. I've seen plenty examples of the workflow runtime being instantiated in the Application On start event.

At this point my workflows will only last the duration of one web request and have looked into using the ManualWorkflowSchedulerService to sort out the threading issue that WF brings to the party.

One thing that i do like and require is the way in which the Software Factory separates the contract from the Business rules, and don't want to bring my Business rules forward to the host application so that i can get a handle on the Workflow runtime.

Here's an article which i found interesting that combines WF and WCF however it moves away from IIS Which i'd prefer to use mainly because of being able to leverage SSL with in IIS... or am i hanging onto IIS unnecessarily?


Am i explaining my self correctly??? and have i got a decent enough handle on the technologies involved?

Tell your team that the guys at my work are loving your work and look forward to more from the P&P team

Feb 10, 2007 at 4:00 PM
I'm in the same situation myself here. We're using SF for a pretty large SOA project and I would like to use WCF and WF to build our Entity Services which manage aggregation from other source, most often WCF services themselves.

I'm looking at the Entity Aggregation Pattern as described on MSDN here: http://msdn2.microsoft.com/en-us/library/ms954596.aspx

I first thought it would be quite easy to kick off a parallel activity workflow from a WCF service and aggregate or orchestrate info from these various sources with WF. But it wasn't as easy as I thought. I also learned quite fast that "parallel activities" wasn't the same as "asynchronous activities" ;)

Entity Aggregation is a design pattern I think would be quite useful to have support for in Software/Service Factory.
Feb 16, 2007 at 7:00 AM
Don... No comments???
Feb 16, 2007 at 8:46 AM
First off, Grant thanks for the positive reinforcement. It's encouraging to know what we're doing is helping.

Now as far as WF goes (reminder: we - the p&p team - haven't identified any proven practices for using WF yet) I can only share my personal opinion at this point. Using a single workflow instance for more than a single request is causing an internal flag to go up. Because the necessity of doing this would be that for some reason one request would have a dependency or corrolation to a different request ... and I'm having trouble working out an appropriate scenario for that. So to me, scoping a workflow instance to a single request makes the most sense (based on my limited knowledge).

I think your desire to stay with IIS rather than hosting WF in a custom host is solid. However, on that note, there is some technology that will be availble before the end of the year (in the next version of Visual Studio) that is effectively a WCF host for WF workflows. I don't know what the official name is but internally we refer to it as Silver. This plumbing will make doing this MUCH easier, but this is where I think the architectural confusion comes in. For example, "Do you need all three layers if the service is just a workflow?" We'll get this figured out. There are already people working on it.

Hey Johan! I definitely understand the need for better guidance on entity aggregation. We thought about addressing it during the first (ASMX) version of the Service Factory, but was cut when we realized our scope needed to go on a diet. This one would be tough because the complexity of the scenarios vary from the relatively straight-forward to the very complex. I'm still not sure how much guidance we're going to be able to do on the inside of the service interface, but I will certainly add it to the list since you suggested it.