Two of today's most used buzz-words in the context of software development are the terms Componentware and Distributed Object-System. The combination of both ideas is then called a Distributed Component-System, meaning a componentware approach where the components are distributed across the network. Today's approaches fulfill the application developers' needs only partly. Also, most are more or less cumbersome to use. I want to call such part-solutions like e.g. Corba, Enterprise Java­Beans and others first generation distributed component systems. In fact, Corba has a different origin, but for the moment let me consider it to be a first generation componentware system, too. In this paper I want to identify the requirements that have to be fulfilled to design and implement a second generation distributed component system. One main aspect is behind all of the ideas of second generation systems: a good distributed component system is one that the application programmers don't notice. The open-source project Dinopolis is currently in its early implementation phase and can be considered the first second-generation distributed component system according to the requirements that are identified in the following. Therefore the very basic cornerstones of Dinopolis are discussed at the end of this paper.

Distributed Object System, Distributed Component System, Componentware, Java, Network Transparency Aspects, Robust Globally Unique Handles, Distributed Relations, Middleware, Dinopolis