When you think ASP, think...
Recent Articles
All Articles
ASP.NET Articles
ASPFAQs.com
Message Board
Related Web Technologies
User Tips!
Coding Tips
Search

Sections:
Book Reviews
Sample Chapters
Commonly Asked Message Board Questions
JavaScript Tutorials
MSDN Communities Hub
Official Docs
Security
Stump the SQL Guru!
Web Hosts
XML
Information:
Advertise
Feedback
Author an Article

ASP ASP.NET ASP FAQs Message Board Feedback
 
Print this Page!
Published: Wednesday, November 19, 2003

An Extensive Examination of Web Services: Part 4

By Scott Mitchell


An Extensive Examination of Web Services Index
An Extensive Examination of Web Services is a multi-part article series spanning several months. Listed below are the current "parts," along with a very brief synopsis and the date published.
  • Part 1 - Examines the basics of Web services, what Web services are, and the technologies and standards that serve as the underpinnings of Web services. (October 8th, 2003)
  • Part 2 - Examines creating Web services using Visual Studio .NET. Looks underneath the hood of the code created by VS.NET. (October 15th, 2003)
  • Part 3 - Examines creating a client application that consumes a Web service. Discusses the purpose and structure of a WSDL document, along with creating and using proxy classes to consume a Web service. (November 5th, 2003)
  • Part 4 - Examines the utility of Web services and common scenarios where Web services make sense. A business-oriented look at Web services. (November 19th, 2003)
  • Part 5 - Takes an in-depth look at XML serialization, which is the process of converting a data type, such as an integer, array, or custom class, into its XML representation, and back again. Every time a message is passed to or from a Web service, XML serialization transpires. (December 17th, 2003)
  • Part 6 - Looks at sending metadata to a Web method through the use of SOAP headers. Examines defining and accepting a SOAP header on the Web service end, and looks at sending a populated SOAP header from the client. (December 31st, 2003)
  • Part 7 - Examines how the incoming and outgoing messages to a Web service can be programmatically modified via SOAP Extensions. (January 21st, 2004)
  • Part 8 - Learn about the Web Service Enhancements (WSE) and Microsoft's free class library for implementing the WSE standards. (June 30th, 2004)
  • Part 9 - See how to implement UsernameToken authentication using the WSE 2.0 Toolkit. (July 14, 2004)
  • Part 10 - Learn how to send large amounts of data as attachments using DIME and WS-Attachments. (September 8th, 2004)
  • Part 11 - Create (and consume) client-side script-accessible Web Services using Microsoft's ASP.NET AJAX framework. (September 26th, 2007)

Introduction


So far in this article series we have examined the standards involved in Web services, looked at creating Web services with Visual Studio .NET, and have examined WSDL and creating proxy classes to consume a Web service. While we have discussed the mechanics of Web services - what they are composed of, and how to create and consume them - we have had little discussion on business uses for Web services. In this article we will discuss how and where Web services can be used in an enterprise. We'll also look at how Web services are being used by businesses today.

- continued -

The Utility of Web Services


When faced with a task, it is important to choose the right tool for the job. Web services are the right tool for some jobs, and the wrong tool for others. In my opinion, Web services are an ideal candidate for tasks that need to accomplish one (or both) of the following:

  • Data transfer between disparate systems
  • Provide a platform-independent interface to hide complexity for a system that is utilized by many clients

To see why Web services are an ideal fit for these types of challenges, let's consider two different scenarios and see how Web services can be utilized.

Transferring Data Between Disparate Systems


For the first scenario, imagine that you work as a wholesaler, selling widgets to redistributors. (These redistributors, then, resell the widgets to the public.) There might be a variety of retailers you sell to, and these retailers need some way to get the latest information about your widgets for sale. They might want to know what types of widgets you carry; what your inventory looks like; the cost per widget; and so on. Clearly you need to provide your inventory information to these resellers in some electronic format.

There are a number of challenges here, the main one being providing this information to a variety of clients who are likely using a hodge-podge of technologies. That is, retailer A might be running their business on Windows 2000, while retailer B might have their data servers running Linux. Clearly picking a technology that focuses on one platform - such as providing the data as a binary dump of a MS-SQL database - is not an option.

One platform-neutral option might be to just post the data on a Web site. That is, as the wholesaler we could export the data we want to share to a tab-delimited text file and then just post that on a Web site URL that only our retailers can access. While this is clearly platform-independent, it has one major downside: we have to tell each of our retailers how to parse our data. While this is no big deal from our perspective, this might be a major headache for retailers, especially considering that they may be buying from multiple wholesalers. If each wholesaler has their own data format, our retailers are going to have to write a lot of code to access the data.

A better approach is to use Web services, since Web services provide both the platform neutrality and a standardized means for accessing the service and for serializing and deserializing the incoming and outgoing data. Since Web services are built on standards, there are already many toolkits designed to allow for Web services and consumers of Web services to be built quickly and with minimal effort. (For example, in Part 3 of this article series we saw how using VS.NET one could build a Web service consumer in a matter of minutes.)

Data transfer scenarios are common in any industry where there are central repositories of information that need to be accessed by independent actors. For example, in the insurance industry there are a number of independent insurance salesmen who sell policies from a variety of companies. These independent sales forces need to be able to access the policy data from the insurance carriers periodically. Scenarios like these are prime candidates for Web services.

Providing Interfaces for Complex, Distributed Systems


