Utility Tools
CHAPTER 7
Web Services enable businesses to share application functionality regardless of the source language, operating system, or hardware used to create that functionality. Web Services overcome implementation incompatibilities by using standard Internet protocols and XML-based messaging to provide intercomponent communication.
This chapter gives an overview of Web Service technologies and how the Novell exteNd Director development environment supports the creation and use of Web Services. Topics include:
Web Services are modular software components whose application functionality is accessible over the Web using Simple Object Access Protocol (SOAP), a standardized XML-based messaging protocol.
Applications invoke Web Services like remote procedure calls, except that the procedure call and response are handled using SOAP messages embedded in HTTP requests and responses. An application calls a Web Service by sending a SOAP message embedded in an HTTP request to a Web location associated with that service. The Web Service performs the application logic for that message and then returns any application output in the form of another SOAP message embedded in an HTTP response.
To learn more about SOAP messages, see www.w3.org/TR/SOAP.
The Web Service architecture typically consists of Web Service providers, consumers, and registries:
A Web Service provider is an organization that creates and hosts Web Services. Typically, a provider publishes information about their organization and the services they offer in a Web Service registry that can be queried by members of the organization or possibly by other businesses.
A Web Service consumer finds a Web Service (typically by querying a Web Service registry) then runs the service by establishing a connection to the provider. This is called binding to a Web Service.
A Web Service registry is a collection of business and service information that is readily accessible to providers and consumers, through programmatic publishing and querying interfaces.
A Web Service provider:
A provider creates the application logic components and deploys them to a network-accessible location, typically using a Web application server. To make these logic components into a Web Service, the provider creates and deploys a SOAP message-handling interface that enables HTTP requests containing well-defined SOAP messages to invoke the appropriate Web Service functionality.
When a consumer application accesses the service by sending a SOAP message embedded in an HTTP request, the provider runs the application logic and returns any application output in another SOAP message embedded in an HTTP response. For example:
To specify information about a Web Service in a standard form, the provider creates a Web Services Description Language (WSDL) document describing its characteristics. WSDL is an XML-based format that describes a Web Service by using these elements:
In WSDL, an endpoint specifies a network address as well as the protocol and data format of messages exchanged with that address.
Given the flexibility of the WSDL specification, the information in a WSDL document can become complicated. For easier understanding, think of a WSDL document as essentially specifying the interface and port location of a Web Service.
To learn more about WSDL, see www.w3.org/TR/wsdl.
Once a Web Service has been created and deployed, the provider can publish information about the service and the provider organization in one or more registries. This enables prospective consumers to discover that the service is available and learn how to use it.
For details, see Using Web Service registries.
Another way to publish Web Service information is to provide the information directly to specific consumers by using Web pages, e-mail, personal communications, and so on. This is called direct publishing.
A Web Service consumer creates applications that use Web Services. Typically, a consumer finds an appropriate Web Service by querying a Web Service registry (see Using Web Service registries).
From the WSDL information provided, the consumer can create the SOAP message-handling code needed to use the Web Service. When the consumer application calls the Web Service, the SOAP message-handling code binds to that service, as follows:
Creates and sends a SOAP message embedded in an HTTP request, instructing the provider to invoke the appropriate Web Service application logic
If the HTTP response contains a SOAP message, converts that message (into a data format understandable to the consumer application) then returns the data to the application
To the consumer application, this is similar to calling a remote method. However, the interaction between the application code and the Web Service uses SOAP messaging embedded in a standard HTTP request and response. For example:
A Web Service registry is a repository of Web Service information that can be accessed programmatically over a network. Both providers and consumers can use Web Service registries:
Providers can publish information about their organization and services to registries, making them visible to prospective consumers.
Consumers can query registries to find the services and businesses that fit their needs and to retrieve provider-supplied information about those services (such as where and how to access them, the WSDL representation, and so on).
A registry can contain these kinds of information:
Registries store their business and service information in a standard XML-based format such as Universal Description, Discovery and Integration (UDDI) or Electronic Business XML (ebXML). Businesses hosting registries typically provide Web page, GUI, or programmatic interfaces for publishing to and querying the registry (so providers and consumers don't need to know details about the internal registry implementation).
To learn more about UDDI, see www.uddi.org. To learn more about ebXML, see www.ebxml.org.
Businesses may use public or local registries:
A public registry is typically visible to anyone on the Web and contains information about numerous companies and services. It may implement varying degrees of authentication and authorization security for publishing and querying.
A local registry might be limited to local network access, enabling a business to share Web Services internally without exposing them to consumers outside the organization.
Here's a summary of Web sites you can visit to find out more about specific Web Service technologies:
|
Topic |
Site |
|---|---|
|
SOAP |
|
|
HTTP |
|
|
WSDL |
|
|
UDDI |
|
|
ebXML |
While it's important to know about the underlying Web Service technologies (SOAP, WSDL, UDDI, ebXML, and so on), it's usually not efficient to develop applications at that level. As a result, higher-level implementations have emerged to make those technologies more accessible by wrapping them in familiar constructs. These implementations include:
J2EE Java 2 Enterprise Edition provides Web Service support through its JAX-RPC (Java API for XML-based RPC) specification.
.NET Microsoft provides Web Service support through its .NET platform.
For example, a programmer familiar with J2EE can more easily use a JAX-RPC implementation to develop and access Web Services. There's no need to become a SOAP expert or process SOAP messages manually.
When properly designed and built, Web Services should be interoperable across different implementations. For instance, a JAX-RPC client should be able to access a .NET Web Service and a .NET client should be able to access a JAX-RPC Web Service.
The exteNd Director development environment provides tools for creating, deploying, and maintaining Web Services based on the JAX-RPC standard. That means Web Services are packaged in J2EE Web archives (WARs) that can be deployed to a J2EE server. You can also develop Java-based Web Service consumers that comply with JAX-RPC.
To help you implement Web Services and Web Service consumers, the development environment includes the following core facilities:
On top of those features, exteNd Director adds higher-level facilities that make it easy to take full advantage of Web Services in your applications.
To learn about these other Web Service facilities of exteNd Director, see the Pageflow and Form Guide.
The Novell exteNd Web Services SDK is a JAX-RPC implementation that includes compilers and a runtime environment for developing and executing Web Service provider and consumer applications.
The Web Service Wizard uses the Web Services SDK compilers to create Web Service components (skeletons, ties, stubs) and WSDL files. Developers can also invoke these compilers separately from the command line.
Both provider and consumer deploy wssdk.jar (and some supporting JARs) with their applications to provide the necessary runtime environment. This includes the SOAP engine that runs when stub and skeleton components pass SOAP messages between consumer and provider applications.
For more information, see the Web Services SDK help.
The Web Service Wizard enables you to create Web Service components from Java classes or WSDL files. It generates the Java remote interface for accessing an object as well as skeleton, tie, and stub Java classes that handle SOAP message communication between a consumer application and a Web Service. The generated code is based on JAX-RPC.
The provider deploys a Web Service as a Web archive (WAR) in which the skeleton and tie classes implement a servlet that processes incoming SOAP messages. A consumer application accesses Web Service functionality by calling methods in the stub class, which sends SOAP messages to the server.
For more information, see:
The Registry Manager helps providers publish to Web Service registries. It helps consumers query Web Service registries.
For more information, see Registry Manager.
The WSDL Wizard helps providers create new WSDL documents. The WSDL Editor helps providers edit and use existing WSDL documents.
For more information, see WSDL Editor.
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...