Enterprise Technologies

UI Frameworks

Play Framework

Play provides a UI framework that has support for HTML5 and JavaScript making it possible to provide a modern web-application feel. The framework provides a developer friendly environment making it easy to develop and test - thus this makes it a suitable choice for a UI framework. Development can be done in both Java and Scala - giving possibility to mix Object Oriented with Functional Programming. All in all it seems like a good UI framework, and is currently the selected choice as UI framework for all web UI applications within the enterprise.

Further information : [1]

Messaging

RabbitMQ

For a choice of messaging system RabbitMQ is currently selected, primarily due to its robustness. But it must be noted that it provides with a rich set of features for a messaging system, and thus probably can't be surpassed by alternative like ActiveMQ. Only primary drawback is that it is developed in Erlang, but that is one of the reasons for its robustness.

Further information : [2]

In memory data-grid

Hazzelcast

Caching mechanism have been used in almost any component of a system to hold configuration data used by the component. E.g. a web-application may cache static information to reduce response time. To support clustered caching, in memory data-grid have been developed, providing with the benefits of caching distributed to all members of a cluster.

Further information : [3]

Datastore

NoSQL

These are mainly "key - value" or "document store". But other forms exist (especially Google has made a few, which are especially well suited for big data and complex searching)

• Key - Value : These represent a persistent form of e.g. the Map collection from java. I.e. a key and associated value, which can be anything. RIAK is a good solution within this domain.
• Document store : These are a persistent form of an object (object in OO terms) usually persisted using JSON. Elasticsearch is a good solution within this domain.

NewSQL

These are trying to get the best from relational and NoSQL, i.e. getting the search capabilities of SQL, but supporting horizontal scaling. This is very new technology, so not many have a good solution. A candidate is NuoDB.

NuoDB

Further information : [4]

Elasticsearch

Elasticsearch is a NoSQL based on Document-store model with data represented using JSON format. Elasticsearch has two stengths:

• Distributed data-store capabilities “out-of-the-box”
  • Shading – by default 5 shards are created. Fixed at “create” time, so need to get this “right” when creating the store.
  • Replication – by default 0, can be changed on the fly.
  • Automatic node identification – cluster formation is done automatically (using multi- or unicast) based on cluster name.
    • A elasticsearch node can have different role – client, data, or “load-balancer”
    • Elasticsearch works with concept of Master, but this handled by the system. I.e. first node becomes Master, and if Master dies next available node becomes Master (a node can be configured never to become a Master if that is required)
• Search capabilities “out-of-the-box”
  • Each field is “searchable” using Lucene.
    • I.e. all text (strings) are by default “analyzed” => search is “fuzzy”. Thus all results are scored defining the “quality of match”.
    • One can configure that only some fields are analyzed, while others are “non-analyzed”. Or the field can be made non-searchable (not sure if that makes sense for a metadata database)

Elasticseach uses the following terminology compared to RDBMS: Indices => Database - i.e. when the term index / indices is used it is same as "database(s)" in RDBMS. So one needs to be a little careful as index / indices in RDBMS means something else Types => Tables - i.e. when the term type(s) is used it is the same as "table(s)" in RDBMS. Documents => Rows - i.e. when the term document(s) is used it is the same as "row(s)" in RDMBS. Fields => Columns - i.e. when the term field(s) is used it is the same as "column(s)" in RDMBS. An Elasticsearch cluster can contain multiple indices ("databases"), which in turn contain multiple types ("tables"). These types hold multiple documents ("rows"), and each document has multiple fields ("columns"). A final term to note is "inverted index"; in RDBMS one adds an index, such as a B-Tree index, to specific columns in order to improve the speed of data retrieval. Elasticsearch and Lucene use a structure called an "inverted index" for exactly the same purpose. By default, every field in a document is indexed (has an "inverted index") and thus is searchable. A field without an inverted index is not searchable.

Further information: [5]

Operation System

CentOS

Further information : [6]

Ubuntu

Further information : [7]

XXX

Further information : [XXX|[XXX]]

FreeBSD

Further information : [8]