Conclusion

Web services are an exciting and powerful technology. By using a distributed, object-oriented model for our application, we can tap into this new technology and still reuse our existing business objects, logic, and data.

In this chapter, we discussed a way of viewing web-services technology as a useful tool in creating an interface to our business objects. This is just another type of interface, on a level with a Windows Forms or Web Forms interface, but instead of being targeted directly at the end user , a web-services interface is targeted at other applications.

We also discussed the fact that a web-services interface, once published, must be viewed as an immutable contract between us and an unknown and unpredictable number of consumers. Any change to our web-method names , parameters, or return types will break consumers. This is complicated when we're dealing with complex data types, because our contract then extends beyond the methods to include the layout of the data we're sending and receiving.

An easy way to define the data layouts for complex data is to use user-defined types, or struct types. These are easy to create, easy to read, and are automatically exposed as part of our web service. This means that consumers can easily determine the data layouts, based on the WSDL definition for our service.

Using all these concepts, coupled with a custom SOAP header to handle security, we implemented a web service containing web methods that expose all the functionality of our business system. Because all of our business logic, including validation and security, is in our business objects, the web methods themselves contain relatively little code.

In Chapter 11, we'll close the book by discussing some ways to do reporting and batch-processing operations in a distributed, object-oriented environment.

Chapter 11: Reporting and Batch Processing

Overview

Up To This Point in the book ”and although you may not have realized it ”our focus has been on online transaction processing (OLTP) applications. We've discussed how to create business objects that model entities within our problem domain, and how to use them to retrieve and update data from a data store. This is all very important, and most real-world applications have a great deal of OLTP functionality.

However, most real-world applications also have functionality that is not interactive, and that's the focus of this final chapter. For example, most applications provide some form of report generation. End users often want to view or print lists of data or groups of data, or to have huge amounts of data compressed into summaries. Retrieving and manipulating all the data required to generate reports is often very complex and resource intensive .

Similarly, many applications need to do batch processing, which typically also involves manipulation of large amounts of data as part of a single process. For instance, most sales systems have end-of-day processing, where they take all the sales transactions for the day and post that data into the accounting system. Most manufacturing systems have daily or weekly processing that recalculates projected manufacturing schedules based on future sales orders.

In truth, it's the rare enterprise application that doesn't have some large reporting or processing task that runs against large amounts of data. This type of task is fundamentally different from OLTP. An OLTP task typically involves the retrieval and update of small, discrete amounts of data. Each such update is relatively isolated from any other OLTP task.

When we discuss report generation or batch processing, however, we're talking about a single task that reads and/or updates large sets of data entirely as part of one large process. Whereas the time to do an OLTP task is often measured in milliseconds , the time to generate a report or run a batch process is often measured in minutes, and sometimes even hours.