Part Two: Understanding Microsoft Windows Workflow Foundation (WF) and the Rules for.net Integration

Transcription

1 ILOG X-RAY Series Part Two: Understanding Microsoft Windows Workflow Foundation (WF) and the Rules for.net Integration Rules for.net 2.6 Abstract The X-RAY Series is a limited set of articles to help accelerate the understanding of Rules for.net. The happy path is a metaphor for your BRMS journey or as some would call it a pilgrimage. Everyone on a pilgrimage starts at a different point but in the end are able to make the right choices and eventually find the sweet spot for their implementation. However, unlike a religious pilgrimage where a little pain and suffering is to be welcomed, your BRMS journey with Rules for.net should be well happy. The X-Ray series of articles is intended to do just that. May 16, 2007 Christopher C. Berg Product Manager

2 Table of Contents 1.0 INTRODUCTION WF and Rules for.net 2.6 Architecture Project Pre-Requisites PROJECT ORIENTATION Building a Console WF Project Contract First Integration The Microsoft Policy Activity USING WF FOR DECISION SERVICES AND SOA INTEGRATION Preparing the XOM Project Creating the Project Adding the Business Interface Web Service Input and Output Activities Publishing the Web Service Creating a Test Client SUMMARY Copyright 2007 ILOG Inc. Unpublished Work. All rights reserved. Do not duplicate without permission. ILOG and its respective logotypes are registered trademarks. All other company and product names are trademarks or registered trademarks of their respective holders. The material presented in this document is summary in nature, subject to change, not contractual and intended for general information only and does not constitute a representation. Page 2 of 37

3 1.0 Introduction The X-RAY Series is a limited set of articles to help accelerate the understanding of Rules for.net. In part one of this series I established how to integrate the RulesEngine API with real world architectures. It was no accident that the article spent a significant amount of time on understanding RuleSet parameters. Now we will build on that knowledge and apply it to the Microsoft Windows Workflow Foundation (WF) integration provided in Rules for.net 2.6. Microsoft has been positioning Microsoft Windows Workflow Foundation (WF) as a lightweight workflow implementation that was originally branched from the BizTalk code base. This framework itself is designed to offer full Visual Studio integration, orchestration, and asynchronous execution along with in-process API integration. ILOG concluded early on that WF was going to need an enterprise class BRMS that fit seamlessly into the WF user experience. In 2006 we embarked on a roadmap that included integration of Rules for.net with the emerging WF that is now bundled with.net 3.0. That integration was delivered this year with the much anticipated 2.6 release. However, the version numbers only jumped from 2.5.x to 2.6 and do not fully communicate the significance of the WF integration that took place. This paper will explore using Rules for.net 2.6 with WF. Unlike the first paper I will be showing a lot more examples and providing more source code than before. The goal here is to provide both the theory and the practice with the least amount of ambiguity. For some this might seem pedantic but for others it might mean the path to a successful project. I have chosen to error on the side of being pedantic--not because it s my nature but because the Microsoft WF integration is new and may be less familiar to many of the readers. By the end of this paper, the reader should be able to use the WF integration provided by Rules for.net 2.6, bind parameters to a workflow, and finally build, deploy and test a strongly typed decision web service. 1.1 WF and Rules for.net 2.6 Architecture The Rules for.net team realized early on that the WF integration of the product would require two key approaches to the effort: 1. The user experience had to match all of the standard WF user experiences including use of WF shapes, properties and bindings within Microsoft Visual Studio The integration of the RuleseEngine had to be turned into an embedded service within WF that included execution features such as hot deployment of BRC/BRX files and pooling. Page 3 of 37

