Component-Based Development (CBD) is a novel software development methodology that has been endorsed by, and is being actively supported by over one hundred leaders in the technology industry today. Authoritative sources (Gartner Group and Butler Group) estimate that the paradigm shifts from conventional development techniques to CBD methods will last many more years and accordingly, by the year 2000, the predominate large-scale software development methodology will be CBD. In this chapter, we will explain the background information and the critical importance of component technology for quality software development and its various techniques, characteristics and design principles. Also we have discussed about a couple of interesting epoch-making applications. Finally there is a brief overview of Enterprise JavaBeans (EJB), an elegant server-side component architecture being promoted ambitiously by Sun Microsystems, and how EJB plays a leading role in CBD, especially on designing portable, scalable, flexible and reusable software components for server applications in a distributed computing environment.

Latest developments caused by several events have shown how thoroughly the world has come to depend upon quality and state-of-the-art software products. Various viruses have been doing immense damages and hinted at a dark side to the information-rich Internet and e-business. The Y2K disaster could be averted only because countries around the globe spent billions to ensure their critical software Y2K-compliant.When denial-of-service attacks shut down some of the largest web sites, there were a lot of disruptions and frustrations were visible on the customer side apart from affecting the stock market prices of the targeted sites. Indeed, as software plays an ever-greater role in managing the daily chores of modern life, its economic importance becomes proportionately greater on the market side.

Yet despite its critical importance, software remains surprisingly fragile, prone to unpredictable performance, dangerously open to malicious attack, and vulnerable to failure at implementation despite the most rigorous development processes, and in many cases software has been assigned tasks beyond its maturity and reliability. This indicates the greater necessity of preserving the quality consciousness state of the software being developed using different paradigms.

Software development is all about managing risks to the development effort. Understanding the problem that the software is being built to solve can best mitigate these risks. The success of a development effort can best be measured by how well the end result meets the original product expectations, usually expressed as requirements. It is important to quantify the expected use of the system as early as possible in the development phase so that the software can be adequately tested and validated and the resultant product set can have the best chance of solving the problem for which it was originally designed. The architects have to define the design constraints and be confident of the related hardware, software, languages, compilers, their versions, and so forth. Apart from these, the software products thus designed have to be flexible, manageable, scalable and can be accommodative of future requirements.

Further on, the process of software development is crucially depending on several factors, such as time, cost and product, and the domains get enlarged as days go by.The future holds an enormous increase in complexity over the horizon as every conceivable device becomes connected to everything else – not only computers and trains, planes, and automobiles, but also appliances of types, from refrigerators to information generators and receivers.Recently we are hearing that mobile phones, personal digital assistants and portable gadgets are also being connected to the Internet.Thus there is a greater role for quality software for not only computers but also for the electronic instruments with tiny memory chips.

Before entering into a discussion of component-based software development, we would like to define the term called software component.

A software component is a unit of code that implements a set of well-defined interfaces. It is a manageable, discreet chunk of logic. Components are not entire applications – they can not run alone. Rather, they can be used as puzzle pieces to solve some larger problems.

But the idea of software components is very powerful. A company can purchase a well-defined component that solves a problem and combine it with other components to solve larger problems. For example, consider a software component that computes the price of goods. Let it be called a pricing component.On supplying the relevant information about a set of products to this particular component, the component will come out with correct price on the basis of various pricing rules such as base price, discounts on quantity and quality of materials purchased, overhead costs, etc.Thus, instead of wasting the precious resources by writing their own sophisticated pricing engine, each company or industry can make use and reuse of a generic pricing component provided by a vendor.Reusable components are quite enticing because components promote rapid application development. The IT (Information Technology) department in industries can quickly assemble an application from prewritten components, rather than writing the entire application from scratch.

Hence the advantages are:

• The IT department needs less in-house expertise. That is, it can consider the pricing component to be a black box, and it does not need to know what algorithms and techniques have been used inside.



• The application is assembled faster. The component vendor has already written the tough logic and the IT department can leverage that work saving its own development time.

There is a lower total cost of ownership.The component vendor’s cash cow is its components, and therefore it must provide top-notch documentation, support, and maintenance if it is to stay in business. Because the component vendor is an expert in its field, the component generally has fewer bugs and higher performance than an IT department’s own solution. This reduces drastically the maintenance costs.Thus, once the rules of engagement have been laid down for how components should be written, a component marketplace is born, where vendors can sell their reusable components to companies. Above all, the IT department can replace the old components with new components, which are technically high, uses different semantics, and more adaptive to the users expectations. Thus, usage of components can really make a point in a digitized society.

The beauty of components is their power and ease of use. Virtually anything that is available as an application is also available as a component and most of these components can be integrated into a new application with little conventional programming. The range of available components is stunning. There are components for 3D modeling, viewing, and editing spreadsheets, full-featured word processing, creating and editing graphics, creating and playing sound files, communicating with other computers through a modem or the Internet, geographical mapping, reading bar codes, and virtually anything else one could imagine.

Visual Basic is the first language that supported component-level programming and the other primary programming languages that support component technology are Visual C++, Java and Delphi. A traditional application consists of an integrated set of routines that solve several different problems. Component-level programming divides the same application into separate components, some of which are developed locally, and others that developers purchase from a component vendor. Thus component tends to be more versatile and easier to use than traditional software packages.

We are to talk more about the components below. To make sense of them, it is helpful to have an understanding of the context in which they arose.

Since its inception, computer programming has taken a natural pace of evolution, from using complex machine instructions to high-level comprehensible procedural language abstractions. Further advances in this field have led to the development of different programming styles that attempt to mimic the way things compute in the real world. In the early days, there were a number of models, such as procedural, modular, and structural programming, for designing both application and system software.Correspondingly there were different programming languages that helped to design software conforming to those models. In the mean time, many technologies came and faded away without making any substantial impact on this topic of software design. They happened to be just buzz and could address some specific issues. Recently two new interesting paradigms known as object-oriented (OO) programming and component-based software have emerged as a natural way of modeling real-world entities and computations.

Object technology is a powerful modeling paradigm with important mechanisms for handling complexity. Any process redesign that deals with a complex problem can benefit immensely from such a modeling approach. Object-oriented programming occupies the central place in software design using OO programming languages like Java, C++ etc. The object-oriented paradigm allows applications to be designed in the contexts of objects, as opposed to processes. These objects, once designed and created, can be reused partially or wholly to create other objects. Thus, a new object may never have to be designed and created from scratch again, since there is probably already an object out there, from which it can be derived. The advantages offered by object technology include improved software quality, economic gains through the use of reusable objects, shorter project development lifecycles, and the creation of truly distributed software across heterogeneous environments. Object technology is not only a buzz but also a clear spark withstanding the pulls and pressure of various factors related with software design and promises its stay in the field for a longer time.

Similarly, deployment of applications has evolved from a single address space computation to cooperating processes on a single host machine and to remote address spaces linked over a network media and protocols, giving rise to the client-server paradigm of computation. At the core of this paradigm is the natural aspect of distributing computational services that can be sought from remote clients. Thus, distributed objects and software components over a network become the next step in the process of evolution.

A spark happens when the entire industry or at least a substantial group of opinion leaders suddenly and synchronously clicks on an idea and determines that the idea is going to change forever the way the industry do business. Sparks can hardly occur more than once a decade or so. Among the sparks, such as the stored-program computer, Windows and object technology, in the software industry circles, component-based development (CBD) is the most likely one for the years to come. In the next section, we are to discuss about the principles of CBD.

In the realm of object technology, components are collections of objects that have well-defined properties and interfaces, and can be embedded into frameworks or containers.Increasingly components are being employed as the basic unit of reuse. The properties and interfaces allow manipulation of underlying capabilities. The granularity, scope boundaries and internal cohesion are important attributes of components. A fine-grained component will be simple to upgrade, have fewer relationships but will require more management because there are likely to be many more parts to meet the requirement. In contrast, a large-grained component will be easier to manage but will require more effort to modify and implement and, because the scope of the functionality is much broader, the impact of change is much greater.

The larger granularity of components compared to individual classes seems to be easier to reuse. The enhancement of functionality by composing or aggregating components avoids the fragile base class problems of inheritance.

