Introduction: Web services

Explore the key concepts pertaining to Web services applications. Web services are self-contained, modular applications that can be described, published, located, and invoked over a network. They implement a service-oriented architecture (SOA), which supports the connecting or sharing of resources and data in a flexible and standardized manner. Services are described and organized to support their dynamic, automated discovery and reuse.

The following list includes the core Web services concepts:

Web services

Web services are self-contained, modular applications that you can describe, publish, locate, and invoke over a network.

Web Services for J2EE specification

The Web services for J2EE specification defines the programming model and runtime architecture for implementing Web services based on the Java language. Another name for the Web Services for J2EE specification is the Java Specification Requirements (JSR) 109. The specification includes open standards for developing and implementing Web services.

Java API for XML-based RPC (JAX-RPC)

You can use the Java API for XML-based RPC (JAX-RPC) specification to develop SOAP-based interoperable and portable Web services and Web services clients. JAX-RPC provides core APIs for developing and deploying Web services on a Java platform and is a required part of the J2EE platform. Use the J2EE platform to develop portable Web services. You can also develop and deploy Web services on J2EE containers.

SOAP

SOAP is a specification for the exchange of structured information in a decentralized, distributed environment. SOAP represents the main way of communication between the three key actors in an SOA environment: service provider, service requestor and service broker. The main goal of its design is to be simple and extensible. A SOAP message is used to request a Web service.

SOAP with Attachments API for Java interface

SOAP with Attachments API for Java (SAAJ) is used for SOAP messaging that works behind the scenes in the JAX-RPC implementation. You can map XML to Java types with standards supported by the JAX-RPC specification; however, there are limited XML schema types. Therefore, you can use the SOAPElement interface to create a custom data binder.

Web Services-Interoperability Basic Profile

The Web Services-Interoperability (WS-I) Basic Profile is a set of non-proprietary Web services specifications that promote interoperability.

RMI-IIOP using JAX-RPC

JAX-RPC is the Java standard API for invoking Web services through remote procedure calls. A transport is used by a programming language to communicate over the Internet. You can use protocols with the transport such as SOAP and RMI. You can use Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) with JAX-RPC to support non-SOAP bindings.

WS-I Attachments Profile

The WS-I Attachments Profile is a set of non-proprietary Web services specifications that promote interoperability. This profile compliments the WS-I Basic Profile to add support for interoperable SOAP messages with attachments-based Web services.

Service-oriented architecture

SOA is a collection of services that communicate with each other, for example, passing data from one service to another or coordinating an activity between one or more services.

Web services approach to a service-oriented architecture

The Web services approach implements a SOA. A major focus of Web services is to make functional building blocks accessible over standard Internet protocols that are independent from platforms and programming languages. These services can be new applications or just built on existing legacy systems to make them network-enabled. A service can rely on another service to achieve its goals.

Web services business models supported

A benefit of using a SOA is that Web services are well-suited for binding small modules that perform independent tasks within a highly heterogeneous e-business model. Web services can be easily built around existing applications in your business model and plugged into different business processes.

Custom data binders

A custom data binder is used to map XML schema types with Java objects. Custom data binders provide bindings for XML schema types that are not supported by the current JAX-RPC specification.

Custom binding providers

A custom binding provider is the packaging of custom data binder classes with a declarative metadata file. The main purpose of a custom binding provider is to aggregate related custom data binders to support particular user scenarios. The custom binding provider is used to plug the custom data binders into the emitter tools and the runtime system so that the emitter tools can generate the appropriate artifacts, and the runtime system can augment its existing type mapping system to reflect the applied custom data binders and invoke them.

Securing Web services applications at the transport level

You can use transport-level security that is based on SSL or Transport Layer Security (TLS) that runs beneath HTTP. Use transport-level security to secure Web services messages. However, transport-level security functionality is independent from functionality that is provided by WS-Security or HTTP Basic Authentication.

Authenticating Web services clients using HTTP basic authentication

HTTP basic authentication uses a user name and password to authenticate a service client to a secure endpoint. The application server can have several resources, including Web services which are protected by a J2EE security model.

