I was in discussion with someone recently about how I go about doing my development, which uses a Javascript user interface built using the Elevate Software WebBuilder product, and a Windows service that is written using Delphi XE2. I was asked why I used the RemObjects SDK rather than any of the other mechanisms available. I have used it for many years and it has served me well, so it took a little time to work out what the benefit is – why do I pay money when there are other options “out of the box”?
Okay, out of the box Delphi can create a TCP/IP server, listen on any port, and talk sockets. The protocol used for the data on that port is up to you the developer. While you could just send data, you usually need some means to determine the beginning and end of a packet. If you want to send a string, two integers and a structure, then you have to work out how to send the appropriate data. You could just send it raw, but when you need to change that to three integers later, you have much work to do.
So one way to do this is to use the “out of the box” web server. The Indy library provides an http server and client to do the work and a lot of the protocol code is sorted for you. You can send some parameters in a URL, and attach a “blob” of data. In return, you get some headers and a “blob” (or more) of data. The blobs could be XML, or JSON, or binary, or images, whatever you want. But the processing of those blobs to convert them to data is up to you. You have to prepare the XML to send in a format the server can process, and you have to interpret the results yourself. And the server of course has to look at the data, and work out what you meant. Basically, you have to do a lot of the legwork. Much less than pure sockets, but interpreting parameters is still work.
The RemObjects SDK takes that capability and gives you a “programmer’s view” on top of it. As a developer, you define what you want the names of the functions to be, and their parameters and their types. You use a nice visual design tool, and it then generates the template code for you to fill in, and all the rest of the “how does it get from client to server and back” is handled by it. On the client, you make a function call “just like any other”. On the server, you implement a function “just like any other”. You don’t have to get involved in any of the protocol used. They have over time supported a large number of channels, including pure sockets with the SuperTCPChannel. This allowed you to send messages both ways, and I think that’s now available on one of the http channels too. But they also included an email channel, which I think is now gone, but it shows how it is able to handle the underlying protocols and you don’t care. One of my servers supports two different channel types, one more efficient than the other (SOAP and SuperTCP), but adding another channel is a matter of dropping on some components and building.
Another aspect of a connection that RemObjects takes care of is session management. On a web server that is going to be providing a different response for each user, you have to have a way to know which client is making the requests. There are various ways, but with RemObjects it handles this for you. You can choose whether to use an in memory store, or database for shared sessions across servers (they have scaling of their part handled already). For example, you can determine with a property that a particular interface must be secure, and you must log in. So you have a login channel that checks the password and if valid creates the session, otherwise it fails. Without the session, the secure interface will not allow access to those functions. And you can customise the session object to have your own data for that client, either a database reference or real objects, so it is able to handle the needs of complex systems.
I won’t claim that it is as easy as falling off a log, but once I got to understand how to hook these things up, it has been really good for me in my work. I use RemObjects SDK to communicate between a “background service” and its “user interface”. I also use it on a system that has to send data out to remote computers, with some systems sending to over 200 server connections. Because it is all at a “programmer level” with simple functions, the coding is very easy, and the plumbing is taken care of by the library. If I come across something odd, there is good support, or they’ve already solved it. When my computer was struggling a little with the 200+ connections, I was able to change one line to switch to a different thread pool mechanism, which restored the performance. One time I had a real issue, and my code was not connecting at all on some systems. Support was good trying to assist, but in the end it was me tracking into their source code that spotted the problem (source availability is marvellous) and it was that I had created a thread pool of zero threads. Oops! I posted the reason on the support forums, and they modified the code to not allow zero threads in future. I was able to fix my bug too of course.
That it supports javascript access “for free” was really nice of course, and it continues to work well for me. Whether it fits your needs, I can’t really say. There are other ways of doing these things, but RemObjects SDK has given me a big step up in functionality for little work. Their http server for example is based on indy, but their code didn’t quite fit my specialised needs, so I just copied their file and modified it. Now my server will spot a server.com/pdf/Inv-GUID.pdf and call my code to return the actual PDF. So you aren’t restricted to what they offer, but you have a solid framework to work with.
RemObjects are also a long term and reliable vendor, and you get the full source. Anyway, that’s why it works for me. I shall show more about how it works in my projects in future blog posts.