• Übersicht

•  

• 

• BOARD Service Oriented Architecture

  Die Architektur von BOARD 7 basiert auf dem "Service Oriented Architecture" (SOA)-Paradigma. Innerhalb dieser Architektur gibt es seinen “Service Provider”, den BOARD Server, und eine Reihe von Service Konsumenten, die Client Programme: z. B. BOARD 7 Client, MS Office Add-In, Web Browser Client oder andere Web-Service-Benutzer.

  

• Das ROAR Protokoll

  Die Client-Server-Kommunikation nutzt ein proprietäres Protokoll namens ROAR (Remote Object Access & Replication), welches eine extrem hohe Kommunikationsperformance bietet und entwickelt wurde, um auch über schwache Breitbandverbindungen wie WAN oder das Internet effizient zu arbeiten. Das ROAR Protokoll basiert auf den Windows Communication Foundation (WCF) Klassen des Microsoft .NET 3.5-Frameworks. Dieses Datenkonventionsformat wird in der Kommunikation zwischen dem BOARD Client und dem BOARD Server verwendet. Das ROAR Protokoll überträgt Daten des Client-Speichers (BOARD Client) zum Speicher des Servers (BOARD Server) mittels eines komprimierten binären Datensatzes. Diese Technologie ist grundsätzlich effizienter im Vergleich zu den Standards XMLA und ODBO. Das Datenaufkommen, das in der Kommunikation zwischen BOARD Client und BOARD Server generiert wird, ist dank des spezialisierten ROAR-Protokolls, welches speziell für die von Performanceverbesserung bei Remote-Verbindungen konzipiert wurde, äußerst gering.

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.