Brain Imaging Network GRID: System Architecture

BING: System Architecture

IEETA Universidade de Aveiro Pedro Lopes [email protected]

Table of Contents

Introduction 3

Overall Project Objectives 4

Overall System Architecture 5

Motivation 6

Report Objectives 6

System Components 7

Architectural Solutions 11

Architecture A 11

Architecture B 13

Usage Scenarios 14

Search and View DICOM 14

View Catalog Manager log 15

View personal history 16

Establish multimedia call 16

Interface 18

Visual Search Engines 18

Deep Zoom 19

Google Maps Engine 20

Summary 21

References 22

2

Introduction

BING stands for Portuguese Brain Imaging Network GRID and is basically a joint effort of four

portuguese universities - Aveiro, Minho, Porto, Coimbra - to improve current research & development

conditions on the Brain Imaging neurosciences sub-area. Brain Imaging uses resources from

engineering, neurology and physics with the main purpose of enhancing brain diseases’ diagnosis

using multimodal imaging techniques like Magnetic Resonance Imaging, Spectroscopy or Single

Photon/Positron Emitting Tomography.

The major bottleneck in Brain Imaging are the extensive computational requirements. It is

necessary to build a hardware platform supporting large image storage, complex analysis workflows

and high bandwidth communications. The solution consists in using GRID infrastructures as they

provide, through distributed computational power, an architecture which is able to support the

demands of Brain Imaging research and development.

The consortium will use a national IT infrastructure and will consist of several nodes - each

university will be a node - and the the Brain Imaging centre containing neuroimaging equipment that

will be located in Coimbra. This node will be the main data provider, Aveiro and Porto will have two

integrated data processing and storage providers. At last, Minho will have a basic and clinical

neurosciences data access client. The connectivity provider will be located in Lisboa. Despite this, the

idea is that all the nodes are clients of the resulting distributed cyber-infrastructure and collaborative e-

Science environment.

3

Figure 1 - Proposed data network nodes planned and their roles in the IT infrastructure

Overall Project Objectives The main objectives behind BING are as follows:

‣ Develop an IT infrastructure to support collaborative use and sharing of neuroimaging

data collections, analysis and modeling software and visualization tools.

‣ Provide a “neuroscientist-friendly” web portal - brainimaging.pt - to enable secure

access to these tools and training in their use. Equipment time management,thematic

discussion forums and collaborative e-Science tools will also be available through this

web portal.

‣ Encourage scientific collaborations among participants from different research

institutions and different areas of science that typically work independently, providing a

virtual environment that promotes pluri-disciplinary studies on neuroimaging issues.

‣ Establish standards for multi-vendor biomedical data exchange between participants

and enable equipment and procedures quality control.

4

Overall System Architecture The BING architecture will be divided in two layers. Layer 1 will comprise computer clusters

providing data services for all clients; a high-bandwidth network connecting the several nodes; the

GRID middleware and data integration services. The upper layer will contain Brain Imaging specific

services and applications, this layer includes brain image processing tools and applications, parallel

processing environments and web based presentation user interfaces. The architecture is shown in

Figure 2.

Figure 2 - BING proposed architecture with infrastructural layer and the brain imaging services and applications layer

5

Motivation

BING’s complexity increases the difficulty in preparing the system for all the possible usage

scenarios. The huge amount of services and functionalities that must exist can’t be easily mapped

and the existing requirements must be carefully studied in order to create an organized structure - of

both hardware and software - from the beginning of the project.

To cope with the project requirements and in order to prevent future setbacks in the real

implementation of the system, this report studies some of the main components, some usage

scenarios and some use cases combining the scenarios and the components.

Report Objectives The main objectives of this report are the following:

‣ Study BING’s components that will fulfill the project requirements.

‣ Propose, when possible, real solutions for the components implementation.

‣ Study architecture scenarios that will support all the project’s requirements.

‣ Study BING usage scenarios with the proposed components in the studied

architecture scenarios.

‣ Give recommendations regarding the final implementation interface.

6

System Components

This section describes the several BING key components. Table 1 gives a proper graphical

symbol - for better identification in the following sections, a description of the component as well as

its function in the system and an existing solution to implement the component in the future.

Table 1 - Component list and description

Scenario Symbol Description Real Solutions

DICOM Server

DICOM Server: the DICOM server will

be located in Coimbra. This server will be

directly linked to the Brain Imaging

hardware that will be used in that node.

This server must have built-in support for

WADO or for command line DICOM

images queries.

Implement a complete solution is not

feasible. In the market there are

several solutions which can be

bought or may be available in the

