Encrypt your C# and VB.Net DLL files to protect your code from decompilers, competitors, hackers, and viruses.

Assembly Lockbox... The anti-Decompiler.

Introduction

Long before you start coding your applications you should first design a stable and capable architecture. This architecture should designate what are the various components of the system and what needs they satisfy. Another name for these needs is requirements. Knowing your requirements allows you to determine what components are needed and why. Each component should contribute to fulfilling a requirement or else it should not exist. When the requirements demand either 1) expandable traffic and/or 2) near 100% uptime then you are best served by architecting your system to use a server cluster and software that takes advantage of it.

Server clusters fullfil both scalability and availability by providing a framework for modular expansion and stateless execution. Modular expansion means that you can add a new pc to the cluster easily, thereby expanding its ability to handle more traffic. Stateless execution means that the servers can run at full speed because they do not store data in RAM between calls which keeps RAM from running out and also a call can be handled by any server instead of waiting in line for a certain server to become available.

In the world of Windows the most basic technology that provides the ability to build server clusters is called NLB (Network Load Balancing). NLB allows Windows servers to coordinate to share the handling of traffic coming into the servers from clients. With NLB servers can be added to the cluster easily and it has settings that allow you to tell the NLB cluster to remain stateless. For the stateless execution to be complete you must also write your software that will run on the servers to be stateless by not storing data on the cluster servers between calls. You might be asking "Where do I store my data between calls then?". Instead of saving data on the cluster servers between calls you simply save all data in a database and cache as much temporary data as possible on the client.

Setup the hardware

As with most things in the computer world there are many ways that a system can be setup. The way I present here is specifically geared towards setting up an infinitely scalable, database driven, three tier network. The clients can be web browser based using XML web services, web browser based using older style post backs, or PC applications such as .Net Smart Clients. When refering the the operating system I am specifically talking about Windows Server 2003 Web Edition up to Enterprise Edition. NLB does work on older Windows Server operating systems and probably will be part of the next Windows OS as well. The hardware can be anything from $500 PCs you buy at a local computer store all the way up to expensive blade servers. Unlike some cluster configurations that Microsoft supports this cluster setup will not require any special hardware and no hardware will be "shared" such as a shared RAID harddrive. So just regular PCs and regular networking gear such as routers and switches will do.

In this setup each cluster PC node has three network cards (NIC). Each network card will be wired to a physically seperate network. The term for using more than one network card is "multi-homing". By having three different network cards you get better and finer grained security, higher performance since networks are not shared with other office traffic, and a more stable cluster.

The first network card in the illustration above is the "Internet NIC". This network card connects a cluster node to the Internet router which then connects to your Internet line (in this case a T1 line). With a single server web host you would have port 80 on the router opened and mapped to a single servers IP address. This way all web calls coming into the router from the T1 line will go to the webservers network card. With a NLB cluster however each nodes "Internet NIC" has a unique IP but also has another shared IP which is shared by each cluster node... yep you heard it right... One network card with two IPs. That is not very common outside of clustering, but with NLB clusters it is normal. In this configuration the Internet routers port 80 is open and mapped to the shared IP address (192.168.1.1 in this case). What this does is make it so that when a web call comes in from the T1 line on port 80 it will be sent to all of the cluster nodes, but only one will end up taking the call. Because the nodes will be setup to work in a stateless manner it does not matter which cluster node ends up taking the call.

The second network card is the "Cluster LAN NIC". This network card is also known as the management network. This network connection is used only by the nodes in the cluster and so has no other traffic on the switch which connects the cluster nodes. This card can be used to allow situations where there are resources between cluster nodes you want access to... for example you may want to synchronize files between the servers such as web pages or images. This way you can move files back and forth without adding traffic on the network that is trying to send Internet calls to your cluster as fast as possible. If you go up one step from just NLB to a Microsoft Application Center cluster (another type of Microsoft cluster technology that also uses NLB) then this management network card is used to keep all the files in the IIS servers synchronized between all the clusters nodes as well as maintain a "heartbeat" between the nodes which is used by MSAC to control the cluster. If you are using just NLB and are not interested in allowing the cluster nodes to talk to each other you can get by without this nic.

