Comments on: Protocol agnostic middleware

By: Snell-Pym » Too many projects

Snell-Pym » Too many projects — Sun, 27 Sep 2009 21:42:49 +0000

[...] my old protocol agnostic middleware idea. "Middleware" is a bit of a dirty word these days, so perhaps "framework" would be better. I [...]

By: Snell-Pym » Middleware

Snell-Pym » Middleware — Mon, 04 Jun 2007 10:12:39 +0000

[...] Once upon a time, I had an idea that middleware should be really easily accessible from different protocols. [...]

By: alaric

alaric — Wed, 04 Aug 2004 12:47:57 +0000

Well, for a lot of simple exported procedures that fall within a range of "obvious" types - integers, strings, floats, lists, sets, dictionaries - mappings to all of the main RPC protocols can be auto generated.

For things not intended to be an RPC protocol, it gets more interesting. You can take two approaches (and I would be inclined to offer both). For example, with SMTP, there could be two interfaces: One where the client obeys the middleware server's conventions, and one where the opposite applies.

The former interface would involve sending email in a format specified by the middleware service. Eg, a message to [name of procedure]@[server] with the body being plain text and containing zero or more param=value strings, with a defined syntax for the textual representation of each of the types supported by the middleware server (perhaps the XMLy thing SOAP uses). This can invoke any exported procedure. The return value of the procedure is serialised into text and sent as a standard email reply.

For the latter interface, if the exported procedure is specially marked as being an SMTP command handler - through metadata, through a naming convention, or just through having a single parameter of type "SMTPEmailMessage", then the message itself is not parsed in any way; it is handed direct to the SMTP command handler to process as it sees fit. This is for use when you do not control the format the client sends the messages in.

In some cases, you will have an RPC protocol that supports some type or concept that is not really supportable by others - in RMI, one could have an instance of a Swing class as a parameter, and supporting that in a non-Java environment would be untenable. Support for such things can only be provided by having special protocol-dependent mappings; if the middleware were written in Java, then exported procedures with Java-dependent signatures would only be available via RMI and not via SMTP.

So there's no need to disallow features that can't be made available over all protocols; and only when a procedure is needed that cannot be accessed by any protocol available to the client under development due to such a feature restriction would anybody need to worry about manually writing protocol mappings on the server.

By: Ben

Ben — Wed, 04 Aug 2004 12:14:41 +0000

All very well and good, but won't each protocol end up supporting only the lowest common denominator of all the other protocols? Otherwise you'll end up writing bindings for all services supported, instead of just one service definition. It's the "little jiggling" that you hint at which is going to be the major problem.

If there isn't a neat way of writing one easy definition for every protocol which supports everything you might want to use, all in one go, then you might as well just implement a private interface which runs on localhost only, and write all the bindings yourself using the pre-existing tools for each protocol. As is done now.

Nice idea though. It would be rather handy.