4 I am pleased to say that the team delivered on both of these points without compromise. However, there are points that do require some discussion if only to educate the user on how the implementation was accomplished and what architectural implications exist. The Business Rule Activity The Business Rule Activity may be considered an abstract form of an execution service embedded within the Microsoft WF framework. The service itself is an in-process invocation of an API that wraps the RuleEngine API. At run-time, the WF framework passes data into the service via the action properties. However, this is not just a simple service wrapper around the RuleEngine API. There are key features here that provide for performance and run-time options. Performance by Design The service wrapper around the RuleEngine API provides a caching feature that enables Ruleset pooling. Each Ruleset in the pool is defined by the BRC/BRX file. At run-time, an engine instance is created and a Ruleset is used from the pool. Even though the engine is thrown away after each execution, the performance is gained by pooling pre-compiled Rulesets in the service wrapper. Below is a high-level architectural diagram: WF Activity Façade and Property Bindings Ruleset Signature Execution Service Wrapper Singleton Pool Ruleset Instance Ruleset Instance BRC/BRX Page 4 of 37

5 Hot Deployment of BRC/BRX Files At run-time, the pool is created using the BRC/BRX file for the Ruleset. The service wrapper monitors changes to the BRC/BRX file on the file system. If a new BRC/BRX file is detected, the pool will be reloaded with a new set of rules. The caveats here for hot deployment are the following: The BRC/BRX files can only have a change in rule content but cannot undergo changes in the Ruleset Signature. This means that you cannot add two new Ruleflows and expect hot deployment of the BRC to work. Also, you cannot change the parameter signature of the Ruleset because this is a design time requirement which we will demonstrate below. The external object model or (XOM) that has been imported to create your business object mdoel (BOM) cannot be modified at run-time. 1 This would change the Ruleset Signature and also the bindings established with passing data as a parameter. However, the BOM can undergo design time changes so long as the projects are recompiled and redeployed. After stating the caveats above, you are free to add any number of rules and hot deploy them with a new BRC/BRX file at any time without shutting down your application. 1.2 Project Pre-Requisites It is hard to imagine using Rules for.net with the WF if you have not yet mastered basic skills. If you are new to Rules for.net, I suggest that you review Part One of the X-Ray Series and follow the guidelines there in the notes. You can also jump directly into the product tutorials and documentation. Before continuing, you should be able to model a BOM, write rules against it and compile a Visual Studio solution that includes three projects a XOM project, a rule project, and a simple client application for testing. Installation If you have not done this already, you will need to download and install.net 3.0. You can do this with the following URL: Next, you will require the Visual Studio 2005 extensions for modeling workflows. You can find this at the following URL: 1FA3-48CF-8023-E8F38E709BA6&displaylang=en 1 I introduced the use of the term External Object Model or XOM in part one of the XRay Series. The XOM refers to your object model before it is imported into your project and becomes a Business Object Model or BOM. Page 5 of 37

6 Finally, you need to run the ILOG Rules for.net Extension for WF. The file should be found in your ILOG directory or out on the support web site. The physical file name should be the following: ILOGRulesForDotnetExtensionsForWindowsWorkflowFoundation2.6.msi Getting Started Assuming all is well with the prerequisite items above, we are ready for a general orientation. When I first used the Rules for.net integration with the WF I discovered early on that it was helpful to have a non-wf solution in Visual Studio 2005 for testing and debugging my rules. This way I have a higher level of confidence once WF is introduced as another moving part. Below is a view of my test solution inside Visual Studio You can plainly see that I have three projects in the solution: a XOM project, a rule project, and a simple client application for testing. In the solution explorer you will see that if I expand the BusinessRules project, I have defined a ruleset and a ruleflow in the project: Page 6 of 37

7 You can decide on your own if you want to use either just rules or a ruleflow together in your rule project. 2 What is important is that your rule project has defined parameters and that they are properly referenced by your rules. In my case, I have defined two parameters in this project: 2 Part one of this series focused on the use various architectures for your rule project. This decision will most likely be determined by the goals of your project in the end. Page 7 of 37

