Flylib.com

Books Software

 
 
 

Practical Usage


Practical Usage

Let’s emphasize a few things we’ve mentioned over the course of the chapter. First, you should focus on building Web services that use the document-literal scheme. This is the scheme that’s being promoted by the WS-I in its basic profile. It also has much better potential for interoperability, especially with .NET applications.

Second, you should use WSDL if at all possible. If you have existing Java code, use Java2WSDL to generate a first cut at a WSDL file. Then you can clean up the file and modularize it. You can use the modularization we showed in the WSDL2Java example, or you can use the one that Java2WSDL uses (if you use Java2WSDL, you can have Java2WSDL do it for you). Once you have a good WSDL file, you should use WSDL2Java to generate the Java classes you need. If you need to work with existing code, then have WSDL2Java generate the skeleton classes, and use the prewritten forwarding methods in the skeleton to connect the skeleton to your existing code. Don’t forget to throw away the template implementation class if you use the skeleton this way.

Third, use TCPMon as a tool when you’re debugging. Doing so can save you many hours of frustration and give you some insight into what your code is doing.

Fourth, ask Axis to generate a JUnit test case for you and write a decent set of tests for your application.

Fifth, make sure you use the Ant tasks to save you from repetitive typing. You can also use the JUnit task for Ant to run your generated test case.



Applications

Much like XML-RPC, the applications for Axis and Web services are broad. Anywhere you can think of invoking a method on an object is a possible candidate for a Web service. The primary areas where Web services can make a difference are as follows :

  • Invoking functionality on a machine not owned by you.

  • Invoking functionality on a machine that uses a different language and/or platform.

Today, most of the activity in Web services involves using Web services to integrate heterogeneous applications within the same organization. We’re beginning to see some use of Web services to integrate applications across the Internet. eBay, Google, and Amazon.com have started developer programs that allow access to their applications via Web services technologies.

Perhaps your company will be the next one to expose pieces of an application to the world using Web services. Or, maybe you’ll create a new application that talks to one of the big players. In either case, Axis is a capable and reliable Web services toolkit.



Chapter 10: XML Security

Overview

XML is being accepted as a way of transferring information between application programs and computers. The volume of data that’s being marked up in XML documents is increasing daily. Some of that data is being used to conduct everyday business. The interoperability benefits of using a format like XML are significant; the drawback is that XML makes data human-readable , even when humans shouldn’t be reading that data. In this chapter, we’ll look at the problem of how to protect the integrity and secrecy of data stored in XML documents.

You might wonder why this is an issue. After all, the existing techniques for protecting documents should work fine. If you want to protect a document, you run it through an encryption algorithm, and the document comes out encrypted. If you want to certify something about a document, then you sign the document with a digital signature. Declaring the integrity of a document is easy—compute a message digest, and someone else can use it to verify that the document hasn’t been tampered with. To satisfy more than one of these goals at once, we know how to combine these techniques. What does XML bring to the table that requires a new solution?

The answer is that you may not want to sign or encrypt the entire document. You may only want to sign or encrypt an element or a few elements. Perhaps an XML document represents a bunch of information, but you only care about or want to be responsible for part of that information. Think of a document that represents a complex agreement among multiple parties. Each part may only want to sign the part of the document they’re responsible for. Likewise, some of the terms of the agreement may be between only two parties, but the entire agreement stands or falls together. In this situation, some of these terms may be a secret between the two parties, and they would like to keep those terms secret. You can implement this requirement by allowing that section of the document to be encrypted so only the relevant parties can decrypt it. Many applications of XML involve workflows (this is true of Web services as well), which have these kinds of requirements.

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

Technically, the solution rests with a pair of specifications from the World Wide Web Consortium (W3C): the XML Signature Syntax and Processing Recommendation and the XML Encryption Syntax and Processing Recommendation. The XML Signature Recommendation describes how to use digital signatures and hashing/message digesting to digitally sign entire XML documents and portions of XML documents. The XML Encryption Recommendation performs a similar function for using symmetric key encryption to encrypt part or all of an XML document. The XML Signature Recommendation uses the Canonical XML and Exclusive XML Canonicalization Recommendations.

XML Security is the xml.apache.org project that’s implementing these four recommendations. The project was started in September 2001 when the XML Security project at the University of Siegen in Germany donated a code base that implemented the Canonicalization and part of the XML Signature Recommendations. Since then, the project has completed implementation of the required portions of the XML Signature Recommendation and has begun implementation of the XML Encryption Recommendation. There has been some cooperation with the Apache Axis project, in particular a set of Axis handlers that can be used to digitally sign SOAP messages. These handlers use the older SOAP Signature specification, which has been superseded by the WS-Security specifications. The Web services project is interested in building a complete WS-Security implementation.