Logical Architecture

The logical architecture identifies the functions to be performed by a system without consideration for physical systems or objects. In this case, we will look at the functional components of a Web service from the call on up. We will group these functions into layers to help us relate to current architectures in Web-based applications. This will also help us to later identify ownership and responsibilities in the Web service call. In general, a logical architecture is not intended to be strictly adhered to during implementation. However, it should be useful as a platform for discussion and analysis. Through this exercise, we will look at every component at its lowest possible level. Many implementations may leave out or group components for good reason, but we break them down to recognize the distinction of functionality.

Note 

Layers and tiers are terms that I will use interchangeably. They both represent a logical grouping of services that may or may not also be physically grouped.

In the functions themselves we will look at a couple of different aspects. First, we will look at the possible tasks that need to be accomplished at that level. This will help us to identify solutions and opportunities later in our design discussion. Second, we will identify the data that must be passed between the layers based on the functionality. This will help us develop a better understanding of the distribution of responsibility and again help us to identify opportunities during the design of our Web services. We will not look at the process for making a Web service call, because this subject was covered by our earlier look at the communication architecture. In this analysis we will just identify when the interaction between layers could or should be handled through a Web services call.

You can think of this exercise as similar to storyboarding an application. Just like that process, this architecture serves as a focus for discussion and ensures that we look at the same issues during design and implementation. Specifically, we look at where functionality goes and where it might interact with other functionality, but we do not concern ourselves with the implementation details or how it actually works.

• Storyboarding is the process of walking through the process or flow of an application and designing a graphical view of the interface that exposes all of the required functionality.

Web Applications

To establish a frame of reference, it is probably worthwhile to review the logical architecture for existing Web applications that are not Web services. This architecture has proven to be very robust. It has managed to grow with the evolving technology because it is a logical architecture. Various changes in tools, implementation, user base, and even physical distribution have not been able to break this model. In fact, when we look at the logical architecture for Web services, we notice that it is merely an extension to this very architecture. So understanding this model will, in essence, be the starting point for understanding the Web services model. It will also help us to distinguish the differences between Web applications and Web services in our designs.

Caution 

It is common for less-experienced developers to confuse the logical architecture with the physical architecture in these discussions. The physical architecture is different because it designates objects with the appropriate functionality. The two n-tier models do not always match up, and, in fact, the two are more likely to not match in implementations. For example, data access is a responsibility of the data layer in the logical architecture, but it may make more sense for certain business layer objects to access the data model directly.

This architecture contains three layers: data, business, and presentation. Each of these layers performs important functionality to achieve the end product of a distributed, Web-based application. As you see in Figure 2-10, the business layer serves as the go-between between the presentation and data layers, and clients can only connect to the presentation layer.

Figure 2-10: Logical architecture of an n-tier Web application

Note 

The business layer is often called the logic or logical layer. The presentation layer is also sometimes called the interface layer. However, this usage will cause more confusion as integration with other applications and organizations becomes more prevalent.

Although it may not be obvious, the presentation layer is responsible for initiating all processes in the application. More precisely, the client calling the presentation layer initiates the process. This means that nothing actually happens independently of client interaction in a true n-tier application. Any processes running automatically on the server fall outside of this model.

Also, all interaction in the tiers is synchronous because the initial call is synchronous. If the presentation layer does not get a response from the business layer, the client tier eventually times out, and all hope for fulfilling that request is gone.

Now that we have the high-level view, let's take a quick look at each layer.

Note 

Notice that there is no inclusion of the client in this architecture, only the acknowledgement of an available interface. This is because no integration or shared ownership is possible in a traditional Web application. The application is designed as an independent entity, and that is one of the existing models that Web services is attempting to break.

Data Layer

The data layer in any application contains the data source(s) and its components. The data source can take many forms, but the most common form is usually a relational database with tables, stored procedures, and triggers. The tier also contains the data access logic. This is the functionality for managing the connection(s) to the data source and making the actual queries.