8 The parameter called customerparameter is an In parameter and its type is referenced to the SampleXOM.Customer which is defined in my XOM project as a Customer class. The stringoutparameter is a string object and is used for passing messages out of the application. Now you are ready to test the solution running your test client and clicking on a command button found on a single form. In my project, I have placed the following code behind my command button: //Get the rule engine instance RuleEngine engine = new RuleEngine(); //Create your XOM Object Customer customer = new Customer(); customer.age = 15; customer.birthdate = System.DateTime.Now; customer.firstname = "Chris"; customer.lastname = "Berg"; customer.maritalstatus = "Married"; //Set the RuleSet engine.ruleset = new BusinessRules(); //Set the parameter which is our XOM engine.setparametervalue("customerparameter", customer); // Set the ruleflow.if you have one engine.ruleflow = engine.ruleset.ruleflows[0]; //grab the known index // Execute the business rules. engine.execute(); IDictionary outparamaters = engine.getparametervalues(); foreach (DictionaryEntry de in outparamaters) if (de.value!= null) Console.WriteLine("Parameter Name: " + de.key.tostring() + " Value: " + de.value.tostring()); } } //Get the user's input to quit the application. Console.WriteLine("end"); Once executed, I can see that my rules run as I intended. The messages I expect are being sent to the Output window. Page 8 of 37

9 From this point forward, you are now ready to integrate a tested rule project with Microsoft WF. 2.0 Project Orientation It is not an accident that the focus of Part One in the X-Ray series narrowed in on Ruleset parameters and how to use them. Parameters form the basis for moving data between architectural boundaries. For our purposes here, the parameter type forms the first level of contract between the context of WF and your Ruleset. Later, we will see how this contract may be extended for web services. For now, let s setup our first WF project and call a Ruleset. I believe it is worth a first pass with WF and Rules for.net using a simple console application. The installation of Rules for.net provides a nice sample, but for someone looking at the code for the first time, it is not immediately clear what code was generated and what code was added by ILOG. Therefore, we will start this exercise from scratch. Page 9 of 37

10 2.1 Building a Console WF Project If you open Visual Studio 2005 and start a new project you will find that the extensions for WF have installed several new project templates. As you create your project, select Sequential Workflow Console Application. Once the project has been created, you can double click on the Workflow1.cs artifact and you will be presented with a workflow workspace. The workspace will already have the start and end points. For our purposes, you need to select the BusinessRule activity from the toolbox and drop it between the start and end points. Page 10 of 37

11 If you cannot find the BusinessRuleActivity in the Toolbox, then you need to register the activity from the list of installed activities. At this moment, right-click on the desired header in the toolbar and click Choose Items from the menu. You will be presented with a dialog that offers a tab for installed activities. In my case, the ILOG Business Rules Activity was at the top. Once selected, the activity should be added to your toolbox. Page 11 of 37

12 When I initially dropped the BusinessRuleActivity onto the workspace, it was displayed with a Red error marker seen below: ILOG has integrated its business activity with the same features and behaviors that Microsoft has established as a standard for this environment. You will also see that the activity properties on the right highlight with a similar red mark depicting a required property that must be satisfied for the workflow to operate correctly. In this case, the activity is expecting me to point the activity to an existing BRX or BRC file on my file system. I will choose a BRC file generated by my sample solution earlier. NOTE: The BRC and BRX files are found in the Debug directory of your rule project and must be deployed in the same directory as your rule application at run-time. Page 12 of 37

13 Once the BRC file has been loaded the Ruleset is parsed and the required parameters appear as properties to the workflow activity and are marked red for a response from the user: At this point in the project, I noticed that I have not added my XOM project to the solution. I need this for a project reference though I could do an assembly reference if I wanted to. Once I have added my XOM project, I can continue binding my parameters with the appropriate types. The dialog for the CustomerParameter property launches the following window: Page 13 of 37

14 I have chosen the Bind to a new member tab and declare that I want a new property created that will pass this type into this activity property. In other words, I want this activity to have a public wrapper property that exposes the required Ruleflow parameter. Likewise, I follow the same procedure for the parameter stringoutparameter. If I launch the Bind dialog again, you will see that two wrapper properties have been created. Page 14 of 37

