| Code reusability can be defined as follows : -
Usage across different programming languages -
Usage across different systems, devices, and host environments -
Integration and extensibility for present and future models Usage Across Different Programming Languages Each programming language has its own power and potential. Most have evolved over a period of time and many still continue to evolve . Each was invented with a specific purpose: Java for code portability across different platforms, FORTRAN for scientific calculations, PERL for text manipulations, COBOL for mainframes, C and C++ for embedded programming, C# for ease of component development, JavaScript/JScript for Internet browsers, and so on. Given a typical scenario, most organizations would like to increase the productivity of their developers, developers would like to enhance their logical skills, and end users would like to see a better quality of service. To increase the productivity, an organization has to use its developers' skills effectively without developers working on different projects using different programming languages across their organizational structure doing the same work. For example, the logic for implementing searching and sorting algorithms does not differ across programming languages; however, the implementations differ syntactically. In the past neither organizations nor developers visualized the need for true code reusability across different programming languages. However, the ice was broken in 1995 with the introduction of CORBA and COM technologies to address the cross-language issues. Hence, the idea of language integration in .NET is not a whole new idea. COM technology is a clear indication of Microsoft's commitment to cross-language interoperability. Using COM, one can develop components using most of the languages as long as one conforms to COM specification. COM requires the binary standard to be followed to call the components written in other languages. You can design very complex networks using COM effectively. It gives us location transparency, which was one of the main reasons behind the success of the billion-dollar COM market. However, the problem posed by COM with respect to code reusability is that it does not permit one to put the code written in one language into another. Hence, the COM technology doesn't advocate the concept of true code reusability; rather it advocates usage of tailor-made functionality. One of the key aspects of true code reusability is that code written in one language can be used in another. It means that one should be able to inherit the code written in one language into another, override a method, and then extend the scope of the functionality if necessary. Microsoft had designed the CLR by considering the views of many compiler designers, researchers, and organizations and of course their own in-house feedback across the world. Many organizations are working hard to bring this idea to reality. As such there are more than 17 languages that support the .NET platform, and it is still flexible enough to accommodate other programming languages in the future. Figure 10-1 shows how languages under .NET can be seamlessly integrated within a project. Figure 10-1. Integration across languages in .NET.  Case Study Consider an organization with 100 developers and the following assumptions: -
Five different projects using different technologies. -
Nearly 20 developers for each project. -
All developers have similar functional expertise in the banking sector. -
Developers possess different sets of programming skill. -
There is a technology that permits code written in one language to be used in another language. (.NET Technology). The following are the banking sector projects and their split up according to technology: -
Project 1. A Web-based solution using Java technologies -
Project 2. A Web-based solution using MS technologies -
Project 3. A client server solution using C and C++ -
Project 4. A mainframe solution using IBM technologies -
Project 5. A CGI solution using different programming languages When it comes to allocating resources to these projects, all the developers possessing more or less the same functional expertise are working only on the same domain, the banking sector. However, from an organization or delivery point of view one has to allocate developers who possess different programming skill sets exclusively to each of these projects. This approach has the following drawbacks: -
More or less the same work is done by developers across the same organization working on different projects. -
Ineffective use of resources, time, and energy. -
Less scope for the developer to enhance individual logical skills. Using .NET, the following advantages can be achieved: -
The code written for project 1 could be used in project 2 and so on. -
The projects get developed with fewer resources than with the traditional way because the code now can be effectively used across different programming languages. -
Developers get more time to concentrate on the business logic. -
Developers can use the language they know best to deliver a specific solution. -
Fewer developers are required. -
True code reusability across multiple different programming languages can be achieved. As the complexity of an organization and project allotment grow, the computations also change. .NET technology gives us a definite power to treat languages alike and still exploit the best of language-specific features. Ultimately, .NET technology brings better productivity to organizations, giving ample time for developers to concentrate on logic rather than on integration issues and more importantly providing desired results to the end users. ISSUES Most organizations have invested a substantial amount of money, resources, and time in building many applications using many different programming languages over the years . Therefore, they should be cautious when planning to migrate to .NET technology. There are many trade-offs for the organizations to think about before deciding when, where, and how to start using this elegant technology. For code written using COM technology, Microsoft has provided tools to ensure both forward and backward compatibility of COM components. When you convert your existing COM code base to .NET, it runs under an unmanaged environment. However, if you target your code to run under the managed environment of .NET and want to exploit the features of the CLR, you need to make changes to the existing API, and use corresponding base class libraries of .NET, which at times may require considerable investment of time, money, and resources. Code written using other languages and technologies is another consideration. Because COBOL and other similar languages were never meant for developing COM, there will be problems converting an existing code base written using those languages to .NET. Developers have to learn the various classes provided by the .NET Framework class library and modify the existing code accordingly and then compile the modified code using a CLR targeted compiler. Usage Across Different Systems, Devices, and Environments Organizations are often spread across different geographical locations. The need for these locations to communicate with each other electronically has grown dramatically. Most systems are heterogeneous in nature, making the integration and use of components across these systems quite difficult. This requires us to have a loosely coupled model that will have great flexibility in both integration and use of components in a distributed environment across the Internet and an intranet. Put simply, what we are trying to do is use the functionality of the code across different heterogeneous systems. Let us have a look at the limitations of current distributed models existing in the market: -
The problem statement. Users are unable to integrate their data across different systems and devices at a desired location. We are unable to use the functionality imparted by code written at another location into our system(s) effectively. This means that we have to reinvest time, resources, and money to get the same desired functionality at our end. Let us try to understand this issue in a more elaborate way. -
Limited interaction with computers. The way we interact with computer is usually limited either to a keyboard or a mouse. -
Localized user information. The preferences we set on a machine or application over a network are a local phenomenon . Although we will be able to log in from a different machine, in most of the cases we won't be able to restore the preferences set on the other machine. -
Same user, same data across different applications. Different applications across the Internet request more or less the same type of data. (Registering for an email account on a different server would ask for more or less the same information.) -
Difficulties in integrating data across different devices and systems. We receive data from various sources every day. We are facing problems integrating the data meant for one device or system with another. -
Web sites are unable to function in a more meaningful way. In other words, Web sites are unable to consume information among themselves to produce a more meaningful experience. -
Need for yet another technology. All these scenarios address what is called distributed computing. Table 10-1 lists various distributed technologies offered by different vendors . These systems have their own advantages and disadvantages. They all work very well within a given environment. The problems arise when integrating with different heterogeneous systems. All these systems break down in a larger heterogeneous network because they rely on tightly coupled architecture. If the implementation at one side is altered , the other side suffers. The limitations of these technologies are listed in Table 10-2. All of them either require a homogeneous environment or tightly coupled interface. Table 10-1. Distributed Technology Vendors | Vendor | Technology | | Microsoft | DCOM | | Object Management Group | CORBA | | Sun Microsystems | RMI | Table 10-2. Limitations of Distributed Technology | Technology | Limitation | | DCOM | Limited acceptability other than in the Windows community | | RMI | Language specific (only for Java) | | CORBA | Suffers vendor noninteroperability | Ideally speaking there should be a distributed technology that is loosely coupled. This means that you can change the implementation at either end of a connection, and the application will still continue to work. One should have a message-based, asynchronous technology using standard protocols such as HTTP, SMTP, and XML. Figure 10-2 shows how systems could communicate with each other. Microsoft .NET technology encourages a loosely coupled distributed architecture. Hence, this takes us a step further toward better code reusability. Figure 10-2. Communication Architecture in .NET.  Integration and Extensibility for Present and Future Models Microsoft .NET relies heavily on open Web standards such as XML, HTTP, SOAP, and SMTP: -
Interoperability, integration, and application extensibility are very difficult and require high expertise, which only few organizations can afford. Microsoft .NET's reliance on XML eliminates the barriers between data exchange and integration across different systems and devices. -
Microsoft .NET uses open standards such as SOAP and WSDL, which themselves are pure implementations of an open standard, XML. -
Many organizations actively participated in the drafting of these standards. -
The loosely coupled model of the .NET Framework and easy accommodation of new languages into .NET takes Microsoft way ahead as compared to its current competitors .  |
