Synchronous transformed to asynchronous (S/Asynchronous)

voraciousdrabSoftware and s/w Development

Dec 14, 2013 (7 years and 10 months ago)

268 views







Version

Date

Responsible

Commentary

0.1

15/09
-
2011

ADS

First draft









Side
1

af
11














DCC


P
RODUCT DESCRIPTION




Page

2

of

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

3

of

11



1

Introduction

The
DCC
is a key component in the Danish
N
ational
S
ervice
P
latform (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 te
mporarily
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 system
s

to tag messag
es 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 supp
o
rts

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 op
eration fails, etc.

The DCC helps client system handle timeout on SOAP
operations
in a
clean

and
transparent

fashion.

Page

4

of

11



Through the DCC a client system may specify individual timeout periods for each
message. If the service provider is unable to respond with
in the timeout period, the
DCC will gracefully
return

either
a timeout

error
-
message, for synchronous
messages,

or
a
queued
error
-
messa
ge
for S/Asynchronous messages



and allow
the service provider to terminate correctly.

1.1.4

Notarization of messages

When a m
essage is scheduled for asynchronous processing,
the

user
s 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 notar
izing the message upon receipt and thereby
guaranteeing, that when the me
ssage was received, the attached

token

was valid.

When notarizing the DCC
thus replaces the attached ID
card with a
n

IDWSH
ident
ity
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

5

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

A
rchitecture

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

6

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

7

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 pe
rsisted 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 h
as 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

8

of

11



Since the S/
Asynchronous

operation utilize
s 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 natur
e 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

operatio
n 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 provi
der.

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

9

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 th
a
n the specified timeout, the DCC returns a
“Queued”
message to the client. The operation is however not termina
ted 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

10

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.


T
his 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

11

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.

Name
space clashes are

avoided by prefixing sequences with values extracted
from
the ID
card.


Furthe
rmore 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.