Host a service in a managed application

I think I have mentioned it before (if I haven’t, I’ll surely do now) that WCF isn’t about web services. It’s about services, as a whole. There are no restrictions on where and how you’d like to host your service. Given this, I’ll show three easy and quick ways in this post to host your WCF services in managed applications:

  • Host with an application having a UI
  • Host with a Windows Service
  • Host with the WCF-provided host

The first two options are essentially the same, the only difference is that Windows Services don’t have a user interface, and they have their own ways of installation and running. But let’s treat them as separate objectives.

We’ll use the simplest form of applications, the Console Application to self-host our WCF service. So if you’re ready (created a console app), add the necessary code files to it (the service class, and the service contract interface, plus an app.config). I’m sure you’ll be able to write a simple service by now, and the whole purpose of this post is to show you how to host your written services, instead of how to write them, so I’ll omit the creation of a service. Let’s assume you’ve a service called MyService, with a contract interface IMyService. Given this, you’d host your service by using the ServiceHost class:

Continue reading “Host a service in a managed application”

Advertisements

Create and configure service endpoints

Well we’ve written a service, specified the contracts, operations, custom data object and the structure of our SOAP message, and now, it’d be time to share it with the world. But how should we do that?

The answer is easy, we need to define endpoints to which clients can connect, and gather (or post) the required information from/to us. An endpoint is built up from three things, which are the ABCs of them. These are:

  • Address: the URL of the service, with which you can reach it. The address of a WCF service can expose the following properties:
    • Scheme: the scheme is the very beginning of the address, typically http://, but this is not the same thing as the protocol, even though it’s called the same.
    • Machine: the name of the machine, for example localhost, or http://www.somedomainname.com, or the IP address.
    • Port: the optional port number (:8080).
    • Path: the path of the service, can be multilevel. I think you can guess what’s it.
    • Binding: the binding specifies how your service can be accessed it defines the protocol name, type, encoding, etc. You should imagine the binding as something which stores anything else than the message contract, and the address used to reach it. So security settings, metadata exposing, and a lot other things belong to here. There are some preinstalled bindings, which you can extend, or create entirely new bindings from scratch. I’ll provide a table of the installed bindings later in this post.
    • Contract: you have seen it in work, we’ve defined it in the previous posts. The contract specifies the methods, operations to expose, custom data types, etc. The name of the contract is the same as the class or interface marked with the ServiceContractAttribute. If you’ve set the “Name” named parameter explicitly, then you should use the value you specified there.

Continue reading “Create and configure service endpoints”

Define Message contracts

So far we’ve looked into the ways of controlling the underlying service metadata on the client and the server. This time, we’ll inspect how to customize the message itself, with the help of message contracts.

As you could guess, there are a bunch of attributes which help us implementing this task. It’s good to know your enemy from the beginning, so here are them:

  • MessageContractAttriubte: this attribute let’s you control the mappings between your custom types and their SOAP representations.
  • MessageBodyMemberAttribute: the given field/property will be serialized as a member of the SOAP body.
  • MessageHeaderAttribute: surprise! The given field/property will be serialized into a SOAP header.
  • MessageHeaderArrayAttribute: defines that no wrapper element should be written to the specified array (each value in the array will be an independent element).

Well, only four attributes. That’s not a big deal for us, so let’s dive into the details!

Continue reading “Define Message contracts”

Define Operation contracts

It is clear that in order to be able to call your service, you need to mark the contract interface/class with the ServiceContractAttribute. After this post, it’ll be also clear that you must mark your exposed methods with the OperationContractAttribute. In most cases you’ll be satisfied with the default settings, but there are certain cases (one-way or duplex messaging pattern) when you need to customize the OperationContractAttribute.

Fortunately, it exposes a set of named parameters for implementing such behaviors. Here’s a brief list of them:

Named Parameters of OperationContractAttribute
Action Controls the action on the request message. The default value is the fully qualified name of the method as an address, for example: http://TheServices/IContract/MyMethod. Set it to an asterisk to indicate an operation which handles all unmatched requests. There’s a constraint on this: there can be only one method like this, and it must take a message as parameter.
AsyncPattern A Boolean value indicating whether the current pattern is asynchronous.
IsInitiating A Boolean value indicating the marked method is the initiation of a session. The default is true.
IsOneWay A Boolean value indicating that the operation returns nothing, and has no output parameters. The default is false. When you set this to true, and return anything else than void, an InvalidOperationException will be thrown at run time.
IsTerminating A Boolean value indicating that after this method the session should be terminated, and the channel closed.
Name Overrides the operation name from the default value: the contract’s method name. This is interesting from the clients point of view. They can call your through the proxy class by the name you specify here (think about IntelliSense support).
ProtectionLevel A member of the System.Net.Security.ProtectionLevel enumeration, indicating the level of protection required by the method.
ReplyAction Controls the action on the reply message. Use it in conjuction

Continue reading “Define Operation contracts”

Define Data contracts

If you could recall the previous post about Service contracts, I mentioned that you must use serializable types as return/parameter types in your exposed methods. When you build custom types (and you’ll certainly do so) you’ll need to tell WCF either implicitly or explicitly how to serialize your types.

The implicit way is to mark your custom types as serializable, with the SerializableAttribute class. This isn’t too exciting, and doesn’t require you to use data contracts, which are cooler, and will be covered by the exam test. Anyway, you should know that all publicly visible properties and fields will be serialized when you use the implicit method.

The explicit way is to mark your custom types with the DataContractAttribute and the fields/properties with the DataMemberAttribute. Then you’ll gain a finer control over how WCF will serialize and deserialize those types. The DataContractAttribute has the following named parameters:

Continue reading “Define Data contracts”

Define Service contracts

A service contract is used to define the set of operations a service exposes, its signature, the data types used, the location of the operations and the specific protocols and serialization format of the service.

In WCF, the best practice is to define the service contract as a .NET interface, and implement that interface by your service class. If you expose only some static and not-too-often changing methods in your service, you can omit the interface, and define the contract in the class.

To define the WCF service contract, you’d typically mark your contract interface with the ServiceContractAttribute, but more on this a little bit later.

At the end of the day, XML service contracts will be generated based on your interfaces and contracts, which can be exposed (and understood) by other applications, even those running on different platforms. This is the real power of services, in one word: interoperability.

Now enough of such high level abstraction, let’s dig ourselves into the layer where the actual work is done, and see how to design and implement our service contracts. First the design:

In SOA (Service Oriented Architecture) a service is a self-explaining unit of functionality. Viewed from this aspect, a class or interface is nothing more than a group of related methods and functions, exposed to the client.

Generally, it’s a better idea to use .NET interfaces as service contracts, because:

  • Service contract interfaces can extend any number of other contract interfaces
  • A class can implement any number of interfaces, thereby any number of contracts
  • You can easily modify the service implementation in the class, while the service contracts encapsulated in an interface remains the same
  • Versioning is enabled by implementing the old interface in a new one

Continue reading “Define Service contracts”

Getting Certified – WCF 70-503

As I promised, the learning continues. My next goal is the Windows Communication Foundation exam, with the number of 70-503. I’ll use the book Pro WCF by Chris Peiris and Dennis Mulder as my primary learning resource, and MSDN. I won’t buy the Training Kit, because of the lack of time (books ordered from Amazon arrive to Hungary in more than a week, and time is short till 30th).

I think this time I won’t use MeasureUp to practice, maybe I know enough of the format of exam questions by now (or maybe I don’t). Anyway, expect 30 posts about this one, I want to go through the syllabus in much more detail than in the previous times.