|
|
Browse by Tags
All Tags » WF (RSS)
-
Just got the email the other day that PDC is less than 4 weeks away, and it got me thinking a bit about how I would think about these sessions as an attendee. Searching on the PDC site will yield 8 talks tagged with WF. Here's how I break some of these these down, the first few are about using WF, and the last 3 are about WF itself: Hosting Workflows and Services Dan Eshner Hear about extensions being made to Windows Server to provide a feature-rich middle-tier execution and deployment environment for Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) applications. Learn about the architecture of this new extension, how it works, how to take advantage of it, and the features it provides that simplify deployment, management, and troubleshooting of workflows and services. This talk is all about the host we're building for WF and WCF, which I mentioned earlier, we're calling "Dublin". If you're familiar with either technology, and have built a host of your own, this will be interesting both from the perspective of what is coming, as well as how we are thinking about solving some of the hosting problems. A Lap around "Oslo" Presenters: Douglas Purdy , Vijaye Raji "Oslo" is the family of new technologies that enable data-driven development and execution of services and applications. Come and learn how to capture all aspects of an application schematized in the "Oslo" repository and use "Oslo" Read More...
|
-
Steve Martin , a director of product management for CSD, has a blog post containing more information on the work that we are doing for the next versions of WF and WCF that we will release as a CTP at PDC. He also introduces "Dublin," the name for our efforts around creating a manageable and scalable host for WF and WCF applications, something that I know a few customers would be interested in. For you WF and WCF fans, there some more information about some of the features that you'll hear more about at PDC. I think for customers who are using either today, you'll see something on the list below that gets you interested. And, if you're not using WF or WCF today, I think there are a few things that might make you interested. We think that the features we're introducing (especially in WF, which is close to my heart) will make it easier to use WF, in more places, and by more people. Let us know what you think. What's exciting in the list below, what do you want to hear more about, is there something else you'd like to see on the list? WF Features Significant improvements in performance and scalability · Ten-fold improvement in performance New workflow flow-control models and pre-built activities · Flowcharts, rules · Expanded built-in activities – PowerShell, database, messaging, etc. Enhancements in workflow modeling · Persistence control, transaction flow, compensation support, data binding and scoping Read More...
|
-
When we start doing this two way style of messaging, we now open up to start modeling some interesting business problems. In the previous post, you'll note that I did not include the code, because I mentioned we needed to be more clever in scenarios where we listen in parallel. First, a brief diversion into how the Receive activity works. Everybody remembers the workflow queues, the technology that underlies all communication between a host and a workflow instance. The Receive activity works by creating a queue that the WorkflowServiceHost (specifically the WorkflowOperationInvoker) will use to send the message received off the wire into the workflow. Now, the Receive activity normally just creates a queue that is named the same as the operation the Receive activity is bound to. However, if we have two Receive activities listening for the same operation at the same time, no longer is a single queue useful to route responses back as we want to route to the correct Receive activity instance. There is property on the Receive activity called ContextToken. Normally this is null in the simple case. However, when we want our Receive activity to operate in parallel, we need to indicate that it needs to be smarter when it creates a queue. By setting this property (you can just type in a name, and then select the common owner all of the parallel receive's share. This will cause the Receive activity to create a queue named Read More...
|
-
So, we've seen in part 1 how to manage context, we saw in part 2 how we can take that basic knowledge to do duplex messaging. Once we start doing duplex work, there are some interesting patterns, and the first one is one that we like to call "long running work". Why are we interested in this? Well, as you probably know, the execution of a workflow is single threaded (this is a feature, not a bug). We also don't have a mechanism to force the workflow to be "pinned" in memory. What this means is that things like the asynchronous programming model (APM), can't be used, since there isn't a guarantee that there will be something to call back when we are done. What this means is that the send activity can not take advantage of the APM to be more thread friendly. We may want to do things in parallel, like this If each of these branches takes 3 seconds, the whole of this workflow will complete in about 9 seconds. The general expectation is that in parallel, this would happen at the length of the longest branch + some minor delta for overhead. The trouble is, APM programming is tricky, especially relative to the layout above. In order to model APM style service calls, but allowing for the service operations to be extremely long running, where extremely is defined as "long enough to where I would want to be able to persist." The approach then is to model this as disjoint send and receive activities. Read More...
|
-
Martin posted an interesting question here on my last post: <quote> The first thing that we need to do in order to enable this duplex messaging to occur is that the "client" workflow has to explicitly provide its context token to the service so that the service can address the appropriate instance of the client workflow. Note, in the real world, you'll probably need to supply more than just the context token, you will need some address and binding information. </quote> Shouldn't we have this built into a custom binding? (or an extra binding element) So with every call from the client the (WF)context information is included. And the developer is not required to follow a (artificial) state machine. Note, at the time, when the service calls back, the endpoint (and the binding) of the client may have changed... So we may need dynamic name-endpoint resolution (sounds like DNS?) Martin The question here is generally also asked as "wait, why do I need to explicitly provide a context token and change the contract to have this context thing?" This is a common question, as changing the contract to reflect implementation details is generally a no-no. There's one part I left out as well, so let me add that here: In the real world, one may also wish to not change the contract (or may not have the ability to). In that case, we still need to explicitly provide the context token and endpoint information in order to allow me to call back. Read More...
|
-
A continuation of my series of demos from my advanced workflow services talk. Here we focus on duplex message exchange patterns. Duplex messaging is something that we model at the application level (as opposed to the infrastructure level) because we want to model that message exchange at the level of the application. Here's some scenarios where I could use duplex messaging: [concrete] I submit an order, and you tell me when it ships [abstract] I ask you do to do some long running work, let me know when it is done [abstract] I ask you to start doing something, you update me on the status One may ask the question, "But, what about the wsHttpDualBinding, or WCF duplex bindings." That's a valid question, but it's important to point out that those bindings are really used to describe the behavior of a given proxy instance (and associated service artifacts). When my proxy dies, or the underlying connection goes away, I lose the ability for the service to call back to me. Additionally, this binds me to listen in the same way that I sent out the initial message. By modeling this at the application layer, we do lose some of the "automagicity" of the WCF duplex behavior, but I get more flexibility, and I get the ability to sustain potentially repeated recycling of the services and clients. Also, you could imagine a service that I call that turns around and calls a third party service. That third party service could call Read More...
|
-
So, last week I wrapped up a conversation at TechReady, our internal conference, where I was talking about the integration between WF and WCF in .NET 3.5. This talk was somewhat bittersweet, it's the last conference where I'm scheduled to talk about WF 3.0/3.5, I'll start talking about WF 4.0 at PDC this fall. There are a series of 4 demos that we'll talk about in this series: Basic Context Management Simple Duplex Long Running Work Pattern Conversations Pattern I've gotten a lot of requests to post the code samples, so I want to do that here: Sample 1, Basic Management of Context The goal of this sample is to show the way that the context channel works, and how to interact with it from imperative code. Ingredients: One basic workflow service that simply has two Receive activities bound to the same operation inside of a sequence. Inside each Receive, I have placed a Code Activity that simply outputs a little bit of info (the vars declared on lines 1 and 2 are used by the Receive activities: 1: public String returnValue = default (System.String); 2: public String inputMessage = default (System.String); 3: 4: private void codeActivity1_ExecuteCode( object sender, EventArgs e) 5: { 6: returnValue = string .Format( "first activity {0}" , inputMessage); 7: Output(inputMessage + " Activity 1" ); 8: } 9: 10: private void Output( string message) 11: { 12: Console.WriteLine( "Workflow {0} : Message {1}" , this .WorkflowInstanceId, Read More...
|
-
One of the things that my team is working on is the next version of the workflow designer. In order to help us get real feedback, we engaged with our usability teams to design and execute a usability study. For details on what the test looks like (when we did them 3 years ago for the first version of the WF designer, see this great channel9 video ). The setup is still the same (one way glass mirror, cameras tracking the face, screen, posture of the subject), the only difference is the software, we're busy testing out some new concepts to make workflow development much more productive. At this stage of the lifecycle, we're really experimenting with some different designer metaphors, and a usability test is a great way to get real feedback. One thing I've always tried to do since I came to Microsoft is being sucked into the Redmond bubble. The symptoms of placement inside said bubble are a gradual removal from the reality that everyday developers face. When I came to the company two years ago, I was chock full of great thoughts and ideas from the outside, and much less tolerant of the "well, that's just how it works" defense. Slowly, though, as you start to get deep into thinking about a problem, and tightly focusing on that problem, those concerns start to fade away, as you look to optimize the experience you are providing. Sitting in on the usability labs yesterday was a great reminder to me of how easily one can slip into Read More...
|
-
My team is looking for people interested in building the next generation of the WF designer. We've posted an opening here , please let me know if you're interested. I can't really say too much about what we're building, but it's a great team that's committed to creating a great experience for building, editing, and viewing workflows. Everyone on the team believes in the power of a declarative model of process, and believes that tools are the way that model is consumable by humans. Everyone also believes that we're making it easier to write code and solve problems with software, which makes our mission exciting. From the job posting: Windows Workflow Foundation (WF) is the workflow engine that powers SharePoint, Speech Server, the next major release of BizTalk, and countless customer and partner solutions as part of the .NET Framework. Our team builds the tooling that allows people to rapidly model, execute and debug the execution logic of their applications in a rich, graphical programming environment. The tools we build range from flowchart and process designers, to the visualization and management of complex rule sets. If you’re passionate about enabling the rapid modeling of process, or creating a great user experience building on the power of WPF, check us out. The tools we build will ship inside the next release of Visual Studio and the .NET Framework, and support the “Oslo” effort currently ongoing in Microsoft’s Connected Read More...
|
-
With all due respect to George and Ira Gershwin , I have a quick question for the readers of this blog. In V1, we have an interesting scenario is talked about frequently, and that's the file extension of our xml form of workflow. When we debuted at PDC05, there existed an XML representation of the workflow which conformed to a schema that the WF team had built, and it was called XOML. Realizing that WPF was doing the same thing to serialize objects nicely to XML, we moved to that (XAML), but the file extensions had been cast in stone due to VS project setups. So, we had XAML contained in a XOML file. Is this a problem for you? I could see three possible solutions in the future <insert usual disclaimer, just gathering feedback>: XOML -- we have a legacy now, let's not change it XAML -- it's XAML, so change the file extension to match it (and introduce an overload to the XAML extension, which for now is associated with WPF) something else, say .WFXAML -- this reflects the purpose, is unique to declarative workflows and doesn't have any weird connotations (What does xoml stand for???). Is this an issue? Is this something you would like to see changed? Do any of these solutions sound like a good idea, bad idea, etc? Thanks, we appreciate your feedback :-) Read More...
|
-
A question recently came up on an internal list about how to start a workflow to do some work and then have it accept a message via a Receive activity. This led to an interesting discussion that provides some insight into how the WorkflowServiceHost instantiates workflows in conjunction with the ContextChannel. Creating a Message Activated Workflow By default, the WorkflowServiceHost will create a workflow when the following two conditions are true: The message received is headed for an operation that is associated with a RecieveActivity that has the CanCreateInstance property set to true The message contains no context information It is interesting to note that you don't even need to use a binding element collection that contains a ContextBindingElement. The ContextBindingElement is responsible for creating the ContextChannel. The job of the ContextChannel is to do two things on the Receive side Extract the context information and pass that along up the stack (hand it off into the service model) On the creation, and only on the creation, of a new instance, return the context information to the caller in the header of the response. So, if we want to create workflows based on messages dropped into an MSMQ queue, we can do that by not trying to add the ContextBindingElement into a custom binding on top of the netMsmqBinding, and associating the operation with a Receive activity with the CanCreateInstance equaling true. Note, that any subsequent communication with Read More...
|
-
I'm moving on from my role as the technical evangelist for WF, but not too far. I've joined the product team, working as a program manager (PM) for the Connected Tools team. The job of the connected tools team is to provide all of the tools for the technologies inside the Oslo effort, including the WF designer. As such, I'll be focused on the programming model for activity designers to use when they create WF activities. Oslo is interesting, as it represents the first real chance to look at the stuff we did in V1 of WF and think about it and find out ways we can improve on the experience. .NET 3.5 was a very "constrained" release for the WF team, as we had only shipped about 12 months prior, so we were primarily concerned with adding functionality to what we shipped (the WF/WCF integration, for instance). For WF, Oslo will be our first chance to take in a lot of the feedback we have heard (and keep it coming) to move things to the next level. I'm excited to be part of that effort, especially from the designer side of things, as I see a great opportunity to simplify a number of things that a lot of our customers have been doing. It was a tough decision to leave DPE (developer and platform evangelism). The job of a TE is probably one of the closest to geek nirvana one can achieve. It was a bit odd when I was looking into this new position to lead off by saying, "I'm leaving the best job I've had." I didn't Read More...
|
-
Yesterday, following my "What's the context for this conversation" presentation, I was approached with the following question: I am sharing a singleton client that I want to use to interact with multiple workflow instances, how do I change the context for each of them. Completely unbeknownst to me, Wenlong, one of the product team's more prolific bloggers, addressed this very topic in his post here , conveniently posted yesterday :-) Read More...
|
-
This morning at the SOA&BP Conference, we talked about Oslo for the first time. For me, this is a big day, as it marks the point where the rest of the world knows what a lot of people have been and will continue to be working on. Robert Wahbe , the VP of Connected Systems, mentioned in the keynote that Oslo can be best viewed as a series of investments that span a number of release cycles. What does this mean for me, a WF developer (note, these are my interpretations). A vehicle for further investments in WF and WCF. There will be a ton of enhancements in order to enable new scenarios, take the idea of modeling processes in an executable workflow to the next level, and drive performance and functional stuff. Moving WF to the next level, by making it a first class citizen in this modeling world, by making rules and other artifacts get elevated into a way to modeled, managed, deployed and monitored. Getting a chance to look at what people are doing with v1, and what lessons we can learn from it. In Orcas, the stuff that we did was purely additive. This longer release gives us a chance to enhance and improve and address things that we couldn't do in the Orcas timeframe. There's some really exciting work going on here that I'm looking forward to talking about more in the future. Finally, it gives us a better way to tell the WF hosting story, in that we will have a host and way to manage and deploy and execute WF and WCF in an host we will deliver, Read More...
|
-
So, we're getting close to .NET 3.5 getting out the door, and as always we're thinking about what comes next. The activities team is looking how to make activities better going forward, and they are very interested in what you have to say, how you have been using them and how you'd like to use them. This feedback will help us understand how to shape the future of things and how we should think about the pain points you are experiencing. Fill survey out here! Read More...
|
|
|
|