|
|
One major problem in the solutions created today is interoperability with other platforms. It would have been great if all applications were written in the same language and ran on Windows XP, but as you know they are not. Most interactions with old legacy systems are done by using file transfers or message queuing, and frequently vary from case to case. Often the specification of this interface is stored in some place other than the interface itself. One of the major computer-related costs for companies today is the integration between different systems and applications. We believe that Web services will cut this cost dramatically if they are used well.
Integration is easier with Web services because all systems can communicate with each other over HTTP, regardless of platform or programming language. Many good examples exist of companies that have exposed legacy functions via Web services, thus receiving a reuse boost because functions were suddenly easily accessible to the organization. The interface of a Web service is also accessible through a Web Services Description Language (WSDL) file, and thereby the specification of the interface matches the interface itself, making it even easier for others to use the Web service.
Web services expose an API via a Web-based protocol like HTTP or HTTPS. (They can also use other protocols, but we will mainly talk about Web services in conjunction with HTTP and HTTPS here.) When we say that Web services use HTTP, we mean that Web services can invoke functions via HTTP, and get results back via HTTP. (HTTP is in this case the transport protocol that the Web service uses.)
For instance, if you would like to build a Web service that returns local weather information, you can create an ASP page that takes a city name as a parameter and returns the local weather forecast. To invoke this Web service, you can call it by sending an HTTP GET request to a Web server such as http://www.myserver.com/weather.asp?CityName=Gothenburg. The return result may look like this:
Degrees: 23 C
Humidity: 67%
Precipitation: 45%
PrecipitationType: Rain
This simple ASP page is a kind of Web service, because it exposes an API based on a standard protocol, in this case HTTP. But Web services can do much more than just tell you what the weather will be today. The following sections discuss what else Web services can do.
By using Web services to integrate applications, you can better automate business processes within a company. But what happens when business processes crossing company boundaries attempt to integrate your company's applications with those of your suppliers and/or customers? Integrating business processes across multiple businesses is commonly referred to as business-to-business integration.
Web services are a technology that enables B2B integration. By using Web services, your company can expose vital business processes to authorized suppliers and customers. For example, you can expose electronic ordering and invoicing, thereby enabling your customers to electronically send purchase orders to you, and your suppliers to electronically send invoices to you.
This is not a new concept: Electronic Data Interchange (EDI) has been around for a while. The key difference is that compared to EDI, Web services are much easier to implement and operate over the Internet, which is widely available to businesses all over the world at a relatively low cost. However, unlike EDI, Web services do not provide a complete solution for document interchange or B2B integration. Instead, Web services are a key-enabling component in B2B integration, with many other components typically needed to complete the picture. The primary advantage of using Web services for B2B integration is low-cost interoperability. By exposing your business functions as Web services, you enable any authorized party to easily invoke those services, regardless of the platform and programming language a particular party uses. This reduces the time and effort it takes to integrate a business process across company boundaries, and ultimately saves time and money. The low cost of integration opens up the playing field for smaller companies that find the cost of implementing EDI prohibitive.
Software reuse can be implemented in many ways. The most basic form is code reuse through classes and modules. Compiling the classes into a binary component that is reused extends code reuse. We would say that Web services are one more step further down the reuse path. With Web services, it is not only possible to reuse the code base, but also the data itself, because the data is located on a server where it can be reached from different applications.
An example of this is an address verification Web service. Instead of having a local database with address information that you need to keep updated, you could have a central database and a Web service that exposes the address information to you. You send an address to the Web service, and it checks the street address, city, state, and zip code to make sure the address exists. If the service is hosted by a provider, the service provider might charge you a periodic fee, or a per-use fee, for the service. A service like this is not possible with component reuse; for this kind of functionality, you need to have a database of street addresses, cities, states, and zip codes.
|
|