Abstract

This report is a study of the developments in the area of component based software engineering. It addresses the technical issues and challenges faced in this context. Beginning with the definition of a component, the report goes through several contemporary component technologies along with their downsides. The report tries to put together some of the key concepts of these technologies along with Architecture description languages to give an idea of the future component systems.

Introduction

Component based software development (CBSD) is becoming increasingly important for large scale software development. Considering the difficulties in coping up with the revolutionary changes brought by the internet, CBSD approach attempts to provide a method of producing software in internet time and which is robust, scalable and flexible.

In response to this demand many technologies such as CORBA, COM, Java Beans, XML,SOAP etc,. have emerged into the market claiming to produce component software. Component definition and related terms are discussed in section 1. Each of the above technologies are briefly described in the section 2. But almost all of these technologies seems to be addressing only a part of the problem.After describing all of these state of the art technologies, section 5 deals with the limitations of them. In my view, Component software development can broadly divided into 2 parts: component development itself and integrating components. Most of the contemporary technologies provide means to develop components but do not directly address issues related to their integration. Until now there is no means to specify the components and their interconnection at an architecture level.

In this regard a seperate set of languages called as Architecture difinition languages(ADLs) attempt to address this issue. These are briefly described in section 4.

The advantages of scripting languages in this context is also included. Finally sections 5 and 6 give my idea of the future component based development.

1. Components and Component Integration

Though there is no general consensus on the definition of a component here i am giving two of the relevant definitions taken directly from [1] and [2].

Definition-1

• A component is a unit of independent deployment.

• It is a unit of third party composition.

• It has no persistent state.

Definition-2

A software component is one which is,

• Ready "off the shelf" whether from a commercial source or re-used from another system.

• Have significant aggregate functionality and complexity.

• Self contained and possibly execute independently.

• Will be used as is rather than modified and must be integrated with other components to achieve required system functionality.

The first definition tells what a component is in its isolation where as the second definition defines it in the context of component integration. Most of the existing component technologies do not follow the "no persistent state" of components. This seems to be reasonable in many contexts. The second definition is a kind of qualitative and it is hard to tell if it is followed strictly or not.

Component integration can be treated as a seperate software engineering practice involving a development cycle. Component integration starts with selecting components according to the requirements, modifying the requirements if necessary to adapt to the components and then figuring out the glue code necessary to integrate them. This can also be considered as COTS based development. There are several problems related to integration of components such as versioning, evolving with changes etc,. Producing robust,scalable and flexible software development have been the ultimate target of component integration. Many technologies are out in the market addressing some of the issues related to components. The next section briefly describes some of them.

2. A description of existing technologies

2.1 OMA and CORBA

CORBA is a distributed object framework based on remote function invocation. It is a middle ware standard following the specifications of Object Management Architecture (OMA). Following are some of the features of CORBA related to components :

• An object is exposed to the outside world using it's interface.

• Language independent communication of objects using ORBs.

• Provides only a set of standars for the middle ware and it is upto the vendors to develop ORBs conforming to these standards.

• Dynamic discovery of the facilities provided by objects is possible with Dynamic invocation interface (DII).

• Since it is only a standard, different ORBs produced by different vendors can interoperate using a standard protocol (IIOP) if the ORBs conform to the prptocol specifications.

2.2 The Component Object Model (COM)

COM is a software architecture that allows software made by different software vendors to be combined into a variety of applications [3]. Though it is supposed to be independent of any programming language, it still requires every language to implement pointers and virtual tables. It implements a binary standard which uses these pointers and virtual tables to point to interfaces, methods etc,. This binary standard according to the inventors of COM is the solution to the interoperability and language dependence problem. An object can have multiple interfaces reflecting the different versions of it. Versioning problem is solved by selecting the appropriate interface through dynamic discovery. COM supposedly achieves cross process interoperability using the RPC framework. DCOM is a development along these lines. Implementation inheritance problem is solved by using containment and delegation mechanisms for code reuse [3].

2.3 The Java Beans Component Model

Java beans is a Java language answer to the component software problem. This model does not claim the cross language interoperability of components but it does porovide a nice framework to develop Java specific components. The model majorly depends on the event based communication of components. Following are some of the key features of beans related to components.

• A component is simply a Java class with persistence.

• A component consists of possibly multiple classes interacting with in it to provide aggregate functionality.

• Components will have visual representation.

• Properties and events take advantage of design patterns to facilitate their discoveries by builder tools.

• Method discovery in interfaces of beans is implemented using the reflection technique which allows to analyze beans properties at run time.

