-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathchannels.html
More file actions
439 lines (430 loc) · 15.6 KB
/
channels.html
File metadata and controls
439 lines (430 loc) · 15.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8" />
<title>Multi-Channel Architecture — Intergov Ledger 0.1.0 documentation</title>
<link rel="stylesheet" href="_static/classic.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<link rel="stylesheet" type="text/css" href="_static/graphviz.css" />
<script type="text/javascript" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<script type="text/javascript" src="_static/language_data.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="prev" title="Backing Services" href="backing.html" />
</head><body>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="backing.html" title="Backing Services"
accesskey="P">previous</a> |</li>
<li class="nav-item nav-item-0"><a href="index.html">Intergov Ledger 0.1.0 documentation</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="multi-channel-architecture">
<h1>Multi-Channel Architecture<a class="headerlink" href="#multi-channel-architecture" title="Permalink to this headline">¶</a></h1>
<p>This page explains the advantages
of a multi-channel architecture
facilitating cross-border trade
by enabling Government to Government (G2G)
document exchange.</p>
<div class="section" id="hubs-models-are-obvious-but-possibly-wrong">
<h2>Hubs models are obvious, but possibly wrong<a class="headerlink" href="#hubs-models-are-obvious-but-possibly-wrong" title="Permalink to this headline">¶</a></h2>
<p>First, let's start
by considering the alternative
to multi-channel architecture;
a single channel (or "Hub") model.</p>
<p class="plantuml">
<img src="_images/plantuml-1754b73dc82f93bffb5def5b731e936e782c8f70.png" alt="@startuml
component ca [
Country A
]
component cb [
Country B
]
component cc [
Country C
]
component cd [
Country D
]
component ce [
Country E
]
component cf [
Country F
]
component cg [
Country G
]
component ch [
Country ...
]
queue Hub
ca -- Hub
cb -- Hub
cc -- Hub
cd -- Hub
Hub -- ce
Hub -- cf
Hub -- cg
Hub -- ch
@enduml"/>
</p>
<p>In this model, there is a single logical Hub
that all messages pass through.
This logical Hub could be a distributed ledger,
traditional database, paper clearinghouse,
so some other technology.
The basic idea is that countries
send their messages to this hub
and receive their messages from it too.</p>
<p>Hub models require participants
to adopt a common technology platform.
This platform must meet the needs
of all participants
both in the moment and in the future.</p>
<p>Hub architectures have been built many times before.
Some people find this sort of design intuitively appealing,
perhaps because the idea of standardising on a single solution
seems like it should minimise interoperability challenges.</p>
<p>But standardising on a single implementation
solves interoperability the wrong way.
Interoperability comes from standard interfaces,
not from common implementation.
If two systems have an effective way to interoperate,
then there is no reason
for them to have the same implementation.
Individual participants should be free
to implement their parts of the system
in the way that makes the most sense to them.</p>
</div>
<div class="section" id="what-is-a-multi-channel-architecture">
<h2>What is a multi-channel architecture?<a class="headerlink" href="#what-is-a-multi-channel-architecture" title="Permalink to this headline">¶</a></h2>
<p>As an alternative to the Hub model,
consider the following:</p>
<p class="plantuml">
<img src="_images/plantuml-24a2659e5d221d84d8a2783b86c21397012c90db.png" alt="@startuml
component ca [
Country A
]
component cb [
Country B
]
component cc [
Country C
]
component cd [
Country D
]
component ce [
Country E
]
component cf [
Country F
]
component cg [
Country G
]
component ch [
Country ...
]
queue ch1 [
bilateral
general purpose
]
queue ch2 [
multilateral
topic-specific
]
queue ch3 [
bilateral
topic specific
]
queue ch4 [
multilateral
general purpose
]
queue ch5 [
multilateral
general purpose
]
cb -- ch5
cc -- ch5
cd -- ch5
ch5 -- cf
ch5 -- cg
ch5 -- ch
ca -- ch1
ca -- ch2
cb -- ch2
cb -- ch4
cc -- ch2
cd -- ch3
ch1 -- ce
ch4 -- ce
ch2 -- cf
ch4 -- cf
ch2 -- cg
ch3 -- ch
@enduml"/>
</p>
<p>The above illustration shows a multi-channel scenario where:</p>
<ul class="simple">
<li><p>Country A and Country E have a bilateral arrangement for exchanging messages on any topic</p></li>
<li><p>There is a multilateral arrangement
between Countries B, E and F
that supports messages on any topic</p></li>
<li><p>There is a multilateral arrangement
between Countries A, B, C, F and G
that supports messages on a specific topic</p></li>
<li><p>There is a multilateral arrangement
between Countries B, C, D, F, G and others (...)
that supports messages on any topic</p></li>
<li><p>There is an arrangement between Country D and others
supporting messages on some specific topic.</p></li>
</ul>
<p>On first impression, the above scenario
might seem overcomplicated.
However, the reality of international trade
is vastly more complex than this diagram!</p>
<p>There three distinct reasons
why a multi-channel architecture is necessary.</p>
<div class="section" id="support-for-variable-topology">
<h3>Support for Variable Topology<a class="headerlink" href="#support-for-variable-topology" title="Permalink to this headline">¶</a></h3>
<p>Agreements between Countries are inherently bespoke.
Some are bilateral (links),
others are multilateral (networks).
The scope and details are customised
and optimised through a process of negotiation.
They changes over time,
as existing arrangements are refined or adjusted
and new arrangements are made.</p>
<p>Even if a hub model is theoretically better
(no such theory is offered here),
the idea of asking almost 200 countries
to agree on a precise scope and details
for sharing cross-border trade documents
seems like it would be slow,
difficult and unlikely to succeed.</p>
<p>There are examples of universal hubs,
but they have narrow scope
(for example, ePhyto Certification).</p>
<p>It seems more pragmatic to assume that
cooperative sharing arrangements
involving cross-border trade documentation
will involve a similar process of negotiation
to other international agreements.</p>
<p>While technical standardisation may reduce waste,
free countries will always ultimately determine
who they share what with, when and how;
and those arrangements will change over time
with policy and circumstance.</p>
<p>Any design that does not support variable topologies
seems likely to result in a sub-optimal compromise.</p>
</div>
<div class="section" id="support-for-variable-technology">
<h3>Support for Variable Technology<a class="headerlink" href="#support-for-variable-technology" title="Permalink to this headline">¶</a></h3>
<p>Technical solutions for cross-border
document exchange have existed for many centuries.
Emerging technologies
(such as distributed ledgers)
have different characteristics
which may confer some advantages,
make new things possible
or make previously difficult things more easy.
No doubt technology will continue to evolve
and as-yet unimagined solutions will emerge
with even more favourable characteristics.</p>
<p>Sometimes, the best technology choice in a given situation
would not be the best choice in a different situation.
The asset lifecycle of existing systems,
infrastructure, organisational capacities
and technology strategies of different groups
can create a prediliction
(or an aversion)
for specific technologies.</p>
<p>Even if it were possible to determine
a universal "best technology"
to implement cross-border trade document sharing,
that would be a fleeting anomaly.</p>
<p>Any design that does not allow countries
to negotiate technology choices
(and mutually agree to update or upgrade technology)
seems incongruent with
the other negotiated details
of international arrangements.
An attempt to unilaterally impose
a single, unchanging technology choice
would not only require impractically challenging negotiation,
it would also pit the fate of the system
against the march of technological progress.</p>
</div>
<div class="section" id="support-for-variable-protocols">
<h3>Support for Variable Protocols<a class="headerlink" href="#support-for-variable-protocols" title="Permalink to this headline">¶</a></h3>
<p>The current proof of concept
supports a wire protocol that
we called "Discrete Generic Message" (DGM).
Each communication packet between countries
contains a single ("discrete") message,
and there is no limit to
the taxonomy of message types
that could be sent
(generic).</p>
<p>This protocol was adequate and sufficient
for the first stage of our Proof Of Concept.
It may yet prove to be a useful protocol
in a wide range of situations.
However, there are also situations
where a different protocol design
may be more appropriate.</p>
<p>If there are very high message volumes,
or a technology is used with a low bandwidth
(or high cost per transmission),
then a <em>batched</em> protocol design
may be more appropriate.
Rather than sending "discrete" messages
(one at a time)
a batch protocol could send
a compressed collection of messages
in in each packet.
This would involve trade-offs,
especially with all-or-nothing validation semantics
(such as blockchain consensus),
but there may be situations where
a batch protocol is the most practical choice.</p>
<p>Some distributed ledger technologies
support a feature called "Smart Contracts".
These are sometimes known by other names,
such as "Transaction Families" or "Chain Code",
but what they all have in common is that they allow
the channel to enforce mutually agreed policies
in a trustworthy way.
Smart contracts allow distributed ledger
to operate like an "independant umpire",
which is potentially useful
in a wide variety situations
that require adversarial trust.
However, this has the downside
of tightly coupling policies
to the message transport mechanism.
This means the channel can only be used
for the purposes that correspond exactly
to the policies implemented in the smart contract.</p>
<p>Given the bespoke nature of international trade agreements,
developing a channel that fits them all well
could be very difficult or perhaps impossible.
The strategy of allowing multiple channels
might make the solution seem more complicated
from some perspectives,
but if countries can route messages over multiple channels
then it should be possible for a country
to maintain integration with the collection of channels
that best fit their needs.</p>
</div>
</div>
<div class="section" id="interoperability-requires-standard-interfaces">
<h2>Interoperability requires standard interfaces<a class="headerlink" href="#interoperability-requires-standard-interfaces" title="Permalink to this headline">¶</a></h2>
<p>The multi-channel architecture theory needs to be tested.</p>
<p>This Proof of Concept software includes a "channel router" component,
with a mechanism for deciding which channel should be used for each message
(i.e. an "outbound message routing" mechanism).
It also includes a "channel observer" component,
which is a mechanism for accepting messages from different messages
and funneling them all into the same process regardless of how they are transmitted.</p>
<p>The code is designed in a way that assumes
that a standardised "Channel API" exists,
however an actual Channel API
has not been developed yet.</p>
<p>This requires active research,
which would benefit greatly from integrating
one (or preferably more) existing G2G message channels.</p>
<p>If a standard Channel API is developed
that can successfully be applied to existing G2G message channels,
then it should be possible
to provide an abstraction over the existing channels
such that:</p>
<ul class="simple">
<li><p>Business to Government (B2G) transactions
operate against standard APIs,
which hide the details of which actual channel is used.</p></li>
<li><p>Governments should be able to modify their channel implementations
in way that insultates their regulated community from the change.
In other words, without impacting their users.</p></li>
<li><p>Makes it possible to integrate
additional, new channels
without modifying the standard Channel API design.</p></li>
</ul>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="index.html">Table of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Multi-Channel Architecture</a><ul>
<li><a class="reference internal" href="#hubs-models-are-obvious-but-possibly-wrong">Hubs models are obvious, but possibly wrong</a></li>
<li><a class="reference internal" href="#what-is-a-multi-channel-architecture">What is a multi-channel architecture?</a><ul>
<li><a class="reference internal" href="#support-for-variable-topology">Support for Variable Topology</a></li>
<li><a class="reference internal" href="#support-for-variable-technology">Support for Variable Technology</a></li>
<li><a class="reference internal" href="#support-for-variable-protocols">Support for Variable Protocols</a></li>
</ul>
</li>
<li><a class="reference internal" href="#interoperability-requires-standard-interfaces">Interoperability requires standard interfaces</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="backing.html"
title="previous chapter">Backing Services</a></p>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/channels.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" />
<input type="submit" value="Go" />
</form>
</div>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="backing.html" title="Backing Services"
>previous</a> |</li>
<li class="nav-item nav-item-0"><a href="index.html">Intergov Ledger 0.1.0 documentation</a> »</li>
</ul>
</div>
<div class="footer" role="contentinfo">
© Copyright 2019, Commonwealth of Australia.
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 2.2.0.
</div>
</body>
</html>