Tuesday, January 05, 2010
Sunday, December 06, 2009
Friday, June 19, 2009
Thursday, May 07, 2009
WCF Service Factory Video
We need to do the below steps for Host Model
Host Model
The host model is used to model the endpoints of the Web service and the client proxies. This model looks completely different from the other two models we've discussed previously. At this point, you can start modeling in the host explorer by right-clicking on elements, as opposed to simply dragging and dropping elements onto the design surface. By right-clicking on the host model element, you can add a new host and a new client, as shown in Figure 7.
Figure 7 Adding Clients and Hosts to the Host Model
After adding a PizzaHost and a PizzaClient, the implementation technology for both can be selected. We have chosen to set both to WCF. It is also necessary to select an implementation project for both. Fortunately, the Service Factory has already generated those for us. As you can see, the Tests folder in the solution structure shown in Figure 5 contains the projects PizzaService.Host and PizzaService.Client. These can be used as implementation projects.
We create a new ServiceReference by right-clicking on the PizzaHost. For this new ServiceReference, we need to select a service implementation—this is a reference to our service model. We can select the implementation in the same way we selected data contracts in Figure 2.
For each ServiceReference you create, you can define different endpoints. We have created one endpoint, called PizzaEndpoint, and have configured it to use the wsHttpBinding.
Now that we have an endpoint, we can create a proxy for our client. To add a new proxy, we right-click on the PizzaClient in the Host Explorer. With a combobox in the property window of the proxy, we can select the endpoint. The completed host model is shown in Figure 8.
Figure 8 Completed Host Model for the Pizza Service
Generating Code
All the models we need for our pizza ordering service are now defined, and we are ready to generate the service. To do this, we first have to fill in the project mapping table field for each of our models—this can be defined in the property window of each model. When selecting this property, a selection window pops up. In our case, there is only one option: PizzaService. This is because all the roles were already defined when we created the solution structure. The roles can be found in the file projectmapping.xml, which is also part of our solution structure. In this file, a role can be associated with a project.
The next step is to actually generate the code. Right-clicking on the data contract model gives us the Generate Code option. Selecting this option generates the data contracts in the PizzaService.DataContracts project. The same can be done for the service contract model, which generates code in the PizzaService.MessageContracts, PizzaService.ServiceContracts, and PizzaService.ServiceImplementation projects.
Generating code for the host model is done in two steps: we generate code once for the host and once for the client. To generate code for the host, we click on the PizzaService ServiceReference and the Visual Studio designer presents a button called Validate Model. When we click the button, the model is validated correctly and we then are presented with the Generate Service button. Clicking this, as you've surely guessed by now, generates code in the PizzaService.Host project.
Now to generate the client, we first have to run the host, so we compile the PizzaService.Host project and run it in a Web browser. Next we click on the PizzaProxy in our host model and click generate code. This opens a wizard, shown in Figure 9, that allows us to configure the client. While the service address is filled in automatically by the Service Factory, we go ahead and define the security settings for the host. For instance, if an X.509 certificate is needed in order to connect to this service, we can add it to the client by using this wizard.
Figure 9 Wizard Used to Generate the Client (Click the image for a larger view)
At this point, the service is ready to use and can be published in IIS. Business logic and entities for the service can be added to the PizzaService.BusinessEntities and PizzaService.BusinessLogic projects. The only other thing we need to do is create a new partial class, called PizzaServicePeedy, in the PizzaService.ServiceImplementation project. This is used to add business logic to the generated service implementation. Unfortunately, if we edit the generated code directly, our logic will be overwritten the next time we generate code. But with a partial class, this is not the case since the generator does not touch a file we have created ourselves.
To show this, we have defined a class in the PizzaService.BusinessLogic project called PriceCalculator with a method called CalculatePrice. (It's important to note that this is not a recommended practice—it's much better if the business logic doesn't "know" anything about the service, which is why there is a translation layer. To support this process, Service Factory has a translator built in that helps you translate your data contract into business entities. But while you may not want to do this in production, we're using this technique here as a simple way to illustrate a fundamental point.) This method takes a PizzaOrder data contract as a parameter and returns the price of the order. The only thing we need to do now is encapsulate this price in a MessageContract and then return the MessageContract. Therefore, to do this we create a partial class in the PizzaService.ServiceImplementation project called PizzaServicePeedy that overrides the method OrderPizza generated by the Service Factory.
Monday, February 09, 2009
Tuesday, November 13, 2007
Monday, September 24, 2007
Subscribe to:
Posts (Atom)