Component-Oriented Thinking (Page 2)

<< Page 1 (Introduction & Message Forum)

Component-Oriented Thinking

So why should component oriented programming be taken seriously?

Component oriented thinking has been gaining acceptance in the literature over the last 5 years. A look at the OOPSLA conferences shows that the number of papers being presented on the subject has now overtaken object orientation. Another reason why component oriented thinking should be accepted is that standards like Web Services have embraced the new idea. Web Services provide a language neutral means of remotely invoking a service.

Web Services lie somewhere between RPC and ORBs in their nature. RPCs are similar to Web Services because they expose functions that can pass data and structures to and from services. ORBs are similar to Web Services because each service has a collection of behaviours. In Web Services, you cannot pass behaviour with the data or structures and you cannot pass a service as a structure. Data and architecture are separate. The next big thing being hyped by the large vendors is not object oriented - it is component oriented.

Apart from web services there are several other important architectural components that have become more component oriented. Looking at the development of Java persistence shows Java very gradually becoming more component oriented. From EJB 1.0 to EJB 2.0 there has been an acceptance that remote and local beans are necessary. The introduction of JDO shows an acceptance that a general set of interfaces can be used to persist objects without specifying the implementation; as EJB does.

Part 2 of this series outlined Java's chequered history of persistence and display and concluded that it followed no clear strategy. It was suggested that a better way to have developed the multiple persistence API's would have been to extend the beans specification to include a set of data and architectural interfaces.

Frustratingly, the history of the Beans APIs is that they were jumped (or pushed) into supporting the integrated development environment (with Bean Context) rather than being extended into component oriented design.

This diversion led to EJB being developed, the limitations of which are now becoming apparent from the readiness to embrace JDO as a simpler alternative. The recently redeployment of the JDO implementation effort to develop web services raises serious questions over Sun's commitment to developing a simple Java persistence layer.

>> Page 3 (Data Binding)

<< Back to Programming

<< Back to Software Reality