Another ideal use for Web services is in providing a platform-independent interface to a complex, distributed system. To understand how Web services can fit in here, imagine that you work for a large Fortune 500 company that has been in business for quite some time. More likely than not, there are a number of different, independent systems used by various departments in the enterprise. For example, there may be an HR system that manages employee information, new hire information, benefits information, and so on. A system for the sales department manages current and prospective clients, past client activity, information about the sales force and their activities, and other relevant information. There are likely numerous other independent systems for other organizations within the enterprise.

More likely than not, these systems were spec'd, developed, and deployed at different times. Hence they might use different technologies and platforms. The HR system might have been created using COBOL back in the 70s. The sales force might be using a system that was designed using DB2 and C++ in the 80s. The IT group might be running their systems using VB 6 applications and components talking to an MS-SQL Server database. The point is, there are a variety of systems created a mishmash of technologies.

The challenge: make these systems interoperable. That is, a developer working on an application that ties into the HR's system should be able to easily reference the sales system. The ideal solution here is to put a Web services interface on each of the various systems. The Web service interface provides a uniform method by which all systems can be accessed, and hides the implementation complexity. That is, when an intranet developer wants to create an intranet page that displays information showing this month's top-selling products, she doesn't have to worry about how the sales system is tapped into - rather, she just connects to the Web service interface provided for the sales system, and invokes the appropriate methods to get the information needed.

The diagram to the right illustrates placing Web service interfaces on the various systems, and shows how a client can communicate directly with the interfaces so that it doesn't have to concern itself with the specific protocols or libraries needed to communicate with the specific system.

Web services make for excellent interfaces for legacy systems. By encasing legacy systems with a Web service interface, clients that wish to communicate with legacy systems don't need to use the antiquated protocols and procedures to do so. This can be especially annoying if there are a multitude of different legacy systems, each which requires its own custom protocols to communicate with. Too, Web services reduce any notion of platform dependency that may exist with legacy systems.

In a related vein, Web service interfaces are a good choice when moving from outdated legacy systems to newer ones. We all know that a big challenge of porting a distributed system is that all the clients that use the legacy system must also be ported to start using the new system. This process can be simplified if Web services are used as an interface to the legacy systems. This way, all clients talk to the Web service. Once the legacy system is ported to the new system, only the Web service interface needs to be updated - the existing clients can keep using the Web service interface as they had before! This demonstrates how interfaces can provide a layer of abstraction that makes ports and other changes less painful.

How Web Services are Being Used Today


The vast majority of companies using Web services today are using Web services to provide solutions to scenarios similar to the ones we examined. Typically, Web services are built for use inside an enterprise, behind the firewall, as a means for interoperability among disparate systems. Web services are also commonly used to exchange information between business partners. For example, an airline company like American wants to make its flight data available to travel agents. Furthermore, American might have a business relationship with Hertz Rental Cars where customers that fly American and rent Hertz get some sort of bonus or savings. In such a scenario, Hertz and American would likely need to share data amongst themselves, and Web services would be an ideal conduit.

Web services can also be built for public consumption, although this isn't done very often today. The main reasons against creating publicly-accessible Web services is that for many business sectors doing so doesn't provide any return to the bottom line. Furthermore, letting anyone hit your Web service adds to the demands placed upon the service which, if not properly managed, can lower the overall quality of service. (A notable exception are Amazon.com's Web services, which can be accessed by developers worldwide.)

Conclusion


In this article we discussed how Web services can be used in the real-world. Typically, Web services are utilized to solve data transfer problems and to create platform-neutral interfaces for distributed systems. Web services for data transfer is typically used for data transfer among business partners, but such data transfer could be opened up to the general public. Also, depending on a company's internal computer infrastructure, data transfer might be difficult even within an enterprise, and therefore might mitigate the use of Web services internally.

In addition to data transfer, Web services are ideal for creating interfaces for complex, distributed systems. These interfaces provide a platform-independent means to access a system. These wrapper interfaces are typically needed for legacy systems that use antiquated protocols for communication and information exchange. With a Web service interface, only the Web service needs to be intimate with the legacy system's outdated protocol - clients wishing to use the system can simply talk to the Web service interface.

Happy Programming!

  • By Scott Mitchell


    Beginner's .NET XML Web Services

    Beginner's .NET XML Web Services DVD

    Beginner's .NET XML Web Services offers nearly eight hours of training on .NET XML Web services in a video format. This two-disc DVD set, presented by author Scott Mitchell, offers a unique opportunity for learning about the fundamentals of Web services. The 14 lessons begin with an examination of the core Web service standards, and then quickly move into showing you how to create and consume Web services in Microsoft's .NET Framework. There are in-depth lessons for each of the core Web service standards - XML, SOAP, and WSDL - along with examples of the Web Service Enhancements (WSE). Scattered throughout each of these chapters are extensive demos, depicting how to build, deploy, and access Web services using Microsoft's Visual Studio .NET. The DVD also contains a thorough examination of a real-world, end-to-end Web service application.

    Scott Mitchell is the editor and founder of 4GuysFromRolla.com, author of the An Extensive Examination of the Web Services article series, and author of numerous ASP and ASP.NET books.

    [Buy this DVD]

    Why get stuck with a 600-page paperweight when you can learn about .NET Web Services through an interesting and interactive video presentation?



  • ASP.NET [1.x] [2.0] | ASPMessageboard.com | ASPFAQs.com | Advertise | Feedback | Author an Article