DCC
PRODUCT DESCRIPTION
Version
Date
Responsible
Commentary
0.1
15/09-2011
ADS
First draft
Side 1 af 11
Table of Contents
1
Introduction ........................................................................................................ 3
1.1
Purpose ...................................................................................................... 3
2 Functionality ........................................................ Error! Bookmark not defined.
2.1
Synchronous communication ...................................................................... 5
2.1.1
Usage ................................................... Error! Bookmark not defined.
2.2
Asynchronous communication..................................................................... 6
2.2.1
Usage ................................................... Error! Bookmark not defined.
2.3
Synchronous transformed to asynchronous communication........................ 7
2.3.1
First in line ........................................................................................... 8
2.3.2
Timeout ................................................................................................ 9
2.3.3
Usage ................................................... Error! Bookmark not defined.
3 The response service ....................................................................................... 10
4 Sequences ....................................................................................................... 11
Page 2 of 11
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” errormessage.
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.
Page 3 of 11
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.
Page 4 of 11
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.
Page 5 of 11
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.
Page 6 of 11
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 4.
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.
Page 7 of 11
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
Page 8 of 11
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.
Page 9 of 11
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.
Page 10 of 11
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