Deploying JavaBeans ~ some issues



   Components: behaviour is modifiable
   Trade-off: function and adaptability
   ~ 35 Beans in ChemSymphony Beans
   Users notice the GUI components
   Unseen Beans are more important
   Design ReUse builds on Code ReUse 


© Cherwell Scientific Publishing 1998

JavaBeans are software components with modifiable behaviour. The behaviour of any individual component can be modified to varying degrees, some aspects of the behaviour can be altered by the user  at runtime, some by the local administrator, some aspects can be customised by a software engineer when designing an application, and some changes will be most easily accomplished by in effect writing a new Bean. In fact, almost anything can be changed at a certain cost. An important point in designing and specifiying Beans is that there is a trade-off between functional completeness and adaptability. In many cases it may be better to build a Bean that is a basic implementation to which 'bells and whistles' can be added, as opposed to building a component which is very 'feature rich'. Beans can be easily modified and good Beans will tend to re-use code which has already been deployed in other Beans; for these reasons the precise number of Beans in a component suite is a somewhat artificial matter.

ChemSymphony Beans are usually first encountered as visual components. Users notice the GUI elements: the sketchers, renderers, control panels, etc. But much of the true value in ChemSymphony comes from its underlying data model and from the 'unseen' Beans which connect to datasources, which handle file conversions or adapt to different databases,