Jan 24, 2001
	by Rukmini Priyadarshini

IF THE 1960s saw assembly coding, the 1970s and 1980s saw the procedural approach to software development. The 1990s tended towards object-oriented programming and the new millennium is going a step ahead to bring in componentware orientation.

Software components are changing the way software is being developed and distributed. As each stage matured, the approach to software development had to change to keep pace with the needs of enterprises and processes.

In the 1980s for instance, there was a huge gap between the problem domain and the solution domain in the procedural approach, according to the iCMG CEO, Sunil Dutt Jha: ``Like being asked to perform a differentiation or integration operation on a Kalidas poem''.

Software developers turned to object-orientation in the past decade. But even that approach met with difficulties when the objects could not operate together without major changes. That is, they were not interoperable.

The millennium's move to software components should deal with that effectively and iCMG is pushing the component approach to middleware, in a bid to deal with these problems.

Freedom and flexibility

Imagine if somebody could develop applications without having to worry about where the tools came from (or where they should go in the system). Standardised software ``components'' will enable this approach to software development says Jha.

In fact, the Gartner Group estimates that in 2001, 98 per cent of new applications will be based on component-technology. IDC reports put the software components market at $93 billion by 2003, up from $1.4 billion now.

``Software packets called components have standardised exteriors (public interfaces) that enable them to be easily combined with other components to provide and use services,'' says Jha. Simply put, they are standardised software nuts and bolts that can be combined to serve a function.

Development minus the hassles

Jha likens the approaches to building a pyramid. The earlier approaches would build the pyramid from scratch, sourcing the materials, taking steps to ensure that all the blocks of each level fitted together and aligning all the levels so the pyramid rose block by difficult block.

The component approach to building a pyramid would mean slotting the pre-fabricated slabs according to the architecture to get the pyramid -- minus the hassles of making sure all the blocks and slabs fit together: ``It is taken for granted that they will because they are standardised components.''

``That way, people don't have to worry about the service and business components -- they will only have to write their business logic (applications),'' says Jha. ``But until the component approach comes to the mainstream, we can't hope for interoperability,'' says Jha.

Their standardised nature means the software developer need not worry about the component being interoperable with software from other platforms. ``Different softwares can be integrated in a plug-and-play manner.''

Value proposition

Can software components do more than agree to agree? Apparently, yes. Components have a deafening value proposition: They cut costs because they are re-usable, they reduce time to market and reduce development cost.

Reusability is componentware's biggest value proposition.

It is all very well to talk of using the components approach to develop software... But over 80 per cent of the applications do not follow that method. What happens to them. And what about the (legacy) systems already in place?

New for old

For companies with considerable investments in legacy systems, iCMG's services offer some hope. The company offers to ``componentise'' both legacy systems and new ones that do not use CBD in two stages:

The legacy/non-CBD system is ``component-coated''-- or wrapped in an interface definition language (IDL).

These IDL-wrapped products are then encapsulated in a compiler -- the component implementation definition language (CIDL) -- to make it a component. Those components necessary for a single function are put in a container which can interoperate with the outside world through connectors.

Regardless of the legacy system's characteristics, the IDL-wrap brings it into conformity with other componentware. So there is no need to abandon legacy systems or indulge in frequent systems integration to be interoperable.

Who needs component-based development?

``Internet growth is driven by middleware -- the layer connecting business logic (applications) to underlying infrastructure. The component-approach to middleware will be the driving force in the future,'' according to Jha.

Thus, the potential uses of CBD are in enterprise resource planning, enterprise application integration (EAI) and e-businesses (worldwide e-business is expected to reach $3.2 trillion by 2003, according to a Forrester Research report).

Reusable interfaces

When an enterprise has invested in setting up a system, it would not like to let go of the investments without getting the most out of them. So as to get the best of both worlds, several enterprises went in for Web-integration of their legacy systems a couple of years ago. But these Web-integrated systems have now become legacy systems, needing further integration.

The solution? Enterprise application integration. EAI uses standardised middleware frameworks and reusable components to create robust architecture. With such architecture in place, enterprises can concentrate on new applications without worrying about costs and time.

Besides extending the life of legacy systems EAI reduced the time to market for new applications by 25-50 per cent; lowered development costs for integration infrastructure by 25-60 per cent and reduced maintenance costs by 10-20 per cent.

Industry backing

Despite having sold the concept for almost a decade now, iCMG acknowledges that even today 99 per cent of people think component-infrastructure is an abstract concept. They could not be more wrong, says Jha.

Major platform vendors are investing heavily in establishing and marketing componentware infrastructure. Microsoft (COM for the desktop), Sun Microsystems (Enterprise Java Beans), IBM, and the Common Object Request Broker Architecture consortia (for corporate networks and the Internet) have all recognised the importance and implications of componentware for software development.