WF from Getting started to proficient (eighth chapter): Calling external methods and workflows (i)

After completing this chapter, you will learn:

1. Create and invoke local data services outside of your workflow

2. Understand how to use interfaces to communicate between the host process and your workflow.

3. Use a design external method to transfer data between your workflow and the host application.

4. Call another workflow in a workflow that is being executed

In writing the previous chapters, I kept thinking, "I can't wait any longer, I want to figure out where to return the real data (in the workflow) to the host application!" Why Doing so much activity and workflow demos, but none actually returns something of interest to the host application. I don't know how many examples and demos of workflows we're interested in, but at most just the initialization of the data (like the ZIP code you saw in the first chapter of-WF's introduction). But things get a lot more interesting, frankly, when we start the workflow, and then look for and process the data from the external sources, and return the processed data to our main application to get closer to reality.

Why not? Exposes an object to pass to the host application from the executing workflow, or to the workflow from the host application. In fact, you can do this by using existing serialization technologies, such as. NET remoting or XML Web services. Serialized, also called serialization, converts data from its original form into a suitable form for transmission between different processes and even different computers.

Why do you talk about serialization? Because your workflow is performed on different threads in your hosting process, transferring data between threads, without proper serialization, can be a disaster, for specific reasons beyond the scope of this book. In fact, your workflow can send its data in a persistent state. This is not on a different thread, not even in execution.

But we want to use a technology such as. NET remoting or XML Web services when we are transferring data between our workflows and the hosting processes that are controlling the workflow. Why is it not considered redundant? In fact, this is absolutely necessary! We will create local communications, and this chapter will start with this. We will build the necessary system to meet the thread data serialization to carry out data transfer between computers or between processes.

Create Externaldataservice Service

When a workflow communicates with its host, the workflow uses queues and messages when it sends and receives data. The more we do with WF, the more we can focus on the solution of specific tasks in the application.

Workflow internal Process Communication

For simple communication tasks, WF uses "abstraction layer" to buffer between the workflow and the host. The abstraction layer is like a black box, you provide input for it, it performs some magical tasks and then the information flows out to the other side. But we don't have to know how it works.

In this case, the black box is a well-known "local communication" service. As with any of the services in WF terminology, it is another pluggable service. The difference is that it's not like the ones in WF that have been created in advance, you need to write a part of the service. Why, then? Because the data you pass between your host application and your workflow is somewhat specific. Further, you can create a variety of data transfer methods that you can use to send data from the host application and then receive the data in the workflow.

Note: There are some things you need to focus on, that is, the problem of sharing objects or collections. Because the host application and the workflow runtime execute in the same application domain, objects and collections of reference types are passed by reference rather than by value. This means that the host application and the workflow instance will access and use the same object at the same time, resulting in a bug in a multithreaded environment with data concurrency access errors. Therefore, for objects or collections that may have concurrent access, you might consider passing a copy of an object or collection, perhaps by implementing the ICloneable interface, or by considering serializing the object or set by itself.

You can write this local service, insert it into the workflow, and then open the connection and send the data. This data can be a string, a DataSet object, or even any custom object that you can design to be serialized. Communication can be two-way, although I don't show it in this chapter. (Here, I simply pass the data back to the host application from the workflow.) From a workflow perspective, we use tools to generate activities to send and receive data. From the perspective of the host application, receiving data is equivalent to an event, and sending data is a simple invocation of a method on a service object.

Note: We will revisit the concept of two-way data transfer after we see more activities in the later chapters. The workflow activity receives data from the host application based on a handleexternalevent activity, we will see it in the 10th chapter "event Event". We also need to have a deeper understanding of the interrelationships between these concepts, which will be covered in chapter 17th, "Host communications". For the current, we simply return the composite data to the host after the workflow instance completes its task.

We need to do more than that, and we eventually need to add externaldataservice services to our workflow runtime. Externaldataservice is a pluggable service that facilitates the transfer of serialized data between a workflow instance and a host application. In the next section we will write the code for this service to do a lot of things (including the transmission of serialized data). Let's take a look at the overall development process.