Chapter 5: Web Services Models

Overview

Some people consider an application model to be the application architecture. I prefer to draw a distinction between the two. I treat architecture as a set of rules established for an entire system or solution. We looked at the architecture for Web services in Chapter 2, which laid out a foundation for us. However, we aren't far enough along to jump into application design yet. We first need to model the solution. This pre-design component is what I will refer to as our model.

A Web services model can almost be designed independently of the actual service and consideration for languages, tools, and platforms. I stress almost, because inevitably at least some of these decisions will be predetermined. When this is the case, it will be too convenient to extend your model into the application design (similar to having the next piece of a puzzle ready to connect). This is not a bad thing from my perspective, but I'm not a purist when it comes to these areas. The best classification of our model may be as a transition state from the architecture to the design.

This concept is not too different from the approach of space planning for a large building or facility. An architect will specify a façade and the overall look and feel but not necessarily the space within the building. Then, a planner with expertise specific to the building's purpose will come in and allocate the space to different functions and purposes. If the building were an indoor arena, there would need to be special consideration for the space necessary to house a hockey rink, a basketball court, and extra seating. In an office building, extra care might be given to the conference rooms. The model developed by the planner reflects these needs appropriately and, working in cooperation with the architecture, allows for a successful building. This model then leads to a design that specifies in greater detail what goes where and how exactly it comes together. This same concept applies to Web services.

Just like different buildings, different Web service providers adopt different models. Potentially, different Web services can support different models, but the provider benefits from maximum consistency to reduce development and deployment time through reuse of a single model. Regardless, any variance between services doesn't preclude their sharing the same infrastructure, because the architecture is consistent.

Web services models will vary because they will have different requirements. Who is the target consumer? What function does this service provide? Is this service likely to be bundled or directly consumed? Do you need to assist with the presentation of your service? Is your service dynamic or static? Many of these questions relate directly to a provider's strategy around its use of Web services. These are all questions whose answers affect, and in fact help define, the model for your Web services.

It is important to note that these questions are not technical. Rather, they are focused on the business requirements for the Web service. As with other business applications, technology is simply the tool for meeting these requirements. Fortunately, no matter what answers you have to these questions, the Web service architecture should be able to deliver a solution.

Note 

I realize that at this point I risk losing my technical audience with all this emphasis on business requirements! Don't worry; the technology is still crucial for building Web services and will continue to be the focus of this book. However, the demands placed on Web services dictate that a good business case is made for creating and hosting one. A Web service can take many technical directions, and it is imperative that the directions selected align with the business drivers.

The answers to your questions may not be the answers you want, because some will be answered by your consumers. A well-conceived model can actually go a long way to help influence this result, though. For example, if you prefer that consumers present your Web service to the end user, provide some presentation information to make the implementation easy. Your service should have defined goals and priorities, and your model should reflect them. You can build a Web service without defining its model, but just like a building without a thoughtful floor plan, a Web service without a model is not maximizing its potential and is likely to fail in meeting the owner's needs.

Three different models are appropriate to define for Web services today: presentation, interface, and security. Even though I refer to them individually as models, the combination of the three could actually be treated as the model for your Web services. In some situations, you might even have multiple instances of these three parts in your Web service model. For example, you might support more than one security model to accommodate different needs. We'll examine this topic in much more detail in each of these three areas.

It is important to not confuse these models with tiers in application development. You don't necessarily need all three components, and they certainly don't communicate with each other, as tiers do. In fact, there is no direct relationship between these models. There will be some overlap in the implementation of their goals, and some pieces of one model may depend on another, but these models are simply areas of focus to aid you in addressing the important issues of designing Web services. Defining an appropriate model goes a long way toward building a successful Web service.

Remember that the consumers of a Web service play a role in its model. As a developer, you will likely play both roles in various situations. As a provider, you will have predetermined goals for your Web services. As a consumer, you may impose your own expectations, and thus new requirements, upon a service. It is then up to the service provider whether or not those requirements are met. Ultimately, a consumer can only utilize what is there and may choose to use a subset of the total offerings. However, consumers can implement a Web service that falls short in some area(s), add services or functionality to it, and expose it as a new Web service.