by

On SoA and SOAP and REST with WebBroker

There has been a lot of talk from Embarcadero recently, regarding their RAD Server product, which is an excellent product, but today I’d like to discuss a far older technology included with RadStudio and related products. Web Broker has been in Rad Studio since the 90’s and is a great technology for building middle-ware, let me explain why…

Service Oriented Architectures and Delphi.

SoA (Service Oriented Architecture) is nothing new, but for reasons that I’ll come to in a moment, I feel I should briefly explain what it is.

In short, SoA is the software design practice of separating software components into individual services, each with their own specific purpose and known interface. A SoA solution is built by composing several services which interact with each other, and these services may not all be running on the same machine, they might communicate with each other over a network for example.

It’s very common for SoA applications to also be “n-tier”, in that, architecturally there are multiple layers of services given, often arbitrary, labels or “domains.” As an example, consider an application like gmail from google. Though I don’t know the actual gmail architecture, I can suppose it looks something like this..

  • Client Layer
  • Presentation Layer
  • Mail Layer
  • Calendar Layer
  • Database Layer

The top layer is the Client layer, this is the HTML/Javascript running on your desktop. The client layer calls services in the presentation layer to retrieve pieces of HTML to display. So the presentation layer consists of the HTTP server for example, and any server-side methods which may be executed to generate HTML. Then we have layers for handling the Mail functions of the application, and the Calendar functions of the application, each of which may talk to an IMAP mail server and/or the database layer which stores user account information and so on.

The point here is that each layer of the application is responsible for a specific purpose. The client layer for example should never be generating HTML, it’s responsible for rendering HTML through the web browser, but the HTML is being generated in the presentation layer, never in the client layer. Similarly, the presentation layer should never talk directly to mail servers, instead, it talks to the Mail layer which does the job of talking to mail servers.

When I say that one layer ‘talks’ to another, what is in fact going on, is that services running in one layer are calling upon services running in another layer. Each service should have a well defined interface, such that the calling service is shielded from the implementation behind that interface. So our Client for example might be able to call “GetHTML()” in the presentation layer, but it need not know how the presentation layer generates HTML. In theory, you could entirely replace the services of the presentation layer with newer versions, so long as they support the “GetHTML()” method, the client layer does not need to be updated in order to take advantage of the updates.

I’m sure I haven’t done justice to SoA or n-Tier in the brief description above, but the reason I felt the need to brief you is this: Despite the fact that Delphi has had n-tier and SoA capabilities for around two decades, the vast majority of Delphi applications aren’t using them!

The most common architectures currently used by Delphi developers, according to surveys, are Monolithic and Two-Tier. A monolithic application is a single executable which performs all of the functions of the application, where-as, a two tier application might be a client executable which calls upon a database.  These two architectures have served us very well, but they are also very limiting and usually have high maintenance overheads.

We’ll discuss the benefits of moving to SoA in more detail in a moment, but first, lets discuss some options available in the RAD product set for building SoA applications…

Enter RAD Server

RAD Server is a recent addition to the RAD family of products, and provides an Enterprise grade, turnkey back end for Delphi and C++ Builder SoA applications. It provides turnkey functionality, out of the box, for user authentication, data storage, mobile push notifications, bluetooth-LE beacon tracking and server-side analytics, as well as a strong framework for building RESTful services for your SoA applications.  … But …

With all of the turn-key functionality and large-scale capabilities, RAD Server is targeted at Enterprise corporate customers. It’s very enticing for all Delphi customers to want these features for their SoA applications, but RAD Server’s licensing limitations are met when trying to build solutions for small enterprises, or mass-market applications. In these cases neither the licensing model, nor the particular bundle of included turnkey components, is necessarily ideally suited.

Now, I am certainly not trying to discourage you from considering RAD Server – it’s an excellent product, which I just got done presenting at our IoT Bootcamp. What I am saying however, is that if you’re not sure about using RAD Server or if it’s right for you, then you could start out using something else instead, and I propose you take another look (or a first look if you’ve not seen it already) at WebBroker.  It’s actually quite a trivial exercise to migrate WebBroker REST services to RAD Server later if you should decide you need the power, scale, and features of RAD Server.

Enter WebBroker

Without hesitation I can tell you that the most commonly read posts on my blog are those on building SOAP and/or REST services using Delphi, and they are the most commonly read by a large margin too. Usually when I discuss SOAP or REST services written in Delphi, I use WebBroker as the technology to host those services.

