Child pages
  • Implementation breakdown
Skip to end of metadata
Go to start of metadata

Description of the different implementation aspects to consider when building the full system, including clients and pillars

Functionality contexts 

As the implementation of a feature across all components making up the Bitmagasin system may be a prolong task, we will split the implementation into smaller steps identified by the parts of the architecture covered by the implementation. Another purpose of defining such architectural contexts are to define test fixtures. eg. is a test running on a full system, a mocked pillar, etc.

The following context definitions are used:


This indicates all relevant parts of the system is involved in the implementation.

Partial (System)

All partial contexts include a coordination layer component. The coordination layer is responsible for all inter-module communication in the system, so without a coordination layer involved the context is just a module (see module section).

Partial contexts include:

  • Specific client
    • Java client
    • .NET client
    • Mockup client
  • Specific pillar
    • SB Tape pillar
    • SB SAN pillar
    • KB pillar
    • SA pillar
    • Mockup pillar

The Mockup implementation can also be considered reference implementations for the purpose of testing modules against the rest of the system.

Coordination layer config

Here we may use different configurations of the Coordination Layer (CL) when running our functionality (not all of the listed options may be relevant).

  • Staging: Use the remote instance running on the staging server at KB
  • Local: Use a locally installed ActiveMQ instance
  • Embedded : ActiveMQ is started up as part of the java process using the coordination layer
  • Loopback: The message bus is simulated by directly connecting the send - receive operations of the relevant components 


A single module context corresponds to a standalone architectural component, like a client or pillar. The coordination layer will be mocked in this case.


An example of using the described context definitions to define a incremental development of a feature could be:




Implement test case


Failing test cases for all contexts

Implement mockup client and pillar functionality


  • Mockup client and pillars with embedded CL test pass 
  • Mockup client and pillars with staging CL test pass

Integrate to Pillar1


  • Mockup client and tape pillar with staging CL test pass

Integrate Java client functionality


  • Java client and mockup pillar with embedded CL integration test pass
  • Java client and tape pillar with staging CL system test pass
  • Java client module test pass

Integrate 2. pillar


  • Mockup client and 2. pillar with staging CL integration test pass

Integrate .NET client functionality


  • .NET client and mockup pillar with staging CL integration test pass

Integrate 3. pillar


  • Mockup client and 3. pillar with staging CL integration test pass

Integrate 4. pillar


  • Mockup client and 4. pillar with staging CL integration test pass
  • Full system test pass (star)

Milestone 3 context

Below you can find an example diagram of the milestone 3 context we are aiming currently working on. The purpose here to validate the message bus software, develop the protocol and start on the development of a reference pillar (and perhaps client). It is also implied that we could begin integration to the tape pillar at SB.  Functionality context

  • No labels

1 Comment

  1. This page should be separated into a part concerning the core protocol/coordination layer related tasks/functionality and a second part describing the tasks involved in getting the full system, including clients and pillars implemented.