Jon Udell talks about Component builders and solution builders, and compares the present situation with one he described in his [now legendary] BYTE cover story, Componentware. I've hung onto this issue and like to return to it on occasion to see if it has anything to offer me - either in terms of good concepts that have been forgotten, or patterns to avoid. It's nice to see Udell revisit the article and update the terminology.
I see no reason, however, that dynamic languages like Python are going to stay in purely in the solution (read: glue) camp. Perl, Python, and Ruby are all great for this situation and do far more than mere scripting. They're fully capable for real application building. But they can be the component providers as well. In the Python world, toolkits and frameworks like Twisted and Zope 3, are powerful component producers as well as consumers. Both Twisted and Zope 3 work well with internet protocols, with Twisted targeted towards many protocols and Zope targeted towards web based ones, and can put up the interfaces (non-user) to data and services, with all the rapid development benefits of Python. Zope 3 and PEAK also use strong component based principals to keep both the component builder and solution builder in the same language and in the same system, while still offering a decent separation of the two halves.