Download Currency Coonverter Projects
This is first article in three part series on writing an end to end solution using WCF, Silverlight. This first article will discuss How to write WCF service for Silverlight clients. Well you may be asking a question now, is there something different about WCF service for Silverlight application? Well short answer to the question is, Yes. I will discuss that little later. For the discussion I have developed a Silverlight application for Foreign Exchange currency conversion. The data flow of the application is as below.
From Silverlight application, user selects two currencies for which conversion rate is to be obtained. Silverlight application connects to a WCF service. The WCF service, using HTMLParser.Net to connect to a data source site. It receives the response and then parses it to get conversion rate. And then sends that conversion rate back to Silverlight client application. And then client application displays the conversion rate. You can see this all in action in demo at following location.
There is lot of documentation available on MSDN about what is WCF and what is purpose of it. I will not go into all those details. I will jump right into what do you need to do to develop a service based on Windows Communication Foundation (WCF) technology. There are couple of questions that you will need to answer before you can dig into actual implementaiton of the service.
I will discuss these points one at a time.
This is the first question that you will need to answer when developing a service using WCF. Loosely defined this what this means is that what are the methods that a client can call in your web service. The following code snipper shows what the contracts look like in the service that I developed for this discussion.
[ServiceContract(Namespace="http://byteblocks.com", Name="CurrencyService")]
public interface ICurrencyService
{
[OperationContract]
List<Currency> GetCurrencies(out CallResult status);
[OperationContract]
double Convert(string from, string to, out CallResult status);
}
This should look very familiar. It is nothing but regular interface declaration. So there is nothing unusual here. By definition an Interface is no more than a contract for its implementers. The only thing different here is attributes that are decorating interface definition and method declrations. WCF uses Opt-in mechanism for you to indicate what needs to be included in service. By putting OperationContract on method, that you indicate that this method is to be exposed to clients as service's contract.
When client and service communicate with each other, there is some data that gets tramissted as well with. If there is some input that method is expecting then client needs to send that. And if there is some response that service is going to send back to caller, then that data objects need to be sent back. This data communication happens by marhsalling or serializing the data in format that both client and service understand. That would mean that what ever data objects are being passed back and forth have to be atleast serialzable. But that is not enough. As I mentioned, WCF uses Opt-in mechanism. That would mean that what ever objects are being serialized, you will have to indicate what part of the object can be serialized. Lets take a look at one of the objects that is sent back as part of the response for method GetCurrencies.
[DataContract]
public class Currency
{
public Currency()
{
}
public Currency(string country, string name, string symbol)
{
Country = country;
Symbol = symbol;
Name = name;
}
[DataMember]
public string Symbol
{
get; set;
}
[DataMember]
public string Name
{
get; set;
}
[DataMember]
public string Country
{
get; set;
}
}
Notice the use of DataContract and DataMember. By decorating an object with DataContract attribute you indicate your intention of making that object visible to callers. And my putting DataMember attribute on properties or fields you make them available for serialization. Any property or field that is not marked with DataMember attribute, will not be serialized.
Silverlight can communicate with any service or application that is capable of communicating via Tcp channel or Http with in some restrictions. I will not talk about communication via raw sockets in this article. In this article I will discuss communication over Http. Silverlight can handle all communications that implement SOAP1.1 specification and also stick to BasicHttpBinding. What this means is that in your service when you define end point, make sure that you choose basicHttpBinding as your binding mechanism. If you choose wsHttpBinding the comunication between silverlight application and WCF service will fail. In configuraiton file of WCF service, your end point defintion may look like as below.
<endpoint address="" binding="basicHttpBinding"
contract="ByteBlocks.ForExService.ICurrencyService">
For this demo project, I have decided to host my service in IIS. That way I can leverage security implemented by ASP.Net framework.
During execution of few WCF/Silverlight projects there are some very important lessons I learned. I will point out those from WCF prespective in this article.
[DataContract]
public class CallResult
{
public CallResult()
{
StatusCode = 0;
StatusMessage = "OK";
}
[DataMember]
public int StatusCode
{get; set;}
[DataMember]
public string StatusMessage
{get; set;}
[DataMember]
public string ExceptionDetails
{get; set;}
}
<host>
<baseAddresses>
<add baseAddress="http://www.myhostserver.com/MyWCFServices/"/>
</baseAddresses>
</host>
In next article Consume WCF Services in silverlight control or application, i will discuss development of Silverlight application that consumes this WCF service.
How to plan CCSP Exam preparation
Develop a MongoDB pipeline to transform data into time buckets
Alert and Confirm pop up using BootBox in AngularJS
AngularJS Grouped Bar Chart and Line Chart using D3
How to lock and unlock account in Asp.Net Identity provider
2025 © Byteblocks, ALL Rights Reserved. Privacy Policy | Terms of Use