Comment

01 January 2004

A .NET in the real world

Platform allows for reusing legacy program code.

By Mikael Sundfors

A little more than three years ago, Microsoft held its professional developers conference in Orlando, Fla., where it first revealed its next generation platform for Windows and Internet software development-.NET.

Microsoft's initiative is broad based and ambitious and revolves around the .NET Framework, which contains the execution platform Common Language Runtime (CLR), plus extensive class libraries providing rich built-in functionality. At its core, the .NET framework embraces XML and SOAP to provide a high level of integration of software.

The most important part of the platform is the .NET Framework. It consists of the CLR environment, a just-in-time compiler, and a set of libraries packaged using the .NET object model.

One important feature of the .NET Framework is that it is language neutral. This happens by translating all .NET languages into a common language called Intermediary Language (IL). It is on this level languages interoperate. There is also a subset of rules defined by a Common Language Specification that all .NET-compliant languages have to comply to.

The language neutrality may be of interest when creating applications for the manufacturing industry, because it allows you to reuse legacy program code and then compile it into new .NET-based systems. Manufacturing industry systems often consist of large code bases that users rarely rewrite. For example Fujitsu Software, implementer of COBOL for .NET, estimated that as late as year 2000, 70% of production business automation systems are still in COBOL.

It is of course also possible to recompile legacy C/C++ code into managed IL code, which may be of more practical interest when rewriting manufacturing industry solutions.

The programming language IL files package together in deployable units called assemblies. These assemblies load into the Common Language Runtime (part of the .NET Framework), compiled by the just-in-time IL compiler, and executed within the CLR. The CLR provides many features we usually associate with a particular language, including garbage collection, type definitions, polymorphic method resolution, error handling, and the deployment model.

SAME LANGUAGE

The core of .NET is the CLR. In a nutshell, the CLR is a run-time environment in which .NET applications run. The CLR layers on top of an operating system, and exists to provide services by being a layer between .NET applications and the operating system.

The CLR loads IL code, manages it, runs it, and provides a number of support services. Some of these vital support services include managing memory and garbage collection, thread management, enabling remote (distributed) method calls, supporting serialization of XML-based SOAP, as well as enforcing code safety and security constraints. Code that is loaded and running under the control of the CLR is managed code. Compiled code in .NET does not contain any direct assembly language instructions.

In principle the CLR resembles the run times of languages such as Smalltalk and Java. However, the similarity is only in principle: the CLR is not an interpreter. The IL is really not open to interpretation, but compiles into native machine code. This provides a much more efficient execution. In practice the difference is that when you execute a subroutine, you do not have to compile it again the next time it goes in a loop.

The key benefits the CLR provides for Windows applications development and for the general manufacturing industry is it offers a consistent and simple programming model compared to the old Windows API. Other important items are:

• Automatic lifetime management of components and classes
• Enhanced security of execution
• Evidence-based security knows code origin and publisher
• User's permissions matched with codes profiles
• Better exception testing and handling
• Better debugging and profiling

The .NET Framework CLR provides means for building more safe and robust solutions than previous technologies for Windows development.

INTEGRATING AUTOMATION

Application integration is becoming increasingly important as businesses realize that processes cannot stand alone. Most processes in a business are somehow related.

Unfortunately the applications that automate them are not usually integrated, or if integrated, one vender provides some kind of monolithic application. The trend, however, seems to be that integration readiness is becoming a more important selling argument concerning software.

Today's industry software often consists of monolithic applications, where the same application automates a wide range of processes, e.g., supply management to maintenance/work order to calibration activities.

While the current situation may be beneficial for big software vendors to implement the wide range of functionality required by the software, it may not be the best situation for end users.

Implementing software and automating a particular business process usually requires a high level of expertise of the domain. The monolithic-application approach may easily result in software that can do a wide range of things, but that is not very good at them.

A different approach, perhaps more positioned for the future, would integrate highly specialized solutions, implemented by companies specialized in the particular business process the solution is intended to handle. This requires solutions designed with integration readiness in mind. The applications should be able to exchange data with other applications.

With this is mind, the emphasis the .NET initiative puts on SOAP- and XML-based Web services as an integration medium is interesting and worth exploring.

COMMUNICATING VIA WEB

Web services are a new step in the application decentralization direction. Webservices.org defines Web services as "encapsulated, loosely coupled contracted functions offered via standard protocols."

In Web services, software functionality becomes a service that does not care what consumes the service. Web services allow developers to build applications by combining local and remote resources for an overall integrated and distributed solution.

Normally Web services implementation comes about by using XML on top of the HTTP protocol, but Web services as defined does not have to use HTTP. For example, a user can consider SMTP, FTP, or some other protocol.

XML is a widely accepted format for exchanging data and its corresponding semantics. It is a fundamental building block for every layer that uses Web services.

In .NET, Web services are part of ASP.NET, which handles all Web interfaces. It allows programs to talk to each other directly over the Web, using SOAP.

