Components do not necessarily have to be object-oriented and object-oriented software may be written without any components. Lets step back and examine the structure of a program to see how this can be true.
Early applications often consisted of a single large function. FORTRAN programmers were especially notorious for writing huge single-function programs whose control flow consisted entirely of goto statements and the occasional if statement. Such programs were fondly referred to as spaghetti code because if you drew lines following the goto statements to their target, the result would look much like a tangled bowl of spaghetti. As the science of computer programming evolved, structured programming concepts were introduced. Languages like C contain goto statements mainly for compatibility with FORTRAN and most C programming and style guides strongly discourage their use. As object-oriented technologies became more popular, new languages such as C++ and Java were developed to simplify development of object-oriented software.
An object-oriented C++ program, however, can be just as monolithic as a non object-oriented C program. Object-orientation does not imply components. Going in the other direction, components are more likely to be object-oriented than not. JavaBeans components are, by definition, written in Java and therefore bear some flavor of object-orientation. ActiveX components can be developed in several languages, including Java, C++, and Visual Basic for which Microsoft has developed ActiveX bindings. In either case, the use of an object-oriented language does not guarantee that good object-oriented design methods were used to create the application. What all this emphasizes is that there is no substitute for good design. Take some programmers who don't understand object-oriented technology and ask them to develop an application with JavaBeans, and you will probably still get a monolithic application using JavaBeans as little more than replacements for functions in a structured programming language. Start with a good object-oriented architect who understands JavaBeans and can partition a problem into its basic components and object classes, and the end result will be much more likely to turn out as intended.