node’s hardware. MiPACS, UniPACS

and PacsOne offer complete PACS

solutions and may be implemented in

the node.

Signal Server

Signal Server: the signal server will

provide storage and access to acquired

signals in the most distinct formats. The

latter is very important as signals may be

saved in raw data or in several data

formats after conversion. This component

will be located in Aveiro.

There aren’t many solutions in the

market but this problem may easily

be addressed w i th a s imp le

database with an API enabling web

access. An example architecture

may be the one built in BioSAL, only

using different software options.

Video Gateway

Video Gateway: the video server will

provide functionality for multi-directional

video streaming between the nodes. This

c o m p o n e n t m u s t e n a b l e H D

videoconference between all the nodes

and is used along with the VoIP gateway.

7

Scenario Symbol Description Real Solutions

VoIP Gateway

VoIP gateway: the VoIP gateway

p u r p o s e i s t o p r o v i d e c e n t r a l

management for the communications

between all the nodes. The gateway must

support not only VoIP direct connections

(to phones) but also connections from the

w e b p a g e o r a c o m m u n i c a t i o n

application developed specifically for this

project.

Asterisk is a great open-source

telephony engine. Despite this, it may

not the be the most adequate

solution. To solve the communication

problem: multidirectional audio,

video, text between the nodes, the

ideal solution would be a typical

messaging software - like Skype -

adapted to the project needs.

Image Converter

Image Converter: DICOM images are

stored in a format that requires specific

applications to be read. Converting the

stored image file to more widely uses

formats is a must to ensure a faster

development of new applications based

on this architecture.

The website I Do Imaging contains a

list of solutions that can be adopted

to solve this problem. Another option

will be to use one of the many

available application frameworks to

develop a simple application that

executes this conversion in a custom

manner.

Video Converter

Video Converter: Just like the images,

the videos also have to be transformed to

allow easier usage in the developed

applications. For instance, it is important

to have a converter to the .flv format to

enable YouTube-like media streaming.

Until the DICOM video format isn’t

s t a n d a rd i z e d , g e n e r i c v i d e o

converters have to be used. These

video converters exist for almost any

programming language and aren’t

hard to implement.

Messaging Centre

Messaging Centre: It is important to

have a pre-defined messaging centre that

acts as a simple controller for all the

tasks that occur in the system workflow.

This importance is related to activities

logging, workflow control, error detection,

statistics and other administrative tools.

This kind of solution has to be

des igned f rom scra tch . Th is

application will be relatively complex

and should fol low the typical

software engineering process in

order to design and application that

fulfills all the initial requirements.

8

Scenario Symbol Description Real Solutions

DBMS

DBMS: The DataBase Management

System will be essential to the system

and will support the entire architecture. It

will be useful to store every kind of

information ranging from technical

metadata to personal user information.

It all depends on the developers

preferences for this component. SQL

Server, MySQL or PostgreSQL will

adequately solve this problem as

long as they’re correctly used.

Authentication

Authentication: Due to the fact that this

system will be used by distinct entities, it

i s impo r t an t t o have a cen t r a l

authentication proxy. This proxy will

process authentication, authorization and

accounting requests from al l the

institutions involved in BING.

Once again, it is up to developers to

deliver a complete solution, fulfilling

al l the secur i ty requirements.

ASP.NET security stack may be a

first complete example to look at as

it encompasses users, memberships

and roles among others.

Web Server

Web Server: Aveiro will control the

central technological node. One of this

node’s functions is to serve the project

web portal allowing access to all the

system’s tools.

Just like the DBMS, the choice for a

Web Server is up to developers

preferences. Apache or IIS are the

most widely used solutions and imply

different aspects on the remaining

architecture. For instance, it is

recommended to use SQL Server as

a DBMS if IIS is the Web Server

because they’re both from the same

company.

Anonymizer

Anonymizer: All the data that is

accessed to the publ ic must be

anonymized before being presented. It

may be stored without personal data or it

may be anonymized in runtime when the

data is accessed. Both the options are

feasible and should be considered.

Any decent DICOM framework

encompasses a data anonymizer. If

an in-house option has to be

developed, the DICOM format is

public, easing the process of

changing the correct fields.

9

Scenario Symbol Description Real Solutions

UI

User Interface: The most important

component is the User Interface. This is

what anyone that accesses the system

will get and has to have top quality.

Following the current Web2.0 trends, one

should look at success cases in

interfaces around the Web - in areas

such as entertainment or CRM - and

adopt the best cases to the BING

system.

Flash and Silverlight are currently the

best user interface design platforms.