The third network card is the "LAN NIC" which connects the cluster nodes to a local LAN where developers and tech support can use tools such as desktop remoting to admin the servers. This way you can access the cluster nodes without adding any extra traffic on the NLB network which is trying to send Internet calls to the cluster as fast as possible. You can also set security differently on this nic than what you would have set on the NLB nic which would probably be more restrictive since it is handling calls from the Internet. If you want to use things such as Windows Automatic Updates or web service calls from the cluster nodes to remote servers which are out bound calls and do not want to add that traffic onto the NLB network then you can switch your gateway settings from the "Internet NIC" to this "LAN NIC" and then all out bound calls from the cluster nodes will use the Internet connection on your local LAN instead of the Internet connection going into your cluster. This will free up your "Internet NIC" to only handle inbound port 80 NLB traffic.

So to sum up... You need at least two network cards and possibly three depending on your setup. At minimum you need a network card that connects each cluster node to the Internet line coming into your cluster and this network card shares an IP address with all the other nodes which is used by Network Load Balancing to divy up the traffic between the nodes. In addition you should have another network card that connects each node to a local LAN which gives developers and tech support remote access to the servers. You can also have a third network card in each node to allow the cluster nodes to communicate back and forth ( though if you are not using Microsoft Application Center then you can probably do without this nic).

Single Cluster Node

Eight Node Cluster

Adding web services to the cluster

Create a smart client to call the web services

Building a cluster aware data access library

VirtualPC VMS files pre-setup for a "Cluster in a ZIP"

The default setup for creating a Microsoft cluster works like this...

Setup the Windows OS

 Setting up two Windows Server 2003 servers into a NLB cluster.

Here we are going to setup a two server Network Load Balancing cluster.  

When starting off you need to setup the network connection properties for the Internet NIC network card on each server. In this case we have only two servers so we will start off by setting up the second server and then we will setup the first server. Once we are done setting up the network connection properties on the first cluster server we will then create the Network Load Balancing on the first server. I am assuming that you know how to setup the servers so that are connected to your local LAN with the LAN NIC network card in each server. The IP address range on your local LAN should be different from the IP address range used on the cluster network. Not only should the IP address ranges be different, but also the two networks should be physically seperated by using dedicated switches and/or routers. This seperation helps with security and using dedicated networking equipment makes sure that the cluster is not competeing with the local LAN for network bandwidth.

On the second cluster server go to the Control Panels Network Connections tool. Here rename your network cards so they match your model. For example use LAN NIC for the network card that connects to your local LAN  and use Internet NIC for the network card that connects to your Internet router. Then right click on the Internet NIC and go to properties. In the properties dialog select "Internet Protocol (TCP/IP) then click the properties button. In the TCP/IP properties dialog input the static IP for this cluster nodes Internet NIC. This IP will uniquely identify this network card on this server just like normal IPs do. In this case we will use the IP 192.168.254.151. The Subnet Mask will be filled in for you automatically (255.255.255.0). And you can leave the Default Gateway empty since the cluster nodes should use the Internet NIC only to receive inbound calls from the Internet. All outbound calls from the servers can use either the LAN NIC or the Cluster LAN card instead. In addition since this network will not be used for outbound calls we can leave the DNS settings blank.

Still on the second cluster server we now tell Windows how to prioritize the use of the network cards. Since you have two and possibly three network cards Windows has to choose one to try each time it needs to communicate out into the networks. To make sure that the NLB cluster runs as fast as possible we need to tell Windows to always try the Internet NIC first so that all cluster traffic (which will be most of the traffic) goes out on the Internet NIC on the first try. To do this click the Advanced button at the bottom of the TCP/IP properties dialog. Then at the bottom of the Advanced TCP/IP Settings dialog there is an option called Metric. This metric tells windows how expensive it is to use this particular network connection. The lower the "cost" to use the connection to more likely Windows will jump straight to using that connection for traffic. Just set this value to a 1. Next go back out to the Network Connections window and on the menubar under the Advanced menu option you will see another menu option called Advanced Settings. At the top of the dialog that appears you will see a list of all the network connections on the server. Use the up and down arrow buttons to move the Internet NIC to the top of the list. This way network services (such as NLB) will first attempt to use the Internet NIC for any traffic. Now Windows has been setup on this server to have a multi-homed networking system with at least two NICs. One connects you to your local LAN and one connects you to the Internet router. In addition you have told Windows to give the Internet NIC preference for all network traffic.

