Web Service Scenarios


Everyone has an answer to the question “What is a Web service?” but at least you can now see where Web services fit into the grand scheme of things and can settle on a definition of your own. Here, we define a Web service as a remotely accessible application component that listens for certain text-based requests, usually made over HTTP, and reacts to them. Web services might not return results in the same way, and what the request is for is irrelevant. Similarly, a service might be used internally by a single application or exposed externally over the Internet for use by any number of applications. What matters is the agnostic nature of the request and its handling.

In practice, there are three general types of Web services: simple services, application integration services, and framework services. We’ll look at each in turn.

Simple Services

The most basic premise for Web services is to provide a simple piece of functionality to the client: data retrieval or simple calculations. For example, an e-commerce site might allow a client to query the shipping cost for a given number of items or query for further details about an item. The workings behind the service might be complex, but its purpose is quite straightforward. We’ll look at a few very simple services later in this chapter.

Application Integration Services

As networks and Internet connections get faster, companies are taking advantage of the increased bandwidth by spreading out their applications and resources over networks and locales. Several servers can talk to each other autonomously and to other applications as well. This integration is fine within a company that uses the same kind of systems, but what if companies want to share their resources with other companies? Common sense would say that their systems would not be instantly compatible.

One fundamental point about the Web service platform is that any machine can expose Web services to and consume Web services from various other platforms— something that cannot be said for any other technology that enables distributed applications. Application integration, or middlemen, services work as intermediaries between applications that wouldn’t normally be able to talk with each other because they were written for different platforms, use different component architectures, and so on. Their functionality or data can be exposed through a set of Web services. Composite applications can then be created on one central system that knows the calls to make to the services to get the information they need from the various systems.

Framework Services

The idea of Web services as application add-ins probably shouldn’t surprise anyone. The concept of a bolt-on component that provides additional functionality to an application isn’t new, but it fits the way Web services work to a tee. Consider for a moment the general characteristics of Web services—loosely coupled, omnipresent thanks to permanent Internet connections—and you can see how they could be used in the same way as add- ins but on the hosting server rather than on the client.

These characteristics of Web services, along with their platform-agnosticism, means that a developer need only write one plug-in for the application regardless of the platform it runs on as long as the Web service interface fits in with the framework laid down by the application. And because the code for the add-in is centralized on the server rather than on the client, deploying an update to the code is a matter of making it live on the server rather than giving it to all clients.

The Microsoft BizTalk Framework already supports this kind of “plug-in” solution. The workflow solutions that a developer creates against BizTalk allow for the inclusion of Web service plug-ins to mirror the addition of new decisions and expansions to already established processes.

This concept also mirrors neatly the continuing development of XML grammars for various vertical markets—finance, bioinformatics, chemistry, and so on. Consider the use of service plug-ins in a situation where a finance package is given information formatted using a schema other than its default. A service plug-in can be called on to transform the information from one markup language to another (using XSLT, for example).

Web Services vs .NET Remoting

This book is very pro–Web services, as it should be, but it’s worth reiterating that Web services are not a substitute for a full-fledged distributed application built using DCOM, RMI, or the .NET equivalent, .NET remoting. There are very good reasons why one might use remoting or an equivalent model over Web services as the basis for a solution:

  • Performance Web services work over open standards, which take a lot of work to adhere to. For example, converting messages to and from XML on each side of the network takes a lot of work. Likewise, using HTTP as the transport protocol is relatively slow, even on a LAN.

  • Security Web services are not very secure yet. Even though calls might be made over HTTPS and new ideas for secure communication appear quite frequently, there is no security standard and little help to fall back on if things go wrong.

  • Control Not having to adhere to standards means you have greater control over your application and can play to the framework’s strengths. In .NET, for example, you can use data types that don’t serialize faithfully into XSD types and back, customize the communications infrastructure, and optimize the application as you see fit.

If the various endpoints of a distributed application are running on the same platform, there’s no need to worry about the agnostic advantages of Web services. You can instead take advantage of the native RPC calls that remoting makes without having to worry about prior parsing and reparsing, and you can make some useful performance improvements. Likewise, you can lock down a remoted application with Windows-based and code-based security measures more tightly than you can a Web services–based application.




Programming Microsoft. NET XML Web Services
Programming MicrosoftВ® .NET XML Web Services (Pro-Developer)
ISBN: 0735619123
EAN: 2147483647
Year: 2005
Pages: 172

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