Introduction

This book is about how you can use Extensible Markup Language (XML) and relational databases in the real world to solve real problems (as opposed to the sometimes academic world of standards bodies and other groups that promote standards usage). In other words, you can really use XML—it's not just hype. In this book, you will find concrete examples, insight into the application development life cycle as I've known it, and a discussion of the why, the how, and the where of building applications (with a special focus on Web applications) using the tools of XML and relational databases.

This book is not intended to be a comprehensive guide. It's an overview of the field, packed with good ideas and witty commentary, which should get you started in the right direction. The areas I've focused the most attention on are ones in which I have something useful to say. In other areas, I've provided an overview of concepts, and, instead of reinventing the wheel, I've included URLs that point you to useful and informative Web resources.

Who Should Read This Book?

This book is intended primarily for software developers who are managing small- to medium-scale projects. My experience is mostly from working on small development teams, where resource limitations often dictate that the person writing the requirements for a project is also the engineer in charge of design and coding. This book is written from that perspective.[1] If you work in a larger, more structured team or environment, you may find it strange that I'm talking about requirements gathering in one sentence and data modeling in the next, but this book can also be useful to you, if applied correctly. I've organized the chapters into the different stages of application design so that you can read through the entire book or flip to a particular piece of interest. In either case, you'll come away with something useful.

[1] A word on humor: In this book, I use humor because it's my way of expressing myself. My apologies to anyone who doesn't find me funny; nonetheless, I hope you find the information in this book useful and are able to read between my tired japes.

Familiarity with the concepts of databases and markup languages (specifically, knowledge of HyperText Markup Language—HTML) will make this book easier to understand. If you're new to markup languages and SQL, you'll still find this book helpful in explaining how they can be used together to develop applications. In addition, I recommend you read XML: A Manager's Guide by Kevin Dick (1999) for an overview of the XML language and its features. I also recommend SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL by Michael J. Hernandez (2000).

Why Would You Read This Book?

Good question! I started writing this book after I worked on a content management application at TheStreet.com, which is an online financial news service—essentially an electronic newspaper—complete with journalists, editors, reporters, contributors, and columnists. TheStreet.com's publishing model was “multichannel”; they published their articles to their Web site (one “channel” of publication). They also published to other channels, such as syndicating articles to other sites (Microsoft Network, Yahoo!, and so forth) and to devices (PDAs, cell phones, pagers, what-have-you). This book is a result of my experiences in building a content management strategy for TheStreet.com and an application of everything I learned during that time, combined with in-depth material that I've picked up along the way. This book is best read when you're starting work on a project that has a content management component and you're thinking of using XML and a SQL database.

The Structure of This Book

This book is broken into ten chapters, corresponding roughly to the stages of application design and development.

  1. Why XML? Notice I'm not asking the more mundane question, “What is XML?” This chapter instead delves into some specific examples of why XML is useful and why you want to start building systems with it.

  2. Introducing XML and SQL: A History Lesson of Sorts. Chapter 2 provides a brief description of XML, its history and structure, and what it brings to the table. A similar discussion of SQL and the rise of the relational database follows.

  3. Project Definition and Management. This chapter is a primer on getting the requirements for your system down on paper. It's included because I think this step is important, and I've often seen it done badly. Chapter 3 also discusses thinking about requirements from a perspective of building a “data-oriented” application. This chapter introduces two examples: a simple e-mail application and the CyberCinema Web site.

  4. Data Modeling. After you have gathered your requirements, you have to start thinking abstractly about your data. It's a tough world out there, and without a bullet-proof data model to protect you, you're going to wake up one day and realize your life has been a dismal failure.

  5. XML Design. You know why you should use XML because you read Chapter 1, but do you know where you should use it? What parts of your data make sense for XML, and what parts should remain purely relational? This chapter discusses the design of your XML documents, focusing on the document type definition (DTD) as a vehicle for this discussion.

  6. Getting Relational: Database Schema Design. Now that you have your data model and your XML design, how do you best write a data schema to get the job done? This chapter is brimming with helpful examples.

  7. Related Standards: XSLT, XML Schema, XML Query, and Other Flora and Fauna. What do you do with all this XML once you have it? This is where the Extensible Stylesheet Language (XSL) comes into play. XSL can be used to translate XML for display or internal purposes. It can also be leveraged to aid in partial decomposition. XML Schema provides an alternative to DTDs in defining XML document structure. Query languages on the near horizon promise to query XML documents and SQL databases.

  8. XML and SQL Server 2000. So how do you take all this XML and relational data and turn it into a real, living, breathing application—one that's actually useful and works? Here's one answer: Use the comprehensive XML support found in Microsoft's SQL Server 2000. This chapter presents a discussion of those features and delves into how you might use them to implement some of the strategies previously discussed.

  9. Java Programming with XML and SQL. Another implementation strategy for your XML applications is to build them using the J2EE (Java 2 Enterprise Edition) framework. Chapter 9 introduces this framework and discusses some of its XML-specific features.

  10. More Examples: Beyond Silly Web Sites. Chapter 10 provides other concrete examples of how to mix XML and SQL harmoniously.

