Abstract Factory

“Provide an interface for creating families of related or dependent objects without specifying their concrete classes.”

Design Patterns – Elements of Reusable Object-Oriented Software

So let’s begin revising the “traditional” object-oriented design patterns. I’m going to stick closely to the book, so the order of posts will be the same as the order in the book.

Abstract Factory is a creational pattern. It means that its sole purpose of such a class is to create another objects/classes. An Abstract Factory pattern has the following participants:

  • Abstract base factory class/interface
  • Concrete factory subclasses derived from the base class, implements the interface
  • Abstract product: the abstract base class of the products to be created
  • Concrete product: the concrete implementation of the abstract product.
  • Client: uses the abstract factory and the abstract product classes, without further knowledge of their concrete implementations.

Continue reading


Blog reopened

Welcome back everybody! As you can guess I was a little overwhelmed in the past days, so I’ve lacked the necessary time to write articles in a continuous manner, but that ends today.

The sad part first: I’ve lost my interest in WCF a while ago, so there won’t be any post about it till something extraordinary happens. The happier: I started to work with ASP.NET MVC, and it was love at the first sight. Producing such clean HTML, and the total control over how’s it rendered (not to say anything about built-in URL routing)! But what was far more appealing is the Model-View-Controller pattern.

I found out that I don’t know enough about design patterns as a whole. That gave me the apropos to order the Design Patterns book written by the Gang of Four. From now on, till there won’t be any more left, I post one or two patterns with C# code examples a day, from tomorrow. Be sure to check back!

No post since 6 days: a new record

Hello everybody, and sorry for the lack of writings on this week. I’m a bit busy right now, but I’ll continue posting my learning notes as soon as possible (if you are interested in the ‘70s and ‘80s sociology writers, and ready for some serious Marxist/communist stuff, let me know, and I send it in mail for you).

The main reason for the my delay is that I’m studying hard for my social-structure exam, which is not like any other stuff posted in this blog. It makes you drowsy in five seconds, and I think there’s a guarantee for that. Otherwise, it’s quite complicated, and lacks any logic and consistency, but enough of it.

There are some sub-reasons as well. I’ve become a little depressed, because Apple rejected my company’s first app (because of copyright and legal issues), and there’s no way to fix this one, the app’s fundamental idea was attacked. This could be easy to survive, but it take me a little time to find some energy to continue learning. Anyway, I’m working hard in the family business (first payment arrived).

The last cause (and I think the ultimate one) is that the book Pro T-SQL 2008 Programmer’s Guide has arrived to me, and it’s something I can’t take down. The next series of posts will be about the SQL Server Developer exam (for which I don’t know the code), I’m quite sure about this.

So these are the reasons that made me stop publishing my notes (there’s nothing to publish). I can promise that if I pass the social-structure exam, I’ll surely continue the series on WCF 70-503. Till then, watch the World Cup. And mute your television, because that bee-swarm sound is just getting more irritating.

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

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

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 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