Recently stumbled upon this paper (PDF) talking about ACLs, or Architectural Composition Languages. They're a fusion of two earlier lines of research: Architectural Definition Languages (such as UML) and Object Composition Languages (such as XAML, WWF, or scripting languages).

The goal of an ACL is to have a high-level description of a program's architecture which can also be compiled into a runnable program. The high-level description assists automated analysis, while the 'executability' means changes can be tested immediately.

You would still author the components of the program in a conventional programming language (C, Java, Python, etc), but they would be composed into a complete program by the ACL. One of the expected benefits is that a program can be ported to a different platform by swapping in "similar but different" components.

I've been hankering for something like this for a long time (see this answer I gave on a StackOverflow question a few years ago).

The paper mentions that the researchers were working on a language called ACL/1 that initially targeted Java, but would be ported to support .Net as well. However, I can't find any more mention of ACL/1 anywhere. Has there been any more work done on this? Are there any other implementations of the ACL concept that are available for use or experimentation?

  • 1
    Sounds to me like a big, terribly complicated and expensive enterprisey solution that won't solve much of anything. Feb 28, 2011 at 22:10

1 Answer 1


Though I can see the benefit, I'm not a big fan of such abstract languages. They tend to mostly provide a good generic solution to a very specific problem, lease the ones I have seen. I believe that they cannot become a reality as much as I believe Architects can create rich complex architectures using nothing but a word processor.

This said, I do believe that it will be possible to compose complex systems from already made building blocks. In a sense this day is already here, some invented their own specific language and it works... somewhat, so long as the target application remains in the domain of the first application the framework was derived from.

Problems that can be solved by programming are vast, and as such to create a single language that does all would invariably becomes unbearable. The idea of having an integration language to help different systems communicate with each-other is nice and protocols definitions such as SOAP, Rest, *RPC try to achieve just that. Some are strong fort the dynamic interactions but provide little to handle the data modelling, others handle data very well but are weak to handle the interconnections others yet will describe very precisely the expected behaviour of a system while giving little to no insight as to how it should be done. I guess my point here is that there is always a trade off to make somewhere that will move the framework a little bit further down the road of specialization. Couple this with the vast diversity of domains and application it becomes impossible to anticipate all of them to create a unified view of how an architecture should be expressed. A software architecture is so much more than a static definition of interacting components and this is where most ACL to date fail miserably.

A better approach IMHO would be to create a loosely defined and open model to express the capability of a component in a programatically discoverable way. A good example of this would be a modern GUI editor. Most will allow the creation of new components that include some sort of declarative feature the editor can use to automatically expose the new component for future compositions. Most current GUI editors excel at composing widgets yet offer very little to express the dynamic interactions of these components.

Agent based architecture attempted to tackle this issue but with little success. I think they were ahead of their time as communication was a central component of agent communities yet the protocols and tools to support such communication richness were still yet to be designed.

To my knowledge the best current attempt at this would be Spring Roo. Though it is language specific (Java) it does attempt to bring together separate high level components in a single architecture model.

The expression of a software system's architecture is relative to your point of view; expressing this point of view will invariably lead to a reduction of information. The expression of all the dimensions of a software architecture is ultimately found in the source code but to "see" them requires a great deal of effort.

As a closing argument I guess that the creation of such language is subject to the Heisenberg uncertainty principle applied to software, the more precisely you represent an aspect of the system the more you loose sight of the other aspects.

my 2 cent... for what it's worth with the change rates these days ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.