This seems fairly simple, but whenever you start putting extended logic in stored procedures, the clarity of this layer starts to blur. By extended logic I mean logic that goes beyond the expected functions of data filtering or extraction of normalized data. For instance, if you have a stored procedure that extracts different data based on a parameter, runs some calculations, and includes some formatting, is it now part of the business layer? Is it in the object that knows which stored procedure to call or the stored procedure that has the intelligence built-in to look up a customer and all of its properties and activities? Although the benefit of doing this is debatable, we consider stored procedures fundamentally as part of the data tier, since ultimately stored procedures are really just tools for extracting the data.

The purpose of our data access objects is to isolate the data source from the business logic. This allows the application to not be "married" to the database implementation. While this certainly doesn't make changes in your database solution easy, it could make it possible to change the database without rewriting the entire application.

Business Layer

The business layer contains the application logic, a series of programmatic algorithms that make the necessary decisions to produce the appropriate output. Tasks in this layer can range from complex math calculations to simple data filtering. Because these tasks are so varied, always make sure you choose an appropriate solution for the functionality needed. These solutions can vary from a script in a packaged application server to custom code using just a programming language. Depending on the functionality, performance, and scalability required, there are generally several solutions available.

Since this layer often contains many business rules, you will likely want to be able to reuse the manifestation of this logic (that is, components or objects). The first step to accomplishing this is implementing a solution that is reusable in your current infrastructure. That is the idea of where compatible technologies and objects start to play a significant role.

To make the most of this strategy, you then want to break your logic down into the appropriate chunks. This means breaking your processes down as small as reasonably possible. These can then be aggregated into the necessary transactions and functions to execute your services and applications. The idea is to isolate low-level functions that are likely to be reused in completely different processes. I call this the lowest-common-denominator approach. If you consider applications as numbers and you need to produce the numbers 9, 12, 27, and 48, you can build functions that give you exactly 9, 12, 27, and 48, respectively. However, you will get more reuse in the future if you break these applications into smaller parts. In this case, you can build functions to produce just a 2 and a 3 and assemble them appropriately, since 3 x 3 = 9, 3 x 2 x 2 = 12, 3 x 3 x 3 = 27, and 3 x 2 x 2 x 2 x 2 = 48. This also allows you to build other applications in the future, such as 6, 8, and so on. But if you never need a 2, or a 6 or 8 for that matter, you may not want to break it down that far. If you could create a function that produced a 4 more efficiently, wouldn't it make sense to do so? Probably. Since the lowest common denominators are 4 and 3, that is likely the best solution.

• A transaction is a unit of work that should either succeed or fail as a whole.

The client does not access the business layer directly. That is the responsibility of the presentation layer. To accommodate this, the business layer needs some type of hook(s) into it that can be accessed externally. This is often done through the interface of the objects in the business layer.

Presentation Layer

The presentation layer is responsible for the presentation of the application to the end user. This actually involves two functions, the display of information and the collection of information. Any logic necessary to complete these functions is considered part of the presentation layer, not the business layer. This logic includes validation, transformations, layout, format, and style.

Validation is the process of ensuring that the end user enters appropriate and acceptable data. The presentation layer has to ensure that the data collected is acceptable because the data typing for the data is much stricter in the business and data tiers. For example, if a user enters an alpha character for a number, the database raises an error because it obviously isn't allowed. Although you could gracefully handle the error and return it to the user, why waste the cycles traveling back through the tiers? If you catch the error up front, you can impact fewer layers and have the user resolve the error much more quickly. In fact, as a rule, you want to handle as many of these issues as close to the user as possible to avoid taxing the entire system.

Transformation is very similar to validation in that the data may be corrected intelligently without involving the user at all. A common example of this is stripping out certain characters from input data. If a user enters "888-555-1212", the presentation layer may strip out the "-" characters to keep the information as a pure numeric data type for more efficient storage.

Dictating the layout involves the placement of information and controls in the user interface. It takes a good UI to make a successful, intuitive client, and it all starts with the layout. It means knowing when to collect the information through an open text field or a predefined dropdown list. It also means knowing when enough is enough when it comes to collecting information in the individual steps of a process.

Formatting is the process of ensuring that data is presented in the appropriate manner. When you work with real numbers and want to dictate the specific digits displayed behind the decimal, you can often do this through formatting. Another example of this is the treatment of numbers as currency. By using a format routine, the presentation layer can take a number like "3214" and turn it into "$3,214".