Component-based development in a way is building of software systems out of prepackaged generic elements. Component technology is often being viewed by potential adopters with a sense of foreboding. There are many new ideas to understand, numerous techniques to master, and countless pitfalls to be avoided in order to attain success in this ever-growing domain. The current excitement about CBD results from the convergence of the following phenomena originating from quite different backgrounds:

• The progress of modern software engineering ideas with their emphasis on reuse



• The widespread success of practically useful techniques for building nice-looking graphical user interfaces (GUI), databases, and other parts of applications out of components



• The arrival of interconnecting technologies like CORBA, DCOM, RMI and Enterprise JavaBeans



• The evolution of object technology that provides both the conceptual basis and the practical tools for building and using components


• Enterprise resource planning systems (ERP).

The above elements make the software industry to take CBD ahead towards its logical ends such as controlling the costs of developing software products and boosting their quality. This makes it imperative to reuse of standard components rather than the still dominant practice of doing too much from the scratch. Also current ERP products are monolithic in nature, very high price and they need costly installation and customization. Only through componentization (which we discuss below), the future ERP systems can continue to compete in the thriving market.

Object technology provides the most relevant technical basis to attain the grand aims of CBD. Hence the object-oriented libraries and frameworks developed in OO languages provide components in their own right. CORBA and DCOM components are being designed as objects using the OO principles. The much wanted encapsulation principle gets fulfilled nicely by the separation of the interfaces of the CORBA objects from their implementation by OO languages.Thus it is more correct if CBD is labeled as the technological evolution of object technology not as the next best thing after objects.

In this section, we will give an overview of objects [Saba Zamir], business objects, distributed objects, components, Web components and distributed software components.

Much research in software engineering and programming languages has focused on the development of implementation methodologies that are simple enough to allow a programmer to easily produce software that meets the implementation goals, such as robustness, adaptability, reusability, and at the same time are powerful enough to allow a programmer to fully express efficient, mission-critical and innovative high-level solutions. Achieving such a balance has not always been easy, but one methodology that is showing considerable promise in being able to strike a balance between simplicity and power is the object-oriented design approach. Chief among the principles of the OO approach: abstraction, encapsulation and modularity. Achieving these principles requires some specific software techniques. The primary techniques of OO design directed at enabling these principles include classes and objects, interfaces and strong typing, inheritance and polymorphism.

In the most basic form, an object is the joining of data and behavior (or the methods and functions to access and manipulate the data). Typically, objects are grouped into classes and are offered as libraries for applications to use. Any object can be classified as belonging to one of three types: Entity, Interface and Control. An entity object contains the persistent information relevant to the business, and its data. An interface object manages the communication that links the application to outside sources or receivers of information. Control objects are transient objects that contain behavior which does not naturally belong in entity or interface objects.

The promise of reuse of objects has been elusive. Two major problems surfaced: First, the granularity of objects was very low at times. Although this low granularity may have been appropriate within a single application, it became too complex to manage across various applications, projects, and companies. Second, dependencies were created between applications that used the same libraries. If the author of a library made a change to an object or interface, that change impacted the other applications. Thus the arrival of component technology seems to be the best bet in accomplishing this target.

Business objects are most frequently implemented as entity objects. As entity objects they represent the business memory required by the business processes they support. Some types of business objects may be implemented as control objects that represent key business processes or parts of business processes. A business object has a meaningful business name and contains essential business knowledge and rules. These objects must directly correspond to the organization/enterprise they support. A business object, then, is a virtual representation of some real-world business thing, or a computer analog for that real-world thing.

Distributed objects differ from regular objects. First, if the granularity of the distributed object is too low, it might result in reduced network performance that may not impact an internal application using a library. Second, instead of being linked as a part of the application, distributed object is accessed through its interface across the network as a running, executable portion. The distributed object may be moved, restarted, combined dynamically to perform different functions, or available on different platforms. Distributed objects can also contain certain interfaces that enable them to exchange messages as well as to explore each other (through introspection interfaces) in order to discover interfaces and capabilities at run-time. Distributed objects, like regular objects, may support the concepts of inheritance, polymorphism, and encapsulation; however, not all of the distributed object technologies support all these concepts.

Software components are reusable building blocks for constructing software systems. Components encapsulate semantically meaningful application or technical services. Components differ from other types of reusable software modules in that they can be modified at design time as binary executables; in contrast, libraries, subroutines, and so on must be modified as source code.

A component can be provided as a library, a single server executable, or a set of different server executables. Components share similar characteristics of objects and can be either local or distributed, however, they need not be object-oriented implementations themselves. One can think of a component as a piece of software that performs a specific and complete function; a good example is a spell checker. As complete pieces of software functionality, components must also deal with features that one might not consider when using standard objects such as installation, startup and shutdown, persistence, security, caching and proxies, and more. Components that are object oriented typically export a number of classes. Components may work across multiple systems and a variety of platforms, languages, and operating systems. Several useful methodological concepts facilitate reuse in component software:

§         Independence – allows components to be composed without introducing implicit interactions, which may lead to subtle program errors.

§         Polymorphism – allows components with differing implementations of the same interface to be interchanged transparently.

§         Late Binding – allows an application to choose components dynamically.

Component standards specify how to build and interconnect software components. They show how a component must present itself to the outside world, independent of its internal implementation. This single-minded emphasis on external interfaces and interaction protocols distinguishes component standards from other communication conventions. Well-thought-out component standards ensure that

·          components with similar specifications are interchangeable and independently upgradable

·          developers can customize the appearance and behavior of components along predetermined dimensions

·          components can be combined to form larger grained components as well as complete applications.

Thus, component standards play a critical role in ensuring that developers achieve the anticipated benefits from reusable components – enhanced productivity, uniformity, ease of use, and faster time to market.

Component Interfaces - A component restricts access to its services and internal structures through one or more public interfaces. The interfaces should be appropriate, adaptable, flexible and carefully defined. An interface defines a set of properties, methods, and events through which external entities can connect to, and communicate with, the component. One has to concern only with the component’s interface, not with its internal workings, when that component is being used to build an application. As long as the existing interface does not get altered, internal workings of a component can be changed without breaking applications that use it.

Components are reusable because the tasks they perform are generic and narrowly defined, and can be applied in similar manners across applications. For example, a button component behaves in the same manner in any application that employs it. A user can click the button to take an action, and the button responds by executing the action assigned to it by the designer at design time. Components require several key capabilities. These capabilities include introspection, properties, events, scripting, and support for complex interactions.

In traditional programming parlance, a component interface defines its entry points, the hooks that one uses to call into a component in order to execute its tasks. In one sense, a component interface is more sophisticated than traditional entry points; it offers both design-time and run-time elements. Design-time elements permit you to customize aspects of a component’s appearance and behavior during application development. For example, a button component may define an interface element that permits the developer to specify the color of the button face. Run-time elements enable the application to interact with a component, in response either to user-initiated actions, or to certain predetermined application conditions set up at design time. For example, a button component typically has a run-time element that responds to a mouse click from the user.

We now dig into the parts of component interface in detail.

From an application developer’s view, properties behave very much like function variables. Developers can set or read property values as if they are variables, but properties are more powerful than variables for two reasons:

• Application developers can set properties at design time. Unlike methods, which are available only at run time, properties let the developer customize components while building an application

• Properties can hide implementation details. Properties let developers attach complex effects to outwardly simple assignments. What looks like an assignment to a variable might be a call to a method that implements elaborate processing.

A method is a run-time interface element. It is a function that operates on data belonging to the component. Application developers use a component’s method to direct the component to perform a special action or return a value not already stored in a component property. Because a method executes code, methods are available only at run time. Methods are useful because they:

·         encapsulate the functionality of a component in the same object where the data resides

·         can hide complicated procedures under a simple, consistent interface. An application developer can call a component’s method without knowing how the method works or how it differs from a similarly named method belonging to another component

·         allow updating of several properties with a single call.

Events are special methods that link a component with an application. Events send information or requests from a component instance to the application that contains and uses the component. For example, when a user clicks a button component, the user action triggers the component’s onClick event handler.

An event handler can perform two types of actions: internal actions that are the same for each instance of a button component, and external actions that differ by application or even by invocation within an application. For example, suppose an application instantiates two button components. Each button’s internal action in response to an onClick event might be to display momentarily the button in its clicked state before redisplaying it in its normal state. Externally, the onClick event for one button might call a routine that submits the current data on a form to a database for one button, while the onClick for the other button might close the application.