Now go over to the first cluster server and do the same setup on its Internet NIC. This time however we will give the Internet NIC the static IP address 192.168.254.150 to uniquely identify this cluster server nic.

Once that is done we can create the NLB cluster itself...

Before getting started creating the NLB cluster make sure you do not have any network connection property windows open from the work you did above. If you do leave one of these open then the NLB creation will fail because the NLB setup makes changes to these TCP/IP settings for you and it will fail if those properties are already open in a dialog. In case you are not sure what windows I am talking about here is a screen shot of one...

To setup a NLB Cluster complete the following steps:

• Open the Network Load Balancing Manager under Windows Administrative Tools. Right click on the Network icon in the treeview and select New Cluster from the popup menu.
• In the Cluster Parameters form enter the Shared Cluster IP Address. This is the address port 80 will be forwarded to from your Internet router. Also give the cluster a name.
• Move on past the "Cluster IP Addresses" wizard step without making any changes.
• Set the shared cluster IP to listen on port 80 and set the Affinity to None.
• In the next step you add the second cluster server to the new NLB cluster. Make sure to select the servers Internet NIC "Interface" or network card to join to the cluster.
• Give the second cluster server a Priority of 2. The first server will get a 1. If you add a third server give it a 3. And so forth... By "Host" windows means a cluster server.
• Now you just wait until the server is merged into the cluster.
• Next you add cluster server 1. You go through the same steps as above being sure to use the first servers IP address, priority, etc... When both nodes are "converged" you are done.

• Open the Network Load Balancing Manager under Windows Administrative Tools. Right click on the Network icon in the treeview and select New Cluster from the popup menu.

• In the Cluster Parameters form enter the Shared Cluster IP Address. This is the address port 80 will be forwarded to from your Internet router. Also give the cluster a name.

• Move on past the "Cluster IP Addresses" wizard step without making any changes.

• Set the shared cluster IP to listen on port 80 and set the Affinity to None.

• In the next step you add the second cluster server to the new NLB cluster. Make sure to select the servers Internet NIC "Interface" or network card to join to the cluster.

• Give the second cluster server a Priority of 2. The first server will get a 1. If you add a third server give it a 3. And so forth... By "Host" windows means a cluster server.

• Now you just wait until the server is merged into the cluster.

• Next you add cluster server 1. You go through the same steps as above being sure to use the first servers IP address, priority, etc... When both nodes are "converged" you are done.

There are three important points that needs a little elaborating here.

First you should be aware that once a cluster node gets added to the cluster then the NLB Manager adds another IP address to the Internet NIC network card properties for that server. This additional IP address is the shared cluster IP. This means the Internet NIC in each cluster server listens on that IP so that they can share the traffic load coming in on that IP address.

Second make sure you understand how a connection is made from the client to one of the cluster servers. In the beginning you have a user on their PC running your application (Windows Smart Client or a Browser app). This application makes a .Net Remoting call or a XML Web service call over the Internet to a particular IP address and Port #. The IP address should point to your Internet router WAN IP address. This is the IP that your Internet router appears to be out on the Internet. The Port # should be port 80. When the call gets to your Internet router then it looks up what local IP address to forward port 80 calls to. This local IP address should be listed in your router as the shared cluster IP. In this example I am using 192.168.254.153. Because all of the cluster servers are listening on that same local IP (192.168.254.153) for port 80 with their Internet NIC connections then any one of them could end up taking that individual call. This is where the "load balancing" part comes in. You can tell NLB Manager how to divide up the traffic between all the nodes. By default it will evenly spread the calls out among all the converged cluster servers.

Third be aware of the importance of the Affinity setting of None. By having no affinity you are making the most scalable type of cluster. When you use affinity you are telling the NLB cluster to track individual users and each time a user call comes in the cluster routes that call back to the same server the user first ended up on with their very first web service call. This can cause some cluster nodes to become over loaded while others go ununsed. The only reason to use affinity is if the software you are running on the cluster maintains state ON the cluster server itself. The reason for this is simple. If the application stores some user session data on the server and then the user gets sent to a different cluster server on their next web service call then that new server doesn't know anything about the session data saved on the previous server the user was on. This storing of state or session data on the server is common with web server apps. In particular the Session object in ASP and ASP.NET stores state data on the server. These types of applications do not work on a zero affinity cluster. To get around this you either must use a networked Session library in your software or you must write your software to store its state in a backend database between each web service call. I use the database method for its stability and so that no new layer of software must be added in on top of everything else that is going on.

 You can see your cluster's heartbeat with Microsoft Performance Monitor

 Using Microsoft Performance Monitor to get live performance measurements of your cluster.

