If I'm reading this correctly (as the terminology always seems to evade me) you're talking about specific design patterns. Request objects, transfer objects, interface design and abstraction.

For instance, a controller class that handles incoming requests that are sent via a request object and passed along to an instantiated class (with the same interface) which handles the actual work and then returns a transfer object which is passed back to the client.

Perl doesn't really need that many layers, or, more truthfully, it already has them. You can define hashes (or particular objects) to be transfer and request objects, dynamically instantiate and pool particular instances of that class, process it, manipulate the hash and return it in a specified way.

There really is nothing new to component-level design, it's simply a new word on a practice which became more acceptable when OOP (and Java) elevated itself past the necessity to make "lightweight" code. It's quite memory-intensive, but highly maintainable and flexible.

True "components" or "containers" in Java are really just lifecycle maintenance shells to be able to do things like having pools of objects available. (e.g. Avalon)