MSDN Magazine - September 2008 - (Page 28)

As an alternate approach to creating the WCF ProductList method with the parameter to an opSilverlight 2 Application service, you can choose the file item template in eration with a new name in the WCF service. Passing Serialized Visual Studio to create a Silverlight-enabled WCF The WCF service simply implements this serEntities Using service. Figure 3 shows the new item template in Async Calls via WCF vice contract interface and calls a manager class Visual Studio. This template automatically sets the that is tasked with getting the products from the binding to basicHttpBinding and adds some attridatabase and mapping them to a List butes to make the service compatible with ASP.NET. so they can be passed out of the service. Figure 4 And while this approach sets the correct binding shows the code that gets the list of products from WCF Services configuration for you, remember that you can certhe Northwind database, maps each product to a Entity tainly still use existing WCF services as long as the Product class, and adds each product instance to Business Layer Model bindings are set for basicHttpBinding. the List . Data Layer The WCF service must be able to request a list of Entities returned by WCF must be decorated products to fill the ListBox, and it must be able to with the DataContract attribute to allow them save any changes a user makes to a product. These to be properly serialized and sent on their way to are simple operations that require no Silverlight-spethe Silverlight app. The Product class referred to in Database cific techniques. The sample application uses a WCF Figure 4 has the DataContract attribute and all of service class named NWServiceGateway, which Figure 2 Architectural its properties are decorated with the DataMember implements the interface INWServiceGateway. Model of the Sample attribute. This tells WCF to serialize and make the INWServiceGateway, shown here, is decorated as Application entity and its DataMember properties available a ServiceContract, which enables any class that imto the Silverlight app. When the WCF service’s plements this interface to be exposed through WCF: FindProductList method is invoked, the Silverlight client app will receive a List and will be able to refer to all of the prop[ServiceContract(Namespace = "")] public interface INWServiceGateway erties decorated with the DataMember attribute. { [OperationContract] Product FindProduct(int productId); [OperationContract] List FindProductList(); [OperationContract(Name="FindProductListByCategory")] List FindProductList(int categoryID); [OperationContract] List FindCategoryList(); [OperationContract] void SaveProduct(Product product); } The interface lists several methods decorated with the OperationContract attribute. OperationContracts can be invoked through the WCF service. Notice that the FindProductList method has two overloads. One accepts a parameter and the other does not. While this is perfectly acceptable in Microsoft® .NET Framework methods, WCF cannot expose two methods with the same name. To work around this, you can either rename the method or use the Name property of the OperationContract to specify a different name in the service definition. Figure 4 shows how to expose the Find- Silverlight applications will execute in the client computer’s environment. This presents a few issues that ASP.NET Web-based applications do not currently face since they execute on the server and render HTML and scripting code on the client. Because Silverlight executes on the client, it must request information from the server using a service-oriented technology such as WCF. However, the WCF service must be secured against unwanted client applications who might take advantage of it. The sample Silverlight application is hosted on your trusted Web server, so it should be permitted to speak to the sample application’s WCF services. If another application that is hosted by another Web server tries to communicate with the sample WCF service, it should be denied. Controlling this kind of access to services is handled by crossdomain policy files. Adobe Flash applications have a standard file to handle this called CrossDomain.xml which lives in the root of the service’s Web server. Silverlight applications behave similarly, first looking for a file called ClientAccessPolicy.xml in the Web server’s root (not the Web application’s root). If the file is found, the application will read it to determine whether the request will be allowed or denied. If it is not found, the application will then look for the CrossDomain.xml file. If neither is found, the request will be denied and the Silverlight client application will not be able to invoke the WCF services. The contents of either of these files must allow the caller permission to the services. Since the sample application exists only on a protected development machine, its ClientAccessPolicy.xml allows all requests, as shown here: Cross-Domain Communications Figure 3 Silverlight-Enabled WCF Template 28 msdn magazine Data Points

Table of Contents Feed for the Digital Edition of MSDN Magazine - September 2008

MSDN Magazine - September 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Cutting Edge Hierarchy ID New Features for Microsoft SQL Server 2008 Prism Data Services Advanced WPF Test Run Security Briefs Foundations { End Bracket }

MSDN Magazine - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.