Let us see a couple of other things related with components.

Components exist and operate within containers, which provide a shared context for interaction with other components. Containers also offer common access to system-level services for a component’s embedded components. Containers are typically implemented as components, which can be nested in other containers. Event-based protocols are commonly used to establish the relationship between a component and its container. An EJB component works in an EJB container environment, which in turn is inside an EJB server. Similarly all other component-developing models choose their own specific containers for components to play in. Containers acquire its special significance as they are assigned a number of tasks to ease the work of component developers.

Component standards specify the self-descriptive information (metadata) that a component must publish to flexibly communicate with other components. This metadata lets containers, scripts, development tools and other components discover a component’s capabilities either statically at design time, or dynamically at run time. The basic categories of metadata are given below:

·          Component information describes the component’s general compile-time and run-time properties, including where to find it and how to activate it

·          External references point to metadata that describes other components

·          Type descriptor and Type form the fundamental metadata elements

·          Interfaces describe public attributes, events, and methods

·          Classes describe the implementation of one or more interfaces

·          Attributes, methods and events characterize the classes and interfaces

·          Return types and parameters specify method inputs and outputs.

Metadata drives component composition and dynamic collaboration, enabling components that discover and manipulate each other’s interfaces at run time.

The notion of a component is inseparable from the notion of a component development environment or builder. IDEs are rapidly moving from text-based programming toward the direct manipulation of visually rendered components. Microsoft’s Visual Studio, IBM’s VisualAge for Java, and Symantec’s VisualCafe, supplemented with scripting languages such as VBScript and JavaScript.

IDEs may come with

• one or more palettes for displaying available components rendered as icons,



• property and script editors that let users customize components within their containers,



• a canvas container onto which components are placed and interconnected, through drag-and-drop operations and pop-up menus,



• editors, browsers, interpreters, compilers, and source-level debuggers for developing new components, and testing and refining component applications,



• a component repository and associated design-time browser services to locate components by matching user search criteria and using inspectors to view component metadata, and



• configuration management tools that structure and coordinate team-based development and release processes – tools that are essential for large software projects.

Thus an IDE helps to construct an application by composing new components visually and scripting interactions between existing and new components. Thus IDE occupies the major part in designing exemplary components. In the next part, we are to discuss about a couple of variants of component.

Developing components for Web applications adds additional requirements to the component model. Components for the Web must satisfy the following:

Operating system (OS) independent – Components must run in any Web-based environment regardless of a system’s underlying OS.

Open standards-based – Components must use languages and protocols with published specifications that are shared across the Internet development community. Adherence to open standards ensures that any corporation’s investment in component technology today can be leveraged at all times across all platforms tomorrow.

Language transparent – Components must either communicate directly with other components and applications written using a variety of programming languages or communicate through commonly shared, and open standards based protocols.

Server and client transparent – Components must work across a distributed, heterogeneous network environment, regardless of the underlying hardware and software architectures of each client or server machine involved.

With the popularity of the Web and the Internet, networked computers are finding their way into a broader range of environments, from corporate offices to schools, homes, and shirt pockets. This new computing model fosters the development of distributed software components that communicate with one another across the underlying networked infrastructure.

A distributed software component can be plugged into distributed applications that may not have existed when it was created. The intention is that many developers will reuse distributed software components to build new systems. For a developer to know what to expect from a distributed software component, the design must clearly document both the component’s interface and the operation’s behavior.

Distributed components require five distributed services:

1. Remote communication protocols, which enable interactions at the application layer among components distributed over a network. Protocols can be synchronous or asynchronous.



2. Directory services, which provide a coherent global scheme for naming, organizing, and accessing shared services and information resources.



3. Security services, which protect shared resources by ensuring that communicating parties are properly authenticated and have suitable authorization and that third parties have not intercepted or tampered with their messages.



4. Transaction services, which coordinate concurrent updates to enterprise-critical data and ensure that all updates leave data in correct and consistent states.



5. System management services, which provide a unified set of facilities to monitor, manage, and administer services and resources across the enterprise.

Several distributed software component technologies have gained acceptance, including RMI, CORBA, DCOM and Enterprise JavaBeans (EJB). These provide their own interface definition language that documents a software component’s services in a location-, platform-, and programming-language-independent fashion. For RMI (Remote Method Invocation), the Java language itself is fitted with interface structure apart from class structure. OMG’s CORBA comes with an IDL and DCOM uses its own IDL. EJB supports two distinct interfaces. We have given more details of these technologies in the coming sections. Also these frameworks fulfils the above said distributed services.

Here we use OMG’s IDL to represent the interface for BankAccount component.

interface BankAccount {

void make_deposit (in Money amount);

void make_withdraw(in Money amount);

Money get_interest_rate();

Money get_account_balance();

void setOverdraftLimit (in Money newLimit);

}

1. An application is running and encounters a call to an operation in a remote software component
2. The operation parameters are marshaled and sent to the server responsible for executing the remote software component
3. The remote server unmarshals the parameters and passes them to the remote operation
4. When the remote operation is finished executing, its return value and any parameters that changed value are marshaled for return to the client
5. The client unmarshals the return value and returned parameters and continues its execution.

Normally, server-side distributed components are often multithreaded, replicated, and pooled to achieve scalability and reliability.  In the next section, we are to give some details of some currently available key component technologies.

There are generally two types of components namely front-end and back-end components. Front-end components (mainly visual components) acquire this name because they reside on desktop systems and directly interact with the users.On the other hand, many platforms, operating systems, languages, and vendors represent the back end (non-visual components).For components to succeed, the component provider must deal with portability across the platforms, the implementation of the component, versioning and licensing.Distributed object technology such as CORBA provides the necessary platform independence, location transparency, and bindings to different programming languages. Java, in particular, provides increasing portability of code, which is an essential part of making components on the back end a reality.For components to be used in the enterprise successfully, there needs a number of advanced tools that deals with installation, configuration management, and run-time administration of the components, development and run-time repositories, a sophisticated and simple-to-use graphical user interface (GUI) and modeling, event configuration, and distributed licensing.

There are a number of competent component technologies, such as JavaBeans, Enterprise JavaBeans, Microsoft’s COM, DCOM, COM+ and ActiveX, and OMG’s CORBA for producing the both desktop and enterprise class software components.

JavaBeans [Ron Zahavi] are components that can be coded using Java. The bean application programming interfaces (API) allow the components to be combined into other components, applets, stand-alone applications, or servlets. One vital feature of beans is their ability to expose information about their features that can be used to visualize the beans in development tools. Beans expose information about their methods, attributes, and events through introspection and classes. Development tools, for example, can display the information, allow a developer to modify it, and visually combine the beans to form applications. A bean may have a set of properties that can be manipulated at design time. For communication purposes, beans utilize events. Source beans can send events and listener beans receive them. The tools can also display the event information as to which events a bean can send and receive. Persistence is also supported and allows beans to serialize themselves.

EJB extends the regular JavaBean model; however, these beans can not be manipulated with an IDE in the same manner as standard JavaBeans. EJBs tend to be larger-grained, more complete components and may be configured by tools provided by the EJB server vendors. The EJB model provides several services that are implicit. Currently, they include life cycle, security, transactions, persistence, and state management. At development time, users may customize the components using properties, but more interestingly at deployment time, users can set management rules for each of these characteristics.

COM is Microsoft’s core component technology and is built on a Microsoft extended version of Distributed Computing Environment (DCE) remote procedure call (RPC) technology. COM allows clients and servers to communicate when they reside in different processes. COM supports multiple interfaces. COM is a binary specification and is not compiled into specific languages and hence any language can interact with COM objects.

ActiveX grew out of the Object Linking and Embedding (OLE) compound document technology, but with the addition of COM-based components and Web capabilities, ActiveX represents a set of technologies. ActiveX controls are part of this set of capabilities and these can be downloaded from a web server to be run in a browser. The ActiveX set of technologies encompasses the utilization of many COM and DCOM capabilities. In contrast to JavaBeans, ActiveX components are native code and run as native Windows applications.  Beans can run in any virtual machine and are portable, but ActiveX components run on the Windows platform. Because ActiveX is native code, it can access local machine resources and does not have the sandbox limitations that Java applets do. This means that ActiveX applets that are downloaded to the client machines should be trusted, they could be dangerous also.