WSDL

Web Services Description Language (WSDL) is an Extensible Markup Language (XML)-based description language. This language was submitted to the World-Wide Web Consortium (W3C) as the industry standard for describing Web services. The capabilities of WSDL are derived from two main architectural principles: the ability to describe a set of business operations and the ability to separate that description into two basic units. These units are a description of the operations and the details of how the operation and the information associated with it are packaged.

What is new for securing Web services

In this version of the product, security enhancements for Web services include supporting sections of the Web services security specifications and providing architectural support for plugging in and extending the capabilities of security tokens.

High-level architecture for Web services security

This version of the product uses the J2EE Web services deployment model to implement Web services security. The Web services security constraints are specified in the IBM extension of the Web services deployment descriptors and bindings. The Web services security run time enforces the security constraints specified in the deployment descriptors. One of the advantages of the deployment model is that you can define the Web services security requirements outside of the application business logic. With the separation of roles, the application developer can focus on the business logic, and the security expert can specify the security requirement.

Overview of platform configuration and default bindings

The Web services security constraints are defined in an IBM extension of the Web services deployment descriptor for J2EE. The IBM extension deployment descriptor and binding for Web services security are IBM proprietary. Due to the complexity of these files, it is not recommended that you edit the deployment descriptor and binding files manually with a text editor because that action might cause errors. It is recommended, however, that you use the tools provided by IBM to configure the Web services security constraints for an application. These tools are the Rational Application Developer, the Application Server Toolkit, and the application server administrative console.

Security model mixture

There can be multiple protocols and channels in the WebSphere Application Server V6 and later programming environments. For example, you might access a Web-based application through the HTTP transport. For example, a servlet, JavaServer Pages file, HTML and so on. You might access an enterprise application through the Remote Method Invocation over the Internet Inter-ORB (RMI/IIOP) protocol and a Web service application through the Simple Object Access Protocol (SOAP) over HTTP, SOAP over the Java Message Service (JMS), or SOAP over RMI/IIOP protocol. Each of these applications serve different business needs. More importantly, Web services are often implemented as servlets with a JavaBeans or an EJB file. Therefore, you can mix and match the Web services security model with the J2EE security model for Web and EJB components. Web services security compliments the J2EE role-based security and the security runtime for this versionof the application server.

Default implementations of the Web services security service provider programming interfaces

The following information describes the default implementations of the service provider interfaces (SPI) for Web services security within this version of the application server. The default implementations of the service provider interfaces for WebSphere Application Server V5.x are not described in this document. Instead, see Securing Web services for V5.x applications based on WS-Security for the V5.x implementations that are deprecated in V6.0.x and later.

Default configuration

This version of the product provides a variety of sample configurations that you can configure through the administrative console. The configurations that you specify are reflected at the cell or server level. Do not use these configurations in a production environment as they are for sample and testing purposes only. To make modifications to these sample configurations, it is recommended that you use the administrative console provided by the application server.

Nonce, a randomly generated token

A nonce is a randomly generated, cryptographic token used to prevent replay attacks. Although a nonce can be inserted anywhere in the SOAP message, you typically insert this token in the UsernameToken element.

XML digital signature

XML-Signature Syntax and Processing (XML digital signature) is a specification that defines XML syntax and processing rules to sign and verify digital signatures for digital content.

Collection certificate store

A collection certificate store is a collection of non-root, certificate authority (CA) certificates and certificate revocation lists (CRLs). This collection of CA certificates and CRLs is used to check the signature of a digitally signed SOAP message.

Trust anchor

A trust anchor specifies the keystores that contain trusted root certificates. Use these certificates to validate the X.509 certificate that is embedded in the SOAP message.

Key locator

A key locator, or the com.ibm.wsspi.wssecurity.keyinfo.KeyLocator class, is an abstraction of the mechanism that retrieves the key for digital signature and encryption.

Trusted ID evaluator

A trusted ID evaluator, (com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl), is an abstraction of the mechanism that evaluates whether the given ID name is trusted.

