Web Services As an Interface

Because web services have received so much publicity, there are a lot of different ideas and opinions about what they are for and how they can best be used. In this section, we'll explore an extreme opinion, before settling down to the idea of using web services as just another interface to our application.

Web services are all about exposing data or functionality to unknown consumers on unknown hardware, written in unknown tools or languages. They're all about providing access to data and functionality in such a way that neither the consumer nor the publisher needs to know anything about the other, beyond the fact that they can send and receive XML.

Our ProjectTracker application has no need for web services internally , because if we do any network communication, we're using the more efficient and powerful remoting technology. However, it's quite possible that our application's data or functionality could have value to other applications within our organization, or perhaps to our business partners or customers. Clearly, we have no good way of predicting the types of hardware, operating systems, or software that may be used to create these other applications, but we shouldn't really care.

A Web Service for Every Tier ?

Some people believe that every logical tier in an application should be exposed via web services. This would allow a consumer to use a web service to retrieve or update data directly from the database, or to call middle-tier business objects, or maybe even to call UI functionality. In our five-tier logical model from Chapter 1, the result would look something like Figure 10-5.

image from book
Figure 10-5: Exposing a service from every tier in our application

The primary rationale for this approach is that we would use web services for all interaction with each tier of the application, thus gaining reuse. This sounds attractive on the surface, but it gets ugly very quickly.

Consider what happens to our application if we allow just any consumer to interact directly with the database via web services. Our data has rulesvalidation, security, and so forththat must be enforced. If a consumer can call a web service to update data in the database, then the database itself must have all the business rules available. Typically, this would mean writing all our business logic in something like T-SQL, which isn't the most productive or easiest language to use.

Remember that we can't predict what kinds of consumers will be created in the future. Anywhere that we allow these unknown consumers to access our code, we must be defensive. We must assume that they will introduce bugs by skipping validation, bypassing security, or otherwise ignoring the functionality required by the business process that our application was intended to address.

Tip 

I'm somewhat adamant on this point, having been the victim of exposing procedures to unknown clients in COM. I exposed a set of low-level COM components to a client application outside of my control, but I hadn't coded my components defensively (they were designed for my application's use). The developer of the new client application misunderstood how data was to be used, and the components didn't enforce the rules, thereby leading to corrupt data.

What this really means is that our application architecture collapses into something like Figure 10-6.

image from book
Figure 10-6: Accessing the data through a web service

Our UI becomes just another client of the database server, where all the business logic and data management occurs.

We've been here before with 2-tier client-server applications, in the early to mid-1990s. Then we learned that if the only place where the business logic resides is the database, our user interface has to accept virtually any user input, and then send it to the database to find out whether what the user entered was any good. In response, developers duplicate the business logic in their UI codebut then the two can get out of sync, and then we have bugs. Hopefully, you can begin to see that web services don't change the fundamental reasons why we use the n-tier designs that I've been advocating in this book!

A Web Service As the "User Interface"

Instead of the approach presented in the previous section, the way to view web services is that they provide "just another interface" to our application. We can tie this idea back to our n-tier model from Chapter 2 as shown in Figure 10-7.

image from book
Figure 10-7: N-tier logical architecture with a web-services interface

Notice that the web service and the consumer have clearly defined roles in this model: The consumer has become responsible for handling presentation and any other details of that sort . From the point of view of a web service, all of that is out of our scope. All we care is that we're providing the Presentation tier with what it needs to do its work.

As always, it's for the UI tier to interact with the business logic, and for the Data Access tier to retrieve, process, and update data on behalf of the Presentation tier. In a Web Forms UI, this revolves around the creation and processing of HTML, while with web services it's all about XML. In many ways, this is a pretty minor difference.

By taking this view of web services, we provide access not only to our data, but also to the combination of data and functionality within the context of our existing application. This is much more powerful, because it means that we automatically gain access to all our existing business logic, including validation, manipulation, security, and so forth. If another application wants to use our data, we want to perform security checks to see if that's OK. If another application wants to update our data, we want to perform security and validation checks, and apply any other business processing or rules.

The end result is that we'll write a set of web services that provide the same basic functionality as our Windows Forms or Web Forms interfaces, but without any consideration for the presentation. The web services code will interact with our existing business objects to retrieve, manipulate, update, or delete data. Since our objects provide not only the data, but also all related business functionality, we're guaranteed to have the same business rules enforced as with our other two interfaces.

Web Services and Contracts

Perhaps the most important thing to remember about web services is that after we publish a web service and consumers start using it, the web-service interface can no longer be changed without breaking those consumers. In other words, those consumers may no longer be able to use our web service once the interface changes.

Note 

This is the same issue we faced with COM components: After you publish the interface to a component (or a web service), you can't change it without risking compatibility issues.

For this reason, we have to view the interface of each web-service method as a contract. Once we publish the web service, the contract is finalized, and we can only change it by paying up on the huge penalty clause built into that contract. In our case, the penalty clause translates to irate calls from all the users and authors of all the consumers that use our web service!

With web services, this issue is potentially even bigger than it was in COMand it was big enough in COM. (Remember DLL hell?) The reason why it's bigger with web services is that we can't predict what consumers may be created to use our service.

Once it's exposed from our server, almost any programmer out there might decide to use it.

If we're not careful, the use of web services can make our overall application architecture very fragile. A change to our application can have a nasty ripple effect throughout our organization, or those of our partners or our customers. Because of this intrinsic fragility, we must be incredibly careful to separate the interface exposed by our web services from the underlying application. We want to be able to change, enhance, and maintain our ProjectTracker application over time, while at the same time minimizing the possibility that we'll break existing web-service consumers.

Tip 

This is another reason why exposing every tier of our application via web services would be problematic . As soon as we expose a web service, we lose almost all flexibility in terms of implementing changes or enhancements. The interface for our tier becomes locked in place. By exposing web services as a form of interface on top of our application, we can largely shield our application itself from these effects, meaning that we can change and enhance the application and still provide a consistent set of web services.

At heart, a web service is just a collection of methods that accept parameters and return results. The parameters and results are just data that's passed between consumer and service. If we can clearly define these parameters and results up front, we'll have gone a long way toward defining the contract by which we must live.

A very easy way to define this data contract clearly is to use struct or class types in our web-service code. When we define a public struct in a web service, that data structure is exposed as part of our SOAP interface. This means that any consumer has easy access to the specific layout of the data structure we've defined.

Tools such as VS .NET take this data structure definition and use it to create consumer-side proxy classes that mirror the data structure automatically. This makes it very easy for the consumer developer to format data that will be sent to our web service properly, and to understand any complex data that our web service returns to the consumer. While we might use other techniques (such as an XML document) to transfer complex data, the use of a struct or class provides the most automated and self-documenting interface with the least amount of work on our part, so that's what I'm recommending in this book.

Now that we've discussed some of the core conceptsmost notably, the view that web services are just another type of interface to our application, and that this interface is an immutable contractwe can move on to implement a set of web services for our sample application.



Expert C# Business Objects
Expert C# 2008 Business Objects
ISBN: 1430210192
EAN: 2147483647
Year: 2006
Pages: 111

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net