Migrating to XML and Web Services

The focus of this guide has been application migration, not application integration. However, application integration requirements are a major component of any application migration.

Recent developments such as eXtensible Markup Language (XML) and Simple Object Access Protocol (SOAP) have the potential to transform both the architecture and development of applications, and can have considerable impact on their migration.

XML, SOAP, and Interoperability

Most of the application migration scenarios discussed so far in this guide use some type of application programming interface (API) for interoperability. This may include one or more of the following API examples:

• Static libraries

• Dynamic libraries

• Shared memory sections

• Remote procedure calls (RPCs)

• Component Object Model (COM)/DCOM

• Common Object Request Broker Architecture (CORBA)

A major problem with any of these methods of integration is that applications require compile-time knowledge to communicate with each other. For an RPC client to use a function exposed by an RPC server, the client must compile stub code generated by an interface definition language (IDL) compiler to actually make the call.

Interoperability and application integration would be much simpler if applications did not require compile-time knowledge and if all potential clients and servers used common method invocation and marshaling rules. XML, SOAP, and Web Services provide such facilities.

XML

XML does not solve interoperability problems directly. However, it enables self-description of data items and data types, thus providing a basis for self-discovery of data definitions and common rules for marshaling. These concepts enable the standardization of cross-application interoperability. Because XML is a platform-independent technology, the value of XML-based services in an application migration is clear. Code developed to use XML can easily migrate from UNIX to Windows as long as an XML parsing component is available on the target platform. This is certainly the case with Windows.

SOAP

Simple Object Access Protocol (SOAP) builds on the capabilities of XML, applying them to method invocation and data marshaling. First, SOAP uses XML to describe the argument signature for methods, enabling the definition of signatures at run time instead of at compile time. Developers no longer have the burden of compiling IDL stubs into the application. Second, developers need not concern themselves with data marshaling because SOAP handles this. All applications need is a way to parse the SOAP message.

The following code is a sample format for a SOAP message that uses an HTTP post method. This sample posts the SOAP call SampleMethod using an argument arg1 with a value of 123456789 to the uniform resource identifier (URI) contained in the POST statement. The MessageType call indicates a SOAP request.

 POST <URI of SOAP Method> MethodName: SampleMethod   InterfaceName: <Optional Name of Interface>   MessageType: Call   Content-Type: text/xml-SOAP <SampleMethod>     <arg1>123456789</arg1>   </SampleMethod> 

SOAP provides the basis for application interoperability on the Microsoft .NET platform. If a migrated application needs to access .NET services on Windows, the most important requirement is to build in SOAP support.

Web Services

Building on the concepts of XML and SOAP, developers can also use Web Services to bridge the gap between traditional UNIX distributed object models, such as CORBA, and XML on Windows. A Web Service represents a way to expose SOAP calls by using HTTP. A Web server (such as Microsoft IIS) exposes the Web Service by using a URL. Microsoft Internet Information Services (IIS) uses a special file extension (.aspx) to indicate a Web Service.

Because SOAP and Web Services invoke remote functions more flexibly, developers can wrap legacy distributed object models or method invocation methods either as Web Services or as clients for Web Services. Wrapping involves writing an additional layer of code that provides an interface between Web Services and the legacy environment.

A Web Service Definition Language (WSDL) file enables access to the definitions of interfaces and arguments in a SOAP service in an XML format. If a client process needs to run a SOAP interface exposed on a Web server, the client can first request the WSDL XML file, and then use XML to discover the exposed interface and data types for the required arguments.

Using XML in the Migration from UNIX

Although a migration to XML is probably out of scope for the base application migration from UNIX to Windows, XML can still play an important role. Using XML in migrated code can help bridge the legacy UNIX environment to the new XML-enabled tools on Windows.

This section looks at strategies for using XML-enabled tools on Windows by using two- tier UNIX applications. By its nature, data plays a primary role in this type of system.

As an example, consider the Microsoft Visual Studio development system automation example from Chapter 7, Creating the Development Environment. This scenario presents a batch build development environment. The developer uses Visual Studio projects for debugging. The solution uses a Windows Scripting Host (WSH) script to automatically create a Visual Studio project based on project definitions contained in an XML file. The solution makes use of XML for the following reasons:

• Windows Scripting Host has built-in support for XML.

• The Microsoft Visual Basic Scripting Edition (VBScript) script that it generates uses the Visual Studio Automation model and can also work with the XML document object mode (DOM).

Note  

In this chapter, XML document refers to XML contained in an XML schema.

In this example, the migrated batch makefiles act as the legacy data source. To extract the flat data file (makefile) and add this data to an XML document, a process is needed. For example, the process can parse the makefile for keywords (such as CFLAGS, INCLUDE, LIB, and so on), then use WSH to generate XML based on the results. This task can be automated by using Interix shell scripting to parse the makefile, and then using the output of the Interix script as input to a WSH script to generate the XML. Here, UNIX-style scripts are used at the front end to create XML. After the project definitions exist in XML, WSH can be used to create the Visual Studio projects.

The process of parsing the makefile and generating an XML project definition creates a connector or adaptor between XML and the non-XML environment. This is a common best practice for bridging XML data or other document types. Connector functions translate and map data between XML documents and external sources. This concept is discussed in greater detail later in this chapter.

Using XML and Web Services on Multiple Platforms

XML, SOAP, and Web Services are not unique to the Windows platform. Most of the major software companies have adopted these technologies. Web Services developed on Windows can be accessed from UNIX. Additionally, Web Services written for UNIX can be accessed from Windows. In other words, it is simpler to migrate applications that use XML, SOAP, and Web Services between the UNIX and Windows platforms.

For example, the Apache.org organization provides a SOAP toolkit for building Web Services for the Apache Web Server on UNIX. This makes Web Services available for legacy integration on UNIX. Its advantage is the use of SOAP for cross-platform integration. With SOAP, the Windows client need not implement legacy RPC calls or some other legacy UNIX network invocation method.

XML and Web Services Beyond the Firewall

The designers of XML and Web Services created technologies that should function just as well in the extranet as they do in the intranet. However, the technologies create new challenges for virtual applications that cross the firewalls of corporations, such as:

• Security, including both authentication and authorization.

• Cross-directory lookup, which requires a directory of directories.

• Location service; that is, applications need to locate and attach to available Web Services.

Security

Independent organizations need to agree on how to identify a valid user and how to determine that user s access rights. This requires an independent, trusted security authority that each organization can access for user credentials.

Microsoft Passport, for example, acts as a single sign-on authority for user credentials outside the corporate firewall. This provides the organizations in the virtual enterprise a common place to obtain a user s credentials without compromising private data about that user contained within an organization s firewall.

Directory Lookup

Within the firewall, a corporation can implement an Lightweight Directory Access Protocol (LDAP) solution. To share some of this information with the users of other corporate directories, the corporation can use a metadirectory. A metadirectory is a way to look up common information that exists in multiple directories, which helps to solve the problem of resources located in another corporation s directories.

Microsoft offers a metadirectory solution called Microsoft Metadirectory Services (MMS).

Location Service

After an enterprise has set up cross-firewall user credentials (by using Passport, for example) and can find users and resources in different directories (by using MMS), a developer targeting this environment still needs to find the appropriate Web Services to perform the business functions. The Universal Description, Discovery, and Integration (UDDI) registry can perform this service. UDDI provides an application with a set of APIs to locate and bind to a particular type of service.