However, they’re plugin dependent.

This leaves AJAX as the ideal

solution to create usable appealing

web interfaces.

Catalog

Catalog Manager : The Cata log

Manager is a simple catalog of the stored

images. The idea is to maintain metadata

about the images stored in the system

and their features.

This has to be a project related

developed solution. It has to cope

with several requirements and one

must consider the tradeoffs of which

information should or shouldn’t be

stored in the Catalog. For instance,

should DICOM image thumbnails be

saved increasing search efficiency?

10

Architectural Solutions

With the proposed system components it is possible to create an immense number of

architectural scenarios. This section will contain two alternatives that may be applied in the future

BING system. The presented scenarios are a simple view of the integration process of the several

system components and only intend to offer a wider and simpler approach of the overall system

architecture.

Implementing each component has to result in a web accessible API. This is because the

several components may be distributed in the network and require communication among themselves

in the easiest possible manner. Component implementation details are mentioned as they depend on

the development team preferences and, as long as they respect the web API (for inclusion in a generic

API) rule and the pre-defined ontologies for the system, everything should fit perfectly.

Architecture A

Architecture A

Web Server

UI

Authentication

Media

VoIP Gateway

Video Gateway

Messaging Centre

DBMS

Catalog

Image Converter

Video Converter

DICOM Server

Signal Server

Anonymizer

Convert

11

As one can see this architecture scenario relies on the Web Server to control all the operations

that occur in the system. The main scenario features are listed next.

‣ The Authentication component is separated from the architecture and is only accessed by

the application itself to generate a security token used by the user to access the system data and tools and, optionally, by any application component that wishes to verify token

authenticity.

‣ The Web Server accesses a Media Gateway that will control VoIP and Video calls. Using a

media gateway, the control over communications is centralized in a single resource,

removing complexity from the system.

‣ The Web Server connects to a generic API, mediating the access to specific component

web APIs, resulting in a modular separation of the system components.

‣ The Web Server only connects with the Catalog Manager. The Catalog Manager will then

mediate data transfers among the application and the storing devices. This means that there

isn’t direct access from the Web Server to the DICOM Server. This method is used to allow a better control of the DICOM Server accesses, increasing security and reducing

performance issues (data may be temporarily in the Catalog Manager’s cache or it may save

DICOM thumbnails).

‣ All the operations have to be reported to the Messaging Centre in order to enhance system

maintenance tools like error detection, log analysis and other administrative tasks.

12

Architecture B

Web Server

UI

Authentication

Media

VoIP Gateway

Video Gateway

Messaging Centre

DBMS

Catalog

Image Converter

Video Converter

DICOM Server

Signal Server

Anonymizer

Convert

Architecture B

Architecture B is basically the same as Architecture A. However, it has a very relevant difference:

the access to the Catalog, and subsequently to the DICOM images, is separated from the rest of the

system. This is due to the fact that the DICOM Server is located in a different node than all the other

components and it is the core component of the system.

Combine these ideas, one has to consider efficiency and quality of service. Placing the DICOM

Server in Coimbra will imply the development of an API that is, structurally, completely different from

the other APIs. With this in mind, it is logical that this API isn’t centrally controlled by the generic API

that the Web Server uses but by a distinct API, designed from scratch to sustain the proposed model

and that takes in count the geographic distribution of the nodes and the quality of service

requirements that maintaining a DICOM repository has.

This distinction between both architectures is very important as it may be one of the main

decisions that have to be made when planning the system components and their implementation.

13

Usage Scenarios

In this section I try to detail some simple use cases that are architecturally independent from the

scenarios proposed in the previous chapter. Only with a simple use case view one can realize the

system workflow and obtain insights about the component involvement and importance in several

areas.

Search and View DICOM Searching for a DICOM file will probably one of the most used functionalities. The next chapter

details some elaborate tools that can be used to better present the search results and the DICOM

imags but the process itself is quite simple.

Web ServerUI

Anonymizer

Catalog

DICOM Server

11 12

13

14

15

Image Converter

1616

Usage Scenario 1 - Search DICOM Image

For a simple DICOM search the presented scenario may include:

1.Send search string to Web Server

2.Contact Catalog Manager

3.Get DICOM files

4.Send anonymized files to the Image Converter

5.Send converted image to the Catalog

6.Send final search results to the user

In this usage scenario the Anonymizer component may not be used if the stored files are

already anonymous. Searching for a DICOM image requires access to the Catalog Manager. It

contains information about the image location and metadata associated to them. If there’s more than

one results, is up to the Catalog Manager component to collect and organize all the results before

