Web Services Concepts

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.

Web services are a boon to service developers as well because they support a wide range of tools. Web services have the following characteristics:

• They are supported on a number of application platforms (BEA, IBM, Microsoft, and the like).

• They can be developed in many languages, including Java, C, C++, VB, C#, Perl, and others.

• They can be run on various hardware platforms (mainframe, server, and handheld).

SHOP TALK : FUNCTIONALITY: WHERE DOES IT BELONG?

WebLogic Workshop provides a simple, easy-to-use interface for creating controls, EJBs, and Web services. This ease of use is great for productivity, but is not without its problems.

With WebLogic Workshop, you can quickly write Web services that look exactly like controls, at least to the developer. Typically, a fair amount of business logic ends up in Web service methods. These methods aggregate data and apply business logic to form a result. For a simple bank fund-transferring Web service, for example, an important development point might be whether the code for the actual transfer should be in the developed Web service or perhaps in an EJB that can be accessed by the Web service and directly via a Web application.

Much debate rages about this aggregation. One camp is made up of those who believe that Web applications and Web services are basically the same thingan interface to a service. Web applications can obviously be considered an interface; after all, people are the primary consumers of Web data todaywith the key word being today , as a different use might be appropriate tomorrow. Web services, on the other hand, represent interfaces that are targeted at other computing entities. Although people might use a Web service directly, what's more likely is that another program would use the Web service. Therefore, Web services can be considered interfaces to services for applications , just as Web applications are interfaces to services for people .

If you accept this argument, you must reconsider how you develop Web services. With the arrival of Struts and the Model-View-Controller paradigm, architects have given considerable thought to separation of functionality. If you apply the same considerations to Web services, you must at least consider that they are really business-level application interfaces, much as a JSP is a human-level interface. If you accept this idea, you must consider whether a Web service is the correct place for business-level logic. Should Web services simply be presenters of logic, as JSPs are under the MVC paradigm?

I'm not going to draw any specific conclusions for you on this issue; instead, I'm offering some ideas you might consider as you build Web services:

• Is functionality appropriate only for the Web service consumer?

• Is functionality a business-level facade to a service that others can use?

• Will other consumers use this service in the future?

• Will users be located within the same application? Same LAN? Same WAN? Or broadly separated?

• Can the functionality be implemented with an EJB or a control and consumed by Web services and Web application consumers?

Remember, Web services are a heavyweight answer to a problem. Before you choose a Web service, make sure the problem justifies the answer.

Figure 9.1 shows a conceptual model of how Web services work inside and outside WebLogic Server. The Web services runtime provides services to WebLogic Workshop applications consuming Web services via controls and makes Web services available to the outside world. Additionally, WebLogic Server 8.1 provides a UDDI server sitting on top of the runtime, supporting all the services of UDDI v2.0. The runtime, as well as traditional Web applications, uses traditional J2EE services as any application would. Other application servers or Web service clients can access Web services by using UDDI and WSDL directly or via controls.

Figure 9.1. WebLogic Server Web services model.

There are two ways a client application typically uses a Web service: by searching for it or by static access. In the first method, a client searches for a Web service that fits a particular set of characteristics and then goes through a number of steps to access the service. Figure 9.2 shows all the steps required to search for, find, bind to, and use a Web service. Second (and this method is more typical), a client already knows the location and interfaces to a Web service and can avoid steps 1 to 3 shown in Figure 9.2.

Figure 9.2. Web services life cycle overview.

This is the general process after a developer creates a Web service (the numbers correspond to the labels in Figure 9.2):

1. The created service is published to a UDDI registry, such as the embedded WLS UDDI Server or another one on the Web.

2. Potential Web service clients contact a repository and use queries to determine what Web services exist.

3. The repository then returns a response in the form of metadata, including interface definitions and service providers.

4. The client then binds to the service, effectively registering its interest in using it.

5. The client begins using the service.

There is nothing stopping WebLogic Workshop clients from accessing Web services exactly as shown in Figure 9.2. However, clients usually know exactly what Web services they want to access and simply access them at runtime via a control wrapper.