[Architecture] Refactoring of core architecture

Antranig Basman antranig.basman at colorado.edu
Mon Jan 12 08:47:46 EST 2015


Over the last few days I've produced a reworking of our core architecture, especially the workflow of the 
matchmaking process, in order to deliver the OAuth 2-secured privacy profile filtered preferences for the 
Cloud-based Flow Manager that we will demonstrate at the EC review next week.

This is currently in my GPII-17 branch with latest commit at
https://github.com/amb26/universal/commit/ca3acd308a4d3f50ae9b047095c20eae5794482f - this is now working, 
with a bit of cleanup required to remove superfluous logging statements, etc.

Those who work with the core architecture regularly should take the time to familiarise themselves with the 
new layout of the workflow as well as some of the new techniques which are being used. Even over the short 
lifetime of our project, there has been time for this workflow to become significantly tangled, especially 
as we stayed restricted to industry-standard techniques involving widely scattered functions with 
privately-addressed arguments bandied about between various callbacks and promises.

To start with, the overall geometry of the matchmaking workflow is now defined centrally in the following 
list of "standard handler priorities":

https://github.com/amb26/universal/commit/ca3acd308a4d3f50ae9b047095c20eae5794482f#diff-98a7cb7c3730aa016621a361c93b22adR92

Whilst these are a little clunky they are easy to overview and all in one place rather than embodied in 
details of logic scattered over half a dozen files as they used to be. When we get some time we'll implement 
a more graceful scheme for encoding these priorities as a result of Infusion improvement 
http://issues.fluidproject.org/browse/FLUID-5506 .

The set of listeners which consume these priorities are attached to our matchmaking grade at 
https://github.com/amb26/universal/commit/ca3acd308a4d3f50ae9b047095c20eae5794482f#diff-98a7cb7c3730aa016621a361c93b22adR160 
and the governing "pseudoevent" is fired at 
https://github.com/amb26/universal/commit/ca3acd308a4d3f50ae9b047095c20eae5794482f#diff-98a7cb7c3730aa016621a361c93b22adR79

In addition to this use of the Infusion facility which eventually is treated by the new 
fluid.promise.sequence machinery, the various handling functions have been changed in their idiom to enable 
the workflow to be more clearly tracked. To start with, you will notice that the privacy filtering handler 
is not configured in this list, but only in the CloudBasedFlowManager.js file where it belongs - 
https://github.com/amb26/universal/commit/ca3acd308a4d3f50ae9b047095c20eae5794482f#diff-5849dc7399970f8a5a589c7764012d2fR153

Secondly, all of these handling functions now avoid using "general signatures" of privately addressed 
arguments, but have necessarily been moved over to a single-arg-ist style where each handler accepts a 
single, structured argument, and returns a similarly-structured argument. This could be termed a form of 
"megapayloadism" which follows similar thinking to that which lay behind our reform of the MatchMaker 
payloads themselves following the Cambridge hackathon this autumn. In this model, elements of the 
(notionally shared, global) payload monotonically accrete, rather than each function accepting and consuming 
private arguments. This enables the overall progress of the workflow to be clear since all previously 
computed results are publically available to be inspected and debugged. We deal with the possible expense of 
repeatedly duplicating material by making suitable use of the (jQuery) "shallow copy" operation at each 
stage - this treats each payload as if it were immutable and ensures that no subsequent payload computation 
unwires or corrupts objects which were computed at previous stages. Note for example its use here:

https://github.com/amb26/universal/commit/ca3acd308a4d3f50ae9b047095c20eae5794482f#diff-ca510d64861aa41f18418f14de8b4153R67

Readers must read carefully (and write carefully when extending the code) to make sure they track whether 
"true" is supplied as the first argument of $.extend indicating a shallow copy or not - different operations 
are used in different situations. Future versions of Infusion will automate this kind of process - this 
"megapayloadism" can be seen as a manual stepping-stone to a future where all of this linkage is expressed 
fully declaratively, with the functions collaborating to build up a "model" rather than having the "shared 
payload" defined informally by convention as it currently is.

In addition this branch holds the declaratively specified test cases for the filtering process using the 
"test case disruption system" here:
https://github.com/amb26/universal/commit/ca3acd308a4d3f50ae9b047095c20eae5794482f#diff-7c96bdf65d788106a9a37d0c35129d69R28

as well as incorporating material from the easit4all pull request 302 
https://github.com/GPII/universal/pull/302/files which has been modified for correctness and consistency.

Cheers,
Antranig


More information about the Architecture mailing list