Finally, styling is the process of adding window dressing to the information displayed in the presentation layer. Common examples of this would be font treatments and colors. There are a number of ways this can be accomplished, and we will touch on some of these later in our sample Web services.

To complete its objective, the presentation layer has to communicate with the business layer to pass and receive data. That means the designs and technologies chosen at each layer must be compatible with those of the other layers. The advances in technology to enable this integration between the presentation and business layers have enabled Web-based applications to become effective enterprise application solutions.

Web Services

Before we discuss the logical architecture for Web services, let us get a better understanding of why Web services don't have the same architecture as Web applications. While we discussed the difference between shared information and shared processes as well as the difference between Web applications and Web services, we need to understand how this distinction impacts the architecture.

Web services do not have a presentation layer. While Web services can contribute to the information defining the presentation, it does not, and in fact could not, dictate the actual presentation delivery to the end user. This goes back to the whole notion of shared ownership for the entire application. That means that proprietary technology and inconsistent implementations could be huge barriers to integration for either the service owner or, even more likely, the consumer. We have already established the communication architecture, which helps with masking the proprietary technologies involved. Now our logical architecture will provide a consistent breakdown that will identify the responsibilities in the tiers and who the owners of those tiers could and should be.

Although we are looking at the architecture for a Web service, it is an incomplete view of the entire application. Because a consumer is responsible for activating the application, it is important to look at both to (1) get a full understanding of Web services usage and (2) relate it to the architecture of existing Web applications, with which we are familiar. Trying to design a Web service without considering its consumers would be like designing a motor without considering the vehicle in which it is going. What will be the demands on the motor? Is it going to be used to carry heavy loads or just move as quickly as possible? Is it a small or large vehicle? Won't we build far better motors knowing the answers to these questions? Although it isn't quite that extreme, because we have established a baseline for all of our "motors" to work with vehicles via our communication architecture, we really need to analyze the Web service and its consumers so we better understand the big picture. So, let's take a look at the overall logical architecture for both (see Figure 2-11).

Figure 2-11: Web service and consumer logical architecture

In the logical architecture for Web services, we will continue to have the same layers of data, business, and presentation. However, we added a fourth layer, the integration/interface layer, between the presentation and business layers. In a Web service, the presentation layer resides on the consumer's infrastructure, and the business layer resides on the service owner's infrastructure. The integration/ interface layer crosses the organizational boundaries and allows for the shared ownership of Web services. This layer bridges the provider and consumer by executing the communication architecture outlined earlier for Web services.

The Service

First, we will look in detail at the service itself. Even though it depends on a consumer to be accessed by an end user, it is a freestanding entity. If a Web service is built and available but not being accessed, is it still a Web service? Is a car still a car when nobody is driving it? Of course!

In the Web service logical architecture (see Figure 2-12), you see that we still have three tiers, but instead of the presentation tier exposing the application, we have the interface tier. Since the presentation layer is shared, the data and business logic exposed play a more significant role. If you take into account that the interface tier is simply a connection to the service, it becomes obvious that the real value differentiating different Web services is contained in those two layers. Let's take a closer look.

Figure 2-12: Web service logical architecture

Data Layer

Unlike with other enterprise applications, it might be inappropriate to label the data layer as the foundation. Depending on the functionality, the service may be passed every piece of data it needs from the consumer. For instance, if the service is a calculator, the functionality may be contained entirely in logic. However, it could be argued that the more valuable services still have some local set of data they are either referencing or depending on to provide their functionality. After all, any logic might be reverse engineered, and the value of the service could be compromised. If the service provider owns or has access to proprietary data, it is harder to replace.

The real impact on the data layer in a Web service application is the fact that, at some point, the data exposed is defined in XML. This doesn't require data to originate as XML, but that is an option. Multiple transformations of data from one type to another ultimately affect performance of the service. For instance, if you are building your Web service in COM objects and use ActiveX Data Objects (ADO) to extract data into a recordset, encapsulate the necessary data into a property bag to marshal across business objects, and then expose the results in XML, you've gone through three very significant data transformations. There are decisions you can make to avoid this, and we will look at these later.

• Marshalling is the process of transferring data between processes. Marshalling objects is more intensive than marshalling strings because the objects have to do more encoding and rebuilding.

Business Layer