XML encryption

XML encryption is a specification developed by the W3C that contains the steps to encrypt data, the steps to decrypt encrypted data, the XML syntax to represent encrypted data, the information used to decrypt the data, and a list of encryption algorithms such as Triple Data Encryption Standard (DES), Advanced Encryption Standard (AES), and RSA.

Security token

A security token represents a set of claims made by a client that might include a name, password, identity, key, certificate, group, privilege, and so on.

Username token

You can use the UsernameToken element to propagate a user name and, optionally, password information. Also, you can use this token type to carry basic authentication information. Both a user name and a password are used to authenticate the message. A UsernameToken containing the user name is used in identity assertion, which establishes the identity of the user based on the trust relationship.

Binary security token

The ValueType attribute identifies the type of the security token, for example, a Lightweight Third Party Authentication (LTPA) token. The EncodingType token type indicates how the security token is encoded, for example, Base64Binary. The BinarySecurityToken element defines a security token that is binary encoded. The encoding is specified using the EncodingType attribute. The value type and space are specified using the ValueType attribute. The Web services security implementation for WebSphere Application Server, V6 and later supports both LTPA and X.509 certificate binary security tokens.

Hardware cryptographic device support for Web Services Security

Web services security supports the use of cryptographic hardware devices. There are two ways in which to use hardware cryptographic devices with Web services security.

Web services security specification—a chronology

This document describes the process used to develop the Web services security specifications.

Web services security and Java 2 Platform, Enterprise Edition security relationship

This document describes the relationship between Web services security (message level security) and J2EE platform security. It also includes information on J2EE role-based authorization checks.

Web Services Addressing support

The Web Services Addressing (WS-Addressing) support in the application server provides the environment for Web services that use the W3C WS-Addressing specifications or the W3C submission WS-Addressing specification.

Web Services Resource Framework support

The Web Services Resource Framework (WSRF) support in the application server provides the environment for Web service applications that follow the OASIS WSRF specifications.

WSIF Overview

The Web Services Invocation Framework (WSIF) provides a Java API for invoking Web services, independent of the service format or the transport protocol through which it is invoked.

Goals of WSIF

WSIF aims to extend the flexibility provided by SOAP services into a general model for invoking Web services, irrespective of the underlying binding or access protocols.

Overview of the V3 UDDI registry

The Universal Description, Discovery and Integration (UDDI) specification defines a way to publish and discover information about Web services. The term Web service describes specific business functionality exposed by a company, usually through an Internet connection, so that another company, or its subsidiaries, or software program can use the service. You can find the UDDI specification on the OASIS UDDI Web site.

Database considerations for production use of the UDDI registry

The UDDI registry fully supports a number of databases (see An overview of the V3 UDDI registry for details) and can be used for development and test purposes. However, there are factors to consider when determining which database is appropriate for your anticipated UDDI registry production use such as the size and volume of the requests and the performance and scalability of the UDDI registry.

Access control for UDDI registry interfaces

Access to UDDI registry interfaces is controlled by a combination of J2EE declarative security using role mappings, and UDDI properties and policies such as the registering of users as UDDI publishers.

UDDI registry security additional considerations

In addition to the configuration of UDDI registry security, there are a number of other UDDI registry settings that might affect the behavior of the UDDI registry. Some of these settings are security specific, while others are points to remember when configuring security.

UDDI registry Administrative (JMX) Interface

Use the UDDI registry Administrative Interface to inspect and manage the run time configuration of a UDDI application. This action includes managing the information and the activation state about a UDDI node; updating properties and policies; setting publish tier limits; registration of UDDI publisher and controlling value set support. You can read and invoke the operations of the UDDI registry Administrative Interface using standard Java Management Extensions (JMX) interfaces.

Java API for XML Registries (JAXR) provider for UDDI

The Java API for XML Registries (JAXR) is a Java client API for accessing both UDDI (V2 only) and ebXML registries. It is part of the J2EE specification.

For a complete list of the specifications and standards the product supports, read about specifications and API documentation.

Related concepts

Related Reference