Using the XmlFormatter
Using the XmlFormatterTo become familiar with the XmlFormatter, open the Visual Studio solution associated with this chapter that you downloaded from www.samspublishing.com. The solution contains a single project, called Serialization, for building a console application. All the code is in a single module, Program.cs, the content of which is shown in Listing 3.3. Note that there is a using statement for the System.Runtime.Serialization namespace, and also that the project references the System.Runtime.Serialization assembly. Listing 3.3. Program.cs
In Listing 3.3, the static Main() method of the class called Program both provides a host for a Windows Communication Foundation service and uses that service as a client. The hosting of the service is accomplished with this code: using (ServiceHost host = new ServiceHost( typeof(DerivativesCalculator), new Uri[] { new Uri("http://localhost:8000/Derivatives") })) { host.AddServiceEndpoint( typeof(IServiceViewOfService), new BasicHttpBinding(), "Calculator"); host.Open(); [...] host.Close(); [...] }In this code, an endpoint, with its address, binding, and contract, is added to the service programmatically, rather than through the host application's configuration, as was done in the preceding chapter. Similarly, the client code directly incorporates information about the service's endpoint, rather than referring to endpoint information in the application's configuration: string address = "http://localhost:8000/Derivatives/Calculator"; ChannelFactory<IClientViewOfService> factory = new ChannelFactory<IClientViewOfService>( new BasicHttpBinding(), new EndpointAddress( new Uri(address))); IClientViewOfService proxy = factory.CreateChannel(); This imperative style of programming with the Windows Communication Foundation is used here for two reasons. The first is simply to show that this style is an option. The second, and more important, reason is to make the code that is discussed here complete in itself, with no reference to outside elements such as configuration files. The contract of the service is defined in this way: [ServiceContract(Name = "DerivativesCalculator")] [...] public interface IServiceViewOfService { [...] }The client has a separate definition of the contract of the service, but the definition used by the client and the definition used by the service are semantically identical: [ServiceContract(Name="DerivativesCalculator")] [...] public interface IClientViewOfService { [...] }In both the client's version of the contract and the service's version, there is this definition of an operation: [OperationContract(Name="FromXSDTypes")] decimal CalculateDerivative( string[] symbols, decimal[] parameters, string[] functions); When the client uses that operation, like this, decimal result = proxy.CalculateDerivative( new string[] { "MSFT" }, new decimal[] { 3 }, new string[] { "TechStockProjection" }); Console.WriteLine( "Value using XSD types is {0}.", result);its attempt to do so works, which can be verified by running the application built from the solution. In this case, the inputs and outputs of the operation are .NET types that correspond quite obviously to XML Schema Datatypes. The XmlFormatter automatically serializes the inputs and outputs into XML. The next operation defined in both the client's version of the contract and the service's version is this one: [OperationContract(Name = "FromDataSet")] DataSet CalculateDerivative(DataSet input); The client uses that operation with this code: DataTable table = new DataTable("InputTable"); table.Columns.Add("Symbol", typeof(string)); table.Columns.Add("Parameter", typeof(decimal)); table.Columns.Add("Function", typeof(string)); table.Columns.Add("Value", typeof(decimal)); table.Rows.Add("MSFT", 3, "TechStockProjection",0.00); DataSet input = new DataSet("Input"); input.Tables.Add(table); DataSet output = proxy.CalculateDerivative(input); [...] Console.WriteLine( "Value using a DataSet is {0}.", output.Tables[0].Rows[0]["Value"]);In this case, the input and output of the operation are both .NET DataSet objects, and the .NET DataSet type does not obviously correspond to any XML Schema Datatype. Nevertheless, the XmlFormatter automatically serializes the input and output to XML, as it will for any .NET type that implements ISerializable. Of course, passing .NET DataSets around is a very bad idea if one can anticipate a non-.NET client needing to participate, and it is never wise to rule that out as a possibility. In the service's version of the contract, this operation is included: [OperationContract(Name = "FromDataContract")] ServiceViewOfData CalculateDerivative(ServiceViewOfData input); The input and output of this operation is an instance of the ServiceViewOfData class, which is defined like so: [DataContract(Name="Calculation")] public class ServiceViewOfData: IUnknownSerializationData { [DataMember(Name = "Symbols")] private string[] symbols; [DataMember(Name = "Parameters")] private decimal[] parameters; [DataMember(Name = "Functions")] private string[] functions; [DataMember(Name="Value")] private decimal value; [...] }The client's version of the contract defines the corresponding operation in this way: [OperationContract(Name = "FromDataContract")] ClientViewOfData CalculateDerivative(ClientViewOfData input); Here, the input and output are of the ClientViewOfData type, which is defined in this way: [DataContract(Name = "Calculation")] public class ClientViewOfData : IUnknownSerializationData { [DataMember(Name = "Symbols")] public string[] Symbols; [DataMember(Name = "Parameters")] public decimal[] Parameters; [DataMember(Name="Functions")] public string[] Functions; [DataMember(Name="Value")] public decimal Value; [DataMember(Name = "Reference")] public Guid Reference; }The service's ServiceViewOfData class and the client's ClientViewOfData class are used to define data contracts that are compatible with one another. The data contracts are compatible because they have the same namespace and name, and because the members that have the same names in each version of the contract also have the same types. Because of the compatibility of the data contracts used in the client's version of the operation and the service's version, those operations that the client and the service define in different ways are also compatible with one another. The client's version of the data contract includes a member that the service's version of the data contract omits: the member named Reference. However, the service's version implements the Windows Communication Foundation's IUnknownSerializationData interface, thus: [DataContract(Name="Calculation")] public class ServiceViewOfData: IUnknownSerializationData { [...] private UnknownSerializationData unknownData; [...] public UnknownSerializationData UnknownData { get { return this.unknownData; } set { this.unknownData = value; } } }By implementing the IUnknownSerializationData interface, it sets aside some memory that the XmlFormatter can use for storing and retrieving the values of members that other versions of the same contract might include. In this case, that memory is named by the variable called unknownData. Thus, when a more advanced version of the same data contract is passed to service, with members that the service's version of the data contract does not include, the XmlFormatter is able to pass the values of those members through the service. In particular, when the client calls the service using this code, ClientViewOfData calculation = new ClientViewOfData(); calculation.Symbols = new string[] { "MSFT" }; calculation.Parameters = new decimal[] { 3 }; calculation.Functions = new string[] { "TechStockProjection" }; calculation.Reference = Guid.NewGuid(); Console.WriteLine( "Reference is {0}.", calculation.Reference); ClientViewOfData calculationResult = proxy.CalculateDerivative(calculation); Console.WriteLine( "Value using a Data Contract is {0}.", calculationResult.Value); Console.WriteLine( "Reference is {0}.", calculationResult.Reference);not only is the XmlFormatter able to serialize the custom type, ClientViewOfData, to XML for transmission to the service, but the member called Reference that is in the client's version of the data contract, but not in the service's version, passes through the service without being lost. Two things should be evident from this case. First, the DataContract and DataMember attributes make it very easy to provide for the serialization of one's custom data types by the Windows Communication Foundation's XmlFormatter. Second, implementing the Windows Communication Foundation's IUnknownSerializationData interface is always a good idea, because it allows different versions of the same data contract to evolve independently of one another, yet still be usable together. The last operation defined for the service is this one, which is defined in the same way both in the code used by the service and in the code used by the client: [OperationContract(Name = "AlsoFromDataContract")] Data DoSomething(Data input); The input and output of the operation are of the custom Data type, which is made serializable by the XmlFormatter through the use of the DataContract and DataMember attributes, thus: [DataContract] public class Data { [DataMember] public string Value; }The client uses that operation with this code: DerivedData derivedData = new DerivedData(); Data outputData = proxy.DoSomething(derivedData); That code passes an instance of the DerivedData type to the service, a type which is derived from the Data class, in this way: [DataContract] public class DerivedData : Data { }What will happen in this case is that the XmlFormatter, in deserializing the data received from the client on behalf of the service, will encounter the XML into which an instance of the DerivedData class had been serialized, when it will be expecting the XML into which an instance of the Data class has been serialized. That will cause the XmlFormatter to throw an exception. However, both the service's version of the endpoint's contract and the client's version have a KnownType attribute that refers to the DerivedData class: [ServiceContract(Name = "DerivativesCalculator")] [KnownType(typeof(DerivedData))] public interface IServiceViewOfService { [...] } [...] [ServiceContract(Name="DerivativesCalculator")] [KnownType(typeof(DerivedData))] public interface IClientViewOfService { [...] }That attribute prepares the XmlFormatter to accept the XML for a DerivedData object whenever it is expecting the XML for an instance of any type from which the DerivedData class derives. So, by virtue of that attribute being added to the definition of the service's contract, when the XmlFormatter encounters XML for a DerivedData object when it is expecting XML for a Data object, it is able to deserialize that XML into an instance of the DerivedData class. It follows that if one was to define an operation in this way, [OperationContract] void DoSomething(object[] inputArray); then one should add to the service contract a KnownType attribute for each of the types that might actually be included in the input parameter array. That the KnownType attribute has to be added in order for the DerivedData objects to be successfully deserialized shows that one should avoid using inheritance as a way of versioning data contracts. If a base type is expected, but a derived type is received, serialization of the derived type will fail unless the code is modified with the addition of the KnownType attribute to anticipate the derived type. The Windows Communication Foundation uses the XmlFormatter invisibly. So these remaining lines of client code in the sample simply show that it can be used separately from the rest of the Windows Communication Foundation for serializing data to XML: MemoryStream stream = new MemoryStream(); XmlFormatter formatter = new XmlFormatter(); formatter.Serialize(stream, calculation); Console.WriteLine( UnicodeEncoding.UTF8.GetChars(stream.GetBuffer())); |
EAN: 2147483647
Pages: 132