Web services have proved the long-awaited solution for communication between distributed applications running on a variety of platforms and created using a variety of programming languages. This article explains how to integrate different applications.

Web services have proved the long-awaited solution for communication between distributed applications running on a variety of platforms and created using a variety of programming languages. The use of XML-based industry standards such as SOAP, WSDL and UDDI has made it possible to exchange data and services between applications running not only within such frameworks as J2EE or Microsoft .NET, but also applications written in practically any other language, whether compiled (for example C++, Pascal, Cobol) or interpreted (Perl, Python, PHP and others).

The rapid development of web service technologies was spurred by the fact that web services are loosely coupled with the applications they serve logic to, so adding a web service has very little effect on existing application components, making it possible to gradually integrate web services with existing functionality. The approach also allows existing capabilities to be served up using web services without costly modifications to the core system, and with a minimum risk of failure.

Web services provide a way to integrate disparate applications into one large distributed system, effectively eliminating the need to deploy costly middleware to translate between the various applications' communication methods. Large web-based corporations were quick to notice the benefits of using web services and start serving functionality using this technology - Google, Amazon, eBay, Yahoo and Allegro (largest Polish auction site) to name but a few.

The level of interest in the technology is best attested by the fact that over 50 000 programmers are currently registered in the Amazon web services program. The eBay program currently has over 8000 corporate and individual participants, with the 600 applications currently using the eBay API accounting for some 40% of all transactions.

Figure 1. Web service architecture

Problems with existing toolkits

A quick web search brings up a multitude of web service development tools. Some of the most popular include:

• Sun's JAX-WS and JAX-RPC: http://java.sun.com/webservices/jwsdp/index.jsp,

• Axis 1.x: http://ws.apache.org/axis,

• XFire: http://xfire.codehaus.org,

• WASP: http://www.systinet.com/products/systinet_server,

• WebLogic Web Services: http://e-docs.bea.com/wls/docs81/webserv/

However, selecting a specific application to suit your needs is not an easy task. Each of the above makes it possible to serve up application logic as a web service, but each also has disadvantages that can make it cumbersome or impossible to use. To start with, let's try to define the features that any sensible development tool should have:

• ease of use - applications can be developed faster (and therefore at a lower cost),

• high performance - more clients can be served without having to invest in additional hardware,

• consistent API - easier maintenance and increased development comfort,

• low price - faster return on investment.

Unfortunately, most of the tools listed above fail in one or more of these areas. Small and medium businesses usually cannot afford to buy costly (though very good) commercial packages, such as WASP or Weblogic Server. The performance of several solutions is also questionable. The typical problem is that SOAP messages are processed using DOM, which usually involves first building a document to represent the XML content of the message and only then creating an application object corresponding to this data. This results not only in lower performance, but also considerable memory overhead, with the document tree frequently taking up many times the space of the data itself. Such performance issues apply to Axis 1.x (Axis 2 will use much faster stream-based XML processing using StAX) and JAX-RPC. Moreover, few commercial offerings shine on ease of use, often requiring complicated configuration and additional operations during installation, or providing awkward APIs that make it much harder to properly understand the tool and develop applications.

Figure 2. Service description in WSDL format

Why XFire?

The XFire project came about in response to problems with developing web services using available tools (including the ones listed above). The aim was to create a free toolkit with all the functionality of commercial solutions, but without their shortcomings. Here is how XFire scores on the features outlined above:

• Low price - XFire is completely free and open source.

• High performance - performance was a key requirement for the project, so the server architecture was based in its entirety on XML processing using the high-performance StAX model, allowing messages to be processed incrementally with minimum memory overhead. The project also features a purpose-built framework for mapping XML messages to Java objects, called Aegis, which is one of the fastest solutions of its type. Benchmarks have shown that, depending on SOAP message size, the XFire engine is 2 to 5 times faster than the market-leading Axis 1.x.

• Consistent API - XFire has a clear and intuitive component-based structure (http://xfire.codehaus.org/Architecture), which makes it possible to quickly grasp its operating principles.

• Ease of use - application success is largely dependent on the time required for development, so a key goal of the XFire project was ensuring maximum ease of use. The aim was achieved by introducing a simple and consistent architecture and making installation and configuration as simple as possible (though still allowing complex solutions to be deployed), as demonstrated by the examples that follow.

A d v e r t i s e m e n t

sum:

0 €

» Library of the Month
» Workshop
» Software Engineering
» Programming Tools
» Interview
» High quality and
secure programming
» Reverse Engineering
» Portable GUI
» Artificial intelligence