Performance monitor is an application that comes with Windows Server 2003. It can be found under the Administrative Tools menu. PerfMon can get metrics about almost anything in the Windows environment. Processor usages, Threads, Memory, Network traffic, on and on and on. There are four main performance counters I like to see in a running NLB cluster. 1) % of Processor usage. 2) Bytes transfered per second. 3) Current Windows user connections. and 4) Total Method Requests per second. Except for #1 all of these counters come from the Web Service category. #1 above comes from the Processor category. With these four performance counters you can see how many web service calls are coming in... how much of the processor is being used to service those calls.... how many bytes of the Internet bandwidth is being used up by those calls ... and finally how many user accounts are in use by those web services calls. All at the same time graphically. Very nice. Watch the video above to see what it looks like.

Architecture for database clustering

When considering the main benefits of using a server cluster two in particular stand out. First there is scalability. You can add more servers and immediately handle more load with no rewritting of code. Second is reliability. If you have a full 32 node NLB cluster and lets say by some streak of bad bad luck you have 10 servers have harddrives die all at the same time.... with a cluster you are still running. Maybe slower depending on the load at the time of the harddrive failures, but still serving customers. To fix the problem you can simply switch to your mirrored harddrive and then the 10 servers come right back online.

To get these same benefits on the database layer of the cluster system I looked around at various offerings from Microsoft, Oracle, and third parties. I think the simplest way to accomplish this is to write your software to give each user of the system a data property that lists which database servers in a cluster of servers that the users database is located. Then you simply add more and more database servers to handle more load and assign all calls to the cluster for that user to connect to the servers that the users databases are hosted on. What this does is make it so for each user of your system you can decide how many databases their data will be replicated to and on which servers those databases are hosted.

This gives infinite scalability because all you must do is host only as many user databases on a server as that server can handle and you can simply add more servers to handle more load without changing any code. To take care of reliability all databases have at least two copies hosted on at least two different servers in the database server layer. In the data tier of your software you make all your database calls duplicate onto all the servers that the users databases are hosted. For example if you issue a SELECT SQL request to the users database you will first query the users first database server in their list and if that call fails then a retry is attempted but this time against the next server in the users database server list. For another example if you are issuing an INSERT SQL request to the users database then you will issue that request to every database server in the users list. Generally two copies of a database are all that are needed. However you could add more for a higher degree of guaranteed uptime.

Now if you combine NLB cluster servers with a software model that also clusters the access to the data layer in the manner presented above you can continue to scale and continue to increase reliability simply by adding more servers. Even to the point of adding clusters over large geographic areas connected together "virtually" because the users own settings points to a particular cluster and this "routes" the calls over the Internet to the NLB cluster and then the users settings "route" the database calls to the database servers hosting the database the user is accessing. This model can scale to any level needed. You could setup two Windows Server 2003 Web Edition servers each running a copy of SQL Server 2005 Express as a cluster... or two Windows Server 2003 Web Edition servers as the NLB cluster servers and two more Web Edition servers running SQL Server 2005 Express as the database servers for a total of 4 servers all the way up to several 32 node NLB clusters each running 64bit Windows 2003 Enterprise Edition servers along with several more clusters of 64 bit Windows Server 2003 Enterprise Edition servers running SQL Server 2005 Enterprise as the database servers. All on the same model. From 2 servers all the way up to thousands. Without changing any code.

Setup the software

There is more to constructing a cluster than just the hardware. There is plenty of work to be done in the software as well. Depending on how your software is written you could cause the cluster to not function correctly or you can help your cluster scale to any size neccessary. As with the hardware and operating system setup there are many ways you can write your software in a clustered environment. You will always want to make sure the model you are using makes sense for the requirements you are dealing with in your own system. Here I will be providing a model that is very fast, secure, and flexible that works well in environments that have many clients calling methods on the cluster that interact with many databases distributed across a data tier.  First I will handle the software neccessary to connect clients to the NLB cluster servers and then after that I will show how to build the software to connect the NLB cluster servers to the databases in such a way to make the databases "clustered" as well.