sending them to the Web Server. The Catalog Manager can also contain DICOM thumbnails. This will

disable steps 3, 4 and 5 and speed up image lookup: only the thumbnails are shown and they are

already stored in the Catalog Manager in an application usable format. For this scenario (and the next

14

one) I’ve considered that DICOM images are available for public access or that at least some of the

DICOM images information is public and can be freely made available to the community.

View Catalog Manager log This use case shows the required components in order for an administrator to view all the

accesses made to the Catalog Manager.

Messaging Centre

Authentication

Web ServerUI

11

12 13

14 14

Usage Scenario 2 - View Catalog Manager log

This simple use case involves the following steps:

1.Authenticate user in the system

2.Process user request in the application server3.Access Messaging Centre in order to obtain the Catalog Manager log

4.Send the data and display it to the user

This use case shows the workflow to view the Catalog Manager log. From the figure displayed

above one can have some conclusions. Authentication doesn’t need the web server to execute: the

application running in the browser - client-side - directly contacts the Authentication server in order to

obtain a user token. Moreover, the Catalog Manager doesn’t appear at all in the workflow. This is due

to the fact that the Messaging Centre controls and logs everything that happens in the system,

independently from the Catalog Manager. This enables a central point of access that contains all the

system’s history. This doesn’t mean that it will be a single database containing all the operations. The

use case abstraction only shows that it isn’t necessary to access the Catalog Manager directly. The

architecture behind the Messaging Centre may involve processing distributed through different layers

and direct access to the services.

15

View personal history The BING network will have personal profiles about their users. For instance, for a clinician, it

will store his personal information, the DICOM images he has submitted, contact list and other

relevant information. This allows him to view his personal history containing his work. Past information

may be relevant when drawing new conclusions in similar diagnostic cases.

DBMS

Catalog

Authentication

Web ServerUI

11

12

13

14

1516

Usage Scenario 3 - View personal history

The workflow to access the personal history is as follows:

1.Authenticate user

2.Process user request

3.Contact DBMS to obtain and update user personal information4.Contact Catalog Manager to get user DICOMs

5.Merge all user information in the Web Server

6.Send information to the user

In this specific case I’m considering that the Catalog Manager will store DICOM thumbnails, this

means that all the DICOM Server access, anonymization process and image conversion aren’t

required. This is one of the usage scenarios that require access to DBMS. The DBMS stores mostly

personal information and historical information. Moreover, it can store information for functionalities

that can be added to the application such as DICOM Favorites, Contact List or interface preferences.

Establish multimedia call The possibility to make multimedia calls among users in the system is one BING’s most

important objectives. Both clinicians and users have to be able to access videoconference capabilities

16

along with information sharing. For instance, if a clinician has any doubts when diagnosing a disease,

he may call a fellow clinician in another node, establish a videoconference session with him and share

the DICOM image he’s watching as well as other medically relevant information.

Authentication

Web ServerUI

11

12

14

VoIP Gateway

Video Gateway

13

Messaging Centre

15

Usage Scenario 4 - Establish videoconference call (single user perspective)

To establish a multimedia call these steps must occur:

1.Authenticate user in the system

2.Process user request in the application server

3.Call media gateway and establish link between the users

4.Send sound and video to user

5.A log is created and updated in the Messaging Centre

Using the available bandwidth for the project and current browser capabilities, it will be possible

to establish browser-based videoconference with high quality image and sound between several

users. The video and audio calls may me mediated by a central media gateway instead of separate

components like in the proposed scenario. However, one must consider that the users may only

require a simple VoIP call and leave the video aside so the components should be separated or at

least, should work independently.

17

Interface

Previously I’ve mentioned that the user interface is the most important part of the system. It

needs to have enough quality and efficiency to support functionalities over the entire architecture. In

addition, it will be the primary access point to the data and tools distributed throughout the distinct

nodes.

Obviously such important feature needs to be carefully designed and implemented. Excluding

plugin-dependent technologies such as Flash or Silverlight one has to rely on AJAX to deliver

interfaces capable of efficiently giving access to all the functionalities/tools and information of the

system. Develop Rich Internet Applications following Web2.0 trends is quite trivial these days and the

developers should look to successful user interface implementations on several web applications in

order to combine several ideas in a single interface.

Information visualization is one of the vital components of the interface. The portal will mainly be

used to search and retrieve information about brain imaging. WIth this in mind, the web application

has to have interfaces that present this kind of complex information and tools in an appealing and

intuitive manner.

Next, I detail some simple examples of user interactions that can be implemented to enhance a

web application interface and may add value to a future portal.