15 Finally, all of my key tasks are complete for incorporating the activity. The workspace shows that there are no more errors related to binding that activity to required properties: If a Ruleset contains more than one Ruleflow, the user will be provided an additional property that requires a specific Ruleflow to be selected from a list. In our case we only have one Ruleflow defined and it will be chosen automatically for us at run-time. 3 At this point your solution should compile without errors in the System window. Assuming we are ok, we are ready to add some code and test the WF integration. All that remains is to create some XOM instances and pass them into the workflow at run time. The project template created some code for us and all we have to do is drop a little of our own code into the project. Add the following code behind the Program.cs artifact (the code I created is in bold): 3 Your are not required to use a Ruleflow in your implementation, we could have simply chosen a Ruleset that used parameters and the same solution would work as described. Page 15 of 37

16 #region Using directives using System; using System.Collections.Generic; using System.Text; using System.Threading; using System.Workflow.Runtime; using System.Workflow.Runtime.Hosting; #endregion namespace WorkflowConsoleApplication1 class Program static void Main(string[] args) using(workflowruntime workflowruntime = new WorkflowRuntime()) AutoResetEvent waithandle = new AutoResetEvent(false); workflowruntime.workflowcompleted += delegate(object sender, WorkflowCompletedEventArgs e) waithandle.set();}; workflowruntime.workflowterminated += delegate(object sender, WorkflowTerminatedEventArgs e) Console.WriteLine(e.Exception.Message); waithandle.set(); }; //create the XOM instance SampleXOM.Customer xom = new SampleXOM.Customer(); xom.firstname = "Chris"; xom.age = 15; xom.birthdate = DateTime.Now; //Standard pattern for passing in parameters Dictionary<string, object> parameters = new Dictionary<string, object>(); parameters.add("businessrulesactivity1_customerparameter1", xom); parameters.add("businessrulesactivity1_stringoutparameter1", ""); WorkflowInstance instance = workflowruntime.createworkflow(typeof(workflowconsoleapplication1.workflow 1), parameters); } } } } instance.start(); waithandle.waitone(); We can be assured that the BusinessRule activity is executing correctly if we can run a test. In order to create a visual test, we add a code activity to the workflow and send a message to the System window. Drop a code activity onto the workspace it will look like the following: Page 16 of 37

17 Like other activites, it will initially be marked for an error because it has a dependent variable. This activity requires binding to a method. If you double click on the activity, a new method will be added to the Program.cs artifact and then you can paste or type in your console messages like the one below (the code I added is in bold): private void codeactivity1_executecode(object sender, EventArgs e) Console.WriteLine("decision was:" + this.businessrulesactivity1_stringoutparameter1); Console.ReadLine(); } When the project is executed, the output should look something like the following: Page 17 of 37

18 2.2 Contract First Integration If you are this far in the paper, then you have likely noticed that all workflows in WF have an associated object model that exposes the state of a workflow and its members at any point. Using the intellisense lookup in the project above shows our new properties that are bound to our BusinessRule activity and our Ruleset parameters: If you are new to workflow and BPM, you will notice that your XOM plays a similar role in both your workflow and your ruleset. Your data is modeled as a transient data object that is now portable and can be passed between architectural boundaries. This pattern formed the basis for N-Tier architectures and it is working for us right here in our integration example. Moreover, this data can now be manipulated by both a workflow and Ruleset without changing the nature of its contract or type. 4 For example, it is possible that my customer object can be updated by a decision with the BusinessRule activity and then it is available within the context of the workflow object model at any time. If we did not have a shared type as the basis for our data contract, then we would have to write code that constantly transformed the data into the required type. At this point, some of you must be thinking why would I ever do that? Well its still a common practice today with non-wsdl based SOA integrations. The good news for us is that WF also provides a mechanism for creating strongly-typed WSDL generation for workflows. When we create a workflow property that is bound to a XOM, we can create WF wrappers that allow us to publish a stronglytyped decision service. 2.3 The Microsoft Policy Activity Once you install Rules for.net, there is nothing to prevent a user from using the Microsoft Policy activity. This activity offers a rudimentary decisioning feature within the WF. For sure, a workflow framework would be incomplete without a basic feature to enable conditional transitions and utility decisions. However, there is always a blurry line between a simple decision in a workflow and what we at ILOG consider to be fully articulated rule management or BRMS. 4 Aaron Skonnard from Microsoft has written two articles on Contract-First design. I have referenced one of them here for you: Page 18 of 37

