Design In Idl

IDL stands for InterfaceDefinitionLanguage. IDL was originally invented by people from Digital, HP, Apollo and others in the DCE standards in the early 1980's that included DCE RPC. DCE RPC needed a language-neutral way of describing parameters to pass over the wire so that RemoteProcedureCall method calls could be made the functions in another process or a whole another machine, perhaps with a different OperatingSystem or byte order. CORBA (CommonObjectRequestBrokerArchitecture) adopted this idea. Microsoft ComponentObjectModel improved on this idea with ORPC or Object RPC which added an interface attribute to IDL to support objects.

It's worth noting that there are IDL's other than those used in CORBA and COM. The statements made below may not be true for any one of these other IDL's

IDL is just declarations, and basically it has two types of objects. *structs* are client side objects and *interfaces* are server side objects. The rules which IDL enforces are

client side objects can only have attributes, no methods
methods have to be on a server side Object, potentially a singleton
strong typing everything
arrays of Objects/types are allowed

The usual enums, typedefs etc familiar to CeeCeePlusPlus are there.

Although I have described this as being "client" and "server", this is not tied to a client/server architecture. Client is the code using an Object Layer. Server is the code which makes up the Object Layer. No TCP/IP if you don't want it.

I realize that it is slightly weird. UnifiedModelingLanguage might be better, but I find IDL more precise. This way we can throw around object definitions very quickly, being precise, but light weight as IDL does not have any method code.

We've used this in Ensembl (http://www.ensembl.org) and more deliberately in a daughter project, Apollo http://www.ensembl.org/Docs/wiki/html/EnsemblDocs/ApolloProject.html

This page written by EwanBirney in a floating an idea mode. Feel free to tear it to shreds if you like.

I don't like the emphasis CORBA/COM places on "Design First" which seems too much like BigDesignUpFront. But I do like the way InterfaceDefinitionLanguage concisely describes a component orientated architecture. Good design has a lot more about a sort of fluffy "vision" thing and then letting good people write good code than anything else. -- EwanBirney

What's the rub? How is this different from design with a header file in CeePlusPlus? I think the important concept is to be interface-centric in your designs. A lot of people propose DesignWithInterfaces. If InterfaceDefinitionLanguage helps you achieve this, that is great. However, if you are not using CORBA or DCOM (or some such) you are probably wasting precious time. Why? Because the important idea is to not violate TheSourceCodeIsTheDesign with DesignWithInterfaces but to instead unify them. FWIW, I find that I really like to specify the contracts (i.e., pre and PostConditions) for each interface member. In JavaLanguage, iContract provides you with a very nice way to do this. -- RobertDiFalco

I think this is precisely CodeTestFirst?, although CodeTestFirst? works with OptimisticallyTyped? languages as well.

The amount of the language you get to use in writing a TestCase is about the same as that provided by an InterfaceDefinitionLanguage.
In setting up the TestFixture, you are generally creating object structures ("client side objects expose attributes")
In executing the test, you are sending message ("server side objects expose messages")

The rub is that with InterfaceDefinitionLanguage, parameters are marshalled across the wire to processes on the same machine or other machines. The marshaller creates a proxy stub pair to communicate over the RPC channel and accounts for differences in OS, machines and byte order. This is vastly different from a CeePlusPlus header file. Of course, you wouldn't use IDL unless you were using CORBA, COM or RemoteMethodInvocation. In regular programming like in JavaLanguage, InterfaceBasedProgramming is probably a great idea though.

So, am I right that InterfaceBasedProgramming is isomorphic to CodeTestFirst?? -- KentBeck

Please define isomorphic. Does it mean orthogonal to?

It means "the same shape as".

I think that CodeTestFirst? and InterfaceBasedProgramming are not identical, but are both kinds of the same thing, which we could call SpecifyBeforeImplementation (and who could argue with that!?), but with a strong sense of "specify", since the implementation cannot drift away from the spec without something very obvious breaking, unlike the situation with UML-on-paper "specifications", say. -- KeithBraithwaite

Right. In ComponentObjectModel programming, it means SpecifyBeforeImplementation. You specify the interfaces. You don't implement them. Then you CodeUnitTestFirst for each of the interfaces before implementing them.

Question: in this scheme which is the definitive artifact, the interface or the test? And, welcome back, nice to see you again. -- Keith

Thanks. I would maintain it's the InterfaceDefinitionLanguage. One of the most basic reflexes of a CeePlusPlus programmer is to begin the coding phase in a "dot-H" file. It is here that the C++ programmer typically begins defining both the public operations of his data types as well as their core internal representations. When working on an exclusively C++-based project, this is a completely reasonable approach. However, when working on a COM-based (or CORBA), this approach usually leads to pain and suffering.

The most fundamental concept in COM is that of SeparateInterfacesFromImplementation. Although the CeePlusPlus language supports this style of programming, it as very little explicit support for defining interfaces as separate entities from the classes that implement them.

It is common for novice ComponentObjectModel developers to forget that interfaces are intended to be abstract definitions of some functionality. This implies that the definition of a COM class should never betray implementation details of one particular class that implements the interface.

It is important to note that COM IDL is not a ProgrammingLanguage and probably is not all that new to people. IDL does not have constructs for writing executable statements. IDL is an attribute-based DeclarativeLanguage and only has constructs for defining COM-compatible data types. Also IDL inherits its syntax from CeeLanguage, making it familiar to the large number of C, C++, and Java programmers today.

You could write COM code for hours without a single executable statement. This is consistent with the COM way. The interface (not the class) dominates the COM design style. Simply hacking together some methods and data members won't work any more. And one must be aware of network round trips when designing their IDL.

My point is that the test expresses everything that's in the IDL and more. Let's try it - I'll write the test for a Point and you write the IDL.

 testTranslate() {
Point p= new Point(0,0);
Point result= p.translateBy(1,-1);
assertEquals(new Point(1,-1), result);
 }

Right, the test helps define the interface. If there weren't a test, there would have to be something that defined the interface such as a written set of requirements. IMO a test is the way to go because it helps you see exactly how the interface will be used at runtime.

-- DrewMarsh

One thing that happens here is that people are very resistant to using CORBA objects anywhere except in the IDL. Instead they create a ParallelHierarchy? and convert back and forwards between the two.

As far as I can tell, the argument is that the code internals shouldn't depend on the interface. Am I missing something? Or is this just YouArentGonnaNeedIt?

-- BenAveling

I see this a lot too, and it does seem wasteful. But often it is simply because the programmer's mental model of the problem doesn't match that of the InterfaceDefinitionLanguage designer. Also, the programmer may have a better idea of The Right Way to implement the system, but cannot get the IDL changed. IDL is generally defined and jealously protected by architects, without regard for how the system really needs to work: see ArchitectsDontCode for more discussion of this problem.

There are also times when the lifecycles of the "implementation objects" don't match the lifecycles of the "CORBA objects", or when there is some other serious mismatch between what the client sees and what is actually going on inside.

-- KrisJohnson

Many modern ORBs reduce the cost for same address-space calls to the cost of a virtual method invocation (more expensive for same host, and more again for other-machine calls). CORBA can be used to define library interface for code that will be transplanted to another host (again, you'd have already have to be fairly certain that this was a likely result up front). -- JamesPreston

CategoryCorba