BING: System Architecture
IEETA
Universidade de Aveiro
Pedro Lopes pedrolopes@ua.pt
Table of Contents
Introduction Overall Project Objectives
4
Overall System Architecture
5
Motivation Report Objectives System Components Architectural Solutions
6 6 7 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
3
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 eScience 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
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 DICOM Server
WADO or for command line DICOM images queries.
Real Solutions
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: the signal server will There aren’t many solutions in the provide storage and access to acquired market but this problem may easily signals in the most distinct formats. The b e a d d r e s s e d w i t h a s i m p l e latter is very important as signals may be database with an API enabling web saved in raw data or in several data access. An example architecture Signal Server
formats after conversion. This component may be the one built in BioSAL, only will be located in Aveiro.
using different software options.
Video Gateway: the video server will provide functionality for multi-directional video streaming between the nodes. This component must enable HD Video Gateway
videoconference between all the nodes and is used along with the VoIP gateway.
7
Scenario Symbol
Description
Real Solutions
VoIP gateway: the VoIP gateway Asterisk is a great open-source 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 telephony engine. Despite this, it may management for the communications not the be the most adequate between all the nodes. The gateway must solution. To solve the communication support not only VoIP direct connections problem: multidirectional audio, (to phones) but also connections from the video, text between the nodes, the VoIP Gateway
w e b p a g e o r a c o m m u n i c a t i o n ideal solution would be a typical application developed specifically for this messaging software project. 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
Image Converter
development of new applications based on this architecture.
- like Skype -
adapted to the project needs. 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: Just like the images, Until the DICOM video format isn’t the videos also have to be transformed to s t a n d a r d i z e d , g e n e r i c v i d e o allow easier usage in the developed converters have to be used. These applications. For instance, it is important video converters exist for almost any Video Converter
to have a converter to the .flv format to programming language and aren’t enable YouTube-like media streaming.
hard to implement.
Messaging Centre: It is important to This kind of solution has to be have a pre-defined messaging centre that d e s i g n e d f r o m s c r a t c h . T h i s acts as a simple controller for all the application will be relatively complex tasks that occur in the system workflow. and should follow the typical This importance is related to activities software engineering process in Messaging Centre
logging, workflow control, error detection, order to design and application that statistics and other administrative tools.
fulfills all the initial requirements.
8
Scenario Symbol
Description
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 DBMS
metadata to personal user information.
Real Solutions
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: Due to the fact that this Once again, it is up to developers to system will be used by distinct entities, it deliver a complete solution, fulfilling i s i m p o r t a n t t o h a v e a c e n t r a l all the security requirements. authentication proxy. This proxy will ASP.NET security stack may be a process authentication, authorization and first complete example to look at as Authentication
accounting requests from all the it encompasses users, memberships institutions involved in BING.
and roles among others. Just like the DBMS, the choice for a Web Server is up to developers
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 Web Server
system’s tools.
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: All the data that is accessed to the public must be anonymized before being presented. It may be stored without personal data or it may be anonymized in runtime when the Anonymizer
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
User Interface: The most important component is the User Interface. This is what anyone that accesses the system Flash and Silverlight are currently the will get and has to have top quality. best user interface design platforms. Following the current Web2.0 trends, one However, they’re plugin dependent. should look at success cases in This leaves AJAX as the ideal interfaces around the Web - in areas solution to create usable appealing UI
such as entertainment or CRM - and web interfaces. adopt the best cases to the BING system. This has to be a project related Catalog Manager: The Catalog Manager is a simple catalog of the stored images. The idea is to maintain metadata about the images stored in the system
Catalog
and their features.
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
Media
Authentication
Video Gateway
UI
Catalog
Convert
VoIP Gateway
Signal Server
Image Converter Anonymizer Video Converter
Web Server
DICOM Server
Messaging Centre
DBMS
Architecture A
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
Media
Authentication
Video Gateway
VoIP Gateway
UI
Messaging Centre
DBMS
Catalog
Convert
Web Server
Signal Server
Image Converter Anonymizer Video Converter
DICOM Server
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. 11
21
61
61
UI
Web Server
Catalog
31
DICOM Server
51
Anonymizer
41
Image Converter
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. 21
31
41
41
UI
Web Server
Messaging Centre
11
Authentication
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 server 3.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. 21
41
61
51
UI
Web Server
11
Catalog
31
Authentication DBMS
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 information 4.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.
21 31
VoIP Gateway
41 UI
Web Server
51
11
Authentication
Video Gateway
Messaging Centre
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-335 3.Dai, W.; Liang, Y.; Zhou, Z. H.; “Web portal to an image database for high resolution threedimensional 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.aspx 12.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-informationservices.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/seadragon 21.Google Maps: http://code.google.com/apis/maps 22.Genome Projector: http://www.g-language.org/GenomeProjector
22