Why would you want to use a Web service? They are flexible and supported on a number of platforms and can be implemented by using a number of languages. This chapter from BEA WebLogic Workshop 8.1 (by Albert J. Saganich, Jr., et al., Sams, 2004, ISBN: 0-672-32622-1) covers Web services concepts, SOA, SOAP, WSDL, and security.
Web services introduce a new high-level development paradigm known as service oriented architecture(SOA). SOA focuses on broader resolutions to problems that potentially encapsulate entire solutions into a single "service." These services can then be combined in whatever way that's required to solve a problem. For example, rather than expose the various methods of a banking service, such as withdrawing and depositing, an SOA-based service might provide a single unified transfer service. A key component of SOA is the service broker, which is an intermediary between someone who needs a service and someone who provides a service. The service broker also keeps a repository of information about service providers. This service metadata can be queried at runtime by someone who needs a service and used to make a decision about who might provide that service.
What's so exciting about Web services is the promise of online registries of services provided by service brokers. Consumers need not know who provides a service, only what service they need. At any given moment, any number of service providers can exist, each providing a service with a different level of cost, reliability, performance, or some other factor. The service consumer chooses at runtime which provider best fits. Consider a Web-based picture printing solution that provides different levels of quality and processing speed. All these services could offer the same interface, yet the end result, the printed picture, could vary widely.
In general, Web services:
Are self-describing, self-contained, modular services accessed via the Web that complete tasks, solve problems, or conduct transactions.
Can be shared by and used as components of distributed Web-based applications.
Are based on interoperability standards so that service consumers need not know how a service is implemented.
Are typically not used when real-time response time is required.
But why would you want to use a Web service? First, Web services are defined and accessed via XML, so they are extremely flexible. Because Web services are accessed by using standard protocols, such as HTTP or Simple Mail Transfer Protocol (SMTP), with an XML payload, they can easily be called through a firewall or via a special-purpose mailer. Additionally, because Web services are supported on a number of platforms and can be implemented by using a number of languages, they are excellent candidates for intermixing development environments, tools, and services.
Use Web services because:
They are language and architecture neutral.
They have a rapid development cycle, especially with WebLogic Workshop.
They can be searched dynamically at runtime via Universal Description, Discovery, and Integration (UDDI).
However, Web services are not the answer to all problems. HTTP is an inherently stateless protocol, XML is a terse heavyweight language, and argument marshaling and unmarshaling over the network are time consuming. Security might also be an issue; that is, security beyond what's currently provided for Web services might be required. You should consider these issues when designing with Web services.
Use Web services when you need to do the following:
Gain interoperability between divergent platforms.
Access applications through firewalls.
Process data via flexible, often standardized, representations.
Intermix different development environments and languages.
Web services are a boon to service consumers largely because of protocol standards. Historically, if you wanted to consume a certain service from an external provider, you needed to develop against its specific Application Programming Interfaces (APIs) and protocols. With Web services, you can simply develop against the Web service's standards and, assuming the provider complies, access a service regardless of who developed it or how it was developed.
Web services are interoperable using:
HTTP, SMTP, and other standard protocols that provide standardized communications.
Simple Object Access Protocol (SOAP), which provides a messaging protocol and wrapper.
Web Services Description Language (WSDL), a standard for describing documents and methods that includes arguments, returns, ordering of calls, and support services.
Universal Description, Discovery, and Integration (UDDI), which is, for all practical purposes, a phone book for Web services.
W3C Schema, which consists of standard XML data types and a description language that can be used to define a Web service.
Document Versus RPC-Based Web Services - Web services differ from the Remote Procedure Call (RPC) services of the past in one significant way. Historically, RPC services were procedure-based, fine-grained APIs based on a method call paradigm. Web services can be method based, but are just as often document based. Document-based Web services typically receive a large, coarse-grained document that includes the content itself and the processing instructions. Document-based Web services are normally loosely coupled and start a chain of back-and-forth communications. These Web service calls are typically very long running and can involve business-based transactions. A good example is clearing a trade after a buyer and seller of stock have agreed. The clearing broker might take hours or even days to receive and transfer the actual stock certificates from the buyer to the seller.
These protocols and standards are examined in more detail later in the chapter.
This chapter is from BEA WebLogic Workshop 8.1, by Albert J. Saganich, Jr., et al. (Sams, 2004, ISBN: 0-672-32622-1). Check it out at your favorite bookstore today.