Conclusion

Download CD Content

Overview

Very often, the owners of a back-end system, such as a database, put a layer in between a Web site or other front-end system, including applications, to provide easy access to data. This way a Web site developer doesn’t need to be concerned about the structure of a CRM or financial database. The developer focuses on how to call a particular object instead.

The objects and method calls remain static while the database or other data can constantly change. This may require changes to the methods themselves, but as long as the signatures remain the same, a Web developer need not change any Web pages.

Think of this in terms of a database-driven Web site. If there are hundreds of pages with SQL queries embedded in them and the database structure changes, each of the SQL statements residing in those Web pages will need to be changed. This becomes a huge maintenance issue, especially as a project grows and database changes need to take place to handle the large amounts of incoming data. With putting up a layer of objects, known as a middle tier, that contains methods to access a database between a Web site and the database, only a handful of SQL statements need to change within the objects. Very often these methods return some sort of results set or object with attributes, so the signature rarely changes.

It isn’t just in accessing data in a Remote Database Management System (RDBMS) that a middle tier can act as a clearinghouse; it can also proxy requests to XML documents, Excel™ Files, CORBA objects, COM objects, or even other Web Services. If you support a middle tier like this, you provide your customers with a one-stop show for data, and they don’t need to be concerned with multiple clients accessing different data types. They can simply interact with your middle tier, and there really isn’t a better technology for a middle tier than a Web Service. Figure 12.1 demonstrates how Web Services may act as a middle tier.

Figure 12.1: A middle tier utilizing Web Services can act as a clearinghouse to various data sources.

Before Web Service became mainstream, it was very common to use either COM+ or CORBA as such a middle tier. If you have ever implemented one of these technologies, you understand the complexities of implementing and maintaining them. Both are fairly complex to implement, and it’s very tough to find developers with the expertise to deploy these technologies in a reliable way. In addition, database developers usually are charged with implementing and maintaining a middle tier, and these team members rarely have the skills to implement COM+ or CORBA. That’s the beauty of Web Services.

Web Services utilize Web servers and several different programming languages, and thus probably already fit into your infrastructure. Once a developer understands the basics of Web Services, they are easy to implement, especially because all the hard work, such as forming the XML for a request, are abstracted in higher levels of code. With less training and infrastructure needs, a middle tier that utilizes Web Services can usually be set up fairly quickly and cheaply.

This chapter examines a middle tier that abstracts access to an XML file containing user information and eventually the Web Service discussed in Chapter 11.