Service Architecture

Under most circumstances the best option for hosting your software on a NLB cluster server is to use Microsoft Internet Information Server (IIS). This method gives you alot of functionality and features that are already cooked into the operating system itself. There is also a big bonus on the coding side of things because writing DLLs that are hosted in IIS is much easier than writing your own Windows Service along with all the TCPIP handling. You even can get the benefit of Visual Studio being able to "publish" your web services directly to the server instead of a more complex distribution scenario.  The web services in this model will be using IIS.

As discussed earlier when going over the affinity setting in NLB cluster setup a major consideration when building cluster capable software is "state management". In fact it can probably be accurately called the number one consideration. Load balancing is all about the ability to easily move users back and forth between servers in the cluster to keep the load evenly balanced. This means that a single user in a single session can make calls to the cluster and end up on a different server each time a call is made. What you dont want in a scenario like this is to have users dependant on or tied to any one server. This will either straight up break the application or at least slow the cluster down as the load can not be balanced well because of the need to route users to the servers they are tied to instead of directing calls to the server that is best for load balancing. The approach to this problem I take is to design an architecture that uses stateless web methods. Obviously state or session data must be maintained some where. It is just that in a stateless web service system that data is not stored on the NLB cluster servers. Instead the state is stored in databases in the data tier. So as the code is being written we will make sure that each call to a web method builds up all its variables, connections to the database(s), etc. from scratch.

Over the years web browsers have become increasingly powerful client side application hosts. Web developers have long taken advantage of Dynamic HTML and Javascript to make reasonably advanced client UIs. Now the new term for this technology is called AJAX and is pushing the browser even further. However desktop applications are still far more sophisticated and powerful than browser based front ends. Because of this my example here is going to present a Windows Smart Client application as the front end. With enough effort a Javascript equivilant could be built to interface with the web services in your cluster that also will work with Smart Clients. You could also create seperate web services for the web browser clients or even host a Smart Client in the web browser if you absolutely need to use a web browser. Later in the article I will show how to create clients in web browsers that use Javascript and the XMLHttpRequest object to communicate with XML web services hosted in the same cluster as the Binary HTTP web services.

Also because of the inheriant ineffiency of XML web services compared to binary only solutions I will be using Remoting to communicate between the client and the cluster servers. Due to using fully functional C# Smart Clients and Remoting the communication library will also incorporate data encryption and compression to both protect data traveling between the client and servers as well as compress the data for a further performance increase. Whenever possible more techniques will be employed to further increase performance. The more performance that can be squeezed out of the code the more load the cluster can handle before needing more servers to be added. Much of the performance advantage of Smart Clients over Browser clients comes from the fact that the client UI already exists on the client PC as the application is running instead of being downloaded on the fly (many times over and over) at runtime from the servers like a web page normally is. This leaves just the data itself to travel back and forth between the client and servers and then this data gets compressed to make the process even more efficient. And finally Smart Clients can communicate via http port 80 using Remoting just like a Web Browser can. This is called Binary HTTP communication. Easily passing through firewalls just like any other web page.

Adding web services to the cluster

So what are the parts of a web service hosted in IIS?

• A virtual directory in IIS
• a web.config file in the virtual directory
• a folder called bin in the virtual directory
• one or more dll files in the bin directory

That is pretty much it. Of coarse there are details all over inside those items, but that is the basic layout. So what are some of these details for each of the items above?

Virtual directory:

• The virtual directory can have IIS settings made that determines the authentication type used to access the service.
• An IP access list can be set that prevents clients from calling the service if their IP address is not in the allowed list.
• HTTP Keep alives can be turned on or off

Web.config:

• Settings in the config file tells IIS how to create and maintain the web service.
• Database connection strings can be maintained here.
• Various other settings that govern other functions such as logging for the web service are set here.

Bin folder and its DLLs:

• The dll files in the bin folder include, but are not limited to, the dll that contains the funtionality for the web service.
• A dll file that exists on the client and the server in this bin folder that contains the "component interfaces" that connect the web service to the client side code.
• And any referenced third party library dll files used by the web service dll to add more functionality.

