DCC
Product description
Table of Contents
1 Introduction 3
1.1 Purpose 3
2 Functionality 4
2.1 Synchronous communication 4
2.1.1 Usage 5
2.2 Asynchronous communication 6
2.2.1 Usage 6
2.3 Synchronous transformed to asynchronous communication 7
2.3.1 First in line 7
2.3.2 Timeout 8
2.3.3 Usage 8
3 The response service 9
4 Sequences 10
1 Introduction
The DCC is a key component in the Danish National Service Platform (NSP). The DCC is the central hub for communication between a client and a service provider.
1.1 Purpose
The purpose of the DCC is to help developers handle some of the more complex aspects of communicating with web services.
In order to facilitate the most common use cases, the DCC supports three different message types:
- Synchronous
- Asynchronous
- Synchronous transformed to asynchronous (S/Asynchronous)
Besides the different supported messages the DCC has a number of advantages, described in the following sections
1.1.1 Asynchronous support/ Retry handling
The DCC helps the client system handle asynchronous message. Once a client system has delivered a message to the DCC, the client system is guaranteed that the message will be processed and sent to the service provider.
The guarantee covers all messages, even if the service provider is temporarily unavailable.
The DCC is backed by a distributed storage, which guarantees that no messages are lost, once accepted by the DCC. This functionality is similar to what is achieved through the use of the WS-ReliableMessaging protocol.
Once a message has been accepted, the DCC replies with a “queued” error-message.
1.1.2 DCC message sequencing
Since all messages in the NSP must pass through the DCC, the DCC can control the flow and order of each message.
Therefore the DCC allows client systems to tag messages with a sequence. All messages with the same sequence will hereafter be executed in the order they are received by the DCC.
This sequence is maintained across all clients of the DCC instance.
The DCC supports sequencing of asynchronous and S/Asynchronous messages.
1.1.3 Timeout handling
Handling timeout when accessing remote functionality is a challenging task, as a number of aspects must be taken into account, e.g. how long it is acceptable for a user to wait before failing a request, how to recover when an operation fails, etc.
The DCC helps client system handle timeout on SOAP operations in a clean and transparent fashion.
Through the DCC a client system may specify individual timeout periods for each message. If the service provider is unable to respond within the timeout period, the DCC will gracefully return either a timeout error-message, for synchronous messages, or a queued error-message for S/Asynchronous messages – and allow the service provider to terminate correctly.
1.1.4 Notarization of messages
When a message is scheduled for asynchronous processing, the users token may be valid, but from the time when the message is scheduled to the time when the message is processed, the validity may have expired. In some cases a remote system may still want to allow the processing of the message, depending on the validity of the message at the request time.
The DCC solves this issue by notarizing the message upon receipt and thereby guaranteeing, that when the message was received, the attached token was valid.
When notarizing the DCC thus replaces the attached IDcard with an IDWSH identity token.
This ensures that asynchronous message can be processed by the service provider, not matter when they arrive.
1.1.5 Server threads
The DCC contains an implementation of JSR236/JSR237 which correctly deals with threads within a J2EE application.
This provides a verified central implementation for handling asynchronous messages on the NSP.
The DCC implementation thus handles the lack of thread support within applications, which is a common problem in the J2EE specification.
2 Message types
The DCC offers three types of communication:
- Synchronous
- Asynchronous
- Synchronous transformed to asynchronous (S/Asynchronous)
The three communication types are displayed in Figure 1.
Figure 1 – Message flow in the DCC.
2.1 Synchronous communication
Synchronous communication should be used if the client needs the response right away. Most normal operations will probably be using synchronous messages.
2.1.1 Architecture
The DCC offers synchronous communication between the client and the service provider. Synchronous messages are directly delivered to an internal worker that handles the actual communication with the service provider. Once a response is received, the worker returns it directly to the client.
Figure 2 - Message flow for synchronous messages.
Synchronous messages are executed in the order they are received by the DCC.
All synchronous messages are given a timeout – either by the client or by the DCC (per default). If the synchronous operation does not complete within the timeout period, the operation will fail and return an exception to the client.
2.2 Asynchronous communication
Asynchronous communication is used in situations, where the user wants something done by the service provider, but is not immediately concerned about the result. The user can then send the request as an asynchronous message, and know that the message will be delivered – at some point in time.
The user can later request the responses from the DCC response storage, and verify that the operation succeeded.
2.2.1 Architecture
The DCC also offers asynchronous communication between the client and a service provider.
Figure 3 - Message flow for asynchronous messages.
The DCC does not offer any guarantees on response times for asynchronous messages. The DCC only guarantees that the messages will be delivered.
All asynchronous messages are executed in the order they are persisted in the DCC task storage – see also chapter 5.
All asynchronous messages are notarized upon receipt and hereafter stored in the DCC task storage.
Once the message has been successfully stored, a “Queued” message is returned to the client.
Inside the DCC an executor thread awakens in a predefined interval and executes a number of the stored tasks.
The responses are afterwards stored in the DCC response storage.
2.3 Synchronous transformed to asynchronous (S/Asynchronous)
S/Asynchronous operations can generally be used as a replacement for a normal asynchronous operation. This would allow the client to give the user an immediate response, in those situations where the conditions are fulfilled.
Since the S/Asynchronous operation utilizes the same interfaces used by synchronous and asynchronous much of the functionality can be reused and hence easily provide the end user a much better user experience.
2.3.1 Architecture
The third and final communication form is rather special. In its very nature it is an asynchronous message, however the DCC will attempt to execute it as a synchronous message.
Figure 4 - Message flow for S/Asynchronous messages.
However in order for the DCC to execute the message as a synchronous message, the following conditions must be fulfilled:
· The message must the first message in the task sequence.
· The message must finish within client specified timeout period.
If either of these conditions is not fulfilled, then the S/Asynchronous operation will follow the flow of a regular asynchronous message.
2.3.2 First in line
In order for the DCC to maintain the order of all messages in any given sequence, asynchronous and S/Asynchronous, the DCC must act as a proxy between the clients and any service provider.
This one road for asynchronous and S/Asynchronous messages is through the DCC task storage. Therefore both asynchronous and S/Asynchronous message are put into the storage. A S/Asynchronous message is then immediately retrieved from the storage again and executed if it was the first message for the specified sequence. If not, then the operation will fail, and the DCC will return a “Queued” message to the client.
2.3.3 Timeout
As with synchronous messages, S/Asynchronous messages are given a timeout either by the client or by the DCC. If the first condition is fulfilled, the operation starts. If the operation takes longer than the specified timeout, the DCC returns a “Queued” message to the client. The operation is however not terminated internally. Once the operation completes, the response is added to the response storage.
If the operation finishes within the timeout period, the response is returned to the client as with normal synchronous operations.
3 The response service
Responses from Asynchrony and S/Asynchrony operations can be retrieved by a client system through the DCC response web service.
This web service returns a predefined number of responses from the storage each time the service is called.
Once the client has received and processes the responses, the client must remove the responses from the DCC storage.
Failure to remove the messages from the storage will result in the same responses being returned by the DCC each time the web service is called.
4 Sequences
In line with the WS-ReliableMessaging (WS-RM) protocol the DCC supports sequencing of messages.
Where the WS-ReliableMessaging protocol is a general all-purpose protocol, the DCC protocol is however highly specialized in regards to its environment.
In order to reduce to the amount of communication required between a client and the DCC, the DCC does not generate sequences but relies on the client to provide it.
Namespace clashes are avoided by prefixing sequences with values extracted from the IDcard.
Furthermore the DCC does not support explicit ordering within sequences. The order of messages within the sequence is determined by the order the messages are added to the DCC task storage.
The DCC supports sequences on asynchrony and S/Asynchrony operations – sequences on synchronous operations is however not supported.
Page 11 of 11