The business layer defines the processes behind the service and contains all application-specific logic. This layer is likely to be the least affected by the fact the application is exposed as a Web service. In fact, you should closely scrutinize any changes you might make internally to an existing application's business layer to make it a Web service. This could easily add overhead to an application that is used through channels other than Web services.

When creating a Web service from scratch (meaning not only the Web service, but also the functionality it is exposing), there are decisions that can be made to support a Web service architecture going forward to optimize both performance and extensibility. These decisions revolve around standardizing the approaches to handling data and maintaining security. Again, since all information is collected and exposed as XML, it would be beneficial to keep consistency in your interfaces and transformations. Also, determining a security scheme to account for public programmatic access to your logic may keep you from having to reconfigure, or even worse redesign, your business layer later when limitations are encountered.

The business layer is also the tier of the Web service that could be a consumer of other Web services. This makes sense when you consider that the business layer is responsible for the logic and accessing various local data sources and/or objects. Web services could be utilized just like other objects, and this is the layer at which that integration occurs (see Figure 2-13).

Figure 2-13: Web service integration with another Web service

Note 

Don't interpret the preceding figure too literally without considering the components that are required in the business layer consuming the Web service. If the business layer is accessing a Web service, it must have the Web service consumer logical architecture, which we will discuss shortly, contained in it.

This same model holds true for traditional applications. Regardless of whether the application is a Web service, a Web site, or even a fat-client application, an n-tier application references Web services from its business layer.

A fat client is commonly referred to as a client application that contains custom logic or processes to facilitate user-interaction with an application.

Interface Layer

This is where we get into the very interesting aspects of Web services. The interface layer is where partnerships are established. For this reason, this layer exposes the service's functionality to its consumers. Don't confuse this with the end user interface, since this interface is designed for programmatic access only. This layer works with the consumer's integration logic to provide the complete tier for our communication architecture.

The interface layer contains the functionality required to expose our Web service. We have to receive the call from the consumer, pass it to our application logic, receive the response from our logic, and return the appropriate information back to the consumer. In the communication architecture, we encapsulated this functionality in a listener and a responder. The listener handles the inbound processes, and the responder the outbound. Both of these components reside in the interface layer.

Although the Web service is not responsible for the presentation layer, it may need to provide information to the owner of the presentation to expose processes directly to the end user. This may involve the filtering and transformation of information or may involve entirely separate processes for extracting data specific to this function. Regardless, any functionality specific to this information is encapsulated in the interface layer.

This would be considered a value-added service to the Web service itself, just as providing a user manual on how to change the oil to the car manufacturer buying our motor would be considered value added. Can you build a motor without providing this information? Probably. The car manufacturer is certainly familiar enough with the process itself they could write the instructions for changing the oil. However, providing the manual makes using the motor easier, and more car manufacturers would be inclined to use your motor because of this value-added service. It also ensures that the car manufacturer is telling the user exactly how you want the oil to be changed. It helps ensure that users aren't abusing your motor (thus making users happier with your product) because they are getting the information straight from the source. Will the car manufacturer use the information? Probably, because of the savings in time and money of reusing our work. Will the manufacturer pass it on directly to the car owner or compile all information about the vehicle into one all-encompassing manual? That depends, but the point is that it is at the car manufacturer's discretion. This same concept can be applied to Web services and the services you provide around it.

Other services may benefit the Web service provider more than its consumers. We will talk about these and other value-added services you can provide later. The main thing to remember for now is that these services are part of the interface layer of your Web service. No matter how complex and robust the functionality, it is all embodied in the interface layer of your logical architecture.

Consumers

In our analysis of the communication architecture, we started to look at the consumer responsibilities and functionality. In this view, we will look a little closer and relate its functionality back again to traditional Web applications. We will start with a high-level view of the entire consumer entity and its layers (see Figure 2-14). In this diagram, we are reinforcing the fact that the consumer owns the presentation layer and its portion of the integration layer.

Figure 2-14: Web Service consumer logical architecture

Notice that the presentation layer is actually displayed differently. This is because this layer is optional in the sense that there may be no presentation layer to the application or the consumer of the service may not be the partner ultimately responsible for it.

