In this article the authors view component-based development as supporting SOA - in the end your SOA needs services to be implemented and you design components as the deliverables which provide the implementation. Some of the skill being to get the granularity and cohesiveness of the components right.
I believe that this perspective is a reasonable characterisation of how SOA is actually done today. For me the key is you first focus on services, what you need to do in a business sense, then later come to the component designs. [Here's an article about identifying services. Disclaimer: I'm an IBM person, these articles are written by colleagues.]
However, if you wind the clock back I think you will find that Component-Based Development was an approach which predates SOA, and had many of the same goals as SOA. I view as unduly cynical the opinion that SOA is just marketing hype, sticking new labels on old concepts. However there is considerable overlap between CBD and SOA. I just view SOA as being the best collective wisdom we have to date on how to do integration, no doubt as we learn more new techniques will emerge until the overall kitbag merits a new name again.
My personal view is that SOA got momentum because a set of technologies emerged that allowed disparate technical teams within an organisation (eg. an IBM base and Microsoft base) to build components that could use each others services. In other words a level of maturity in how to do components emerged, such that a new label (SOA) was attractive.