This article shows how to create and deploy a new RemObjects SDK-powered server application for Windows Azure. It can also be useful for porting existing production applications in the Microsoft cloud.
Before we start, please make sure that you have installed all necessary tools and packages. Please visit this page for more info.
Windows Azure currently supports the following role types: Web Role, Worker Role and VM Role. Our choice is a Worker Role (we don’t use Web Role, as we currently do not need IIS and ASP.net infrastructure to run SDK Server).
To create a simple project, just perform the following steps (I’ve used vs2010, but Azure MSDN articles say vs2008 is supported as well):
1. First of all, let’s create the simplest SDK client and server application. We can do it by using the template RemObjects SDK \ Command Line Server: 
There is no need to create a WinForms Server, because we won’t use any user interface.
2. In the wizard, leave all options in default and press OK. The wizard should generate client and server application projects with an Http channels and the **Bin **message format.
Note:
We should add implementations of two operations that are defined in the RODL. To do this, open and close the RODL file, so the IDE can add other required files to the server project and then add the following code to the method implementation in the …Impl.cs file:
| publicvirtualint Sum(int A, int B){return A + B;}publicvirtualSystem.DateTime GetServerTime(){return DateTime.Now;} |
[](http://blogs.remobjects.com/wp-content/uploads/2011/05/New-Windows-Azure-Project.png)
5. Now we are going to port the RoServer project to the Worker Role project. There are different ways of doing this. One of them is to add a reference from the WorkerRole to the SDK Server project. To do this, you have to make some changes to both projects:
6. In the RoServer project, open the Main.cs file and add the following code: | class ROServerMain {[STAThread]staticvoid Main(string[] args){//…} privatestatic RemObjects.SDK.Server.IpHttpServerChannel serverChannel;privatestatic RemObjects.SDK.BinMessage message; publicstaticvoid Start(int aPort){ serverChannel =new RemObjects.SDK.Server.IpHttpServerChannel(); serverChannel.Port= aPort; message =new RemObjects.SDK.BinMessage(); serverChannel.Dispatchers.Add(message.DefaultDispatcherName, message); serverChannel.Activate();} publicstaticvoid Stop(){ serverChannel.Deactivate();}} |
Here, we have added two static methods and introduced fields for the channel and message. We’ve also made the class public.
7. Now, go to your Worker Role Project and add a reference to the RoServer1 project to it. Then open the WorkerRole.cs and change it like this: | publicclass WorkerRole : RoleEntryPoint {publicoverridevoid Run(){// leave unchanged// …}publicoverridebool OnStart(){// Set the maximum number of concurrent connections ServicePointManager.DefaultConnectionLimit=12; int port = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["SdkEndpoint"].IPEndpoint.Port; ROServer.ROServerMain.Start(port); Trace.WriteLine("Server activated", "Information"); returnbase.OnStart();} publicoverridevoid OnStop(){ ROServer.ROServerMain.Stop(); Trace.WriteLine("Server deactivated", "Information");base.OnStop();}} |
By using Start/Stop wrappers in the channel activation, we avoid referencing the SDK libraries in the Worker Role project.
Notice how we set the **server port**. We need to do so to deploy the application not in an emulator but in the real Azure Cloud. In Azure, all inbound communication happens via endpoints declared in ServiceDefinition.csdef. There are two types of endpoints: input and internal. Input endpoints are exposed to the internet, while internal endpoints are used for communication inside the application. The internal Endpoint should be configured for the SDK server (default port – 8099, port type – tcp, name – SdkEndpoint). You can set the endpoint up via the Visual Studio designer by double-clicking on the Worker Role and entering the Endpoints tab:
[](http://blogs.remobjects.com/wp-content/uploads/2011/05/Endpoints-Setup.png)
or you can edit the ServiceDefinition.csdef manually by adding this node:
Also note that we are using the TCP type. You can read more about endpoints for servers in Azure [here](http://blog.smarx.com/posts/using-other-web-servers-on-windows-azure) (section Background: Endpoints in Windows Azure).
8. Now, all preparations have been done. Deploy your Azure project and start it. If you use a Compute emulator, you will see the following result: [
](http://blogs.remobjects.com/wp-content/uploads/2011/05/Windows-Azure-Compute-Emulator.png)
9. Now you can add logic to the SDK client and direct it to the already deployed Service instance. Or you can just browse the RODL by pointing your browser to http://localhost:8099/rodl to see that the server is working. Feel free to use other channels and messages available in RemObjects SDK in the same way.
Summary
Another easy way to port your SDK server application into Windows Azure is just copying all source code files from an existing application to WorkerRole (except the UI code, of course). In that case, don’t forget to reference all SDK-related libraries.
In conclusion, as you can see from the article, there are no difficulties to porting RemObjects SDK Server to WindowsAzure: it is similar to deploying WindowsService.
