Step 5: Your First Demo, Building the Business Object and the Server (Part 2 of 3)
Now that you've established the interface, the next step is to build the business object that the client side will access, and then write a small server-side process to host the service.
|Learn the fundamental WCF terms and security options. Study the entire object model in System.ServiceModel. These will be your vocabulary.|
To create the business object, do the following:
- Create a new class library project called DemoCustomerBz.
- In Solution Explorer, right click on references and add a .NET reference to the DemoInterfaces.DLL that you created when you built the interface project in the previous step.
- Add the code in Listing 3 or Listing 4 (CustomerBz.cs or CustomerBz.vb).
- Build the project, which will create DemoCustomerBz.DLL.
The only noteworthy aspect of the customer business object (aside from the fact that the methods are merely test methods that return dummy test data) is that the class implements the ICustomer interface from the previous step.
public class CustomerBz : ICustomer
One of the requirements of this demo application is the ability to access the back-end business object through different communication protocols (e.g., TCP, HTTP). Prior to WCF, developers who used .NET remoting would often derive from System.MarshalByRefObject in conjunction with interfaces. This allowed them to set up the necessary messaging between the client proxy and the remote object.
TCP remoting in WCF means three words: No more MarshalByRefObject! WCF handles that in the endpoint binding definition and the interface; therefore, you no longer need System.MarshalByRefObject, and the back-end class looks like any other class implementing an interface. In other words, this allows you to separate the interface from the implementation.
Next, you can build a small server application to host the service. To do this:
- Create a new Windows Forms project called DemoServer.
- In Solution Explorer, right click on references and add a .NET reference to both
, as well as System.ServiceModel.DLL
- Right click and add a new item as an Application Configuration File (as App.Config), and insert the contents from Listing 5.
- In the main form for the Windows Forms application, add two command buttons and a label, and insert the code from Listing 6 or Listing 7 (DemoServer.cs or DemoServer.vb).
The server-side hosting is very simple. The code includes the App.Config
reference to the service, which starts with the name of the business class:
also contains the endpoint address, binding, and contract name. This first example will use basic TCP binding to the localhost port 8228. Note that the contract specifics the interface. (Later in the article you'll add more endpoint addresses to demonstrate that multiple clients can access different addresses and bindings.)
Finally, the code in the application can open the service by using the ServiceHost class:
ServiceHost oHost = new ServiceHost(typeof(CustomerBz));
// TO CLOSE
At this point you've created a listener program, a self-hosting application that allows a client application to connect using the specific TCP address, and to use the back-end class CustomerBz that implements the ICustomer interface contract. The next step creates the client application.
Step 6: Your First Demo, Building the Client Piece (Part 3 of 3)
Now you'll construct a simple .NET application that accesses and uses the service. To do this:
- Create a new Windows Forms project called DemoClient.
- The client application will utilize the ICustomer interface, as well as the WCF object model. So in Solution Explorer, right click on references and add a .NET reference to DemoInterfaces.DLL as well as System.ServiceModel.DLL.
- Right click and add a new item as an Application Configuration File (as App.Config), and insert the contents from Listing 8.
- In the main form for the Windows Form application, add two command buttons and a label, and insert the code from Listing 9 or Listing 10.
Notice that the client-side configuration settings for App.Config
are almost identical to those on the server-side in the previous tip.
The code also specifies (with the name
tag) a variable that you'll use in the application that relates to this connection information. You could use this if you needed to present multiple communication options to a user.
The code to activate the service on the client side uses the ChannelFactory class, a cornerstone of the client piece. The ChannelFactory is a factory class that creates a communication channel of a specific type for the client to send a message to an endpoint that you specified in your configuration.
ChannelFactory<ICustomer> customersFactory =
If that sounds like a mouthful, think of it this way: you're creating a factory class called customersFactory
. It is of type ICustomer (the interface), and inherits all the endpoint information that matches the "Customer" tag.
Note that you haven't (yet) accessed the WCF serviceyou've created a class from the ChannelFactory that allows you to instantiate a strongly-typed proxy you can use to communicate with the service. The next line creates a strongly-typed proxy (customersProxy
) of type ICustomer, using the base ChannelFactory method CreateChannel
ICustomer customersProxy =
You can then use the proxy customersProxy
to access the two methods, GetCustomer
string CustomerString =
string CustomerHistory =
Finally, if you wanted to change the communication binding to use HTTP, or use a different TCP port, you'd only need to modify and distribute the app.config