A WebBroker application consists of one or more “WebModules”, the primary purpose of which is to host one or more “Actions”. Building your service means creating new actions, configuring them to be called from other services, and then hosting them inside a server. WebBroker provides several options for this server including “StandAlone” an embedded HTTP server, “ISAPI” for hosting your services inside Microsofts IIS server, and “Apache Module” for hosting your service inside an Apache Web Server.

One of the nicest things about WebBroker for development is that you can easily move WebModules (and therefore the associated actions) from one type of WebBroker project to another. So you could for example build an ISAPI IIS plugin, and later migrate it to run on Apache instead with very little change to your project. Consider that with the new release of RAD Studio / Delphi or C++ Builder having Linux support available, you might also host your WebBroker services inside Apache on a Linux server.

Unfortunately, the same flexible-server feature of WebBroker that I’ve just praised, has also lead to some confusion, and historically some unjustified criticism of WebBroker. You see, WebBroker has the ability to host services within an embedded “StandAlone” HTTP server. This HTTP Server is NOT by any means a feature rich HTTP server, nor is it able to host large scale applications. Delphi / Builder users that have built WebBroker services as “StandAlone” have complained about these limitations of the technology, but are perhaps missing an important point.

The “StandAlone” option for WebBroker was never intended to be used for large scale hosting of WebBroker services! In fact, it was intended to be used almost exclusively for debugging web modules locally before migrating them to IIS or Apache. The fact that “StandAlone” wasn’t named “Debug” or something similarly descriptive of this intention, is because the “StandAlone” option could also be used for small scale services within smaller enterprise. Using “StandAlone” in these limited scenarios would prevent you having the need of a full scale HTTP server and the maintenance associated with that.

So having addressed this criticism of WebBroker, what can it be used for?

Well, you can use WebBroker to build services for almost any scale of application from the very small to the very large, in fact, anywhere you need a web service. The technology was the underpinning technology beneath DataSnap (the SOAP and State based fore-runner to RAD Server), and it’s the underpinning technology beneath RAD Server it’s self. You see, WebBroker is simply a framework which allows you to expose your code to a HTTP server, and so anywhere a web-based service might be used, WebBroker may be used.

WebBroker does not provide you with turnkey components such as user authentication, or beacon fencing, in fact, it’s quite a thin framework over the HTTP protocol, to the point that a criticism of WebBroker is essentially a criticism of HTTP, and that surely can’t make sense today right?

Advantages of going SoA

So before I close out this post, I wanted to come back and simply list a few of the advantages of migrating your application to a SaO architecture.

  • Centralization.
    Your application may be centralized to one server, or a server farm, or even to a wide cloud. A client layer of your application is installed or otherwise delivered via the web to your users, and is then able to connect up to your server(s). Should you need to do heavy processing within your application, you can shift this processing to the server and there-by reduce the hardware requirements for your customers or users.
  • Ease of Maintenance.
    If your service interfaces are sufficiently designed, you need not distribute a new client application to your customers in order for them to benefit from maintenance or even feature enhancements to your software solution. Simply update the service software running on your servers and your customers immediately get the update without the need of a software roll-out.
  • Scale.
    SoA architecture is flexible in scale such that in order to service more customers, you need only provide sufficient server side resource. The scale of a SoA application is easily expanded.
  • Multi-Technology (Multi-Target, Multi-Compiler).
    Any one service in your application need not know what computing language was used to build some other service. You can easily interact between services written in Delphi or C++ Builder, with other languages such as C#, Java, Javascript and so on and so on. Leveraging your entire code-base, regardless of the language it was written in.In fact, you could create multiple versions of the client application for different use cases. For example, you could provide a fully fledged desktop client for your application on Windows and Mac using Delphi, a Mobile version of the client also using Delphi, and then create a web based client using HTML and Javascript. Each of the clients needs only to know how work with the service layers of your application, so you don’t need to re-implement your application in multiple different languages for multiple targets.
  • Licensing protection.
    Is piracy or revenue protection a concern for your application? SoA applications distributed over a network will only function when connected to the network. This eases the concern of validating the licensing of connecting clients. It also points out the biggest disadvantage of distributed SoA applications, in that they will only function when connectivity is available between services.

Using WebBroker

In the coming weeks, I’d like to explore the capabilities of WebBroker in more detail on my blog, but for now, having either introduced you to WebBroker, or having reminded you of it, I’ll refer you back to some of my previous posts which you may not have realized made use of WebBroker…

As always,

Thanks for Reading!