• Unlike COM, a Java bean component can not have multiple interfaces as it just another Java class.

2.4 XML, SOAP and HTTP

This is a rather different approach to component development compared to the previous ones. No middle layer concept is invloved and no interoperability protocols are specified. The main goal is to utilize the existing popular technologies as much as possible. The motivation for this different approach is probably the exponential growth of internet and the ubiquity of HTTP as a proven and successful protocol for communicating over the internet. XML is an extension to HTML and SGML. XML comes into component picture because of it's flexible data representation. Document Type Definitions (DTDs) and XML schemas are some of the key attributes of XML. Following points summarize the capabilities of XML.

• XML supports strong and weak typing.

• It is platform and language independent since it only provides interoperability. If two systems have support for XML, they can easily cmmunicate irrespect of their platforms and implementations [4].

• It is a framework for sharing data.

The Simple Object Access protocol (SOAP) is simply a combination of HTTP and XML to provide cross platform and cross language interoperability. It uses the HTTP request/responce mechanism to achieve the power of Object RPC. XML is used as an encoding scheme. SOAP combines these two and operates with it's own encoding rules. There is no middle layer mechanism involved in SOAP and it doesn't tell anything about mapping of calls to spefific objects. It is upto the implementor to take care of these issues.

2.5 Microsoft .NET framework

.NET is a new framework or platform for building rapid internet based and distributed applications. It uses a mechanism similar to a Java byte code called as Microsoft Intermediate Language (MSIL) to achieve cross platform interoperation. It defines a common language runtime (CLR) similar to the Java virtual machine. It also embraces the XML technology for encoding data.

A component in the .NET framework is represented by an assembly. Similar to all other components an assembly is a unit of deployment with it's own identity. The identity also gives the version information. There can be no multiple instances of an assembly. Every type is scoped by it's assembly and hence there are no name conflicts. There is no concept of registry for assemblies and the underlying system keeps track of their information using certain heuristics [5]. Since the identity of an assembly reflects it's version, there can be several versions of the same assembly running simultaneously. In essence .NET does support version evolution to some extent.

2.6 Scripting Languages

Scripting languages are not directly related to the previous technologies and hence to component development. But they do provide some interesting features which need to considered for component integration. Scripting essentially offers following features,

• Rapid application development

• No strong typing at all and hence all the advantages of weak typing.

• Advantage of interpretation over compilation.

• Clear and flexible software production.

• Can be used as a glue to integrate components

3. Limitations of the State of the Art technologies

Last section gave an overview of the various component technologies currently dominating the distributed computing world. But in a broader sense, do we really consider them as true means to develop and maintain robust,scalable, flexible and evolvable component software..? The answer may not be immediate but from the software architecture research point of view, it is no. The reason is that none of these technologies provide a means to design the applications at an architecture level. There are many technicalities that are implicitly assumed by the developers of the software. For example, there is no way to express how components communicate or interact with others and the developer should be aware of what components interact with what others. More over, a component can only express what it provides and not what it requires. CORBA IDL, COM IDL or a Java bean provide interfaces to components which present only what a component provides. Each technology brought it's own advantages to components along with their dark sides. Following are some of the other issues.

• CORBA services and facilities are yet to be standardized.

• Version problem is not addressed completely.

• All technologies suffer with the strong typing and static intefaces.Strong typing does not allow for flexible software development.

• Although scripting allows weak typing, it is not suitable for large scale development.

Based on the above argument one can observe that there needs to be a change in traditional software development practices especially at an architecture level. The traditional development needs to be modified to accommodate the COTS based development and integration. There is a need for explicit representation of component requirements,provisions and interconnections at the architecture level. The architecture frame work must be able to control and coordinate different components according to the initial design of the system. A set of languages which address most of these issues are called Architecture Description Languages (ADLs). These are the current area of research in component based development. An ADL focusses primarily on the high level structure of over all application rather than implementation details [6]. The next section briefly describes some of the interesting points of ADLs.

4. Architecture Description Languages

ADLs mainly concentrate on high level structure of a system. They provide a way to specify the whole system in terms of components and their interconnections. This specification will be implementation independent and hence the designer can concentrate more on application specific problems. One of the key aspects of ADLs is that they capture the early decisions of design that must be consistent across a family of similar architectures [6].

An application in an ADL is modeled using components,connectors,configuration and tool support. A connector in turn may be considered as a component connecting other components according the interconnection criteria. Connectors may be implicit or explicit depending on specific ADL. Architectural configurations are connected graphs of components and connectors that describe the architectural structure[6]. A description of the software configuration helps to understand the several qualities of the system. The primary qualities related to components are scalability,evolvability and dynamism[6]. certain non functional properties such as reliability,throughput and security can also be assessed using configurations.

