Have you heard the news? The Internet is moving into its third generation, and with it comes a significant paradigm shift. Software will move from something you get on a CD and install on your PC to something you subscribe to and use across the Net. There are several names for the new application server provider approach, such as "applications pay-per-view," "rent-an-app" and "self-serve software."

Microsoft has the most extensive plan for this transition, but other vendors are also in the game. Obviously, the shift will mean across-the-board changes to how software products are developed and delivered. The differences may be as significant as the change from DOS to Windows.

But what impact will all this change have on software globalization processes?

This article provides an overview of the move toward Web-based applications and predicts some of the areas of impact on global software delivery.

Roots of Change

The primary driver behind the latest revolution is that people want to get at their data from wherever they are, using whatever device they have handy. Anyone who occasionally works while away from the office knows how frustrating it is to find that you forgot to e-mail yourself that one critical file. Or maybe you have the file and need to send it to a co-worker who has a cell phone but no computer.

Java made the first step toward solving part of this problem. It allowed one set of code to be run anywhere. But it didn't address the problem of how to get access to data and how different applications could work together.

From the development end, developers and integrators want to use a wide variety of objects which were created a variety of ways — that is, by different people using different programming languages.

Providing "software as services" reduces the challenge of connecting disparate platforms, clients and servers together and allows information to be moved around much more easily. Addressing users' needs, Microsoft's Web site claims that they will make information available "any time, any place, and on any device." User information will be stored in centralized databases so that people can move from place to place and access what they need.

In addition to making users and developers happy, Web applications should also make administrators' jobs easier. Installation and backup of these applications will be transparent to users, and updates are easy to implement.

Players

Microsoft is the most vocal player in the Web-applications game, but it isn't the only one. All the big software names are offering solutions. In fact, Sun, Oracle and Novell have been focused on Net-based services for some time.

A table in this article lists the names of Web-based offerings from competitors.

While Microsoft is a more recent arrival to the Web-based application playing field, it has the most complete architectural vision of how the whole thing will work. The new platform is called the Next Generation Windows Services, and includes Microsoft.NET. Given the ubiquitous nature of Microsoft operating systems, browsers and applications, it is likely that the company will be a key player in the Web-based software transition.

What's in It for Microsoft?

One reason for Microsoft's push is a need to change the company's revenue model. Microsoft management has long been interested in creating an annualized income model instead of the current one-time payment approach for software sales.

A big portion of the company's revenue stream currently comes from the Office suite, and Microsoft wants to capture that existing market going forward into the .NET world. It will therefore be critical that Web-based applications "feel" like the ones people are used to using. The new Office.NET products won't be out for another year or two, but in the meantime, upcoming versions of desktop-based Office products (Office 10 and 11) will begin to incorporate .NET technology. Exposing traditional Office users to new features should make the transition to Office.NET a bit smoother once those products are actually available.

The Microsoft Approach

The Microsoft vision is "an Internet made up of an infinite number of interoperable Web applications which together form a global service exchange network."

The .NET platform is based on the interaction of three key areas. At the server end, new operating systems will be required. Microsoft has announced a number of operating systems which perform varied functions. At the client end, operating systems will need to support XML tags. And in the middle, XML will work with SOAP (Simple Object Access Protocol) to get information back and forth between the two ends.

The .NET Compact Framework is a variation designed to run on Windows CE and other embedded operating systems, to support non-PC devices.

Moving to Web-based applications will obviously affect users, but because of the architectural changes, network administrators and developers will also need to change the way they work.

Impact on the Development Community

In addition to providing their own Web-based suite of Office products, Microsoft is also creating a set of application development tools to encourage developers to adopt the technology. The move to service-based software has a significant impact on how developers create applications, and Microsoft wants as many developers as possible to hop on board.

Given the difficulties with shipping product upgrades out to existing customers, the traditional approach to software design was to build it with as many features and capabilities as possible so that users don't have to upgrade too soon. The software-as-service model drastically reduces the work needed to deliver product updates. This means that the focus will be on building a modifiable infrastructure and architecture so that users can adjust the software on an ongoing basis as business conditions change. Abstraction of architecture, business rules, data and delivery allow this customizable approach.

Developers working with the .NET platform can create applications which pull information from a variety of sources using their favorite programming languages.

Key Technology Components

