A Manifesto For Component Assembly

Component assembly is the construction of applications by visually assembling and manipulating objects. The method of component assembly is closer aligned with the real world process of building artifacts in which the craftsperson directly manipulates the creation. Component assembly in Java^TM was introduced with the Bean Box and comercialized with Java Studio^TM. The Bean Builder re-examines component assembly with current Java technology. This method of software construction is worth exploring and may be suitable for some development problems which require high domain expertise and lower programming expertise.

The current method of software development shields the developer from directly interacting with the designed artifact by adding a level of indirection - source code. Source code is created, maintained and edited, the source is passed to a compiler which generates byte code instances of the object state and then the byte code is interpreted to realize objects. In a component assembly development environment, you build the application by interacting with the actual objects themselves. Component assembly allows for the direct manipulation of the object graph by assembling an application object by object. In component assembly, there is no distinction between the designed object and the runtime object - they are one and the same. You are building a live application.

One analogy to describe this approach to software development is assembling bicycles. There are many types of bikes in the world many suited for different purposes and characteristics: road bikes, downhill mountain bikes, cross country mountain bikes, BMX bikes, etc... just like there are many different software applications in the world.

I'm fairly knowledgeable about bicycle mechanics (domain expert) and want to build a new bike for dual slalom racing, I know what components work with which frame and the characteristics of a winning bike. I don't know how to design the individual components which make up the bike but I'm educated enough to know the specifications of the components.

The conventional way of programming would require me to write up a specification of that bike (source code), email it to the bike store (compiler) and wait for delivery of the bike that I requested (byte code). This seems like a rather indirect way of interacting and building a bicycle. When I get the bike, I would test it out a little bit and if I want to make revisions, say change the color of the frame, I would have to revise my description of the bike, send it to the bike store and they would send me an almost identical bike with the changes that I requested. Meanwhile, I can only have one bike per description so I would take the old bike and throw it in the dumpster out back. Even if the bike store is next door and they can guarantee a turn around time of an hour, it seems like I waste a little time waiting for the bike to be reconstructed. It also seems to be a waste of objects since I keep throwing bikes in the dumpster. It's a good thing I have a large dumpster since garbage collection is a little costly. At least the bike parts (objects) are recyclable.

The method of component assembly is much more aligned with the the real world assembly of artifacts. If I want to build a new bicycle, I would go to my well stocked garage in which I have plenty of bicycle components (Palette). I specified and bought components which I felt would be suitable for building my bicycle. I start with the frame (root container) and attach parts piece by piece, testing the behavior after I attach them to the bike frame. I can also attach behavior which expresses the relationships between the components, like cables which attach the shifter to the derailuer - in which a change in the shifter position translates to the inward or outward motion of the deraileur. In the software world, I can attach event adapters between visual components in an application so that a button press may invoke a database query. Meanwhile, I don't have to know how to design a shifter or a deraileur in order to make these two components work together.

This brave new world for component assembly will not replace the market for software engineers with component assemblers. In fact, I see a role for both of them. The software engineers who went to colleges to study algorithm design, database optimizations and data structures still have a place designing components that may be as general or vertical as the market requires. The component assemblers are domain experts - people who understand the problem really well but aren't interested in the implementation details of the components. These assemblers are knowledgeable enough to specify and purchase components. The task of the component assemblers is to rapidly translate software requirements into applications.

Component assembly can also be used for rapid prototyping - allowing a greater understanding of the requirements. In fact, with the correct suite of beans, an application can be assembled right in front of the customer in a collaborative manner. The exported design can be extended and maintained by imported it into a complete Java IDE.

There are a lot of potential for component assembly techniques to lower the barrier of entry of Java application programming. Java is now mature enough to enable this reality. It's really up to some smart people to bring it to the masses.

Mark Davidson

The Bean Builder, is a product of Sun Microsystems^TM, Inc.
For answers to common questions and further contact
information please see the java.sun.com Help Pages.