| 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
ONE Studio 5, Standard Edition 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 implementations of 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 all or part of the functionality of an application to other applications over an open network.
Application functionality exposed through a web service can be used within an enterprise, by related enterprises such as business partners, and by external enterprises that might or might not have an organizational or contractual relationship with the enterprise providing the 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.
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.
Enterprises often need to accommodate elaborate processes, regulations, and relationships with external enterprises and government entities. A payroll system might be responsible for tax withholding, direct deposit to banks, and other functions that provide information to systems outside the enterprise. 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. 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 common example of a business-to-business (B2B) application is software 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. This is a more complex requirement than the typical business-to-customer application that might involve an online catalog and ordering process on the business side, and a browser on the customer side.
Web services are distributed, reusable application components that expose the functionality of business services such as EJB components, and make business methods available to applications through standardized Internet protocols and message formats.
The web services architecture satisfies these requirements:
Web services technologies support distributed application development. Clients of different types can be created by developers based on a description of a web service's external interfaces, using a standardized web service definition language. This eliminates the need for client developers to have knowledge of the internal logic of a web service.
The Sun ONE Studio 5, Standard Edition IDE provides a user-friendly environment in which you can create web services and clients that meet these requirements.
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. This section provides a summary description of the three standards, followed by a more substantial description and references to the full specifications.
In general terms the three-pronged architecture can be described as follows:
Implementations of web services generally involve passing Extensible Markup Language (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 data.
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. With this information, developers can create SOAP clients 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, such as the location of the WSDL file that describes a web service's external interfaces.
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 provides the technical information to enable a developer to 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 web service and its provider. For example, potential users might want to know how committed the provider is to supporting the service and whether there is a charge for accessing the service.
A registry might have entries for multiple web services that implement the same external interfaces (the same WSDL), possibly differing in runtime characteristics such as performance or availability, or provided by different vendors on different terms. Registry search facilities can help a client developer to choose the best web service to access for a given application.
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.
One of the issues to consider in using a web service that you find through a UDDI registry search is the reputation of the service provider. This issue does not originate with web services. The question of trustworthy sources arises with network security technology in which digitally signed certificates are exchanged. Certain companies are widely recognized as certificate-granting authorities. The same question arises with older technology, as in the credit card industry, or in relying on government institutions such as the National Bureau of Standards.
Web services technologies can enhance the capabilities of widely-recognized industry or governmental organizations to make available complex, standardized tables of technical information to interested parties.
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.
The Web Services Interoperability Organization (WS-I) is an open industry association whose purpose is to promote web services interoperability across platforms, applications, and programming languages. This is achieved through the specification of profiles which define the precise rules to be used by conforming services. A profile includes web services specifications at designated release levels, together with guidelines for how to use the features in the specifications. A WS-I profile guides the work of web services developers in using lower-level specifications such as SOAP, WSDL, and UDDI.
WS-I works with other standards organizations, including the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). WS-I, founded in February 2002, is composed of members from over 150 companies, and is governed by a Board of Directors, of which Sun Microsystems is a member. You can find more information about WS-I, including their published documents, at the WS-I web site: http://www.ws-i.org.
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. The numbered steps in FIGURE 1-1 can be described as follows:
The first three steps in the process occur during development. The fourth step occurs at runtime, when the deployed client communicates with the deployed web service.
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, and selects the web service created by Company P.
3. Company R gets the WSDL file and creates a client component capable of interacting with the web service. Company R incorporates the client into an application and deploys the application.
4. Company R runs the application. At runtime, the client component binds to the web service and executes SOAP requests, passing XML data over HTTP.
|
Note - The UDDI registry is not used at runtime. It is a development facility. |
The process includes the following technical tasks:
The 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.
The following features are new in this release.
You can create a web service based on the methods of an existing business component (a bottom-up development model) or based on a WSDL file (a top-down development 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.
When you build a web service or client, the IDE generates a supporting structure of classes and other objects. You can use the IDE to customized the generated objects. For example, you can customize a generated client to better meet the needs of your production application and end-users.
When you create a web service, the IDE gives you a choice of two architectures, called multitier and web-centric. The default multitier architecture is illustrated in FIGURE 1-2. The web-centric architecture is illustrated in FIGURE 1-3. See Creating a JAX-RPC Web Service From Java Methods for procedures.
FIGURE 1-2 illustrates the main components of a web service application developed with the IDE using the multitier architecture. The web service is a logical entity that at runtime spans the web and EJB containers of your J2EE application server.
On the client side, there is a SOAP client proxy. This is a set of Java classes that use 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 component that makes calls to the SOAP client proxy and processes or displays the value returned by the web service. This component might consist of HTML and JSP pages, or it could be a Java Swing component, another kind of client, or another service. The HTML browser, typically used to access the client, is not illustrated.
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 client's 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 (optionally) invokes an XML operation.
A multitier web service cannot run in a web container, because the generated EJB component requires an application server. Moreover, a multitier web service can only call methods on business components running in the EJB container of an application server.
FIGURE 1-3 illustrates the main components of a web service application developed with the IDE using the web-centric architecture. 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.
A web-centric web service can call methods on web tier business components and EBJ business components, thus providing more flexibility than a multitier web service. If your web-centric web service uses only web tier business components, you do not need an application server. A web server is sufficient.
If your application uses only EJB business components, choose the multitier architecture for scalability. A generated support structure that runs in the same container as the business EJB components is more efficient.
The deployment model depends on the web service architecture and the type of business components:
See Assembling and Deploying a Web Service for more information about assembly and deployment.
Web standards and technologies are still evolving. The Sun ONE Studio 5, Standard Edition IDE uses the following versions of each standard and software implementation.
ONE Application Server 7, Standard Edition
2 Software Development Kit, Standard Edition (J2SE SDK), version 1.4.1_02 or higher
This feature is deprecated and might not be supported in future releases of the IDE. See Chapter 5 for further information.
| Building Web Services | 817-2324-10 |
|
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.