The key technology components of the Microsoft strategy are described below. Additional information is provided in the Acronyms and Definitions sidebar.

XML (eXtensible Markup Language) A markup language which defines the content of data rather than its presentation. Increasingly referred to as the lingua franca of the next-generation Web services. XML is a cornerstone of all vendor approaches to Web-based applications.

C# (C Sharp) Microsoft's first component-oriented language in the C/C++ family. Follows the CLS (Common Language Specification) requirements in order to properly generate the Microsoft Intermediate Language (MSIL). C# is the first programming language that is .NET-ready.

CLR (Common Language Runtime) A sort of virtual machine on which MSIL runs. CLR manages resources and monitors application execution.

ADO+ The XML and SOAP-based mechanism by which .NET applications get data from databases.

SOAP The protocol which allows the .NET platform to share data messages with other platforms. SOAP specifies how to encode HTTP headers and XML files so that programs on various computers can pass and receive information. SOAP works with any operating system, any programming language and any platform.

UDDI An XML repository of information about businesses such as name, product, location and services. Functions like a yellow-page service for the Web.

Visual Studio.NET The new Microsoft development environment which includes a Component Designer, an XML Designer, Web Services/Web References and a Multi-tier Data Form Wizard.

VisualStudio.NET is a layered architecture. The top layer, Visual Studio Design and Development Environment, is a visual designer for drag-and-drop development. The next layer, .NET Framework, uses a Simplified Class Framework as building blocks (forms, data and so on). Below that is the technology substrate (XML, HTTP, SOAP, HTML) of open Internet standards.

Managed Code provides metadata describing data, location of references to objects and exception handling tables. This allows CLR to provide exception handling, security, automatic lifetime management, debugging and profiling.

Assemblies Comparable to a logical .exe or .dll. Assemblies are the primary building blocks of .NET applications. They are collections of functionality that are built, versioned and deployed as a single implementation unit (as one or more files). The assembly level is therefore where reuse, versioning, security and deployment take place. Assemblies can include PE (Portable Executable) files with metadata and resource files such as .gif or .jpg files. There are two types of assemblies: private and shared.

Wide Programming Language Support The .NET platform plans to support a wide range of programming languages such as Java, C++, Perl, Cobol, Visual Basic and others. This is great news for devotees of these languages who previously have not been able to develop for the Microsoft world.

In order to properly generate MSIL, programming languages must comply with CLS requirements. This means that all languages will need to be revised in order to run in the Common Language Runtime. So, while a wide range of programs will be supported, they will be variations of the languages which are in use today.

Microsoft plans to provide migration tools to help developers move to the next-generation languages. The tools won't be able to perform 100% of conversions, however, and architectural changes to applications may also be required.

But given the degree of change in the overall approach, it is not surprising that programming languages also need to evolve.

Technology Interaction While the .NET architecture is specific to Microsoft, .NET applications will still be able to communicate with competitor products. This is because the basic technologies for all of the new platforms are the same: XML, SOAP and UDDI. A company using the Microsoft framework should, therefore, be able to work with another company using Oracle-based or other services.

Key Components for Internationalization

Here, briefly, are some of the key .NET internationalization components.

RegionInfo is used to determine the unit of measurement and to map region codes to region names.

CultureInfo is used to format dates, times and numbers, to sort strings and to determine the language for text by specifying which localized resources to load.

CultureInfo replaces LCIDs, which were used in ASP to identify a locale for National Language Support.

Culture Tags are defined by RFC1766 and are composed of two-letter primary and secondary tags.

Culture information is associated with assemblies and individual resource files to allow for retrieval of localized versions.

Linking .resources A link is used to add the .resources binary to the main assembly or to create a satellite.

Key Classes Some key classes for localization are Calendar, Char, DateTime, Number, RegionInfo and String.

ASP+ Enhancements. Encoding can be set independently for ASP+ page files, requests and responses. Culture and encoding can be specified programmatically, by page directives, or in configuration files by application or machine. ASP+ automatically sets the CharSet attribute in the HTTP header so that manual checks of meta tags are not required. This increased level of control ensures that encoding is consistent.

ASP+ has a flexible resource model so developers can choose how to deal with localized resources. They can include resources in source code, separate resources from code using .resources files, or use satellite assemblies if pages are not created on the fly.