The basic class model for communicating over the Internet using Binary HTTP Remoting is quite simple. Below is an illustration of this model. Lets go over the three main components of this model. From the client perspective we have an object that "stands in for" or "represents" the Remoting Web Service on the cluster servers. This object is called a proxy. Whenever the client code wants to call the remoting web service it instead calls the proxy and the proxy then makes the actual call over the Internet to the web service. A proxy itself is like a faceless formless being. In order to make it useful you connect it to an interface and then call the methods on the interface. These calls do not actually get made at this point. Instead the calls are "captured" and then packaged up with all the parameters passed into the method and this package is sent across the Internet to the web service. IIS and .Net then unpackage this and make the actual call against the web service as long as the web service supports the same Interface used on the client side with the proxy. The result from the web service is then returned back over the Internet and back out of the proxy through the Interface back to the client code that had started the call in the first place. So the steps go something like this...

• Create a proxy object that represents a particular web service by URL
• Cast the proxy object as a Interface
• Call methods on the Interface which get forwarded to IIS
• IIS and .Net create an object from the web service and casts it as the same Interface
• The call is made against the Interface attached to the web service object
• The return result from the call is sent back to the client

Most web developers have never dealt with Interfaces. I first started using interfaces when COM (Component Object Model) was introduced to Windows. An interface is simply a set of functions that go together in a group and are given a name such as IMyInterface. This name represents all of those functions together. It is an all or nothing thing. When you create an interface you do not really add any code, but instead you just create the "shell" of each function that defines what the name of each function is, what parameters to pass into each function, and what the function returns when it is done. So if an Interface has no code in its functions how does it do anything? Well the Interface by itself does not do anything. Instead after you create an Interface you then create a class that you intend on creating objects with and then make that class "support" the interface. What does "supporting" an interface mean? It means that the class will declare that it supports that interface and then it actually implements each and every one of the functions in the interface. Each interface function that the class implements must match exactly each function in the interface as far as the parameters that are passed, the name of the function must be the same, and the return type must be the same.

So why go through all the trouble to create these interfaces (that have no code in them) and then recreate all those same functions again in your class (with code in them this time)? Well the answer can be looked at like this... A physical real world interface we all deal with are electrical outlet interfaces. We have many different devices (classes/objects) that need to have electricity to work. But we only have one or two types of electrical outlets (interfaces) that are supported in each country of the world. So what we do is we decide to standardize all electrical devices to support a small number of interfaces that they can get electricity from. Then we can go to any house any where in our country and plug the electical devices (classes/objects)  into an interface that gaurantees electricity. This way we dont have to have special electrical outlets for each and every device (classes/objects) that we might want to buy from the store. Now this metaphor goes even further. Some times you have a situation where the electrical device (classes/objects) cannot reach all the way to an electrical outlet. So what we do is we use a proxy for the electrical outlet that we call an extension cord. This extension cord is not the actual electical outlet, but it does know how to plug into one and it knows how to pretend it is an electrical outlet by supporting the same interface. We then can plug our Christmas tree into the electrical outlet proxy (extension cord) and now we get it all to work even though the Christmas tree and the electrical outlet are very far apart.

This works just the same way when dealing with objects that are hosted very far apart across the Internet. An object that is running on the client supports an interface that will allow it to talk to a database. Another object that is on a server on the Internet also supports this same interface. But they are too far apart and so what you do is you get out a proxy (extension cord) to act as a middle man to make the connection. So there are two benefits to using Interfaces. 1) is we can plug into many different types of objects that all support the same interface and 2) we can use proxies that give us extra flexibility to jump over distance gaps.

So when we are designing our cluster software we really need to start off thinking about what is the design of our interfaces. What things do we need to plug into the objects on the servers? Or more specifically what data do we need to move back and forth between the clients and the servers? We also need to decide where we are going to define these interfaces. When the client says it is using Interface1 then that MUST be the same Interface1 that is on the server. The easiest way to do this is to define a DLL file that contains only interfaces and then use this same DLL file on both the client PCs and the servers. Then any time you add a new interface or make changes to an interface you distribute the interfaces DLL to both the client and server so they can both plug into each other correctly.

Lets start off designing a very simple interface and a web service class that supports the interface. This web service is not going to do much work. We will just make it return a string that says "Hello Client. From Server.". Following is a small video showing me using Visual Studio 2005 to create the interface in its own DLL file and then a web service that will implement this interface.

 Create an interface and a class that supports it.