XML-RPC over BEEP: Building fast, prototyping better

Motivation

In this article is explained how BEEP [1] and XML-RPC [2] over BEEP could be mixed to create new application protocols, rather than just reusing native features provided by BEEP, to quickly prototype application protocols.

Introduction

As you may know, BEEP allows to build new application protocols really fast. This is because many details are already addressed by the protocol, remaining what is usually called "the useful part", that is, roughly, the BEEP message semantics.

Even knowing this fact, if you take every application protocol design, you'll find that most if its definitions are RPC based exchanges: the "client" request some resource, the "server" replies some data.

Usually, while facing the question: how do I fulfil all the application protocol requirement?, the fact is that you don't have too many possibilities:

  1. Take an already existing protocol, an layer on it: HTTP, SMTP, FTP, etc.
  2. Design your own application protocol, defining all the details.
  3. Use a RPC framework, including those ones based on the remote object reference concept. Some of them could be ONC RPC [3], CORBA [4] or ICE [5].
  4. Use BEEP to define your own profile and message semantic.

Choosing a solution in terms of your work

Solutions 1. and 2. aren't, in the most cases, the best solution. First, because it involves many work, and second, layering on top of protocols not designed for this purpose creates many problems. See on designing application protocols [6].

A first impression, in terms of work, using a RPC framework is the most convenient solution. This is because you only have to use facilities provided by the framework. This facilities are defined in higher level terms allowing to produce solutions quite fast, without paying too much attention to details.

However, its main disadvantage is that your problem must be adapted, and many times redefined, to be implemented on top of the RPC framework.

In fact, you "can't get outside the RPC platform selected", that is, you must take it and accept it completely. This usually isn't a good new because you are locked to a vendor specific platform.

Layering on top of BEEP

BEEP allows you to have many of the advantages provided by previous solutions, but without its pitfalls. It is a building block protocol that allows you to re-use really interesting features.

You can start your development by choosing protocol block pieces already working and integrated into a single product.

  • If your application protocol requires peer authentication: you simply use SASL profiles.

    If authentication its a part of the project to be implemented later, that's not a problem at all. You can concentrate all your efforts in the "real work" and then add to your application protocol authentication support without worrying you missed something.

  • If your application protocol requires session privacy: you simply use TLS profile

  • If your application protocol requires a ready made RPC framework: you can use XML-RPC profile.

app-stack

The advantage of this approach is that you design block (or reuse them) to build modern and feature-rich application protocols that won't stop you from adding more profiles, while previously deployed applications keep working.

That is, if you don't like XML-RPC profile that's not a problem. You can use it for the project initial stage and then add a new RPC protocol more fitted to your requirements that co-exists initially, allowing to perform a gradual application deploy.

Mixing the RPC based solution with BEEP

Seems we have two solutions, the RPC based solution and the BEEP based solution, that offers desirable features, but initially, both seems to be mutually exclusive. However, this not applies to BEEP.

The main advantage that comes with BEEP is that you can mix many application protocols at the same time over the same connection. This allows to take the best approach for every part of the application protocol to be defined.

Using a RPC framework, will enforce you to use its invocation semantic, message formats, etc. However, BEEP will allow you to easily add more application protocols that coexist with previous one, as "profiles".

Now, define an application protocol, could mean to define it in terms of mixing the XML-RPC over BEEP profile and additional BEEP profiles required to fill those part not properly addressed.

Conclusion: putting all together

We have seen that building a new application protocol can be defined in terms of a "request-response" pattern, allowing to use "XML-RPC over BEEP", and reuse those parts not provided by this profile like SASL and TLS.

For those part not covered by a "request-response" pattern, or not implemented properly/efficiently by "XML-RPC over BEEP", a new profile can be added to fill the gap.

In fact, even knowing "XML-RPC over BEEP" won't be the profile to be used in the production environment, it allows you to prototype an network application protocol really fast.

Now, it only remains to reuse existing security and authentication features already provided by BEEP to have a modern and robust application protocol.

What's next: starting now!

Check the following XML-RPC manual to start producing XML-RPC over BEEP solution: [2] Vortex XML-RPC over BEEP manual.

References

[1] BEEP Core community site

[2] Vortex Library XML-RPC over BEEP

[3] ONC RPC, Sun RPC

[4] OMG CORBA

[5] ICE Zero conf

[6] On designing application protocols