Rollout of .NET. Given the technical changes required to support .NET, the transition will take some time. XML needs to become more fully integrated into browsers, servers and applications, and the next generations of programming languages need to be refined.

The final version of .NET is scheduled to be available early in 2002.

Impact on Multilingual Product Development

Now that we've covered the basic issues related to Web-based application delivery, what will be the impact on multilingual software development processes?

Platform support. Platform support is always an issue with multilingual software. The hardware and operating systems most commonly in use by businesses in the United States may not be the same as those used in the home. Systems used by graphic designers are different from those used by accountants. Consider how much this variability increases when you factor in different types of users in various countries. Adding Web-based application support to the overall mix requires that you continue to do a good job of understanding how your target users prefer to run software. It's hard to say what the adoption rate around the world will be for .NET and other on-line applications. For some period of time, both desktop and Web-based versions of multilingual products will be required. Supporting both delivery types will take time and money.

Character set support. One of the biggest challenges for multilingual software development is ensuring that required character sets are supported and can be properly displayed. XML uses Unicode by default, and since so much of the Web application framework is based on XML, character support should be much less of an issue than in the old world of software. The ASP+ encoding specification enhancements will also make character handling simpler. In addition, browsers continue to improve character support, and while browser version variation is currently an issue, as time draws closer to the Web-based applications world, browsers with solid character set support should be more widely in use.

Multiple devices. Since one of the primary drivers behind the Net revolution is to allow people to access their data using whatever devices they like, the impact on multilingual software development is pretty significant. This issue is similar to the challenge of platform support, but with the additional difficulty of requiring variations on display formats. Your target audience in Thailand may use phones rather than PCs, and a "rich" dialog box that was designed for use on a PC and is packed with options will not work when accessed from a cell phone. While XML provides a great mechanism for separating data from display, the challenge is to ensure that all the appropriate display formats are created so that people logging in from PCs, phones and PDAs all get the format which works best for them. So now instead of designing one screen layout for a US-based product to be displayed on a PC, a global software company needs to think about not only which languages to support, but also which devices.

Some languages will require unique changes. For example, small-format German displays may dictate that screens include fewer options since German words are longer.

Because of these issues, user interface design for multilingual software in the Web-based applications world will require more time and effort.

"Universal canvas" concept. The universal canvas is an integrated environment for applications, e-mail and the browser. This concept raises interesting linguistic questions. Current software localization processes result in wide-ranging terminology differences among software manufacturers and even among software products created by a single manufacturer. When information is merged from a variety of applications and sources, the resulting language could become a hodgepodge of translated text. This may create a need for controlled or standardized language for applications.

Better translation tools. Implementation of XML has already made a significant impact on the evolution of computer-aided translation tools, and the next generation of tools should take an even bigger step toward making the localization process easier. XML filters for translation database tools will become more sophisticated, and translators will continue to become comfortable working with tagged files.

Database content storage. Content will increasingly be stored in databases, which make translation simple in many ways because content is completely separated from code. Text in databases creates its own problem for translation, however, because text strings appear in isolation. Translators may not have the context they need in order to produce an accurate translation.

Easier Global Collaboration

The software localization process is typically conducted by a geographically distributed team. As applications move from being desktop-based to Web-based, data access for global localization teams is sure to improve. More efficient central access to project files should increase efficiency and help global teams operate seamlessly.

The localization industry is probably the largest group to consistently (and historically) conduct projects using resources around the world. The Web revolution should therefore be a giant step forward in making the logistics of localization easier.

Testing

Multilingual software testing is a challenge, particularly when dealing with Web sites. It's hard enough to test a desktop-based application in six languages and three platforms, let alone having to deal with the complexity of browser versions, database interactions and all the various levels of communication points and system interactions that go along with transferring information across the world. The Net revolution will force software developers to deal with this change, and for some time, multilingual testing will have to be performed on both desktop-based and Web-based systems. Performance is always an issue, and it will be even more important as people compare working on the Web to working on their hard drives.

Complexity of testing will also be increased due to the use of non-PC devices for accessing and running Web-based applications. Developers need to do a thorough job of targeting intended users and platforms, and testing must be designed to exercise all of these potential user interfaces.

Changes Will Evolve

The third-generation Internet is upon us and with it the advent of significant changes in the multilingual software development process. The changes will evolve over the next year or two, giving us time to understand the differences and better gauge the impact on our processes.