19 At a project level, it is surprising how quickly a simple decision can turn into a business issue that requires many more requirements than the Policy activity can provide including centralized management, versioning, annotations with reallanguage and business tools for policy managers. As your project matures, it is likely that your use of rules will mature with it. I have heard any number of statements about practices when to use one activity over the other. However, in hind-sight, I have not seen a single practice that did not invite some cost. From my perspective, I suggest that you be practical and start with where you intend to make your investment. If you are reading this paper and have made an investment in Rules for.net, then I suggest that you explore this for all of your decisions until which time you can list any cost or management issues that are not reasonable. At least in this way, you would be favoring a single repository for rules and a single implementation. 3.0 Using WF for Decision Services and SOA Integration The Microsoft WF offering is exceptionally rich in features. This is especially true in the case of publishing workflows as a strongly typed web service. In this section, we will create a WSDL-based decision service by wrapping it within a WF process and deploying to IIS. 3.1 Preparing the XOM Project Since we already have a working example of a WF process working with our Ruleset, we can reuse that project for the web service we intend to create. However, before we create the new WF project, we need to touch up the XOM project. Our current XOM project has a Customer class. Since the XOM project was initially created and passed a parameter, we knew that we would use the object as a local instance. However, once we intend to use the XOM with web services, the object must be marshaled over XML and HTTP. This process requires serialization or the process of converting the bytecode into a standard format. 5 We can prepare the XOM for serialization simply by adding the attribute [Serializable] above the class declaration like the following: 5 By now lots of.net folks have used attributes. Here is a link for the un-initiated that covers attributes and creating custom attributes: Secondly, I have included a link to the serializable attribute itself as a reference: Page 19 of 37

20 using System; using System.Collections.Generic; using System.Text; namespace SampleXOM [Serializable] public class Customer private string _firstname; private string _lastname; private int _age; private DateTime _birthdate; private string _maritalstatus; public string firstname get return _firstname; } set _firstname = value; } } } } This is the only modification we need to do that prepares the object for use in the web service framework provided by WF. Let s turn our attention now to creating the project. 3.2 Creating the Project Microsoft WF is capable of publishing a workflow project so long as its project type is a Workflow Library. 6 In our case, I chose to use a Sequential Workflow Library because our process will be nothing more than a lightweight process wrapper around a Ruleset. Let s go ahead and create the project like I have done below: 6 Dino Espisito from Microsoft has written an excellent article on this very topic. This tutorial is based on his article: Page 20 of 37

21 Once the project has been created, let s add the existing XOM project to the solution and add the project reference to the Sequential Workflow Library project we just created. When you are done, it should look something like the following: Now that the project is prepared we will add the BusinessRule activity and prepare all of the required properties. At this point, the project should look very similar to steps that we followed in the first part of this paper: Page 21 of 37

22 3.3 Adding the Business Interface Next, let s manually add a new interface to the workflow project that will be referenced in the future by the tool that will generate our WSDL file. In our case below, the tool will simply use the interface as a guide and a concrete implementation of the interface is never added to the project. Below is the code I used for the interface: Page 22 of 37

