Cloud computing

Cloud computing

Cloud computing = Computing in a cloud, means storing and accessing data and programs over the Internet instead of your computer's hard drive. With Cloud computing, users can access files and use applications from any device that can access the Internet.

Cloud computing is the use of hardware and software to deliver a service over a network (typically the Internet). The cloud is just a metaphor for the whole Internet... 

Cloud computing is the practice of using a network of remote servers hosted on the Internet to store, manage, and process data, rather than a local "on-premise" server or a personal computer.

Main types of Cloud computing:

IaaS = Infrastructure as a Service = A third party hosts elements of infrastructure, such as hardware, software, servers, and storage, also providing backup, security, and maintenance.

SaaS = Software as a Service  = sometimes called "on-demand software", a delivery model in which software is licensed on a subscription basis and is centrally hosted. An example of a Cloud computing SaaS provider is Gmail.

PaaS = Platform as a Service = a platform-based service or model that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app.

HTTP Verbs for RESTful Services

HTTP Verbs for RESTful Services

My best page about REST and HTTP "verbs"/methods is as the following:
https://spring.io/understanding/REST

when we ca read about ...

Principles of REST

Resources expose easily understood directory structure URIs.
Representations transfer JSON or XML to represent data objects and attributes.
Messages use HTTP methods explicitly (for example, the most important: GET, POST, PUT, and DELETE).
Stateless interactions store no client context on the server between requests. State dependencies limit and restrict scalability. The client holds session state.

HTTP methods

Use HTTP methods to map CRUD (create, retrieve, update, delete) operations to HTTP requests.
The most important:PUT, GET, POST and DELETE...
HTTP defines a set of request methods to indicate the desired action to be performed for a given resource. Although they can also be nouns, these request methods are sometimes referred as HTTP verbs.

The meaning and interpretation of HTTP Verbs/Methods for RESTful Services:
HTTP Verb CRUD
POST Create
GET Read
PUT Update/Replace
PATCH Update/Modify (Limited. Pay attention! ...)
Delete Delete
OPTIONS       (less important and useful... Pay attention! Sometimes not implemented.)
HEAD             (less important and useful...)


HTTP status codes
Status codes indicate the result of the HTTP request.

1XX - informational
2XX - success
3XX - redirection
4XX - client error, e.g. 404 Not Found at https://en.wikipedia.org/wiki/HTTP_404
5XX - server error

Tools for diagnose of problems with the communication: e.g. Firebug tool (with Firefox) and Chrome Developer Tools.

HeuristicMixedException

HeuristicMixedException

javax.transaction.HeuristicMixedException is a strange problem with transaction handling not only on JBOSS Application Server... during commiting the transaction.

This a problem any dangerous inconsistencies in applications after a database crash...

A HeuristicMixedException exception thrown by the container due to a failure to commit a transaction, does not contain the reason why the resource manager failed.

see similar RollbackException, HeuristicRollbackException, SystemException in the Internet and examples at:

https://www.javatips.net/api/javax.transaction.heuristicmixedexception

sharding

sharding

Sharding is a type of database partitioning that separates very large databases the into smaller, faster, more easily managed parts called data shards. The word shard means a small part of a whole.

A database shard is a horizontal partition of data in a database or search engine. Each of multiple shards is held on a separate database server instance, to spread load. Some data within a database remains present in all shards, but some appears only in a single shard.

What is the difference between sharding and partitioning?

Sharding is a method of splitting and storing a single logical dataset in multiple databases.
Sharding is also referred as horizontal partitioning.

JFrog Maven Repository

JFrog Maven Repository

org.mockito

Sometimes we need Stub or Mock objects as following:

import org.mockito.Mock;
import org.mockito.Mockito;

    @Mock
    private EntityManager em;
(...)

        @SuppressWarnings("rawtypes")
        public Object find(Class class1, Object obj) {
            Object object = Mockito.mock(Object.class);
            return object;
        }

Let me look at definitions from DZone Refcardz (by M.Zajaczkowski) about Mockito:

1. Dummy = an empty object passed in an invocation (usually only
to satisfy a compiler when a method ar- gument is required)

2. Fake = an object having a functional implementation, but usually
in a simplified form, just to satisfy the test (e.g., an in-memory
database)

3. Stub = an object with hardcoded behavior suitable for a given
test (or a group of tests)