DCOM, the distributed version of COM, uses a network stack of protocols to forward calls to processes residing on different machines. DCOM provides location independence; components need not be recompiled and simply must register their availability. DCOM, which is supported on Windows platforms, uses reference counts and “keep-alive pings” to manage connections between distributed components. These features allow the object life cycle to be managed by the underlying infrastructure. DCOM also supports versioning and security is based on NT security. DCOM supports multiple languages via binary compatibility, allowing components to be accessed by multiple languages. DCOM’s wire protocol is based on an extension of DCE.

COM+ is the next generation of the Component Object Model (COM) that is going to be shipped with the final release of Windows 2000 this year. Essentially, COM+ is the integration of Microsoft Transaction Server (MTS) into the COM run-time, along with lots of other goodies like load balancing, a new thread neutral apartment (TNA), object pooling, queues and in-memory databases. In a typical COM development, programmers define interfaces to their objects; however, COM+ programming revolves around a declarative approach in which developers define methods, properties, and fields on classes. COM+ also supports events and inheritance. The key aspects of COM+ are the run-time, the services, and, to a lesser extent, the administration. Unlike COM, which supports only interface inheritance, COM+ also supports implementation inheritance. One important new capability planned for COM+ is that of interceptors. We have discussed about the role of interceptors in enhancing the capabilities of CORBA below. COM+ supports services, such as queuing, load balancing, or security. A naming registration service provides the ability to manage the naming space for components.

CORBA [Dirk Slama] is a conceptual software bus that allows applications to communicate with one another, regardless of who designed them, the platform they are running on, the language they are coded in, and where they are executing. CORBA also enables the building of a plug-and-play component software environment. On the enterprise side, CORBA enables the development of portable, object-oriented, interoperable code that is hardware, operating system, network, and programming language independent. The furious pace at which the Internet and the Web are growing requires a technological leap that can be provided by CORBA.

Having discussed some of the worthy technologies for component development, we now enter into studying some useful characteristics of components.

Components have a number of valuable characteristics. We discuss some of them in this part as they will be of highly beneficial to understand properly the nuances of CBD.

Components have long promised to neatly encapsulate data and programs into a box that operates predictably without requiring that users know the specifics of how it does so. Many believe that components will bring about the bright future of large-scale software reuse and spawn a niche market for components usable with distributed object technologies like CORBA and DCOM.

Analysts give mixed results when using and reusing components in mission-critical settings. This raises many serious questions about the trustworthy of components, such as how one can put trust on components, what if the component behaves unexpectedly, either because it is faulty or simply because one misused it? Thus there is a need to know beforehand many important points of the components. The component providers should provide the details of the interface of components such as the operations a component can perform, the input and output parameters each component requires, and the possible exceptions that might be raised during operation. Apart from these, there must be some parameters or meeting points against which the component can be verified and validated and this provides a kind of contract between the components and their users. Thus there is a strong need to have the importance of contracts that the components have to preserve and it is absolutely necessary that quality-checking should be done very strictly at every developmental stage of the component development to meet the core requirements of mission-critical software.

Software inconsistency can occur in any phase of the development process and during the run of applications as there is every possibility of serious bugs knowingly or unknowingly intruding into the process. Avoidance of static inconsistencies in software design, implementation, and maintenance, as well as protection of dynamic inconsistencies of software at run-time, are important topics in software engineering research and in the software industry. Thus the consistency process should be maintained precisely from the beginning to the end and acquires the special significance due to the resulting implications, which may be occasionally harmful.

Making components interactive is rarely pleasant and the solutions obtained are seldom elegant. Here we tell about why components have to interact, the requirements for interoperation, and the programming model to specify interoperation.

If a system’s software architecture is viewed as an abstraction of components and their interactions, a component interacts with others in four basic ways. It provides services to other components, gets services from other components, generates events, and observes events. These four elements define the component boundary. These boundary elements give rise to three possible component interaction styles such as service-service (a component uses a service provided by another component), event-event (a component observes an event generated by another) and event-service (an event generated by one component triggers a service provided by another component). It is imperative to implement components that express the boundary elements as well as enable the interaction styles. Since there is not yet a component-oriented language, component developers must choose an object-oriented language.

In an object-oriented component implementation, developers implement a component as one or more objects and all interaction styles as object method invocations. A distributed communication protocol or middleware product is also needed to support interactions among distributed components.

Clearly there are gaps between components and objects and between component interaction styles and object method invocations and the gaps must be bridged. Currently available component models, such as JavaBeans, COM (Component Object Model) etc., fulfil this task to some extent. Also another innovative model called CORBA component model is under consideration by OMG. This model specifies that a component can declare both the services (interfaces) it provides and the services it uses as well as events it emits and consumes. This feature is all set to reduce the above said gaps significantly. Also the communication mechanisms should be meticulously designed to have objects not to have strong dependencies among them and also on the distributed object middleware. This dependency problem is more severe in component-based systems as a component may contain many internal objects, which may be composed in multiple layers. In this context, getting the services of components outside the component’s boundary can be accomplished by having a special object internally that can access the services provided by the outside components through the component’s boundary. Thus assembling of components is being achieved by the internal object for the purpose of interactions among components.

Asynchronous vs. synchronous communication – On the communication side, asynchronous communication between components should be introduced in order to allow time-consuming computations to be performed off-line by another process or thread. Introducing asynchronous communication can also affect interfaces, because in order for a component to receive the results of an asynchronous computation there must be an event to transmit the results back. The other reasons for making interactions asynchronous include:

Let us see how Web components interoperate. Components are generally service-oriented. The Web connects services (information resources, vendors, brokers, and such) to users and to each other. Users want related services to work together. On the Web, the services available are heterogeneous, dynamically changing, and autonomous. As we said earlier, current programming models are found to be ill-suited to building systems of components that implement the above services. To engineer interoperation intendedly , we need an effective programming model to specify it and a strong behavior model to make it operational. Meeting these interoperation requirements calls for a programming model that includes a small interface consisting of patterns of interaction among inter-operating components. The following are the more fundamental patterns:

·          Entertain specified kinds of requests from other components

·          Notify others of specified information when it becomes available

·          Re-notify others when a specified condition is achieved or violated.

The programming model should be conceptually clean, combines well with traditional software engineering, and offers a natural implementation of high-level abstractions. Thus interoperability of components to achieve greater levels of functionality acquires a special significance in the realm of component world.

Component encapsulation creates a component object that is usable within an object-based framework out of a stand-alone, non-interactive program. Encapsulating filter-style programs that transform one data stream into another is a fairly straightforward process. Programs requiring limited user interaction can be encapsulated using a suitable wrapper, while programs that have a graphical front end are poor candidates for encapsulation. Encapsulating a stand-alone program makes it directly usable in object-based frameworks. And specifying a standard filer-type component class allows repetitive aspects of the encapsulation to reuse. One can even specify a class to automate the encapsulation, but doing so means one is bound to a generic component interface. Component encapsulation allows you to experiment with different component implementations that may vary in terms of performance, cost, licensing restrictions, and resource use.

Encapsulated components do not operate in a vacuum. They are composed to create more powerful components and are integrated within an object-based system to provide more specialized services. The composition of encapsulated components with component glue can be used to provide efficient access to offline data, GUIs, and a multitude of other component-based services. A spelling checker, for instance, can be easily constructed by composing the components such as translate, sort, and others while gluing together the editbox and listbox components to provide GUI. The components composed are object instances of either active process components- that are connected to existing data sources and sinks- or glue components that provide such sources and sinks. By using component composition, it is possible to implement highly sophisticated component interaction topologies. It is also possible to package together existing basic components to create new, innovative and reusable ones.

Replication of a service means that there are multiple instances of the same server, each of which provides the same functionality and access to the same set of data objects. Since the replicas all provide the same service, a client request can be directed towards any of the servers currently available. As the name replica suggests, a single object might exist simultaneously in more than one server to achieve the goal of load balancing. For example, a component can be defined to include a server representing application logic and two event servers in a CORBA environment. Why two event servers is that they tend to be more heavily loaded than the server with application logic. The event servers continually push updates to clients, while the regular server is relatively infrequently used. The important point is that the component becomes the unit of replication, rather than the individual servers themselves and thus the intended load balancing can be accomplished successfully through the idea of component replication.

