• Overview

•  

• 

• BOARD Service Oriented Architecture

  BOARD 7 architecture is based on the "Service Oriented Architecture" (SOA) paradigm. In this architecture you can identify a "service provider" which is the BOARD Server program, and a set of different service consumers which are the client programs, namely the BOARD 7 client, the MS-Excel Add-in and the Web browser client or other web service consumer.

  

• The ROAR protocol

  Communications between the client and the server uses a proprietary protocol named ROAR (Remote Object Access & Replication) which provides extremely high performance in communications and is designed to work efficiently over low band-width connections such as WAN or the Internet. The ROAR protocol in BOARD 7 is built upon the Windows Communication Foundation (WCF) classes of Microsoft .Net Framework 3.5. It is a data convention format used in communications between the BOARD client and BOARD server programs. The ROAR protocol transfers data from the client’s memory (BOARD Client) to the server’s memory (BOARD Server) through a compressed data stream. This technology is fundamentally more efficient compared to the verbose industry standards of XMLA and ODBO. The data traffic generated in the dialog between BOARD Client and BOARD Server is extremely low thanks to the specialized ROAR protocol, which has been designed for delivering performance over remote connections.

Performance

• The time-tested and powerful multi-dimensional database and back-end system are the foundations of BOARD’s success. Input: BOARD MDB Datareader module supports the loading of millions of records from external data sources in minutes. Transformation: the Data-entry and DataFlow module supports running calculations and simulations interactively without the need for batch processing. Output: BOARD’s performance in accessing data and aggregating InfoCubes is unparalleled, even on InfoCubes with dimensions having millions of members query time remains extremely low and constant. This is typically where other multi-dimensional databases fail. Communications: the ROAR protocol grants performance of connections. Queries or analysis returning large data sets are efficiently compressed and transferred to the end-user. Multi-thread processing: BOARD can fully take advantage of modern multi-core CPU technology to parallelize process execution. 64 bit architecture: BOARD’s 64 bit engine allows to address massive RAM resources to better handle large data volume High compression ratio: a sophisticated sparse-data management technology results in multi-dimensional databases which are significantly smaller than the size of the incoming data. Highly compressed InfoCubes grant faster fetch/update times. The bottom-up hierarchies: thanks to a unique reversed bottom-up data model, BOARD’s MDB doesn’t suffer from data-explosion and grants constant query times regardless of the aggregation level. Remote system control: a sophisticated system administration interface monitors any user log-in, running tasks and process performance – providing the capability to smoothly abort critical processes.

Scalability

• Scalability is designed into BOARD from the core and from every layer. From application performance to database design to RAM and processing power to network communications considerations, BOARD optimizes and delivers powerful scalability. Application scalability: the usual trade-off between performance that requires aggregated data and the need for detail is resolved by designing solutions in a multi-database mode. This technique allows users to transparently view more databases within the application and seamlessly navigate and run analysis on selections from the databases containing summarized data, to the database holding the desired detail level of data (transaction level). Database scalability: multi-dimensional databases are known to suffer limitations in the size and the detail of the data that they can manage. Most multi-dimensional databases have intrinsic limitations which cannot be compensated simply by adding more hardware. BOARD’s MDB breaks this limitation, commonly handling InfoCubes having several million members (distinct item codes) per dimension. Low RAM requirements: unlike many, BOARD’s MDB is not RAM based, meaning that data volumes can freely grow beyond what RAM can manage. Low network traffic: thanks to the highly compressed ROAR protocol, even a high number of users have limited impact on your network.

Security

• Security is pervasive in BOARD. Every functional layer has its security with the various layers complementing each other to form an integrated, flexible and comprehensive model. Front-end (Capsules): applications can be locked, particular analyses can be accessible to individual users or to groups or simply public without any restrictions Mid-layer (User Profile): a functional profile defines access to basic or advanced features to user accounts or groups, e.g., lite user, power user or developer. Back-end (Database Profile): a functional profile is defined together with restrictions on data access, down to the InfoCube cell-level. Secure communications: the ROAR protocol grant security on connections. Audit trial: comply with audit requirements by tracing who entered a budget or forecast figure and when. User activity logs: a rich set of log files traces users activity for the purpose of optimization: identify commonly used InfoCubes, identify peak hours, monitor server workload down to the CPU time required by a user.