A document-oriented database is a designed for storing, retrieving, and managing document-oriented, or semi structured data. Document-oriented databases are one of the main categories of NoSQL databases. The central concept of a document-oriented database is the notion of a Document. While each document-oriented database implementation differs on the details of this definition, in general, they all assume documents encapsulate and encode data (or information) in some standard format(s) (or encoding(s)). Encodings in use include XML, YAML, JSON and BSON, as well as binary forms like PDF and Microsoft Office documents (MS Word, Excel, and so on).
MongoDB: MongoDB is a collection-oriented, schema-free document database. Data is grouped into sets that are called ‘collections’. Each collection has a unique name in the database, and can contain an unlimited number of documents. Collections are analogous to tables in a RDBMS, except that they don’t have any defined schema.
It store data (which is in BASON – “Binary Serialized dOcument Notation” format) that is a structured collection of key-value pairs, where keys are strings, and values are any of a rich set of data types, including arrays and documents.
- Terrastore: Terrastore is a modern document store which provides advanced scalability and elasticity features without sacrificing consistency. It is based on Terracotta, so it relies on an industry-proven, fast clustering technology.
- RavenDB: Raven is a .NET Linq enabled Document Database, focused on providing high performance, schema-less, flexible and scalable NoSQL data store for the .NET and Windows platforms.
Raven store any JSON document inside the database. It is schema-less database where you can define indexes using C#’s Linq syntax.
- OrientDB: OrientDB is an open source NoSQL database management system written in Java. Even if it is a document-based database, the relationships are managed as in graph databases with direct connections between records. It supports schema-less, schema-full and schema-mixed modes. It has a strong security profiling system based on users and roles and supports SQL as a query languages.
- ThruDB: Thrudb is a set of simple services built on top of the Apache Thrift framework that provides indexing and document storage services for building and scaling websites. Its purpose is to offer web developers flexible, fast and easy-to-use services that can enhance or replace traditional data storage and access layers.
It supports multiple storage backends such as BerkeleyDB, Disk, MySQL and also having Memcache and Spread integration.
- SisoDB: SisoDb is a document-oriented db-provider for Sql-Server written in C#. It lets you store object graphs of POCOs (plain old clr objects) without having to configure any mappings. Each entity is treated as an aggregate root and will get separate tables created on the fly.
Quick Start: http://www.sisodb.com/Wiki
- RaptorDB: RaptorDB is a extremely small size and fast embedded, noSql, persisted dictionary database using b+tree or MurMur hash indexing. It was primarily designed to store JSON data (see my fastJSON implementation), but can store any type of data that you give it.
- CloudKit: CloudKit provides schema-free, auto-versioned, RESTful JSON storage with optional OpenID and OAuth support, including OAuth Discovery.
- Jackrabbit: The Apache Jackrabbit™ content repository is a fully conforming implementation of the Content Repository for Java Technology API (JCR, specified in JSR 170 and 283). A content repository is a hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation, and more.
Document databases store and retrieve documents and basic atomic stored unit is a document. As always your requirement leads into the decision. You need to think about your data-access patterns / use-cases to create a smart document-model. When your domain model can be split and partitioned across some documents, a document-database will be a suitable one for you. For example for a blog-software, a CMS or a wiki-software a document-db works extremely well. But at the same time a non-relational database is not better than a relational one in some cases where your database have a lot of relations and normalization.
Just check the following link from stackoverflow also to cover the pros/cons of Relational Vs Document based databases.
Apache Wink 1.0 is a complete Java based solution for implementing and consuming REST based Web Services. The goal of the Wink framework is to provide a reusable and extendable set of classes and interfaces that will serve as a foundation on which a developer can efficiently construct applications.
Taken from Apache Wink official site: Click Here
Wink consists of a Server module for developing REST services, and of a Client module for consuming REST services. It cleanly separates the low-level protocol aspects from the application aspects. Therefore, in order to implement and consume REST Web Services the developer only needs to focus on the application business logic and not on the low-level technical details.
REST Web Service design structure
The Wink Server module is a complete implementation of the JAX-RS v1.0 specification. On top of this implementation, the Wink Server module provides a set of additional features that were designed to facilitate the development of RESTful Web services.
The Wink Client module is a Java based framework that provides functionality for communicating with RESTful Web services. The framework is built on top of the JDK HttpURLConnection and adds essential features that facilitate the development of such client applications.
How to create a RESTful service using Wink? [Coming soon – next post 🙂 ]
“Your life today is the result of your attitudes and choices in the past. Your life tomorrow will be the result.”
This is a story of an elderly carpenter who had been working for a contractor for the past 53 years. He had built many beautiful houses but now as he was getting old, he wanted to retire and lead a leisurely life with his family. So, he goes to the contractor and tells him about his plan of retiring. The contractor feels sad at the prospect of losing a good worker but agrees to the plan because the carpenter had indeed become too fragile for the tough building work. But as a last request, he asks the old carpenter to construct just one last house.
The old man agrees and starts working but his heart was not in his work any more. He had lost the motivation towards work. So, he resorted to shoddy workmanship and constructed the house half-heartedly. After the house was built, the contractor came to visit his employee’s last piece of work. After inspecting the house, he handed over the front door keys to the carpenter and said, “This is your new house. My gift to you.” The carpenter was shocked and upset. Had he known that he was building his own house, he would have done a better job! Now, he would have to live in the house, which is not worth staying.
Think of yourself as the carpenter. You work hard every day but are you giving your best? We put our least to the work we don’t like or do not have interest in. Later, we get shocked at the situation we have created for ourselves and try to figure out why we didn’t do it differently.
Enjoy your tasks and carry on your responsibilities with pleasure and not with pain. “Life is a do-it-yourself project”. Do your job enthusiastically and with devotion, a positive output and a pleasing life will certainly be on your way.
The goal of the Geronimo project is to produce a server runtime framework that pulls together the best Open Source alternatives to create runtimes that meet the needs of developers and system administrators. Our most popular distribution is a fully certified Java EE 5 application server runtime.
Some of our guiding principles are:
- Easy to use.
- Build servers that are distributed under the Apache Software License.
- Provide runtimes that meet the needs of developers, administrators and system integrators.
- Integrate with the best open source tooling available like Eclipse.
- Provide frequent releases of our software so users can experience the newest features and have access to the latest bug fixes.
- Build a community that incorporates multiple disciplines required to create complex runtime and toolable infrastructure.
Unit testing is now a "best practice" for software development. In this unit testing we have to face so many situations where we need to interact with Database or any other resources. But at the same time we need to make our Tests isolated too. Here comes the importance of Mock objects.
Mock objects are a useful way to write unit tests for objects that act as mediators. “Instead of calling the real domain objects, the tested object calls a mock domain object that merely asserts that the correct methods were called, with the expected parameters, in the correct order.”
Using EasyMock Framework
EasyMock is a framework for creating mock objects using the java.lang.reflect.Proxy object. When a mock object is created, a proxy object takes the place of the real object. The proxy object gets its definition from the interface or class you pass when creating the mock.
EasyMock is providing two APIs for creating mock objects that are based on interfaces, the other on classes (org.easymock.EasyMock and org.easymock. classextensions.EasyMock respectively).
We can separate the EasyMock implementation into FOUR steps
1. Creating a Mock Object using “EasyMock.createMock”.
Create Mock : Using this static method we are creating a mock object. And this is the first step which we need to do in mock testing.
When we creates this mock objects then we can follow three levels.
Regular: If we are expecting some methods to be executed then it was not executed then the test will fail. And if any unexpected tests executed then also test will fail. Here the order of the method execution is not important.
Ex: EmpDAO empDAO = EasyMock.createMock(EmpDAO.class);
Nice: If we are expecting some methods to be executed then it was not executed then the test will fail. And if any unexpected tests executed then it will return a default value. Here also order is not important.
Ex: EmpDAO empDAO = EasyMock.createNiceMock(EmpDAO.class);
Strict: Same as regular but here the Order of the expected methods also important.
Ex: EmpDAO empDAO = EasyMock.createStrictMock(EmpDAO.class);
2. Expecting mock object method calls using “EasyMock.expect”.
This is used to expect some method calls from our mock object. Lets go through one example.
Lets assume we have the following methods which gets employee information from DB.
List<Employee> employee = empDao.getEmpDetails();
List<Employee> employee = empDao.getEmpDetailsByName(“bond”);
In the unit test we need to follow as follows…
EmpDao mockDao = EaskMock.createMock(EmpDao.class);
Employee mockEmp = new Employee();
List<Employee> empList= new ArrayList<Employee>(1);
3. Registering/replaying expected methods using “EasyMock.replay”.
Once the behavior of the mock objects has been recorded with expectations, the mock objects must be prepared to replay those expectations. We are using replay() method for this purpose. EaskMock will stop the expecting behavior once this method calls.
4. Verifying the expected methods using “EasyMock.verify”.
Veirfying the mock expectations is the final step which we need to follow. This includes validating that all methods that were expected to be called were called and that any calls that were not expected are also noted.
Easymock is providing more functionalities like “Matchers” etc for more unit testing flexibility. EasyMock has been the first dynamic Mock Object generator, relieving users of hand-writing Mock Objects, or generating code for them. It helps us to increase our testing coverage a lot.
Writing Unit test cases is now mandatory for every developers in the Companies. But at the same time it is very important that we need to analyze the Unit test coverage that is done by that developer. Just writing some test cases will not make sense. Here comes the job of Cobertura.
Cobertura is an open source tool used to analyze the Coverage of Unit tests. It will give Percentage values for the Line coverage as well as Branch coverage.
Some features are listed below.
- Can be executed from ant or from the command line.
- In maven case we have Corbertura Maven plugins.
- Instruments Java bytecode after it has been compiled.
- Can generate reports in HTML or XML.
- Shows the percentage of lines and branches covered for each class, each package, and for the overall project.
- Shows the McCabe cyclomatic code complexity of each class, and the average cyclomatic code complexity for each package, and for the overall product.
- Can sort HTML results by class name, percent of lines covered, percent of branches covered, etc. And can sort in ascending or decending order.