| Building Web Services |    
|
| Building Web Services |
|
| C H A P T E R 1 |
|
Web Services: A Conceptual Overview |
This book explains how you can build simple and complex web services using the Sun
Open Net Environment (Sun ONE) Studio 4, Enterprise Edition for Java integrated development environment (IDE). The explanations assume that you have general knowledge of how to use the IDE.
Industry standards for web services are still evolving. The software implementing the standards are evolving. Even the meaning of web services can be confusing to developers who simply want to get started using the new technologies. This chapter provides an overview of web services, and lays the groundwork for subsequent chapters that describe how to use the web services features of the IDE.
In general terms, web services are distributed application components that conform to standards that make them externally available and solve certain kinds of widespread industry problems. This section describes some of the problems addressed by web services, and provides an overview of web services standards.
One of the basic problems of a modern private enterprise or public agency is how to integrate diverse computer applications that have been developed independently and run on a variety of software and hardware platforms. The proliferation of distributed environments has created a need for an enterprise to be able to expose part of the functionality of an application to other applications over a network. Those functions might be used within the enterprise, by related enterprises such as business partners, and even by external enterprises that have no organizational or contractual relationship with the enterprise providing the service.
Decoupling client and service development enables a given service to be accessed by a variety of client types (such as browser-based clients and wireless clients) that adhere to the standardized web services technologies. In this context, a "client" means any user of a service, including another service.
Traditional enterprise systems often require interfaces between related suites of applications. One example is software that manages accounts payable, accounts receivable, general ledger, and departmental budgets. Another example is software for personnel data, payroll, and benefits. A payroll system typically is responsible for tax withholding, direct deposit to banks, and other functions that provide information to systems outside the enterprise.
The traditional use of programmed interfaces and shared data for integration requires coordination of the logic and data structures of the applications involved, as well as the ability to handle differences between hardware and software platforms. This approach creates maintenance problems even within an enterprise. A desired change in one application might require a series of changes in other applications. Changes in tax regulations and government-mandated reporting requirements can prove difficult and costly for enterprises and industries that rely on heterogeneous computer systems.
Recent years have seen enormous growth of Internet commerce, electronic transfer of funds, and other networked activities that are necessary to economic and social institutions. Production, supply, and trade is often widely distributed, with complex logistics and tracking requirements. Enterprises need to accommodate elaborate processes, regulations, and relationships with external enterprises and government entities. These developments have created a greater need for computer applications that are interoperable across platforms, capable of being shared across networks, and adaptable to change.
A simple example of a widely shared type of Internet application is an online catalog. Many web sites make browser-based interfaces available to customers for this purpose. A more complex example is a business application that orders parts of many different types from a variety of vendors. A given transaction might involve several suppliers, the decisions can depend on dynamically changing prices and dates of availability, and the items that make up a transaction must have compatible technical specifications. The desire of enterprises to be able to do business in this way is a major motivation behind the efforts of computer vendors and standards groups to develop a web services infrastructure.
Another industry requirement is for modern applications to access standardized, computationally intensive algorithms written in low-level programming languages. Examples include actuarial calculations, stock analysis formulas, weather forecasting, optimal route selections, and general-purpose statistical routines. Some of these programs are very complex, highly optimized, and widely established, so that it is not feasible to consider rewriting them. Web services make it possible to expose the functionality of these programs to new applications. (Appendix A explains how you can access C and C++ shared libraries in a web service.)
Web services are distributed, reusable application components that selectively expose the functionality of business services such as EJB components and make that functionality available to applications through standardized Internet protocols.
The web services architecture satisfies these requirements:
The Sun ONE Studio 4, Enterprise Edition for Java IDE meets these requirements and, additionally, gives you the ability to combine the low-level methods of one or more business components into higher-level functionality suitable for a web service.
The following section describes the standards, technologies, and architecture that define web services.
The web services architecture is based on three related standards: SOAP, WSDL, and UDDI. The standards documents are lengthy, but in general terms the three-pronged architecture can be described as follows:
|
Note - Implementations of web services generally involve passing XML documents over HTTP. This book assumes that the reader is familiar with XML and HTTP. |
SOAP (Simple Object Access Protocol) is a W3C (World Wide Web Consortium) standard defining protocols for passing objects using XML. A SOAP runtime system (an implementation of the SOAP standard) enables a client to call methods on a SOAP-enabled service, passing objects in XML format.
The following summary is from the abstract of the W3C SOAP 1.1 specification. See http://www.w3.org/TR/2000/NOTE-SOAP-20000508 for more information.
"SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework."
The payload of a SOAP RPC message contains application data (objects and primitive types) serialized and represented as XML.
WSDL (Web Service Description Language) is a W3C standard, XML-based language used to describe a web service's external interface.
You can make a web service available to other users by giving them a link to its WSDL file. UDDI registries, described later in this chapter, provide a place where you can publish information about a web service. Developers who search the UDDI registry and decide to use your service can find the location of the service and its WSDL file, and use this information to create a SOAP client capable of issuing remote requests to your service.
The following summary is from the abstract of the W3C WSDL 1.1 specification. See http://www.w3.org/TR/2001/NOTE-wsdl-20010315 for more information.
"WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to enable description of endpoints and their messages regardless of what message formats or network protocols are used to communicate."
UDDI (Universal Description, Discovery, and Integration) is a protocol for web-based registries that contain information about web services.
A UDDI registry can be public, private, or hybrid. These descriptive terms are not technical distinctions, but differences in the scope of a registry and how it is used.
A registry entry for a web service has enough information so that a developer can create a client application capable of binding to the service and calling its methods. The term "client" is relative, referring to any component that issues calls to the web service. A registry entry must contain the location of the WSDL file describing a service (needed to create the client) and the location of the runtime service (needed to run the client).
A registry entry can contain additional information about the service and its provider. For example, potential users might want to know how committed the provider is to supporting the service and whether the provider has "credentials" or a reputation as a trustworthy source for the service. This issue does not originate with web services. The question of trustworthy sources arises with SSL-based certificates, where certain companies are widely recognized as certificate-granting authorities. The same question arises with older technology, as in the credit card industry or, to take a governmental example, the National Bureau of Standards.
A public registry might grow to thousands or even millions of services. Therefore, the UDDI standard supports categorization of services. A variety of taxonomies are already available based on categories such as industry, geographical region, product, and service. UDDI registry implementations provide facilities for publishing services and for searching a registry.
See http://www.uddi.org for UDDI specification documents, discussions, articles, and a list of participating enterprises. Sun Microsystems, Inc., is one of the companies participating in the UDDI project.
FIGURE 1-1 shows how a web service is made available through a UDDI registry. In the example, Company P is the web service provider and Company R is the web service requester. You can also think of Company P and Company R as divisions within a single company, using a private registry.
1. Company P creates the web service and the WSDL file that describes its external interface. Company P publishes the web service to a UDDI registry, providing information about the web service, including the location of the WSDL file and the location of the runtime web service.
2. Company R searches the UDDI registry for a web service that provides certain functionality, and selects the web service created by Company P.
3. Company R uses the WSDL description and other information about the web service to create a client component capable of making requests to the web service. Company R incorporates the client into its application.
4. Company R runs the application. At runtime, the client component binds to the web service and executes SOAP requests, passing data as XML over HTTP.
The process includes the following tasks:
1. Company P gets permission from the UDDI registry host to write to the registry. Company P establishes itself in the registry through business entries that include name, locator information, and business categorization information.
2. Company P creates an entry in the registry with a URL pointing to the WSDL for its web service. This kind of registry entry is called a technical model (tModel).
3. Company P creates one or more service entries in the registry associated with the tModel. Each service entry has a URL pointing to a runtime instance of the web service. For example, there might be four different runtime instances: one for use by Company P, one for use by business partners, one for use by the general public, and one for test purposes. All of the instances have the same functionality and the same inputs and outputs, but they can have different performance and availability characteristics.
4. Company R creates a client using information from both a tModel and a service entry in the registry. The tModel, with its pointer to the WSDL, has structural information about the external interfaces of the web service. The service entry points to a runtime instance of the web service and might have additional information about the support, performance, and availability that is offered by Company P for the particular runtime instance.
5. Company R can use this information to create and customize a variety of clients for a given web service.
Sun ONE Studio 4, Enterprise Edition for Java web services are implemented as J2EE components. You package a web service along with your business components into a single application.
The Sun ONE Studio 4, Enterprise Edition for Java IDE supports the following major functions without the need for coding (assuming that you have a business component available). These functions and others are described in subsequent chapters of this book.
You can customize the automatically generated entities in the IDE.
A Sun ONE Studio 4 web service can make direct calls to methods of business components. You can also make calls to XML operations. An XML operation encapsulates multiple business method calls into a single, higher-level method. This feature is covered in architectural terms later in this chapter, and its use is described in Chapter 4.
You can create a web service based on the methods of an existing business component (a bottom-up model), or based on a WSDL file (a top-down model). If you create a web service from a WSDL file, the IDE also generates the stub of a enterprise bean. The stub has all the methods designated in the WSDL, but you have to fill in the desired method code. For further information on both models, see Chapter 2.
FIGURE 1-2 illustrates the main components of a web service application developed with the Sun ONE Studio 4, Enterprise Edition for Java IDE. The web service is a logical entity that at runtime spans the web and EJB containers of your J2EE application server and therefore has a multitier architecture.
On the client side, there is a SOAP client proxy. This is a Java class that uses a SOAP runtime system on the client to communicate with the SOAP runtime system on the server, sending SOAP requests and receiving SOAP responses. A SOAP request is an XML wrapper that contains a method call on the web service and input data in serialized form. A SOAP response is an XML wrapper that contains the return value of the method in serialized form. Also on the client side is a front-end client component that makes calls to the SOAP client proxy and processes the return value. This component might consist of HTML and JSP pages, or it could be a Java Swing component, another kind of client, or another service.
On the server side, the JAX-RPC runtime (an implementation of the SOAP 1.1 standard) is in the web container, handling SOAP messages that pass between the client and the web service.
The SOAP requests are transformed into method calls on a generated EJB component (a session bean, created automatically by the IDE as infrastructure for your web service). The generated session bean in turn makes method calls on business services in an EJB container or invokes an XML operation.
When you create a new web service, the IDE gives you a choice of architectures. You can choose a multitier architecture (the default), illustrated in FIGURE 1-2, or a web- centric architecture, illustrated in FIGURE 1-3. See Creating a JAX-RPC Web Service from Java Methods for the procedure.
A web service created with the multitier architecture can call business methods only on components in an application server. A web service created with the web-centric architecture can call methods on web tier business components and EBJ business components. If a web-centric web service uses only web tier business components, the service can be deployed to a web server, and in this case you do not need an application server.
If you choose the web-centric architecture, the IDE generates a support structure based on Java classes instead of an EJB session bean. This enables the support structure to run in a web container.
In terms of application assembly and deployment, there are three alternatives:
For further information, see Assembling and Deploying a Web Service.
Web standards and technologies are still evolving. The Sun ONE Studio 4 IDE uses the following versions of each standard and software implementation.
ONE Application Server 7
2 Software Development Kit, Standard Edition, 1.4 or 1.4.1 (J2SE SDK)
2 Platform, Enterprise Edition (J2EE SDK) 1.3.1 (installed with the IDE)
The IDE makes it easy for you to create web services that expose Java methods of existing application components. However, some EJB components are not designed to be exposed externally through web services. You might have to create a web service interface layer, either by programming additional Java components or by creating XML operations.
|
Note - You can bypass the XML operation machinery if your web service simply exposes individual methods of a business component. The procedure is explained in Chapter 2. |
The IDE user interface enables you to create complex applications based on existing J2EE components without additional coding. You can:
EJB components are often designed to be used by smart clients that understand and can manage the internal logic of the components. The methods might be too low-level to be directly exposed in a web service, or several method calls on different components might be necessary to return a desired object in the desired form.
A new business component that is designed with a web service model in mind might have methods that provide just the right high-level features. However, an existing business component, or a component not specifically designed as the basis for a web service, might not have the necessary higher-level methods.
The IDE solves this problem by providing the XML operation, which plays an intermediary role. An XML operation can chain together multiple EJB methods into a single higher-level business function suitable for a web service. Chapter 4 explains how to create XML operations.
An XML operation can encapsulate a number of business methods. To an external client, the operation looks like a single RPC call into the web service.
You define an XML operation using a codeless editor. Chapter 4 explains the capabilities of an XML operation and how to use the editor.
The XML operation is a logical entity that specifies how a particular web service request is processed. You create all the XML operations and add them to the web service along with business methods of other components. Then you generate the web service's runtime classes in the IDE. This creates an EJB session bean and one class for each XML operation. When a client sends a request to the web service, the request is transformed into a method call on the session bean. The request is processed either as a single direct call to a business method or as a more complex set of method calls defined by an XML operation.
|
Note - All the methods in a single XML operation have the same state and can share data for the duration of the operation. |
The XML operations feature has these major benefits, compared with trying to accomplish the same purpose by manual coding:
A Sun ONE Studio 4 web service provides two kinds of external functionality, which you can think of as simple and complex: direct method calls to business components and XML operations. From the standpoint of a client using the web service, they look alike, since an XML operation encapsulates a number of method calls. Each XML operation defines a response to a particular client request message. The web service developer defines and generates the XML operations from existing components.
When a web service receives a client request, it forwards the request in the form of an XML document (the XML input document) to the appropriate XML operation. The XML operation calls one or more methods on business components, transforms the return values of these method calls into an XML document (the XML output document), and returns the document to the client.
When an XML operation is executed, the web service:
1. Parses the XML input document, mapping the document's elements to the parameters of the methods that the XML operation is defined to call.
2. Calls the methods defined in the XML operation, in their specified order.
3. Formats return values of the methods into an XML output document according to the definition of the XML operation.
4. Returns the XML output document.
For example, FIGURE 1-4 shows an XML operation named ProductName that calls methods on three different objects.
The ProductName XML operation takes the product ID as a request parameter and returns the capitalized name of the corresponding product. When executed, the operation:
1. Parses the XML input document, using the value of the document's prod_id element as the input parameter to the Catalog.getProduct method.
2. Calls the Catalog.getProduct method, which returns an instance of the Product class.
3. Calls the getName method on the Product object, which returns a String object that contains the product name.
4. Calls the static method StringUtility.capitalize, passing the String object that contains the product name as a parameter. This method returns a String object containing the product name formatted with initial capital letters.
5. Formats the String object containing the capitalized product name as an XML document and returns it.
| Building Web Services | 816-7862-10 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.