23 using System; using System.Collections.Generic; using System.Text; using SampleXOM; namespace WorkflowLibrary1 interface ICustomerWorkflow String decision(customer cust); } } When I designed this interface, I intentionally mapped the Customer as the input to decision method and the string as the output. If you recall our In and Out parameters, they easily map to this interface structure and I have made the connections above for your reference. Page 23 of 37

24 3.4 Web Service Input and Output Activities Now we are ready to add the web service activities to the project. From the toolbar, you will add WebServiceInput activity in front of the BusinessRule activity. Next, you will add a WebServiceOutput activity at the end of the process. Now the BusinessRule activity should be wrapped by the two new activities and your project should look something like the following: You will notice that both new activities are marked with an error flag and have required properties that need to be configured. The IsActivating property by default is False and must be set to True for the process to start once the data is posted to the service. Next, the interface for the service must be selected. This is managed by the InterfaceType property. This property launches a wizard that directs the user to a desired interface. In this case, I have chosen the interface we just added above: Page 24 of 37

25 Once I have selected the interfaces, the project reflects on the interface and exposes possible methods to use for the service. In this case I had only one and it appears in the dropdown within the property list itself: Page 25 of 37

26 Once the decision method is chosen, Visual Studio reflects upon the parameters of the method and adds a property to the grid which is of type Customer and has a name of cust. When I launch the wizard, I can easily recognize the new method I added that binds to my parameter that is expecting my XOM or specifically my Customer object. At this point, I am done working the required properties for the WebServiceInput activity. However, even though all of the properties are correct, the shape in the workflow remains marked with a Red error. I suspect this is because the WebServiceOutput activity is also a dependency and it still has some required properties to configure. Let s turn to those. The WebServiceOutput activity must know its corresponding Input activity so its property is marked as required first. Since we only have one, just pick the single item in the list: Page 26 of 37

27 Once the InputActivityName is established, Visual Studio reflects on the interface and adds a new property to the grid for an output mapping. You can launch the wizard and select the property that binds to the Ruleset s output parameter: Once you click OK in the dialog, you will notice that you have a complete process with no more required properties. At this time, you should be able to compile the project without errors. Your efforts should have produced a project that looks similar to the project below: Page 27 of 37

28 3.5 Publishing the Web Service Publishing the web service is essentially a two step process generating the deployment artifacts and then registering the virtual directory within IIS. Let s look at each in turn. Generating the Artifacts From the Project menu you will find an option entitled Publish as a Web Service. This feature is easy to use but only works when your process has the two required Web Service Input and Output activities. In our case, everything should go well and the web service artifacts should be generated without issue. You will know things have gone well when a dialogue box is presented to you stating that all is well. You should be able to see that a new project has been added to your solution in the solution explorer pane of Visual Studio: Page 28 of 37

29 The new project is complete and typically displays the Web.config file for the service when the wizard is complete. You need to do little else but re-build the solution to test for errors. Manually Configure IIS Before we configure IIS, we need to manually move the BRC file from our Ruleset to the newly generated directory. It must be in the same directory as the dlls that reference it. If you miss this step, you will receive an error in the web service that the file cannot be found. Simply copy the BRC file into the bin directory of the web service directory like I have done below: Page 29 of 37

30 Adding the web service to IIS follows the same process for creating a new virtual direction for an existing ASP.NET application. Here are the steps to follow: 1. From the Web Site node, select New and then Web Site. This will launch the Web Site Creation Wizard. 2. The wizard will prompt for a site name. I have used DecisionService. Then I click Next. Page 30 of 37

31 3. In the next screen, I allow IIS to handle the IP address. However, I know that I have other sites running under IIS and they use the default port 80. Since the web service will share the same IP address I need to give it a different port to avoid contention. I have opted to use the port 8080 and click Next. 4. In the next step, we need to point IIS to the directory that has the web service project. Note that you should point to the directory that is one level above bin. I have also allowed for anonymous access to the service since security creates over-head for a decision service that requires high performance. If you decide that you require security, you can read through the various examples Microsoft gives for security web service projects. 7 7 I have included a link to an MSDN article that covers a high-level view of web service security for the Microsoft.NET platform: Page 31 of 37

