Introduction: Web services


 

+

Search Tips   |   Advanced Search

 

Overview

Web services are SOA apps invoked over a network, for example, to return data such as weather, flight status, pictures, etc...

Services are described to support automated discovery.

WAS Web service applications are...

Using JAX-WS, clients can invoke Web services asynchronously, allowing the client to continue processing without waiting on the response.

 

Links

JAXB

Map Java classes and XML schema.

Java API for XML Web Services (JAX-WS)

Supports annotations. Has a document-centric messaging model that replaces the remote procedure call model defined by JAX-RPC.

SOAP with Attachments API for Java (SAAJ) V1.3

Extends support to SOAP V1.2 message constructs.

JAX-RPC requires that SOAP messages be manipulated in order to pass through the run time. SOAP messages need to be manipulated, but, at the same time remain in context. SAAJ was introduced to satisfy this requirement.

JAX-WS adds more enhancements to the use of Web services applications, including support for SOAP 1.2 messages, which are supported by SAAJ 1.3.

Streaming API for XML (StAX)

In previous releases, to manipulate XML schemas and types, you had to use one of two standard mechanisms for parsing the XML data:

  • Documents Object Model (DOM)
  • Simple API for XML (SAX)

StAX is an alternative to change and traverse XML data.

SOAP Message Transmission Optimization Mechanism (MTOM)

SOAP MTOM adds support for sending binary attachments, including images or files, with the Web services request.

Web Services Reliable Messaging

Supports reliable message exchange between Web services.

Web services

Self-contained, modular applications that we can describe, publish, locate, and invoke over a network.

Web Services for Java EE specification

Defines the runtime architecture for implementing Web services based on the Java language. JSR 109.

JAX-RPC

Develop SOAP-based Web services. Required part of the Java EE platform.

SOAP

Main method of communication between...

  • service provider
  • service requestor
  • service broker

A SOAP message is used to request a Web service.

SOAP with Attachments API for Java interface

Map XML to Java types with standards supported by the JAX-RPC specification. There are limited XML schema types. Use the SOAPElement interface to create custom data binders.

Web Services-Interoperability Basic Profile

Set of non-proprietary Web services specifications that promote interoperability.

RMI-IIOP using JAX-RPC

Invoke Web services through remote procedure calls. A transport is used by a programming language to communicate over the Internet. Use protocols with the transport such as SOAP and RMI. Use RMI-IIOP with JAX-RPC to support non-SOAP bindings.

WS-I Attachments Profile

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

Collection of services communicating with each other, passing data from one service to another, coordinating activities between one or more services.

Web services approach to a service-oriented architecture

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

Web services are well-suited for binding small modules that perform independent tasks within a highly heterogeneous e-business model. Web services can be built around existing applications in the business model and plugged into different business processes.

Custom data binders for JAX-RPC applications

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 for JAX-RPC applications

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.

Secure Web services applications at the transport level

Based on SSL or 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.

Authenticate Web services clients using HTTP basic authentication

Uses a user name and password to authenticate a service client to a secure endpoint. The server can have several resources, including Web services which are protected by a Java EE security model.

WSDL

Use XML to describe 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

Support of security tokens and other WS-Security enhancements...

High-level architecture for WS-Security

Web services security constraints are specified in the IBM extension of the Web services deployment descriptors and bindings. The WS-Security run time enforces the security constraints specified in the deployment descriptors. One of the advantages of the deployment model is that we can define the WS-Security requirements outside of the business logic. With the separation of roles, the developer can focus on the business logic, and the security expert can specify the security requirement.

Platform configuration and bindings

The Web services security constraints are defined in an IBM extension of the Web services deployment descriptor for Java EE. The IBM extension deployment descriptor and binding for WS-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. IBM recommends, however, that you use the tools provided by IBM to configure the Web services security constraints. These tools are the Rational Application Developer and the appserver admin console.

Security model mixture

There can be multiple protocols and channels in the WebSphere Server V6 and later programming environments. For example, we might access a Web-based through the HTTP transport. For example, a servlet, JSPs file, HTML and so on. We might access an enterprise through the RMI/IIOP protocol and a Web service through the SOAP over HTTP, SOAP over 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 Java Beansor an EJB file. Therefore, we can mix and match the WS-Security model with the Java EE security model for Web and EJB components. WS-Security compliments the Java EE role-based security and the security runtime for this version of the server.

Default implementations of the WS-Security service provider programming interfaces

The following describes default implementations of the service provider interfaces (SPI) for WS-Security within this version of the server. The default implementations of the service provider interfaces for WebSphere 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 WAS provides a variety of sample configurations that we can configure through the admin console. The configurations specified 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, IBM recommends that you use the admin console provided by the server.

Nonce, a randomly generated token

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

Define XML syntax and processing rules to sign and verify digital signatures for digital content.

Collection certificate store

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

Keystores that contain trusted root certificates. Use these certificates to validate the X.509 certificate that is embedded in the SOAP message.

Key locator

Abstraction of the mechanism that retrieves the key for digital signature and encryption. The (JAAS) login module implementation is used to create the security token on the generator side and to validate or authenticate the security token on the consumer side.

Trusted ID evaluator

com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl. Abstraction of the mechanism that evaluates whether the given ID name is trusted.

XML encryption

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

Set of claims made by a client that might include a name, password, identity, key, certificate, group, privilege, and so on.

Username token

Propagate a user name and, optionally, password information. Also, we 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 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 WS-Security implementation for WebSphere Server, V6 and later supports both LTPA and X.509 certificate binary security tokens.

Hardware cryptographic device support for WS-Security

WS-Security supports the use of cryptographic hardware devices. There are two ways in which to use hardware cryptographic devices with WS-Security.

WS-Security specification—a chronology

This document describes the process used to develop the WS-Security specifications.

WS-Security and Java EE security relationship

This document describes the relationship between WS-Security (message level security) and Java EE platform security. It also includes information on Java EE role-based authorization checks.

Web Services Addressing support

WS-Addressing support in the 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

Provides the environment for Web service applications that follow the OASIS WSRF specifications.

WSIF Overview

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

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

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. We can find the UDDI spec 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 the 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 Java EE declarative security using role mappings, and UDDI properties and policies such as the registering of users as UDDI publishers.

UDDI registry security and UDDI registry settings

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

Manage the run time configuration of a UDDI. 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. We can read and invoke the operations of the UDDI registry Administrative Interface using standard JMX interfaces.

Java API for XML Registries (JAXR) provider for UDDI

Java client API for accessing both UDDI (V2 only) and ebXML registries. Part of the Java EE specification.

For a complete list of the supported standards and specifications, see the Web services specifications and API documentation.


Related concepts

WS-Security enhancements
Learn about Web services

 

Related tasks

Task overview: Implement Web services applications

 

Related

Web services specifications and APIs