| A number of great books about Web Services are available, so the material presented here is intended to just be an overview. Note If you're interested in more details on Web Services technology, please refer to the following books: Java Web Services Unleashed (ISBN: 067232363X) by Robert, J. Brunner, Frank Cohen, et al; Sams Publishing Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI (ISBN: 0672321815) by Steve Graham, et al; Sams Publishing
How Web Services Communications Work The concept that Web Services communicate using XML was introduced at the beginning of the chapter. It's worth expanding on here. In case you've never seen XML, here's a sample: <customer> <name>Fred Flintstone</name> <address>123 Main Street</address> <city>Bedrock City</city> </customer> As you can see, XML representation of data is independent of any particular language. It's usually readable English and is extremely flexible in the ways you can use it to represent information. This XML fragment represents a customer and contains the customer's name, address, and city. The key to Web Services communications using XML revolves around three high-level ideas: -
Converting the data you need to send into XML. The Web Services client (which is Struts in this case) must turn the data into an XML format to send it. This is easy if the data you're sending are simple strings. It becomes more challenging if you want to send complex objects. This process of converting the data into an XML format is called serializing the data. -
Communicating the data to the Web Service server and retrieving the response. This communication is usually done using HTTP (although other protocols can be used). Data is communicated between the client and server using a protocol called SOAP (Simple Object Access Protocol). During this process, the data being communicated is generally transferred in character strings encoded using XML. -
Converting the data back into a useable format on the server. This process is referred to as deserializing the data. The program running in the server doesn't need to be written using the same language as the program running on the client. As long as the program on the server can deserialize the data that the client sends it, the conversion can work. This is how Web Services makes it possible to easily connect two systems together. It doesn't matter if the client and server run on different platforms. By using Web Services, both sides just need to know how to communicate using SOAP and how to serialize and deserialize each other's data. Comparing the EJB and Web Services Approaches Comparing this to the EJB technology presented in previous chapter, here are some highly generalized comparisons: -
Web Services are more flexible for communications between languages or platforms. EJBs are by definition Java specific. -
Using Web Services, the contract between client and server is defined by specifying the XML that can be sent between them. For EJBs, the equivalent is specifying the home and remote interfaces (which are Java-specific and more difficult for non-programmers to understand). One important benefit here is that nonprogrammers (for example, business analysts, program managers, and so on) might be able to coordinate the development of XML specifications. Specifying the interface between two systems using EJB technologies is not as straightforward. -
EJBs can be counted on to have certain container services supporting them. For example, they can be made transaction-aware if required. These types of container services aren't necessarily available in Web Services, although they might be, depending on your Web Services implementation. -
Web Services are generally sent over HTTP, although they aren't tied to it. This provides a great deal more flexibility when it comes to protocol support. EJB implementations are tightly tied to both JNDI and RMI technologies, which are more restrictive . The ability to use HTTP also makes Web Services more firewall-friendly. -
Because Web Services use XML for communications, sending complex objects between systems might require developing complicated serializers and deserializers. If you're using Java on both the client and server, you can send complex objects much easier by using EJBs. In summary, Web Services are more flexible and make interfaces between different systems easier to both specify and develop. EJBs are less flexible, but come with more sophisticated container support (for example, sophisticated transactional support). Also, sending complex objects directly between systems is easier using EJBs. Sending complex data using Web Services is possible as well, but might require custom serializers/deserializers to be written for both client and server. Anatomy of a Web Service Based on the previous section, here are the pieces of the puzzle that we need to use Struts with a Web Service: -
Web Service client software. This is the software that understands the SOAP protocol and knows how to serialize and deserialize the data. -
Web Service server software. This is the software that runs on the server that the client communicates with. It communicates using SOAP as well, and must know how to serialize and deserialize the specific data types you're sending to it. -
Business logic code inside the Web Service server. After Struts can communicate with the server, there must be something for it to do! For the sample application in this chapter, you use Apache Axis. Apache Axis, according to its developers, is "the third generation of Apache Soap!" They refer to it as " essentially a SOAP engine ”a framework for constructing SOAP processors such as clients , servers, gateways, etc." Apache Axis is among the fastest growing open source Web Services. The sample application in this book gets you up and running with a basic Web Service application based on Struts and Apache Axis. We hope that this basic application can provide a foundation for building production applications using these technologies. |