My Day Job in the Multimodal World

Since I started writing this book, I've actually moved on from leading development teams. My most recent work has been on a more conceptual level, and some of the chapters of this book, particularly Chapter 3, which deals with requirements gathering, draw from this work.

My latest work is on something I call the “multimodal” world, a world in which consumers interact seamlessly with services through the most convenient devices or modalities at hand. The breakneck speed with which the e-revolution has engulfed us has left the world in a shambles, leaving consumers feeling helpless and frustrated. I've been looking back with a little bit of pragmatism and figuring out what we've really accomplished. People, who today have the tools of technology, have unprecedented access to information, products, and services, but they still don't have seamless access to the information they need. The popularity of the Net has forced everyone to become part-time computer support technicians. The advent of wireless and Internet devices and digital television has brought these technologies closer to becoming “appliances,” a ubiquitous and seamlessly integrated part of people's lives. But people have a much different expectation of appliances than they do of the Internet. Internet browsers are allowed to crash; microwave ovens can't. Appliances have to work reliably and integrate themselves into our daily lives—seamlessly.

Let me give you an example of how technology hasn't interacted seamlessly with my life. Recently I was waiting for a replacement American Express credit card to arrive in the mail. I called customer service at American Express several times and was assured that the card was on its way. Finally I received a letter from SDS (Special Delivery Services, a company I had no previous dealings with or knowledge of), informing me that they had tried to deliver a new American Express card, but nobody had been home. The letter listed a Web address, an e-mail address, and a phone number for me to use to arrange delivery. The form I filled out on the SDS Web site yielded a system error. I tried the e-mail option with no results. Finally I called the number and was placed on eternal hold.

The interjection of the unknown company, SDS, shatters the seamless integration of my experience as an American Express customer. SDS's lack of customer service isn't American Express's fault, but I'm still left with a bad taste in my mouth. Likewise American Express's “handoff” to SDS means that their customer service staff and information systems are unaware of the disposition of my replacement card. Unfortunately this sort of thing happens all the time, and the results are not always as innocuous as my charge card replacement problem.

Here's an example of how this scenario might play out in a world where consumers interact more seamlessly with technology (the multimodal world). When I discovered that my card was lost, I could have registered this information using my Internet-enabled mobile phone. A customer service agent would have called me to arrange for delivery. If I wasn't at home to receive the package, I could have received a message on my mobile phone, directing me to an interactive service or a Web page on which I could arrange for redelivery. Or I could have called my American Express customer service agent to arrange delivery, or perhaps they would call me (imagine that!).

This example implies a tight integration between American Express and its delivery company and an ability for consistent information to flow between different systems within American Express—their Web site, their customer service systems, their Wireless Application Protocol (WAP) systems, and so forth. That kind of integration, in turn, implies standard languages and protocols with which businesses can communicate with other businesses as well as with consumers. XML facilitates this layer of standardization by providing a framework on which to base those standard languages. For instance, American Express might use a specialized XML-based business-to-business (B2B) language to communicate with suppliers. XML is the glue that can make this kind of integration possible—both inside and outside an enterprise—which is why I'm passionate about XML becoming even more pervasive than it is today.

Another enabler of this world of seamless interaction is content management. In the multimodal world, consumers should be able to use whatever device is most conveniently at hand to accomplish their goal—make transactions, find information, send or receive messages, whatever. If I want to check the weather report for tomorrow or book a flight from New York to Hong Kong, I should be able to use any device, for example, a mobile phone. When obtaining weather information, I may want it spoken to me while I'm in a car, but I'll want to read it on the screen when I'm in a meeting. A mobile phone might be sufficient to determine weather conditions. For flight information, I might want to stop the transaction once I hear some of the initial fares and finish when I'm in front of a Web browser, or I might want to call a customer service agent who is aware of my fare search and preferences. This kind of consistent and seamless access to information in different formats implies robust content management, and XML is a key enabling technology for content management. XML also plays a role in the delivery of information and applications to different platforms because the languages these devices speak (such as WML and xHTML) are built on top of XML.

An “emergent property” of a system is a property or capability that “emerges” only after the pieces are put together in the right way. If you mix a bunch of proteins with water in a bowl, you wouldn't expect them to start reciting from Shakespeare's Hamlet, Prince of Denmark, but the human brain, which is essentially a mass of neatly arranged proteins, has emergent properties of intelligence, self-awareness, and creativity. The proliferation of Internet-connected devices and the widespread adoption of XML and XML-linked technologies in B2B, B2C (business-to-consumer), and B2E (business-to-employee) communications and transactions will develop an emergent property: the radical transformation of global business. As astounding as the rise of the Internet and the industry shift toward e-enabled services have been over the past five years, it is nothing compared with the transformation of business that is to come.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.12.240