The ability to substitute one component with another one that provides the same functionality has often been heralded as one of the key objectives of object-orientation and, in particular, of componentization. To a certain extent, CORBA has achieved this goal. It is possible to replace a CORBA server with another one that exposes exactly the same interfaces made of OMG’s IDL. However, there is currently no way to guarantee that the components are semantically equivalent. For example, even though two components expose exact the same IDL interface, a method call to getCustomerID ( ) on one component might have completely different semantics from the same call in the other component. Thus substitutability as a characteristic of components is to help to fit newer, nicer, highly appealing implementations in the place of the existing ones to realize the same functionality.

Over the last decade, the much-hyped benefits of software reuse have never been realized by most software organizations. The real bane of software reuse has always been the great difficulty of attaining the true interoperability between software written in different languages or on heterogeneous hardware platforms. Fortunately this is beginning to change, thanks to the maturation and convergence of technologies, such as distributed object computing represented by CORBA and Java. Java’s inherent platform independence conveniently facilitates software reuse in heterogeneous environments. CORBA’s language-neutral approach to object interface specification allows objects to interoperate without respect to the implementation language. Java and CORBA, taken together, provide a solid architectural bedrock for developing highly reusable and portable distributed software systems and mission-critical components.

Component-level reuse has emerged from the soup of competing computing paradigms, languages, and development environments to become the dominant theme in software development today. Objects participating in a distributed system can access data, business logic, and functional behavior directly through distributed components with little or no concern for how those components are implemented or where they reside on a network. With Java objects distributed through CORBA, one has a highly productive environment for component-based software development and can accomplish the realistic target of write it once, deploy it anywhere, and use it over and over again.

In this part, we talk about a couple of vital domains where componentization is bound to play an important role and about the key contributions of components in CORBA and about designing a component-based OS.

The concept of componentization is very common in many engineering disciplines and in even industries other than software. For example, automobiles, computers and other mobile telephones are all assembled from parts that can collaborate within their respective architecture. The parts are typically not a homogeneous set, but comprise many different types and standards. For example, in a personal computer, we have the motherboard, the chips, memory, keyboard, cables, drives, casing and so on. However, there are agreed standard interfaces that allow the disparate parts to be assembled, to interoperate and to be upgraded with newer parts that conform to the same interface. This joining of old and new parts is made possible because the product line is based on an architecture designed to facilitate an evolutionary life cycle. Regrettably, most software produced to date has been delivered as monolithic code and does not implement the very sensible concepts of componentization. Today there is widespread consensus and realization that component-based techniques are essential quality requirements for software development. The advantages of a componentized software architecture are very similar to the architecture of a PC, which is designed for incremental evolution of processor, systems, functions, utilities, and so forth. The parts of a componentized software product may be constructed by potentially many different manufacturers and brought together to be assembled very rapidly. The assemblers need not be experts in the internal workings of each assembled component. Thus the process of componentization is very essential for survival of many disciplines in the future.

It becomes imperative for the legacy assets of an organization to be leveraged and integrated into next-generation business systems to meet the end users’ wishes and the future challenges. Identifying the most promising of those highly respected components from the legacy applications, one has to extract and re-encapsulate them in components that satisfy today’s view of component-based development, based on the principles of object technology. Legacy systems can be componentized physically by developers or they can be perceived as components by means of their interfaces. Needs for legacy componentization could be met by either case, depending upon the business objectives. These may include:

• Replacement – This allows the implementation of the whole or parts of the legacy assets to be upgraded or replaced at the component level, without having any impact on other components
• Enhancement – The function of the legacy applications must be changed to meet new requirements
• Separation of concerns – This requires that components provide separate services and determine how these services are invoked via the component interface
• Selective reuse – Reusing the services locked inside the legacy code may not require reworking the existing applications, just the ability to access it and integrate it into new systems. This option can be used if one wants to use part of the legacy system in current and future implementations.

Component encapsulation is also used to partition and to componentize legacy systems. Each component can be objectified separately and hence each component can be reused and system upgrades can happen incrementally.

Component Mining – As a related topic, component mining acquires special attention lately. Component mining is the process of extracting reusable components from an existing component-rich software base. All along, there are a number of applications that have been used as components. The process of identifying and mining components and subsequently using them within an application or to build new applications can be divided into the three phases: exploration, excogitation, and exploitation. We discuss each phase briefly.

During the exploration phase, one will elicit component requirements and select components on the basis of component abstractions. In this phase, the selected components and the system architecture determine the corresponding interface requirements. The second phase deals with the encapsulation of the components that have to be mined and implementation of suitable interfacing glue for connecting components with the rest of the system. The abstract nature of packaged components and interfaces means that many of them can be stored in a repository for future reuse or retrieved from this repository for direct reuse. The exploitation phase deals with creating a functioning system by using the reused and newly encapsulated components with their interfaces.

The ease of encapsulation, the limitless possibilities of object structuring, and the flexibility of using a high-level language to interact with the components have opened novel ways to leverage existing tools and applications. Component mining as a very recent field may be extended to other mining fields.

The so-called enterprise resource planning (ERP) applications market was one of the fastest growing and most profitable areas of the software industry not long before the present. Organizations tend to have a strong desire to acquire functionality rather than develop custom solutions, particularly for relatively unexciting transactional applications that did not differentiate the business significantly. Unfortunately these packages, being better known for the time and cost involved in implementation, give poor business benefits and hence the application package providers, such as SAP, Peoplesoft, Oracle, Bann and others, embarked upon upgrading the core design architecture of their applications.

The market-leading enterprise applications represent some of the largest, most complex applications on this planet. The complexity comes particularly from the highly generalized nature of the packaged applications and the need to adopt and rapidly evolve to meet requirements in many different situations. So there is a genuine concern for the packaged application providers to solve this mission-critical problem quickly. The idea is to continue adding new functionality rapidly and at low cost, while making it easier for new customers to implement, and existing customers to upgrade to that new functionality.

The challenge here lies with the package providers as they face a rather more complex problem than organizations managing in-house developed applications. Many ERP vendors’ packages have evolved from simple beginnings and are composed of large functional modules such as Finance, Manufacturing and Logistics. These are large application systems. Some vendors, for the sake of the market competition, took upon the challenge of componentizing the applications as the viable solution and broke up their large-scale application modules. Some even rebuilt their applications as components recognizing the commercial necessity towards real adaptability in the development phase. Thus most of the leading application suppliers started compenentizing their packages as a direct and concrete response to customer needs.

There is a general agreement that software components will bring profound impact in the way that software is designed and delivered today. The application package vendors have started to respond to this challenge and those who are successful will in time become true component providers themselves, having rearchitected their products into sets or kits of components. Componentized products exhibit vastly superior adaptability characteristics demanded by fast-moving e-business environments. The successful vendors will provide their customers with a flexible and economic operational infrastructure, easily integrated with open market components, that allows their customers to exercise considerable choice in procurement to create customized solutions from readily and widely available building blocks. Thus, componentization will become a key business productivity action for both suppliers and consumers in the application market.

Operating system application programming interfaces (API) are typically monolithic procedural interfaces that address a single machine’s requirements. This design limits evolutionary development and complicates application development for distributed systems. An OS’s functionality will change over its lifetime, and these changes should be reflected in the API. But it should be ideal if the obsolete API calls would be deleted and the calls with modified semantics (but unmodified parameters and return values) would remain the same. Unfortunately, since the OS must continue to support legacy applications, obsolete calls can never be deleted and new call semantics have to be introduced through new calls. The need for backward compatibility leads to bloat in the API and the supporting code. Further on, typical OS APIs do not adequately address the needs of emerging distributed applications. They have support for intermediate communication but lack high-level support for accessing remote OS resources. The primary omission is a uniform method for naming remote resources, such as windows, files, and synchronization objects.