Although it may be disturbing to think that the consumer may not have a presentation layer, there are many examples where this may be the case. For instance, you could have an automated back end process utilizing Web services to transfer data. Also, if the consumer is a Web service itself, it would pass its information on to another consumer, and it may or may not own the presentation layer. This gets back to the idea of stacking multiple Web services to provide a complete application (see Figure 2-15).

Figure 2-15: Logical architecture of an application with stacked Web services

Remember that the business layer of the first Web service also doubles as the integration/application layer for the second Web service, since it is acting as a consumer of it. Through the rest of the discussion in this chapter, we will work with a simple partnership of one consumer and one Web service. Thus, the consumer will own the presentation layer. Later, we will build logical diagrams of more complex applications based on these same rules.

Integration Layer

In our Web service, the integration/inferface layer was responsible for its interface. In the consumer, the integration portion of that layer is responsible for calling the Web service. Together, these two components allow for the integration of the external process into the local processes. Since the consumer calls the service from its business logic and integrates the two, the distinction of a consumer's integration layer is purely logical, not physical.

As we discussed earlier in "Communication Architecture," the consumer is responsible for packaging up the input data, making the call to the Web service, receiving the response, and parsing out its returned data. These functions were split into the caller and the parser, with the caller responsible for the outbound processes and the parser for the inbound. The additional function not explicitly stated is the communication with the presentation tier. Similar to the relationship in a traditional n-tier application between the business and presentation tiers, the consumer's presentation tier would call the integration tier for its functionality, or it could be retrieved through the business layer. Either way, the presentation layer is returned the information necessary to display to the end user. The complexity in this relationship is largely determined by how much of this information came from the Web service versus the application itself. In other words, to what extent must the presentation data be intergrated? The answer to this question can be as easy as "none" and as complex as "a lot!" With more integration comes more logic, but also more functionality and more reuse. As you can suspect, with less integration come fewer benefits. However, if you are interested in Web services, you probably want to maximize your integration potential with your partners.

In our earlier oil change manual scenario, how hard would it have been for the car manufacturer to utilize our oil change documentation? It depends on how integrated the company wanted to make it. The company could have passed it directly on to the end user, as a separate document, but it wouldn't have any of the car manufacturer's branding or information on it. They could have made several copies and manually inserted them into the manual, but it would have looked out of place. If the company had it rekeyed into a word processor, it could have merged it into the existing manual and made it fit much better, but any changes would cause a lot of rework. Certainly there are different levels of effort involved, along with different benefits. By exposing it through a Web service, we can provide a current electronic copy of the manual every time the company requests it. If all of the car manufacturer's partners cooperate on using the same process, how easy would it be to create manuals for the car with every component up to date? Very!

Note 

In case you didn't notice, we just referenced a scenario encountering the same issues that we saw in Chapter 1 when integrating Web applications through redirection, frames, and duplicate content versus Web services!

Once a consumer has the logic for working with a Web service, it should have the logic for working with a whole host of Web services. In fact, in the integration layer, calls may be made to multiple Web services. This is the concept of brokering Web services that we saw in Figure 2-4. This may complicate the integration layer a little, but it is primarily the same functionality so will likely benefit from reusable objects. The additional complexity comes from the integration of the resulting information into the business logic.

This is where the definition of data plays an important role. It will be up to the integration layer to parse the data returned to the consumer so that it can work with it or pass it on. This may mean simply putting the information into an XML-compatible data model like the DOM or transforming it into a more system-specific structure like an ADO recordset (if you are working in a COM environment).

Tip 

Be aware that when you start to transform data between various formats, your performance is going to suffer. This is not to say transformations should never be used, because they will be necessary. You are just much better off establishing a consistent model format for your data in each tier instead of catering to the model or format preferred by each language or methodology utilized in the system.

When the application has to work with the data, the consumer has to have a very clear understanding of what the data is and what it means. Referencing one of the industry standards for defining XML datasets will help the consumer accomplish this. However, it is up to the Web service owner to provide a definition and comply with it. If all partners are working with the same definitions, life will be much better for the consumers. Otherwise, the consumers will have to work the data into an acceptable format.

In this case, a complex design will likely be necessary for consistent integration. For instance, what would be easier for the car manufacturer to automate: assembling 100 .txt files or assembling 35 .doc, 30 .txt, 15 .rtf, 5 .sdw, and 15 .ps files from all of its partners into a manual? Sure, either one can be done, but isn't the former going to happen more often, a lot sooner, more easily, and at a lower cost?