SOAP is a lightweight, extensible, XML-based protocol for information exchange in a decentralized, distributed environment. Pri-marily, SOAP defines a framework for message structure and a message-processing model. SOAP also defines a set of encoding rules for serializing data and a convention for making remote procedure calls. Because Web services run in heterogeneous environments, the protocols used to perform the data transfer between functions have to be independent of any run-time environment. SOAP is a protocol having these characteristics.

Implementing a Web service in .NET is not very hard. All you need to do is indicate that a member should be included in the Web services interface, and the .NET Framework takes care of the rest.

Web services can provide many types of value to the manufacturing industry information technology. Web services allow applications running in different parts of an organization, or in different organizations, to talk to one another and exchange data.

Because Web services are implementation agnostic, they allow pieces of software written in different languages, or running on different operating systems, to talk to one another cheaply and easily. Based on nonproprietary and universal data standards, Web services allow integration between new pieces of software and legacy systems.

In the long run we can anticipate a replacement of enterprise-class monolithic applications by smaller component applications, some written in-house and some rented on a per use basis from outside specialists, communicating as Web services, assembled by a business process orchestration tool.

The current widely accepted XML Web services standards are the key enablers of this vision, but what still is lacking is additional standards and tools for workflow, transaction, and business process management. Until we will see this kind of functionality mature, loosely coupled, program-to-program communication, using Web services, will integrate on a custom basis.

LEGACY SOFTWARE

When starting new software projects, one key question is often how to reuse existing investments in software. There are several possibilities to achieve this in .NET.

Because the .NET Framework is in principle language neutral, a variety of languages can plug into it. The standard Microsoft languages that ship with Visual Studio.NET are Visual Basic, C++, and C#, but other languages are available through third parties. This includes, for example, COBOL from Fujitsu and Eiffel from Interactive Software Engineering.

The language neutrality of the .NET platform is an important point concerning reuse and integration of old code. In practice it means that old code, if only well structured and not dependent on, for example, the user interface, can be compiled as part of a new .NET application and operate as a Web service. Differing from the other .NET languages, C++ code can compile into either managed or native code. Changing old C++ to managed C++ code requires marking the classes garbage collected and removing the code-handling release of memory. This causes the class destructor to be executed undeterministically, which can be a major obstacle when converting some code, depending on destructor logic, to managed .NET C++.

Legacy code can also integrate as native dynamic link libraries (DLLs) or component object model (COM) components. The .NET Framework makes it transparent to deal with a COM/COM+ component as if it were a .NET component. Interface translation is automatic. And any .NET Framework component can also be a COM component by traditional COM-based software.

Developing applications in the .NET architecture, using a broad, consistent framework, allows developers to write less, and reuse more. Less code is possible because the system provides a rich set of underlying functionality. Programs in .NET access this functionality in a standard, consistent way, requiring less customization to interface with these functions than is typical.

The CLR either handles quite a bit of the programming infrastructure, or it is completely unnecessary. Some of the infrastructure remains hidden, and some of it is just not there anymore. One example of this hidden infrastructure is memory management.

SIMPLE WORKS BEST

Another significant benefit is that .NET Framework introduces a new model aimed at simplifying application deployment and avoiding versioning conflicts. Applications produced in the .NET framework can install with a simple XCOPY.

This point cannot be overemphasized. The problems with the current Windows deployment model, based on shared components and DLLs registered in Windows registry, has been an endless source of problems for system administrators and developers, commonly known as "DLL Hell."

Concerning integration issues, the consistent support for the XML integration medium is worth notifying. Support for XML is present in most scenarios, and XML Web services are easy to create in .NET.

The .NET Framework can bring at least significant benefits for certain types of manufacturing industry application development. There are, however, some downsides.

One aspect is dependence of the Windows operating system. While technically the core parts of .NET Framework are platform independent (and to some extent open standards), there are parts tightly bound to Microsoft Windows, such as the Windows.Forms namespace.

So far there are no significant implementations of .NET Framework on other non-Microsoft operating systems.

Another potential downside is syntax differences between programming languages. Making languages work in .NET Framework sometimes means adjusting language syntax.

This introduces compatibility problems in moving existing code into .NET. Visual Basic is a particular problem, as the changes between the previous version 6, which was not fully object oriented, to VB.NET with full object inheritance is significant.

A third aspect worth considering is protection of intellectual property. The Intermediate Language instructions are at a much higher level than the processor instructions in machine code.

Although current machine code compiled programs can disassemble, the result is of limited use. .NET programs disassembled from IL, on the other hand, will more closely resemble actual source code. They will also contain the information needed to understand data structures. Such disassembled programs make algorithms and code processes more transparent than with current environments, making it more difficult to protect intellectual property.

Based on the information technology complexities faced by modern manufacturing industry, new tasks must happen, and the constant demand for more data mandates specialized software systems. Combined with efficiency and productivity restraints, these systems must be easy to implement, integrate, and maintain. The future appears to favor .NET. IT

Behind the byline

Mikael Sundfors is a software architect in research and development at Beamex Oy Ab in Pietarsaari, Finland and a member of the Finnish Microsoft .NET Architect Council. His e-mail is mikael.sundfors@beamex.com.