Component software methods can eliminate these weaknesses. Component software environments are largely based on distributed platforms and, due to natural software evolution typically contain multiple active versions of components. Component infrastructure therefore must have good distributed computing support and also have versioning support for managing multiple versions of code. A component-based OS API is constructed entirely of software components, each modeling an OS resource with perfection. To facilitate independence, components necessarily encapsulate state and functionality. The component modeling an OS resource will therefore contain all necessary access and manipulation functions. This encapsulation allows the OS resources to be instantiated on a remote machine and also provides a natural unit for API versioning. Only the API must be component-based. The underlying OS can be monolithic, a microkernel, or component-based. A component-based API controls access to the OS, which is sufficient to provide API versioning and to expose OS resources outside the host machine. Thus componentization has all the guts to design component-based OS a reality in the near future.

Distributed object frameworks like CORBA have many attractive features for enterprise computing but unfortunately provide little support for alternative protocols, profiling and monitoring, scheduling, security, or reliability. With the advent of non-application components, called interceptors, one can enhance CORBA applications at run-time with components whose operation is transparent to both the application and the CORBA framework; this means that one can modify application behavior without having to modify the application or the CORBA framework. Interceptors let chain together multiple components (each with its own functionality) to achieve new functionality transparently without much hassle.

At present, CORBA objects can not interact with other kinds of distributed objects over protocols that do not confirm to its General Inter-ORB Protocol (GIOP). To enable CORBA applications to communicate using protocols other than IIOP, one has to divert the GIOP messages sent by CORBA objects transparently to these non-application components that map GIOP onto other protocols.

CORBA does not currently include components for profiling or monitoring. For monitoring the system and measuring its performance, one can use existing profiling components that can trace an application and its messages transparently, without the need to embed any special code into the application or the ORB.

CORBA provides support for many of the commonly used multithreading models. However, for some applications it is desirable to employ a custom thread-dispatching policy that the ORB does not support. An approach is to use an interceptor to introduce a scheduling component before the incoming requests to reach the target objects. By controlling the order in which the threads and the requests are released to the application, the scheduling component can override the ORB’s or the application’s thread and scheduling policy accordingly.

The fault tolerance mechanisms that CORBA currently provides are rudimentary, consisting mostly of exceptions returned if an object or a processor fails. One good approach is to use an interceptor to add components that handle object replication, fault detection, and fault recovery in a manner that is transparent to both the CORBA application and the ORB. These components, once configured, operate independently of the programmer, the application, and the ORB. There are a couple of mechanisms to develop components such as interceptors, which play a vital role in enhancing the workings of CORBA framework.

Educational Software Components – The idea of component software development permeates into different domains and fields in the recent years. One important and expanding field is education. The demand for educational software is growing exponentially with the surge of interest in educational reform, the Internet, and distance learning. As the development of educational software using conventional types is found to be not desirable and not trendy in education, component technology appears to fill the vacuum and be able to meet the tremendous demand for customized learning materials. Educational application must be flexible as there are numerous teaching methodologies and curriculum development.

Consumer Electronics Components -- Most consumer electronics (CE) today contain embedded software. Developing software for consumer electronics poses some problems as described below:

• The size and complexity of the software in individual products are increasing rapidly

• The required diversity of products and their software is increasing rapidly

• Development time must decrease significantly

Some of the hardware tasks have been shifted to software and software has made new product features possible, such as electronic programming guides and fancy user interfaces. Thus CE products have become members of complex product-family structures. These structures exhibit diversity in product features, user control style, supported broadcasting standards, and hardware technology- all factors that increase complexity. Today’s dynamic CE market requires the vendors to keep prices low, using computing hardware with severely constrained capabilities. How can the vendors handle the diversity and complexity of embedded software at an increasing production speed? The answer lies in the use and reuse of software components that work within an explicit software architecture. The component-oriented approach is an ideal way to handle the diversity of software in consumer electronics.

In the next few sections, we are to discuss the main concepts of component-based software development especially on server-side in client/server environment and the lead role being provided by EJB [Ed Roman] in designing server-side components for the component world.

For a component to succeed in solving a business problem, both the component developer and the customer using the component should agree on the syntax and semantics of calling the component’s methods. Thus, the component vendor must publish the contract (or rules) for calling the component, and the client code must adhere to these rules. When there is a new release for the component, the vendor’s customer will want to upgrade. There will arise a number of issues such as whether the new component work with the customer’s code that called the old component. There comes the idea of separation of component’s implementation of core programming logic from the component’s interface, which contains only the calling method’s signature and parameters. The Java language supports interface/implementation separation at a syntactic level quite nicely via the interface keyword and class keyword.

Thus, it is possible to make changes in a component’s proprietary logic without making any changes in the client code, that is, one can plug in an altogether different implementation that performs the same task more efficiently. This is possible because the actual implementation is not needed at compile time – only the interface is needed.

When Java [Ivor Horton] was first introduced, most of the IT industry focused on its graphical user interface (GUI) characteristics and the competitive advantage it offered in terms of distribution and platform independence. Today, the focus has broadened considerably: Java has been recognized as an excellent platform for creating multithreaded enterprise solutions, specifically for developing distributed server-side applications. This shift has much to do with Java’s emerging role as a universal language for producing implementation-independent abstractions for common enterprise technologies.Java is not only a sublime programming language but also a superb platform that has revolutionized the way of software development in the recent times.

Let us look at what sort of component architectures is available in Java. The earlier one is JavaBeans.They are small-grained applications and mainly do client-side operations. We can use JavaBeans to assemble larger-grained components or to build entire applications too. JavaBeans are development components. Also there are two other types of client-side Java component: applets and servlets.

Object-oriented languages, such as Java, C++, are used to write software that is flexible, robust, extensible, and reusable- the three goals of object-oriented programming model. In business systems, OO languages are intended to improve the development of GUIs, to simplify access to data, and to encapsulate the business logic. The encapsulation of business logic into business objects has become the most recent focus in the information technology industry. Business is fluid, which means that a business’s products, processes and objects evolve over time. If the software that models the business can be encapsulated into business objects, it can become flexible, extensible, and reusable, and therefor evolve well as the business evolves.

A server-side component model defines architecture for developing distributed business objects. They combine the accessibility of distributed object systems with the fluidity of objectified business logic. Server-side component models are used on the middle-tier application servers, which manage the components at run-time and make them available to remote clients. They provide a baseline of functionality that makes it easy to develop distributed business objects and assemble them into business solutions.

Server-side components, like other components, can be bought and sold as independent pieces of executable software. They confirm to a standard component model and can be executed without direct modification in a server that supports the component model. Server-side component models often support attribute-based programming, which allows the run-time behavior of the component to be modified when it is deployed in a container environment, without having to change the programming code in the component. Depending on the component model, the server administrator can declare a server-side component’s transactional, security, and even persistence behavior by setting these attributes to specific values.

As new products are developed and operating procedures change, server-side components can be reassembled, changed, and extended so that the business system reflects those changes. Imagine a business system as a collection of server-side components that model concepts like customers, products, reservations, and warehouses. Each component can be combined with each other components to design a formal business solution. Products can be stored in the warehouse or delivered to a customer; a customer can make a reservation or purchase a product. We can assemble components, take them apart, use them in different combinations, and change their definitions.

A new breed of software called application servers has recently evolved to manage the complexities associated with developing business systems in today’s Internet world. An application server is often made up of some combination of several different technologies, including web servers, Object Request Brokers (ORBs), Message-oriented middleware (MOM), databases and so forth. Also an application server can focus on one technology like distributed objects. This just facilitates connectivity between the client applications and the distributed objects. But ORBs have proved often to be inadequate in high-volume transactional environments and they fail to provide the kind of robust infrastructure that is needed to handle large user populations and mission-critical work. Further on, ORBs provide a fairly crude server-side component model that places the burden of handling transactions, concurrency, persistence, and other system-level considerations on the shoulders of the application developers. These vital services are not available in ORBs, which just works as communication backbones for distributed objects.

The latest sensation for enterprise computing is Enterprise JavaBeans (EJB). They are server-side components and deployable components. They are intended to perform server-side operations, such as executing complex algorithms or performing high-volume business transactions. Enterprise JavaBeans promised to revolutionize the way of developing of mission-critical enterprise software. It combines server-side components with distributed object technologies such as CORBA and Java RMI to greatly simplify the task of application development. It automatically takes into account many of the requirements of business systems: security, resource pooling, persistence, concurrency, and transactional integrity.

Before plunging into formal discussion of Enterprise JavaBeans, let us set the stage by discussing two important concepts such as distributed computing and transaction processing monitors.