Fortunately, if information is going to be passed directly to the end user, there is usually a lower level of understanding about the information required by the business layer. In fact, the integration layer might not even have to share the same physical tier as the business layer. That is because the presentation layer may call it separately from any other logic calls. This means that integrating Web services may not modify your existing business objects, but simply add to them. And minimizing the impact on existing code is always a good thing!

Even in these instances, the integration layer will still have some logic. Some filtering, transforming, or modifying may occur. The integration layer will at least have to parse the data so that the presentation layer can work with it. What do I mean by work with it? Let's find out.

Presentation Layer

The presentation layer can be the most complex layer in an application that consumes Web services. Additionally, this is the layer that can have the most variation from application to application. This is because all of the partnerships and collaboration of services have to come together at this point. They can be as simple as a single consumer calling a single service or as complex as a consumer brokering multiple application chains with multiple partners.

Our logical architecture will be able to support any of these models, so we have a fairly robust architecture on our hands. This will help us to break down the complexity into sublayers so that we can be certain we have accommodated nearly every conceivable scenario.

It could also be argued that this layer should be the most thought out, because it carries the most significance on a business level. It is the presenter of the application to the end user and is also probably one of the reasons the end user is there in the first place. In this competitive industry, there aren't too many poorly designed applications or Web sites with massive success these days.

Note 

Of course we remember from our earlier analogy that a chain is only as strong as its weakest link. However, many organizations emphasize the presentation more than the back-end processes, since they are more visible, and often perception is reality.

While I am presenting the logical architecture for a Web service consumer, this same breakdown of the presentation layer could also apply to traditional n-tier applications. It is a little more relevant here, since this architecture forces more structure on the design due to its complexity. Web applications are known for being very forgiving to less-structured designs because their demands have been relatively light. This is similar to the forgiving nature of HTML versus XML. You can get away with more inaccuracies in HTML because it isn't considered mission critical, and often "close enough" is fine. Web services require a bit more discipline to be implemented correctly, and this architecture should help achieve that.

One of the biggest reasons for this stricter adherence is the shared nature of the presentation for applications utilizing Web services. As I mentioned before, Web services can contribute to the presentation layer. While this is not a requirement of Web services in general, it is a feature that consumers need to support architecturally. Supporting this means that the integration of the presentation information needs to happen systematically in a way that is effective and repeatable. Keep in mind that we are not talking about actual implementations, but rather the architecture defining the structure for our designs (see Figure 2-16).

Figure 2-16: Web service consumer presentation logical sublayers

Note 

Something worth mentioning at this point is that the focus of the presentation layer's abilities center on Web-based clients. Inherent functionality is exposed through HTML on a browser that allows for incredible flexibility in the presentation layer. (For example, it is a simple process to reference .GIF images on external systems over the Internet.) To compensate for these limitations in applications with custom clients that are not Web based, additional functionality would have to be added to your client. Of course you could make your life easier and build your interface for a Web browser!

Content Layer

The name of this layer tends to give away its jurisdiction. While it is easy enough to say that the content layer is responsible for all the content of the application's presentation, it is really not quite that simple when you take a closer look. That content may be local, or it may be external to the application's environment. Rather than dismissing it as the directory containing all the HTML and graphic files for the content, you need to think of it as a reference to all of the content for the presentation. This puts the content layer in more of a logical state than a physical one.

Just as with current Web sites, it is simple for the local application to reference external as well as internal content. That content may take the form of HTML code, client-side scripts, images, and other supported file formats. However, the content layer may be very dynamic, since the application layer can also pass information that may reference external content. This content could be either embedded or defined in the data or simply referenced by the data. For example, the hotel service in our traffic scenario may have passed our reservation system the necessary data to define a drop-down box that allows users to select a bed size. This would allow the hotel to directly define a piece of information critical to its room availability Web service. The hotel may also reference an image on its own Web site for the purpose of cobranding the reservation application.

• Cobranding is the practice of partnering to share the exposure from a public marketing vehicle, in this case a public Web application, by giving exposure to the two or more organizations involved. A good example of this in everyday life is the packaging of toys from a movie inside children's meals at fast food restaurants. This effort gains publicity for both the restaurant and the movie.