The next section describes my idea of how the existing technologies combine with ADLs to produce better component systems.

5. A near future shape of CBSD

Last two sections described about two main aspects. On one side, there are several component technologies that are already in the market trying to establish their own standards in the component area. On the other side component research is coming with ADLs to produce true component based systems. Not surprisingly, the existing technologies tend to accommodate these ADLs into their standards. For example, OMG may decide to introduce a new CORBA ADL to specify CORBA components and their interconnections. CORBA IDL interfaces may be generated automatically using tool support once the the ADL file is ready. Builder tools similar to text editors may come into the market helping to specify architectures. A component interface will reflect both the requirements and provisions. Architecture frameworks will be developed to ensure proper functionality of the system during runtime.

Separate CORBA objects can then be assigned connection oriented tasks. These connectors will be able to handle different data representations of the components they are connecting. Following are some other possibilities.

• Components produced by different vendors with different standards will start communicating even though no global standard is maintained. This can be perceived from the proceedings in the market towards building bridges such as COM aware, CORBA EJB bridge etc., to enable interaction among heterogeneous components. But this is only at a beginning stage.

• Open source software development will gain momentum though the use of internet.

• Software agent technology will also gain momentum with the help of distributed component technology and frameworks.

• Software engineering practices will be modified to address the new challenges posed by COTS based development. For example, there may be another software engineering cycle dealing with the selection of COTS, requirement modifications to adapt to suitable COTS components, COTS integration using appropriate architecture models etc.,.

Although the above mentioned possibilities are likely to appear in the near future, many other problems may still remain unsolved for few more years. For example, in order for a component to use another component, it has to know it's static interface. This is a major constraint which restricts components from freely using meaningful application specific names. The solution to this problem is one of the goals of ADLs.

Components of different versions may not communicate properly. Though several newer technologies including the .NET framework address this issue it is still not comprehensive. It is difficult to offer reliable and robust applications in the presence of versioning problem since the system becomes vulnerable to version changes.

The next section describes my idea of the progress in component based systems after several years.

6. A far future shape of CBSD

This section gives an imagination of the state of CBSD after several years. These are only possibilities that are likely to appear. Following points summarize some of these possibilities.

• Intermediate languages and virtual machines will make the internet a single platform,single language global network.

• No static interfaces : Components can use custom names to use the services of other components and the architecture framework deals with the name resolution using connectors.

• Strong typing and weak typing live together providing clarity whenever necessary.

• No version problems and components of different versions communicate seamlessly.

• COTS integration will be the only fast way of developing large scale software.

• Component standards enable communication among heterogeneous components.

• Robust scalable, flexible and evolvable software can be produced in internet time [7].

• Virtual organizations on internet produce specialized solutions in flexible ways.

• Traditional software engineering transforms itself into component based software engineering.

• Software agents will represent human beings acquiring intelligence and traveling in the global network using component frameworks and distributed object technologies.

Summary

CBSE is still in it's early stages with constantly changing standards and specifications. Existing distributed object technologies and reusable component systems are participating in this rapidly changing scenario. Current research suggests that these technologies should evolve themselves with the support of Architecture description languages to build more robust and scalable software. This integration is likely in the near future. Yet there are many other issues that are open for research and likely to get solved in the far future.

REFERENCES

[1]. Clemens Szypersky, "Component Software",Addison Wesley,ISBN 0-201-17888-5, 1999

[2]. Evan Wallace,Kut C.Wallnau, "A situated evaluation of the Object Management Group's (OMG) Object Management Architecture", IEEE computer Society Press, Los Alamitos, California.

[3]. Sara Williams, Charlie Kindel, "The Component Object Model : A technical overview", Developer Relations Group, Microsoft Corporation, October, 1994.

[4]. Don Box,"Lessons from the Component Wars : An XML manifesto", Developmentor, September,1999.

[5]. Jeffrey Richter, "Microsoft .NET framework delivers the platform for an integrated,service oriented Web", MSDN Magazine, October,2000.

[6]. Nenad Medvidovic,Richard N. Taylor, "A classification and comparison framework for architecture description languages", IEEE computer society, Vol 26,No. 1, January 2000.

[7]. Alan W. Brown, "Large-Scale, Component - Based Development", Prentice Hall Ptr, Upper Saddle River, NJ 07458.