4. Mock = an object with the ability to a) have a programmed
expected behavior, and b) verify the interactions occurring in its
lifetime (this object is usually created with the help of mocking
framework)

5. Spy = a mock created as a proxy to an existing real object; some
methods can be stubbed, while the un- stubbed ones are forwarded
to the covered object

We can create a mock iterator or mock list, for example in such way:

import static org.mockito.Mockito.*;
import java.util.Iterator;
import org.junit.Test;
(...)
    @Test
    public void mockito_example_test01(){
        Iterator iter = mock(Iterator.class);
         List mockedList = mock(List.class);
         mockedList.add("one");


Another example is related with return value. Stubs can also return different values depending on arguments passed into the method, for example...

    @Test
    public void with_return_value(){
        Comparable c = mock(Comparable.class);
        when(c.compareTo("Test")).thenReturn(1);
        assertEquals(1,c.compareTo("Test"));
    }

The paradox of RELATIONSHIP: NoSQL vs. RDBMS

The paradox of RELATIONSHIP: NoSQL vs. RDBMS

The real paradox of RELATIONSHIP existence in current databases is that, in my opinion, a NoSQL graph database is MORE RELATIONAL than RDBMS can be. And this is an advantage of NoSQL, because its RELATIONSHIPS are richer and complete.
Why?
An example: a “friend” RELATIONSHIP in NoSQL graph database can include a “friends since” datetime stamp (a whole lifecycle of relationship), together with information in properties describing the degree and quality of this friendship (measure!!!), and so on. So we can automatically understand these rich relationships in runtime  :-)
As I have read this in my favorite book "Graph Databases" (authors: Ian Robinson, Jim Webber and Emil Eifrem) richer RELATIONSHIP is only one of many advantages of using NoSQL graph databases.
The very beginning of graph theory started in the 18th century by Leonhard Euler, who is a daddy and first pioneer of it. The graph theory is the study of graphs, which are mathematical structures used to model pairwise relations between objects. A graph may be undirected or directed, and it is just a collection of vertexes and lines called edges that connect them or in simpler way: a set of nodes and the RELATIONSHIPS that connect them.

The whole world for RELATIONSHIPS in a single graph…

Unlike RDBMSs, which require a level of specialized training to understand, graph databases store information in ways that much more closely resemble the ways humans think about data. In this context, we can easier understand the architecture of different networks (electronic and social), circuits, management and rules. And that is why graph databases have been proven to solve some of the more relevant current data management challenges, including important problems in the areas of social networking, master data management, geospatial, recommendations engines, and more. This increased focus on graph is driven by successes of companies such as Facebook, Google, and Twitter. So where we can use it? From the supply-chain to medical history for populations, and from the construction of a space shuttle, to a system of roads, and so on.
Major matter of the unique things about graph databases that makes them especially adapted to
modeling the real world is that they elevate RELATIONSHIP to be first-class principal citizens of the
data model.

Is there a great hope for economic world in graphs?

We live in a spacetime of the continuous threat of the “supersonic” domino effect, when the biggest worldwide bank can fall tomorrow without a special causes. Graph databases address one of the great macroscopic current business trends: leveraging complex and dynamic relationships to generate insight and competitive advantage.
For us it is hard to understand dynamic and “supersonic” relationships between worldwide supply and demand chain, customer’s needs, networks of power and energy, access elements in a
telephone or datacenter network, producers and consumers of entertainment, or genes
and proteins, gaming and military. Such RELATIONSHIPS are like protein neural networks in our brains which can starts with a one idea and occur real for ages. Maybe graph databases is the best tool to use theories of John Nash, an American mathematician whose works are used in market economics, computing, evolutionary biology, artificial intelligence, accounting, politics and military theory. The ability to understand and analyze such data in graphs is a key factor over the coming decade.

BASE vs. ACID

As I have read this in "Graph Databases", instead of using ACID (Atomic, Consistent, Isolated,Durable), the term BASE has arisen as a popular way of describing the properties of a more optimistic storage strategy:
1. (BA) Basic Availability:
The store appears to work most of the time.
2. (S) Soft-state:
Stores do not have to be write-consistent, nor do different replicas have to
be mutually consistent all the time.
3. (E) Eventual consistency:
Stores exhibit consistency at some later point (e.g. lazily at
read time).

Now I use Neo4j for the beginning from Neo Technology. MongoDB will be the next station soon  :-)