Visual Search Engines When dealing with search results, the typical approach is to list the results in a simple text list.

This isn’t always the best solution when the objective is to give a generic insight of the results and

offer the users an interface that allows them to reach conclusion faster and in a small amount of time.

Visual search engines offer a distinct approach. They try to take advantage of the human vision

sense, presenting the data in a more visually favorable way. Usually dependent on web screenshots -

screenshots of a web site without browsing it - applications like Viewzi offer novel and agile interfaces

for presenting search results data to users.

18

Figure 3 - Viewzi Power Grid interface

Deep Zoom Microsoft’s SeaDragon project intends to offer a framework for presenting high quality and very

large images using simple scripting technologies like AJAX. The objectives are speed of navigation,

bandwidth dependent performance, smooth transitions and efficient scaling of the image sizes. Not

only Microsoft offers this technology, there are now several other AJAX frameworks that implement

this functionality.

This technology may be used to improve navigation in DICOM images using the browser

providing faster access to every important pixel of the image.

Figure 4 - Before and after zoom with Microsoft’s SeaDragon

19

Google Maps Engine Google Maps isn’t simply an online world map. The engine offers an API with several

functionalities that can be used in many other areas. One can create points on an existing map or

even change the map in order to navigate in different areas.

In this particular case, one could create a map from an existing signal and then use Google

Maps Engine to navigate in the signal, viewing important points and provide all the Google Maps

functionalities in a new context.

Figure 5 - Genome Projector circular genome map

20

Summary

BING is an ambitious project being coordinated by the IEETA’s SIAS group. The main idea is to

connect several research institutes in order to share and increase knowledge on the brain imaging

scientific area.

Architecturally, BING infrastructure will be distributed - according to GRID principles - and the

nodes will generically access to the same set of functionalities. These functionalities will be available to

researchers, clinicians and the interested community in a web portal: http://brainimaing.pt. This portal

will provide access to the entire BING system and the system will also be designed to allow easy

integration in the portal.

Planning such a complex architecture isn’t a task to take lightly. The amount of components

and variables involved in the system is immense. This requires a modular approach to solve specific

smaller problems, following some pre-defined rules, that will allow, ultimately, the connection among

all the smaller problems thereby solving the main problem.

This report doesn’t detail the development of any of the components nor the architecture. The

rational behind this report is to provide a clean and simple overview over what may be the BING

architecture, present some usage scenarios and raise several problems and give recommendations

based on my experience both in computer science and the DICOM world.

The first features about BING one realizes are its complexity, its ambition and its huge size.

BING will be a very difficult system to implement and will require great efforts and capable

coordination to overcome the difficulties that will arise in the development and implementation

process.

21

References

1. Cunha, J. P.; Oliveira, I.; Fernandes, J. M.; Campilho, A.; Castelo-Branco, M.; Sousa, N.;

Sousa Pereira, A.; “BING: The Portuguese Brain Imaging Network GRID”

2.Hur, W.; Lee, J; Kim, C. Y.; “Web-based Diagnostic Imaging Service Using XML Forms”;

Journal of Digital Imaging Vol 19, Dec 2006, pp. 328-3353.Dai, W.; Liang, Y.; Zhou, Z. H.; “Web portal to an image database for high resolution three-

dimensional reconstruction”; Journal of Structural Biology, Sep 2003

4.MiPACS: http://www.medicorimaging.com/Radiology/MiPacs-Server.htm

5.UniPACS: http://www.unipacs.com/en/index.html

6.PacsOne: http://www.pacsone.net

7.BioSAL: http://people.clarkson.edu/~biosal/research/websignaldatabase.html

8.Skype: http://www.skype.com

9.I Do Imaging: http://www.idoimaging.com/index.shtml

10.Flash Video: http://en.wikipedia.org/wiki/Flash_Video

11.Microsoft SQL Server: http://www.microsoft.com/sqlserver/2008/en/us/default.aspx12.Sun MySQL: http://www.mysql.com

13.PostgreSQL: http://www.postgresql.org

14.Apache: http://www.apache.org

15.IIS: http://www.microsoft.com/windowsserver2008/en/us/internet-information-

services.aspx

16.Flash: http://www.adobe.com/products/flashplayer

17.Silverlight: http://silverlight.net

18.AJAX: http://en.wikipedia.org/wiki/AJAX

19.Viewzi: http://viewzi.com

20.Microsoft SeaDragon: http://livelabs.com/seadragon21.Google Maps: http://code.google.com/apis/maps

22.Genome Projector: http://www.g-language.org/GenomeProjector

22