If you are developing a modern enterprise application, you are likely going to be concerned with creating an application that has many pluggability points, and can be integrated with and plugged into a diverse array of presentation, middle-tier and even backend technologies.
Furthermore, you want your applications to have serviceability points that are not tied to a particular programming language, be it some type of Java implementation or a .NET interface. If interoperability and pluggability are the goals, a good way to implement business functionality is by using Web services.
So what are Web services?
In the simplest terms, a Web service is an electronic means for two computer programs or applications to communicate and exchange data. Of course, that is a pretty broad definition which could include anything from a walkie-talkie to an Internet browser.
What sets a Web service apart is the small scale granularity of what is communicated between the two devices. This small and granular interaction really gets to the heart of the 'service' part of the term 'Web service.'
A typical Web service will be nothing more complicated than a simple piece of functionality that might be built into any enterprise application. The key difference with the Web service is the assumption that this code will be invoked over the network, as opposed to simply being invoked directly through a local programming call.
The other key differentiator is the fact that a disparate set of clients might be invoking the service. So, a given application might be developed entirely in Java and deployed to Unix based machines, but the clients invoking the program might be .NET applications, Java EE applications or even older J2EE application, all of which might be deployed to a Windows platform, a Unix platform, or any other type of platform imaginable.
Use cases for Web services
So, what might be a good use for a Web service? The possibilities are endless, but a few hypothetical examples might include a credit card checking service that validates whether a given number and expiration date are valid, or whether a given card has an adequate available balance in order for a user to make a purchase. Another example might be a Web service that could take a given tracking number and return the pertinent routing information about a given package to the client. Another example might be a Web service developed for a warehouse that allows retailers and other sellers to provide a stock keeping unit code (SKU) to the service, and the calling program would be informed as to how many units are available for delivery.
These three scenarios are excellent examples of service functionalities that an enterprise might want to make available to clients. In each instance, there is a clearly identifiable service that is being offered. Furthermore, each service would be of interest to a variety of different clients, many of which might be developed in environments that are not necessarily controlled by the developer of the service.
For example, the credit card checker might be coded in Java, but various retail stores that use competing frameworks would still have the ability to invoke the service as long as those clients were able to connect to the network on which the Web service was running.
Not every piece of code or implemented functionality in any application needs to be invoked remotely by a vast array of client implementations. But when this type of functionality is necessary, the standard solution is a Web services implementation.