Development efforts in the corporate world are changing to leverage the power and interoperability of the Internet. Focus has shifted from developing traditional client/server applications—which require strict definition of the data structures and protocols used to exchange data—to developing Web applications using XML. Like traditional client/server applications, Web applications exchange data between different logical entities over a LAN or WAN. But instead of using dedicated connections and binary data formats, Web applications use the public Internet and XML. Most Web applications are also similar to client/server applications in their need to access and update data stored in a relational database such as SQL Server. Web applications have to obtain XML query results from SQL Server and update SQL Server with XML-formatted data. Microsoft has satisfied these requirements by implementing many technologies within SQL Server 2000, XML for SQL Server 2000 (SQLXML), and the .NET Framework. (For an overview of these technologies, see "Selecting XML Technologies for Queries and Updates," April 2002, InstantDoc ID 24342.) These technologies provide a solid basis for building a variety of Web applications. However, processing database updates has proven consistently difficult.
Microsoft provides several options for updating a database, including OpenXML, XML Bulk Load, updategrams, and Diffgrams. We've explored OpenXML and XML Bulk Load in previous columns; now it's time to look at updategrams and Diffgrams. Each technology has significant drawbacks for rapidly building real-world Web applications—scenarios in which data is requested from a Web application, modified remotely at the client site, then returned to the Web application so that modifications can be stored in the database. Implicit in these scenarios are three requirements for the Web application. First is the need for optimistic update. A Web application needs optimistic update because of the asynchronous, short-lived, potentially unreliable Internet connections between client and server. Without optimistic update, application and database performance deteriorate swiftly because many locks are held until they time out. The second requirement is that the client doesn't need—and should have no foreknowledge of—the database structure. Third, the client needs a way to transmit changes to the data—including concurrency information—to circumvent competing updates that multiple clients make to the server. Updategrams and Diffgrams are similar technologies that support these three requirements to varying degrees. So, assuming you're building a Web application, which technology should you use?
Updategrams
An updategram is an XML document that describes the changes made to an XML query result. You can use updategrams with any SQLXML Web release to optimistically update your database. Updategrams also support updating one or more tables in the database corresponding to hierarchical relationships in the XML. For example, you can insert order items nested within an XML order element into the database's Order and LineItem tables. Although updategrams attempt to satisfy the three requirements for updating data, they fall short in several areas.
Primarily, updategrams aren't supported by ADO, SQL Server, SQLXML, or object models such as the XML Document Object Model (DOM). This deficiency reduces the usefulness of updategrams in three ways. First, because ADO and DOM don't support generating updategrams, you must implement client code that generates the updategram syntax directly. What's worse, this onerous task doesn't scale across projects; you have to implement the logic every time you want to produce an updategram. Second, Web applications usually require business logic to verify and validate the data before storing it in the database. Again, you need an object model to express the business logic and—because the technology uses optimistic update—to verify that the data wasn't changed between the time you retrieved the data from the database and the time you attempted to update it. Third, an object model ideally can give you access to the updated data and to the original values in a consistent manner. But again, you'd need to implement code that interprets the updategram syntax in addition to performing the business logic and concurrency checks.
Updategrams also miss the mark because they can't call stored procedures to perform a database update. Therefore, business logic, constraints, and referential integrity that you implement by using stored procedures are rendered useless.
The way updategrams express changes made to a data set can pose an additional problem. These changes are expressed in terms of the XML—not the relational database. Although expressing the changes this way is generally beneficial because it hides details of the database from the client, it also can exclude data that you might require to validate changes or execute business logic before you commit the changes to the database.
Finally, updategrams fall short in the way they're usually applied. Because updategrams are best used for batch processing, they would produce the most efficient results if SQL Server processed them the same way it processes T-SQL UPDATE statements. However, the current SQLXML implementation processes updategrams on the middle tier, generating SQL statements that SQL Server executes instead of directly processing the updategrams. So although updategrams appear on the surface to be a good way to update data within your Web application and might work for a narrow set of scenarios, their shortcomings prevent them from being generally useful.
Prev. page
[1]
2
next page 
