Research Interests

Interoperability

The issue that always fascinated me most was and is interoperability, i.e. the ability to have distinctly different systems exchange well-formatted (syntax) and meaningful (semantics) messages. This is a very hard problem and in many cases interoperability is more a goal to strive for than one that we could actually reach.

There is a reasonable classification of interoperability and related concepts in the military; in fact, NATO and the U.S. government actually defined interoperability and created a system to classify how good interoperability gets: the four levels are compatibility, interoperability, interchangeability, and commonality.

Interoperability

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

IEEE Computer Directory 1990

Beyond this degree of interoperability it is also quite important to properly scope the application domain of interoperability. For example, two computer systems can achieve perfect commonality on the network transport layer, i.e. TCP/IP, yet be completely unable to interoperate on the application layer. This would happen if you try to use telnet from Linux to create a remote desktop session to a Windows machine.

The holy grail of IT interoperability is obviously commonality for applications. Just as with the finding of the holy grail, this goal is not achievable. Once more, the path is really the final destination.

There are some areas of technologies that enable (or hinder, depends on your view point) interoperability. Of those I am interested in the following:

Web Services

While even the definition of web services is not too precise and varies over space and time, I am interested in applications that are layered on top of HTTP. As far as I am concerned, this is currently the best definition of web services. One special case - that is starting to get some traction - is not covered, though: distributed applications that use the same protocols and patterns as web services, but use a different transport protocol (e.g. SOAP over TCP).

Opinions divide what a web service is. Click here to see some of the definitions.

SOAP (Simple Object Access Protocol) is certainly an interesting technology, although it has become fashionable to dismiss it as too bloaty. Instead, people are looking now more at architectural patterns like REST. Such patterns an protocols will run into similar issues as the prior distributed application protocols like SOAP or CORBA: as soon as applications are starting to use them, they will grow and become more unwieldy and complex.

I am currently looking into making web services more efficient and less complex. There are a couple of promising technologies on the horizon like FastInfoset or EXI (for efficiency). To arrive at a lower complexity, it seems important to me to push some of the functionality like security again further down in the stack of protocols. My GSS-SAML proposal is focusing on this.

Security

My interest in security goes back some time. In my first job in the U.S. is was focusing on Active Directory and its security systems. the Kerberos subsystem was quite interesting, in particular since Microsoft decided to use the so far rarely utilized AUTH_DATA field for storing the NT security token. This along with some other profiling issues created a highly non-interoperable system, based on a fairly well understood.

My current ideas, as already mentioned, are focusing on driving security again further down the stack. At the same time, it seems prudent to me to allow for proper application-accessible security. By that I mean that even if the underlying platform deals with most aspects of security, the application developer still needs some configuration options to adjust his application and its security. For this reason, I propose a security stack model, that should allow for a free-flow of security relevant information between the application, the platform, and the underlying layers in the protocol stack.

XML

While XML has its root in the document processing and management world, it became tremendously useful as a lingua franca for interoperability. In these days, most modern systems are capable of processing XML documents - for content or data.

It is really from this interoperability point of view that I got interested in XML. Similar to the TCP/IP family of protocol enabling basic network compatibility and now even higher degrees of interoperability, XML has the potential to become the universal data exchange protocol.

Operating Systems

For a long time, I had a knack for operating systems. Not that I understand a lot about them, but I simply like to play with them. I remember well when I was first standing in a general shop, playing with the exhibited VC 20s and staring to write some simple BASIC scripts. Later I had a lot of fun with a variety of systems, including my C64, my father's office system (much to his dismay - it was a RAND Computers CP/M box) and then with Windows 2.0.

When Linux entered my world, it was at kernel version 0.99.7. I was working in a large datacenter on a Cyber 2000 with NOS/VE and a Cray Y-MP with UNICOS.

Today, I am quite interested in operating systems, in particular in the context of interoperability.