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 ...