Distributed computing [Dirk Slama, David Linthicum] allows a business system to be more accessible. Distributed system allow parts of the system to be located on separate computers, possibly in many different locations, where they make the most sense. In other words, distributed computing allows business logic and data to be reached from remote locations. Customers, business partners, and other remote parties can use a business system at any time from almost anywhere. The most recent development in distributed computing is distributed objects. Distributed object technologies such as Java RMI and EJB, CORBA, and Microsoft’s DCOM allow objects running on one machine to be accessed by client applications running on different computers.

Distributed objects evolved from a legacy form of three-tier architecture, which is used in Transaction Processing (TP) monitor systems such as IBM’s CICS or BEA’s TUXEDO. These systems separate the presentation, business logic, and database into three distinct tiers (or layers). These systems were usually composed of a green screen or dumb terminals for the presentation tier (first tier), COBOL or PL/1 applications on the middle tier (second tier), and some sort of database such as DB2 as the backend (third tier). The introduction of distributed objects in recent years has given rise to a new form of three-tier architecture.Distributed object technologies make it possible to replace the procedural COBOL and PL/1 applications on the middle tier with business objects. A three-tier distributed business object architecture might have a sophisticated graphical user interface (GUI), business objects on the middle tier, and a relational or object database on the backend. More complex architectures are often used in which there are many tiers: different objects reside on different servers and interact to get the job done.

Component transaction monitors (CTM) evolved as a hybrid of traditional transaction processing monitors and ORB technologies. They implement robust server-side component models that make it easier for developers to create, use, and deploy business systems. CTMs provide a solid infrastructure that can automatically manage transactions, object distribution, concurrency, security, persistence, and resource management. They are capable of handling huge user participation and mission-critical task, but also provide value to small systems.

The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications. Applications written using Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications, written only once, and then deployed on any server platform that supports the EJB specification.

Enterprise JavaBeans is a server-side component architecture that enables and simplifies the process of building enterprises-class distributed object applications in Java. By using EJB, one can write scalable, reliable, and secure applications without writing the complex distributed object framework. EJB is about rapid application development for the server-side; one can quickly and easily construct server-side components in Java by leveraging a prewritten distributed infrastructure provided by the industry. EJB is designed to support application portability and reusability across any vendor’s enterprise middleware services.

We had enough theory and let us turn to some practical things. We have chosen Enterprise JavaBeans for showing it as a leading component technology especially on server-side. Though there are a number of nice component technologies from different software firms, we have preferred EJB due to the following valid reasons. Component-based, multitier applications are the future of enterprise computing. And EJB developers lead the way in realizing the benefits of these components: portability, scalability to a wide range of enterprise servers, simplified development through divide and conquer policy, deployment, and maintenance.

Currently there are two kinds of enterprise bean, namely entity beans and session beans. A good way to understand the design of enterprise beans is to look at how one would go about implementing one. To implement an enterprise bean, one need to define two interfaces and one or two classes:

Remote interface – The remote interface for an enterprise bean defines the bean’s business methods: the methods a bean presents to the outside world to do its work. The remote interface extends javax.ejb.EJBObject, which in turn extends java.rmi.Remote. The object implementing this interface is called EJB object.

Home interface – The home interface defines the bean’s life cycle methods: methods for creating new beans, removing beans, and finding beans. The home interface extends javax.ejb.EJBHome, which in turn extends java.rmi.Remote. The object implementing this interface is called EJB home.

Bean class – The bean class actually implements the bean’s business methods. The bean class usually does not implement the bean’s home or remote interfaces. However, it must have methods matching the signatures of the methods defined in the remote interface and must have methods corresponding to some of the methods in the home interface. An entity bean must implement javax.ejb.EntityBean; a session bean must implement javax.ejb.SessionBean. Both EntityBean and SessionBean extend javax.ejb.EnterpriseBean.

Primary key – The primary key is a very simple class that provides a pointer into the database. Only entity beans need a primary key; the only requirement for this class is that it has to implement java.io.Serializable.

Having introduced the theory, let us look at how to build an enterprise bean. In this section, we design a BankAccount bean. Let us start with its remote interface. We will define the remote interface for a BankAccount bean and the remote interface defines business methods for working with bank accounts. All remote-interface types extend the javax.ejb.EJBObject interface. The remote interface is specified by BankAccount.java.

import javax.ejb.*;

import java.rmi.RemoteException;

Public interface BankAccount extends EJBObject {

Public void deposit (double amount) throws RemoteException;

Public void withdraw (double amount) throws RemoteException, BankAccountException;

Public double getBalance ( ) throws RemoteException;

Public String getCustomerName ( ) throws RemoteException;

Public void setCustomerName ( String name ) throws RemoteException;

Public String getAccountID( ) throws RemoteException;

Public void setAccountID( String id) throws RemoteException;

}

All of these methods declare that they throw RemoteException, which is required of any method that can be invoked through RMI. EJB requires the use of Java RMI-IIOP conventions, although the underlying protocol can be CORBA IIOP or Java Remote Method Protocol (JRMP). The BankAccountException class is given below.