32 5. The next screen of the wizard controls file system access for the IIS service accounts. To avoid a mis-step here, I have opened up everything except browsing. This will allow for some variations in your configuration but you will be prompted by the wizard explaining that its not safe to allow both Write and Execute permissions. Click Yes in the dialog box and then click Next to move on to the next screen. Congratulations, by default, IIS should create the directory in the IIS window and start the web site. Your view of IIS should look something like the following 8 : 8 I have intentionally constrained the discussion to a single node deployment of the service. If you are interested in highavailability and clustering for your service I have included the following link: Page 32 of 37

33 3.6 Creating a Test Client Now that we have our decision service running, its only fitting that we should write a test client to prove that it works. Create new solution in Visual Studio and choose the project type Windows Application. Once the project has been created we will add a Web Reference to our project. If you right click on Web References in the solution explorer, you will be presented with this wizard: If you click on the link called Web services on the local machine the wizard will discover all of the web services running on you workstation. The next screen should look something like this: Page 33 of 37

34 You may need to scroll to the bottom of the list before you see the service that we just published. The next screen will show that the service was detected, the URI and the attributes of the service determined by the generated WSDL: I typed in DecisionService as the Web Reference Name and click the button Add Reference. Page 34 of 37

35 Once the reference has been created, my solution within Visual Studio should look something like the following: The final steps for the test client require us to add a command button to Form1 and put some code behind it. I have included my sample code below (The code in bold I created.): using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Text; using System.Windows.Forms; namespace TestClient public partial class Form1 : Form public Form1() InitializeComponent(); } private void button1_click(object sender, EventArgs e) //create the test client DecisionService.Customer cust = new DecisionService.Customer(); cust.age = 15; cust.firstname = "Chris"; cust.lastname = "Berg"; cust.maritalstatus = "Married"; Page 35 of 37

36 DecisionService.Workflow1_WebService service = new TestClient.DecisionService.Workflow1_WebService(); string retval = service.decision(cust); Console.WriteLine(retval); } } } The first thing you should notice about the test client is that I have created an instance of a Customer object but its type is managed by the Web Reference. I never had to directly reference the XOM project that defined the original object. This makes the service very portable and easy to consume since the contract is managed by the WSDL of the service. ASP.NET Client Adding the web reference to an ASP.NET application follows the same process as a fat client. As you would expect, the project looks different because of the ASP.NET project artifacts in Visual Studio. You can add a web reference to your project just like the example above. The code for the web reference is slightly different however. Below is the example I created (The code I added is in bold.): <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns=" > <head runat="server"> <title>untitled Page</title> </head> <body> <form id="form1" runat="server"> <div> <% //create the test client DecisionService.Customer cust = new DecisionService.Customer(); cust.age = 15; cust.firstname = "Chris"; cust.lastname = "Berg"; cust.maritalstatus = "Married"; DecisionService.Workflow1_WebService service = new DecisionService.Workflow1_WebService(); string retval = service.decision(cust); Response.Write(retval); %> </div> </form> </body> </html> Page 36 of 37

37 When the page is executed, you can see the response of the decision service in the page: 4.0 Summary The strength of the Rules for.net integration with the Windows Workflow Foundation is most profoundly demonstrated in its seamless use of existing patterns, tools, and behaviors that a user of WF would expect. Moreover, the nature of the BusinessRule activity assumes a contract-based integration that allows for a seamless movement of data between the workflows and rules. Of course there is always a lot more to explore when we have only scratched the surface but I will leave that up to you and a future X-Ray paper. Good luck. About the Author Chris C. Berg is the Product Manager for the Rules for.net product at ILOG. He has nearly 20 years of experience in the software industry and has deep industry knowledge in the areas of BRMS and BPM. Page 37 of 37