What is WPF?
WPF is the engine that is responsible for creating, displaying, and manipulating user-interfaces, documents, images, movies, and media in Windows Vista.
Physically, WPF is a set of libraries that have all functionalty you need to build, run, execute, and manage Windows Vista applications.
What is XAML?
XAML is a new descriptive programming language developed by Microsoft to write user interfaces for next generation managed applications.
How XAML is related to WPF?
XAML is a new descriptive programming language developed by Microsoft to write user interfaces for next generation managed applications. XAML is used in WPF to represent the controls and code with the help of C#, Visual Basic, and other .NET Framework languages.
XAML can be think as ASP.NET and/or Windows Forms in Windows Vista. For example, to write a Web application in .NET 1.0, 1.1, or 2.0, you use ASP.NET and to write Windows Applications, you use Windows Forms. Now in Windows Vista and .NET 3.0, you will use XAML instead of Windows Forms and ASP.NET.
Does that mean XAML will replace ASP.NET and Windows Forms? YES and NO. Both ASP.NET and Windows Forms will also be supported on .NET 3.0 but you don't have to use them if you don't want.
What Operating Systems does WPF support?
Windows Vista, Windows XP, and Windows 2003 Server.
How do I build WPF Applicaitons?
To build WPF application, you must install .NET 3.0 SDK. It can be found on MSDN downloads sites.
What do I need to run WPF Applications?
To run WPF applications, you must install .NET 3.0 SDK redistributable. It can be found on MSDN downloads sites.
Get Started with WPF
Download a free version of Visual Studio 2008, if you do not have Visual Studio 2008 or express version here: www.c-sharpcorner.com/Downloads
Friday, July 24, 2009
WCF Basics
WCF is fundamentally different from previous communication technologies. Another common "jargon-phrase" you will hear thrown around a lot is "SOA" or Service Oriented Architecture. Extremely simplified, think of SOA has different pieces of code/services running around the world and clients can make use of those services. These service hosts take care of internal complexities, and the communication infrastructure allows for things such as versioning and the communication infrastructure.
Thus, a big tenet of SOA is isolation. Let me explain with an example.
Say, you are consuming a web service, that accepts a zipcode, and returns you a weather forecast. All you, the client, ever cares about is .. the zipcode (input), and the forecast (output). Beyond the input/output .. or request/response .. the service host .. never talks to the client. There is an isolation between the client and server, and they interoperate on only what they had agreed to interoperate upon, i.e. the contract. So, this brings me to the first important piece in WCF, "The Contract".
Contract: This is the heart of your service - what does your service do!
In WCF, a contract is usually implemented as an interface decorated by the [ServiceContractAttribute]. For instance, in this particular case, your contract would look like this -
1: [ServiceContract]
2: public interface IWeatherService
3: {
4: [OperationContract]
5: public WeatherForecast GetForeCast(int zipCode);
6: }
But is a contract all I need? Well no .. because I need to know atleast 3 peices of information before I can use such a service -
Where can I find this service - The Address.
What protocol will I use in using this service - The Binding.
And of course the contract - when I know where the service is (address), and how I will technologically speaking use it (binding) - what the heck will I do with it .. the Contract.
So, in WCF, you have ABC's -
The Basics
Address: Address is where your service can be found. Usually in the format of scheme://domaon[:port]/path. Example http://localhost:8080/MyService
Binding: A binding refers to specific protocols used by a particular endpoint. Example, http, tcp, msmq etc.
Contract: This is the heart of your service - what does your service do!
These 3 together, form an "EndPoint".
EndPoint: EndPoint is how a ServiceHost, exposes a service, so clients can invoke it's operations defined in the contract. (Read that again!). So, how is an EndPoint different from an Address? An EndPoint have 3 peices - Address, Binding, and Contract.
Now, note that in the contract I showed above, I am using a return type called "WeatherForecast". The "WeatherForecast" is a class I wrote, that represents a business object which lets me conveniently hold the details of the data I am accepting or sending. This along with all details of the endpoint constitute, the "MetaData" for the service.
Also, for "WeatherForecast" to go over the wire, it must be Serializable. Being Serializable means, the object can be hydrated, dehydradted from a stream/bunch of bytes, into a living class instance. Thus, if the human body was serializable, teleportation like Star Wars shows us all the time, would be possible. The business object "Human Body" would be dehydrated into "information" - sent over a communication channel(s), and then rehydrated at the other side - to produce a human being on the other side. Sure beats my commute.
And given the MetaData for a service, a consumer of the service, can now create a Proxy - which is an empty shell, or a type, that exposes all details of the service.
Proxies: A client communicates with a host using a proxy. A proxy is an empty type that exposes all operations in a service contract, and hides serialization/sending over wire details. A single proxy, uses a single endpoint.
Finally, the client, and the host, talk to each other through various channels. And around these channels, you may have various behaviors associated with the service.
Channels: Channels, is what a message goes through when it goes between a client and a host. Usually you have multiple stacked channels.
Behavior: Behaviors modify the message as they flow through a channel stack. A good example of a behavior is authorization.
So .. overall ..
You have a host, and a client, both agree on a contract. The host exposes EndPoints which are a combination of Address, Binding and Contract. The client uses a proxy, that is tied to a particular endpoint - thus tied to a particular contract. And the actual communication related details are abstracted in Channels and Behaviors.
That one line above, summarizes WCF.
So, what makes WCF different?
You first think of the Contract - What am I trying to get done!?
Then you think of where will I host it, and what technology will I use to host it.
Then you worry about the nitty gritties such as authentication etc.
For the very first time, you have a communication technology, that lets you first focus on what you're trying to get done, and worry about communication later.
Thus, a big tenet of SOA is isolation. Let me explain with an example.
Say, you are consuming a web service, that accepts a zipcode, and returns you a weather forecast. All you, the client, ever cares about is .. the zipcode (input), and the forecast (output). Beyond the input/output .. or request/response .. the service host .. never talks to the client. There is an isolation between the client and server, and they interoperate on only what they had agreed to interoperate upon, i.e. the contract. So, this brings me to the first important piece in WCF, "The Contract".
Contract: This is the heart of your service - what does your service do!
In WCF, a contract is usually implemented as an interface decorated by the [ServiceContractAttribute]. For instance, in this particular case, your contract would look like this -
1: [ServiceContract]
2: public interface IWeatherService
3: {
4: [OperationContract]
5: public WeatherForecast GetForeCast(int zipCode);
6: }
But is a contract all I need? Well no .. because I need to know atleast 3 peices of information before I can use such a service -
Where can I find this service - The Address.
What protocol will I use in using this service - The Binding.
And of course the contract - when I know where the service is (address), and how I will technologically speaking use it (binding) - what the heck will I do with it .. the Contract.
So, in WCF, you have ABC's -
The Basics
Address: Address is where your service can be found. Usually in the format of scheme://domaon[:port]/path. Example http://localhost:8080/MyService
Binding: A binding refers to specific protocols used by a particular endpoint. Example, http, tcp, msmq etc.
Contract: This is the heart of your service - what does your service do!
These 3 together, form an "EndPoint".
EndPoint: EndPoint is how a ServiceHost, exposes a service, so clients can invoke it's operations defined in the contract. (Read that again!). So, how is an EndPoint different from an Address? An EndPoint have 3 peices - Address, Binding, and Contract.
Now, note that in the contract I showed above, I am using a return type called "WeatherForecast". The "WeatherForecast" is a class I wrote, that represents a business object which lets me conveniently hold the details of the data I am accepting or sending. This along with all details of the endpoint constitute, the "MetaData" for the service.
Also, for "WeatherForecast" to go over the wire, it must be Serializable. Being Serializable means, the object can be hydrated, dehydradted from a stream/bunch of bytes, into a living class instance. Thus, if the human body was serializable, teleportation like Star Wars shows us all the time, would be possible. The business object "Human Body" would be dehydrated into "information" - sent over a communication channel(s), and then rehydrated at the other side - to produce a human being on the other side. Sure beats my commute.
And given the MetaData for a service, a consumer of the service, can now create a Proxy - which is an empty shell, or a type, that exposes all details of the service.
Proxies: A client communicates with a host using a proxy. A proxy is an empty type that exposes all operations in a service contract, and hides serialization/sending over wire details. A single proxy, uses a single endpoint.
Finally, the client, and the host, talk to each other through various channels. And around these channels, you may have various behaviors associated with the service.
Channels: Channels, is what a message goes through when it goes between a client and a host. Usually you have multiple stacked channels.
Behavior: Behaviors modify the message as they flow through a channel stack. A good example of a behavior is authorization.
So .. overall ..
You have a host, and a client, both agree on a contract. The host exposes EndPoints which are a combination of Address, Binding and Contract. The client uses a proxy, that is tied to a particular endpoint - thus tied to a particular contract. And the actual communication related details are abstracted in Channels and Behaviors.
That one line above, summarizes WCF.
So, what makes WCF different?
You first think of the Contract - What am I trying to get done!?
Then you think of where will I host it, and what technology will I use to host it.
Then you worry about the nitty gritties such as authentication etc.
For the very first time, you have a communication technology, that lets you first focus on what you're trying to get done, and worry about communication later.
Subscribe to:
Posts (Atom)