Caution 

It is worth re-emphasizing that the reservation system will have the ultimate choice of whether to utilize this information. The hotel cannot enforce, through technology, any requirements it may make of its consumers to use or not use the data it returns when accessed. We will look later at how the hotel can better protect its processes.

Another example of service-driven content would be content derived logically by the integration layer based on what was received from the Web service call. An excellent example of this is error handling. If the Web service cannot be reached, the consumer's integration layer should handle the failure and provide some kind of data to the presentation layer to keep the end user from getting stuck in a dead end.

Regardless of the method, all of these processes result in data consisting of the content layer. We could consider our content layer a toolbox of information for building the application's presentation. By being able to work with a simple content layer, the rest of the presentation layer will have no concept of servicefed versus local content. It can treat all content as a group and thus reduce the complexity of the remaining functionality.

The content required of the application beyond the Web service functionality would also be contained in this layer. This is often referred to as base-level content for the application, since it is used independently of the Web service. This content may still be dynamically referenced and utilized by the business layer, but the integration layer will generally have no impact on this content.

Style Layer

The style layer is responsible for the formatting and treatment of all content on the site. This layer is entirely owned by the local application, since its objective is to maintain a consistent look throughout the application, regardless of whether the functionality is provided by a Web service or the local business layer. While it is possible for a Web service to define some styling, it is generally counterproductive, since the consumer will probably want to control it.

This styling can take many different forms, including cascading style sheets (CSSs), eXtensible Style Sheet Language (XSL), and a number of programming languages. Through these methods, the style layer can define how to present everything from currency to HTML form controls to plain text. This is done by either asking the client to map content to a style, as with CSS, or by transforming the content to another format prior to pushing it to the client.

Caution 

Although XSL can be used to have the browser map content to a style, this is limited to newer versions of browsers and, more importantly, is more limiting to XSL's capabilities than manipulating the content server side.

Although the style layer defines these functions, even in the case of serverside manipulations, it is not actually responsible for making the changes or transforming the content. This would require the style layer to contain the logic of which pieces of content it should be associated with. That is actually a more involved process, since it is often affected by other content outside of its control. For that, you need functionality that is aware of everything being presented to the user, not just one piece of content. This is the responsibility of the design layer.

Design Layer

The design layer is responsible for building an application's presentation from all the tools provided through the content and style layers. This is the layer with all the control over what content goes where and how much space it consumes, what content is styled, and what content is discarded. The design layer is ultimately responsible for the look and feel of the site.

While much of this functionality can be provided statically through programmatic logic, modifying dynamic content will probably be required, depending on the application's processes. This may be as simple as referencing random images for a look of "freshness" or as sophisticated as transforming raw data into its final format for presentation to the user. While we will look at how to implement this functionality in our sample applications later, suffice it to say here that we demand much more of our presentation layer than we have in traditional n-tier applications.

Although this layer can contain quite a bit of sophistication, the ideal design layer implementations will offload as much logic as possible to the integration layer so that it can focus on just the presentation aspects. For instance, if the design layer is getting back 100 data points and filtering for just one to be shown, try to push that responsibility back to the integration or business layer.

The reason for streamlining this layer is twofold. First, any kind of purist will want to limit the amount of logic creeping into the presentation layer, just as you would in an n-tier application. Second, if you are following the practice of splitting your presentation and business layers onto separate systems, your presentation system could quickly become a bottleneck from the additional responsibilities it has taken on in dynamically building the presentation. While you can always add more systems to one tier of the system, you want to avoid getting into great disparities of system counts between the tiers. Adding logic to this layer would only compound that issue.

Now that we have discussed all the levels in the presentation layer, let us look at how they might fit together visually. In the sample layout model presented in Figure 2-17, you see a single view with many content elements from different sources. In that layout may be modules of straight content or styled content, depending on the design and the content in question. No distinction is made to where the content originated because it doesn't matter to the presentation layer. In our design scenarios, we will get much more in depth on content sourcing and how that is handled. The focus of this illustration is to present each of these sublayers and where their responsibilities lie.

Figure 2-17: Visual segmentation of presentation sublayers