Public class BankAccountException extends Exception {

public BankAccountException (Exception e ) {

super (e.toString ( ) );

}

The home interface defines life-cycle methods for looking up beans. The home interface extends javax.ejb.EJBHome. The home interface is specified by BankAccountHome.java.

import javax.ejb.*;

import java.rmi.RemoteException;

import javax.ejb.CreateException;

import javax.ejb.FinderException;

import java.util.Enumeration;

public interface BankAccountHome extends EJBHome {

BankAccount create(String accountID, String CustomerName ) throws CreateException, RemoteException;

public BankAccount findByPrimaryKey (BankAccountPK key) throws FinderException, RemoteException;

public Enumeration findByCustomerName (String name) throws FinderException, RemoteException;

}

The create( ) method will be responsible for initializing an instance of BankAccount bean. This will create new database data representing a bank account. It returns an EJB object to the client so that the client can manipulate that newly created bank account. There may be more create ( ) methods with different arguments in home interface. All create methods must throw CreateException. We have put two finder methods. FindByPrimaryKey ( ) searches the database using the account ID for a bank account that already exists. We have also put another finder method, findByCustomerName ( ), which searches the database for all bank accounts that have the same owner’s name. These finder methods return EJB objects so that client can manipulate the newly found bank accounts. Finally, finder methods are only used in Entity beans and are not used in SessionBean types.

Certain public fields of an entity bean are stored in a database. These fields are called persistent fields. Determining how the data in the database relates to the persistent fields of the bean class is called data mapping. When a bean is deployed into an EJB server, its persistent fields must be mapped to the database. The data used to populate persistent fields in the bean instance is obtained using a primary key. The primary key is a pointer that helps to locate data that describes a unique record or entity in the database; it is used in the findbyPrimaryKey ( ) method of the home interface to locate a specific entity. The database could be relational database, an objectified version of the database, or an object database.

Primary keys are defined by the bean developer and must be some type of serializable object. Our primary key is a simple string. For example,“AB 143298”. This string must be unique to its bank account. Primary key is used to identify each bank account uniquely. Here is the primary key for BankAccount bean:

import java.io.Serializable;

public class BankAccountPK implements java.io.Serializable {

public string accountID;

public BankAccountPK (String id ) {

this.accountID = id;

}

public String toString ( ) {

return accountID;

}

BankAccount bean is an entity bean, but a session bean would not be all that different. It would extend SessionBean instead of EntityBean; it would have an ejbCreate ( ) method that would initialize the bean’s state, but no ejbPostCreate ( ). Session beans do not have ejbLoad or ejbStore ( ) methods because session beans are not persistent. While session beans have a setSessionContext ( ) method, they do not have an unsetSessionContext ( ) method. Finally, a session bean would provide an ejbRemove ( ) method, which would be called to notify the bean that the client no longer needs it. However, this method would not tell the bean that its data was about to be removed from the database, because a session bean does not represent data in the database. Session beans do not have a primary key. That is because session beans are not persistent themselves, so there is no need for a key that maps to the database. Designing session beans is relatively easy.

This is the entity bean implementation class, BankAccountBean.java. This source code contains bean-managed state fields, business logic methods and EJB-required methods. The fields are persistent and the bean instance will load and store the database data into these fields. Business logic methods perform services for clients, such as withdrawing or depositing into an account. These methods are exposed by the remote interface, BankAccount. The home interface, which the client initially contacts, includes the creator and finder methods. We give here only a snippet of BankAccountBean.java:

public class BankAccountBean implements EntityBean {

//bean-managed state fields

public String accountID;

public String CustomerName;

public double balance;

//business logic methods

public void deposit (double amount) {

System.out.println (“deposit” + amount );

Balance = balance + amount;

}

We have to supply the data access code in BankAccountBean.java program as the process of persistence is being looked after by the bean itself.

Most EJB container vendors provide a kind of tool, available at deployment time that helps to map the primary key and the bean’s persistent fields to the database.

Much of the information about how beans are managed at run-time is not addressed in the interfaces and classes discussed previously. There are some primary services, such as how beans interact with security, transactions, naming and other services pertaining to distributed object systems, which are being handled by the EJB server automatically. But the EJB server still needs to know how to apply the primary services to each bean class at run time. To accomplish this, there is a special file called deployment descriptors. This allows customizing behavior of beans at run time without having to change the software itself. It allows users to describe run-time attributes of server-side components (security, transactional context, etc.).

When a bean class and its interfaces have been defined, a deployment descriptor for the bean is created and populated with data about the bean. After the developer has set all the properties for a bean, the deployment descriptor is saved to a file. Finally, the bean can be packaged in a JAR file for deployment in EJB container environment. A JAR file containing one or more beans includes the bean class, remote and home interfaces, and primary keys for each bean. It also contains one deployment descriptor, which is used for all the beans in the JAR files. When a bean is deployed, the JAR’s path is given to the container’s deployment tools, which read the JAR file.

Enterprise JavaBeans version 1.1 uses the flexible file format based on XML (Extensible Markup Language) [Mark Birbech, Brett McLaughlin] to set and store the deployment descriptor information. The XML deployment descriptors are text files structured according to a standard EJB DTD (Document Type Definition) that can be extended so the type of deployment information stored can evolve as the EJB specification evolves. The following deployment descriptor may be used to describe the BankAccount bean:

<?xml version=”1.0”>

<!DOCTYPE ejb-jar PUBLIC “-//Sun MicroSystems Inc. //DTD Enterprise JavaBeans 1.2//EN” http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd>

<ejb-jar>

<enterprise-beans>

<entity>

<ejb-name>BankAccountEJB</ejb-name>

<home>peter.EJB.BankAccount.BankAccountHome</home>

<remote>peter.EJB.BankAccount.BankAccount</remote>

<ejb-class>peter.EJB.BankAccount.BankAccountBean</ejb-class>

<prim-key-class>peter.EJB.BankAccount.BankAccountPK</prim-key-class>

<persistence-type>Bean</persistence-type>

<reentrant>False</reentrant>

</entity>

</enterprise-beans>

</ejb-jar>

Finally a manifest and an ejb-jar file have to be created. The ejb-jar file is suitable for deployment. The deployment process will vary slightly. There are a number of application server products from BEA, IBM, Inprise, etc. These vendors provide a deployment tool that examines either the jar file itself or the deployment descriptor (EJB 1.0 uses serialized deployment descriptor and EJB 1.1 uses XML for deployment descriptor).

The EJB specification includes a mapping that allows using both RMI and CORBA clients [Tom Valesky] to communicate with EJB objects. Even an EJB bean itself as a client can assess EJBs. EJB beans use exactly the same API as any other client when they access an EJB. A Java applet and servlet can also position themselves as clients and can call EJBs. An EJB client that uses RMI will use the JNDI API [Andrew Patzer, et al.] to locate the home interface of the desired bean. The client will then invoke a

find ( ) or create ( ) method contained in the bean’s home interface; this call results in a reference to the bean’s remote interface. Once the client is having a reference to the remote interface, it can start to use the service of remote bean as accessing a normal class. The only difference is that inclusion of exception-handling code to catch the java.rmi.RemoteException exception. Using EJB via CORBA is very similar conceptually to using them via RMI. Instead of using JNDI to locate a bean’s home interface, however, one can use CORBA’s COS naming service.

We have designed a GUI client applet called as BankCustomerClient using Java Swing for accessing the services being provided by BankAccount bean. The GUI is given below:

Component-based software development is poised to grow by leaps and bounds in the days to come as this paradigm is encompassing almost all the characteristics and requirements for quality software design. Also CBD provides enterprise-level scalability across the board, supports very large models and complex databases, large groups of developers and a high-volume production environment.Unfortunately, practical experience and in-depth information is very scarce regarding what CBD is, understanding CBD, how to architect using CBD effectively etc. We, in this chapter, have supplied all the relevant details regarding components, their characteristics, development and deployment and how the importance of quality consciousness is being precisely accomplished in the resulting software product out of CBD. In the end, we have discussed how EJB appears to be a very efficient and competing server-side component architecture and how EJB is bound to fulfil the hype of design once, and then deploy everywhere- across multiple platforms, using multiple languages. The Enterprise JavaBeans specification targets simpler enterprise development and portability. EJB adds mission-critical features and robustness to components, making them ideal for back-end component development. In particular, support is included for transactions and security as well as connection pooling and threading, naming and persistence.

Component-level programming still offers enormous potential for growth, and once the area stabilizes, a wave of new ideas will arise from the research community. The prime research opportunities are in extensions of object-oriented programming to better support the component-level view of objects, the division of standard applications into components, and the standardization component communication. Methods for sharing components and objects among incompatible operating system and hardware are also areas for innovation. Not only has the component-level programming revolution already happened, it promises to be the wave of the future.

We would like to thank Sweetlin Reena for her corrections and suggestions in improving the quality of this work and express our sincere gratitude to JSPS (Japan Society for Promotion of Science) for their moral and financial support.

Andrew Patzer, et al., Professional Java Server Programming: with Servlets, JavaServer Pages (JSP), XML, Enterprise JavaBeans (EJB), JNDI, CORBA, Jini and Javaspaces, Wrox Press Inc., Chicago, USA, 1999.

Brett McLaughlin and Mike Loukides, Java and XML (O’Reilly Java Tools) O’Reilly & Associates, CA, 2000

David S.Linthicum, Enterprise Application Integration, Addison-Wesley, Reading, Massachusetts, 2000

David Krieger and Richard Adler, The Emergence of Distributed Component Platforms”, IEEE Computer, March 1998.

Dirk Slama et al., Enterprise CORBA, Prentice-Hall, Inc., NJ, 1999.

Ed Roman, Mastering Enterprise JavaBeans and the Java 2 Platform Enterprise Edition, Wiley Computer Publishing, John Wiley & Sons, Inc., 1999.

Ivor Horton, Beginning Java 2 JDK 1.3 Edition, Wrox Press Ltd., Birmingham, UK, 2000.

Matthew Robinson et al., Swing, Manning Publications Company, Greenwich, CT, USA, 1999.

Mark Birbeck et al., Professional XML, Wrox Press Inc., Chicago, USA, 2000

Peter Maurer, Components: What if they gave a Revolution and Nobody Game?, IEEE Computer, June 2000.

Pethuru Raj and Naohiro Ishii, “StringMatcher - An CORBA Application”, communicated to the 7^th International Conference on High Performance Computing, Bangalore, India.

Priya Narasimhan et al., Using Interceptors to Enhance CORBA, IEEE Computer, July 1999

Richard Monson-Haefel, Enterprise JavaBeans, Second Edition, Oreilly Associates, CA, 2000

Ron Zahavi, Enterprise Application Integration with CORBA Component and Web-Based Solutions, Wiley Computer Publishing, John Wiley & Sons, Inc., New York, 2000.

Saba Zamir, Editor-in-Chief, Handbook of Object Technology, CRC Press, New York, 1999.

Tom Valesky, Enterprise JavaBeans, Developing Component-Based Distributed Applications, Addison-Wesley, Massachutsetts, 1999.

Some web sites for information about component technologies:

• ActiveX, COM, and DCOM are key component technologies from Microsoft



• JavaBeans is proprietary technology of Sun, which hosts this site



• The Object Management Group hosts this site, the primary source for information about CORBA



• COM and COM+ are available in this site



• The definitive source for software components.