Mercosul (or Mercosur) is a trading zone among Brazil, Argentina, Uruguay, and Paraguay founded in 1991. Its purpose is to promote free trade and the movement of goods and people, and skills and money between these countries. The four member countries combined represent the fourth largest economy in the world.

As part of their cooperation, the member countries need to exchange data on imported and exported products. In a first attempt, Argentina, Brazil, and Uruguay tried to exchange information using magnetic tapes. It didn't work out, due to the difficulty in matching the operations and the different types of registration of each system in a single, consistent way.

In the second attempt, Brazil and Argentina connected their respective host systems by establishing an active connection to exchange data but this solution had issues by not being reliable and also just supporting batch-mode interactions. Moreover, another big problem was that it was not possible to exchange some detailed information between the systems.

Each country was running a different application on a different platform and was challenged to exchange data between these different systems. As a requirement, the data exchange should be easily accessible with precise or selective searches, avoiding unnecessary interchanges with large amounts of data. It was also important to control access to the system for security reasons.

The Brazilian Ministry of Trade has its data stored in an Adabas database in a mainframe. Most of the applications are developed in Natural, while some Java applications running in WebSphere Application Server 4.0.1 for z/OS exist as well.

Argentina uses Microsoft IIS, Microsoft Visual Basic .NET, and an Oracle database. Paraguay uses Linux with Java and Apache Tomcat with an Oracle database running on AIX. Uruguay runs Linux with Java and Genexus.

Serpro is a federal organization for income tax data processing in Brazil and it was chosen to represent Brazil in the Mercosul project. In 2002, a group of Serpro architects went to an IBM developers' conference and heard about "Web services" and immediately realized the potential for this technology to be used for the Mercosul project. Web services technology promised to allow application interaction based on standardized XML messages across platforms and programming languages, which made it a good fit for the challenge at hand.

The First Iteration
The first step was to connect the Brazilian and Argentinean systems. Both systems would act as a service provider and a service consumer. They used different Web services environments and, back in those days, interoperability problems were common. Hence, the decision was made not to create a common, shared Web Services Definition Language (WSDL) definition of the service, but to let each side define their own service description. The only thing that was formalized was the structure of the data that was sent back and forth.

One of the first questions that had to be answered by the Serpro team was how to expose the functionality that was developed in Adabas as a Web service. Looking at the existing support for Web services in WebSphere, it became clear that a JavaBean proxy was the right answer. As soon as a Java front end to the Adabas application was in place, standard tooling in WebSphere Studio could be used to generate all the required artifacts for the Web service. The JavaBean would run inside the application server on the mainframe and access the back end. The application server would receive the incoming simple object access protocol (SOAP) message, parse it, and invoke the JavaBean.

The JavaBean was developed and WebSphere Studio took care of the rest. At the time, WebSphere used the Apache SOAP engine for its Web services support. The resulting WSDL file was sent to Argentina to be used there to create the respective client code.

The same happened the other way around. The team in Argentina created a Web service based on the .NET framework, and a WSDL file describing that service was sent to Brazil. The Serpro team used WebSphere Studio tooling to generate a proxy for the service and created a Web application around it.

If you have followed the evolution of Web services technology over the past few years, you will have heard about differences in encoding and invocation styles between Web services from different vendors. The Java community preferred "RPC" style services with so-called "SOAP encoding," whereas Microsoft favored "document" style services with "literal" encoding. The respective WSDL files from Brazil and Argentina reflected this, and some changes had to be made to both to make it work on either end. These and other problems related to interoperability are all resolved today between the major Web services vendors, but more about that later.

Listing 1 shows a subset of the WSDL file for the service that is currently offered by Brazil.

Serpro also added some extensions to the code to allow for logging and monitoring of their service. Access to the service was secured by running the connection over a virtual private network (VPN). After some testing, the solution went into production in both countries. The typical transaction rate of the system is very low, so performance and throughput are not yet big concerns. After some time, Paraguay and Uruguay joined the project and developed their own versions of the Web service. They are also in production today, running on Linux, as we had described earlier.

Figure 1 shows the architecture of the overall system.

What's Next?
Currently, Serpro is in the process of migrating towards WebSphere Application Server v5.0.2 on zOS. The Web services engine in this release is a new, high-performance IBM SOAP engine supporting message exchange across both HTTP and JMS. It leverages an XML parser that is optimized for SOAP parsing, giving it significantly better performance than other Web services engines.

The new version allows Serpro to start using standards like JAX-RPC (http://java.sun.com/xml/jaxrpc/), which is the new standard API for programming Web services in Java, and JSR-109 1.0, which is the new J2EE deployment model for Java Web services.

Among other things, JAX-RPC defines a mechanism with which it is possible to manage service invocations by intercepting request and response messages without having to change the actual service consumer or provider. In J2EE, handlers can be configured in a deployment descriptor, without writing any code, providing you with a powerful way of controlling SOAP messages as they pass through your system. For example, using JAX-RPC handlers it is possible to implement logging and other management features. Serpro will utilize this to identify and log client access to the system. Developing JAX-RPC handlers for this allows them to keep management code separate from business logic.

WebSphere Application Server v.5.0.2 also supports the "WS-I Basic Profile" (http://ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html), which will all but eliminate interoperability problems with other Web services engines. WS-I is an open industry organization chartered to promote Web services interoperability across platforms, operating systems, and programming languages. The organization works across the industry and standards organizations to respond to customer needs by providing guidance, best practices, and resources for developing Web Services solutions (www.ws-i.org).

As we had mentioned earlier, the countries participating in the project only share a common data schema describing the exchanged message structure. Given the progress that was made around interoperability, it should now be possible to share the entire WSDL definition across systems with only the respective endpoint addresses being different. For example, WebSphere Studio now follows the WS-I recommendation to create "document/literal" Web services by default, thus allowing sharing between the exact same SOAP binding and the .NET system.

Moreover, this release of WebSphere Application Server supports the WS-Security specification, which describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. While there is no immediate plan to deploy the Mercosul services with WS-Security enabled, it becomes an option for offering the service outside the VPN, improving overall accessibility of the system. Note, however, that Apache SOAP does not support WS-Security at this time, so that the systems in Paraguay and Uruguay, both of which utilize Apache SOAP, would have to be upgraded.

Summary
The Mercosul trade system is a great example for the potential of Web services technology. It connects systems running on a variety of platforms, developed in a variety of programming languages. Other countries could join the project at a later time simply by providing and consuming the same services, regardless of implementation. Serpro could utilize their existing mainframe system by developing and running their service implementation with WebSphere Studio and WebSphere Application Server. As new standards evolve, they can start expanding on the quality of service characteristics of the overall system, beginning by adding support for WS-Security.