燃气用户服务系统Web端的设计与实现外文翻译资料

设计（论文）题目： 燃气用户服务系统Web端的设计与实现

2017年 2 月 19日

Chapter 6. Reactive Jersey Client API

Links: Table of Contents | Single HTML

Chapter 6. Reactive Jersey Client API

Table of Contents

6.1. Motivation for Reactive Client Extension

6.2. Usage and Extension Modules

6.3. Supported Reactive Libraries

6.3.1. RxJava (Observable)

6.3.2. Java 8 (CompletionStage and CompletableFuture)

6.3.3. Guava (ListenableFuture and Futures)

6.3.4. JSR-166e (CompletableFuture)

6.4. Implementing Support for Custom Reactive Libraries (SPI)

6.5. Examples

Reactive Jersey Client API is quite a generic API allowing end users to utilize the popular reactive programming model when using Jersey Client. Several extensions come out of the box with Jersey that bring support for several existing 3rd party libraries for reactive programming. Along with describing the API itself, this section also covers existing extension modules and provides hints to implement a custom extension if needed.

If you are not familiar with the JAX-RS Client API, it is recommended that you see Chapter 5, Client API where the basics of JAX-RS Client API along with some advanced techniques are described.

6.1. Motivation for Reactive Client Extension

The Problem

Imagine a travel agency whose information system consists of multiple basic services. These services might be built using different technologies (JMS, EJB, WS, ...). For simplicity we presume that the services can be consumed using REST interface via HTTP method calls (e.g. using a JAX-RS Client). We also presume that the basic services we need to work with are:

Customers service – provides information about customers of the travel agency.

Destinations service – provides a list of visited and recommended destinations for an authenticated customer.

Weather service – provides weather forecast for a given destination.

Quoting service – provides price calculation for a customer to travel to a recommended destination.

The task is to create a publicly available feature that would, for an authenticated user, display a list of 10 last visited places and also display a list of 10 new recommended destinations including weather forecast and price calculations for the user. Notice that some of the requests (to retrieve data) depend on results of previous requests. E.g. getting recommended destinations depends on obtaining information about the authenticated user first. Obtaining weather forecast depends on destination information, etc. This relationship between some of the requests is an important part of the problem and an area where you can take a real advantage of the reactive programming model.

One way how to obtain data is to make multiple HTTP method calls from the client (e.g. mobile device) to all services involved and combine the retrieved data on the client. However, since the basic services are available in the internal network only wed rather create a public orchestration layer instead of exposing all internal services to the outside world. The orchestration layer would expose only the desired operations of the basic services to the public. To limit traffic and achieve lower latency wed like to return all the necessary information to the client in a single response.

The orchestration layer is illustrated in the Figure 6.1. The layer accepts requests from the outside and is responsible of invoking multiple requests to the internal services. When responses from the internal services are available in the orchestration layer theyre combined into a single response that is sent back to the client.

Figure 6.1. Travel Agency Orchestration Service

Travel Agency Orchestration Service

The next sections describe various approaches (using JAX-RS Client) how the orchestration layer can be implemented.

A Naive Approach

The simplest way to implement the orchestration layer is to use synchronous approach. For this purpose we can use JAX-RS Client Sync API (see Example 6.1, “Excerpt from a synchronous approach while implementing the orchestration layer”). The implementation is simple to do, easy to read and straightforward to debug.

Example 6.1. Excerpt from a synchronous approach while implementing the orchestration layer

final WebTarget destination = ...;

final WebTarget forecast = ...;

// Obtain recommended destinations.

Listlt;Destinationgt; recommended = Collections.emptyList();

try {

recommended = destination.path('recommended').request()

// Identify the user.

.header('Rx-User', 'Sync')

// Return a list of destinations.

.get(new GenericTypelt;Listlt;Destinationgt;gt;() {});

} catch (final Throwable throwable) {

errors.offer('Recommended: ' throwable.getMessage());

}

// Forecasts. (depend on recommended destinations)

final Maplt;String, Forecastgt; forecasts = new HashMaplt;gt;();

for (final Destination dest : recommended) {

try {

forecasts.put(dest.getDestination(),

forecast.resolveTemplate('destination', dest.getDestination()).request().get(Forecast.class));

} catch (final Throwable throwable) {

errors.offer('Forecast: ' throwable.getMessage());

}

}

The downside of this approach is its slowness. You need to sequentially process all the independent requests which means that youre wasting resources. You are needlessly blocking thr

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[140854]，资料为PDF文档或Word文档，PDF文档可免费转换为Word