Object Relational Mapping Frameworks (ORM)
Object Relational Mapping
Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.
Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.
However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables. The programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.
The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored on the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object when needed. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.
Plain Old Java Objects
In computing software, POJO is an acronym for Plain Old Java Object. The name is used to emphasize that a given object is an ordinary Java Object, not a special object. The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000: "We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely."
The term "POJO" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks. The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS (Plain Old Telephone Service) in telephony, PODS (Plain Old Data Structures) that are defined in C++ but use only C language features, and POD (Plain Old Documentation) in Perl. The equivalent to POJO on the .NET framework is Plain Old CLR Object (POCO). For PHP, it is Plain Old PHP Object (POPO).
The POJO phenomenon has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks.
A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods that follow a simple naming convention. Because of this convention, simple declarative references can be made to the properties of arbitrary JavaBeans. Code using such a declarative reference does not have to know anything about the type of the bean, and the bean can be used with many frameworks without these frameworks having to know the exact type of the bean.
- Active Record Pattern :
Active Record Pattern
In software engineering, the active record pattern is an architectural pattern found in software that stores its data in relational databases. It was named by Martin Fowler in his 2003 book Patterns of Enterprise Application Architecture. The interface of an object conforming to this pattern would include functions such as Insert, Update, and Delete, plus properties that correspond more or less directly to the columns in the underlying database table.
Active record is an approach to accessing data in a database. A database table or view is wrapped into a class. Thus, an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database. When an object is updated the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.
This pattern is commonly used by object persistence tools, and in object-relational mapping (ORM). Typically, foreign key relationships will be exposed as an object instance of the appropriate type via a property.
Implementations of the concept can be found in various frameworks for many programming environments.
ColdFusion has an open source implementation of the Active Record pattern.
The ColdFusion on Wheels framework has an implementation of the Active Record pattern. It is open source and has the added advantage of requiring no complex configuration.
Several PHP open-source frameworks bundle their own ORM implementing the Active Record pattern, including Agile Toolkit, Kohana, Doctrine (Before version 2), Propel, CakePHP, Horde, K2F, Laravel, Yii, SilverStripe and FuelPHP, LIMB aMember. Most implementations support relationships, behaviors, validation, serialization and support for multiple adapters.
The framework CodeIgniter has a query builder it calls "ActiveRecord", but which doesn't implement the Active Record pattern. Instead it implements what the user guide refers to as a modified version of the pattern. The Active Record functionality in CodeIgniter can be achieved by using either CodeIgniter DataMapper library or CodeIgniter Gas ORM library.
The Ruby library ActiveRecord implements ORM. It creates a persistable domain model from business objects and database tables, where logic and data are presented as a unified package. ActiveRecord adds inheritance and associations to the pattern above, solving two substantial limitations of that pattern. A set of macros acts as a domain language for the latter, and the Single Table Inheritance pattern is integrated for the former; thus, ActiveRecord increases the functionality of the active record pattern approach to database interaction. ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.
Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework. As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.
The Java language has a new library called ActiveJDBC. ActiveJDBC is an implementation of Active Record design pattern inspired by Ruby on Rails ActiveRecord. ActiveJDBC is lightweight, fast, small and does not require any configuration.
Another library implementing the Active record pattern is jOOQ (for Java Object Oriented Querying). It combines active records with source code generation and a querying DSL similar to SQL allowing for retrieving active records using complex SQL statements.
The Play Framework is a Java web framework which implements the Active Record pattern, using ideas from Ruby on Rails.
Due to the coupling of database interaction and application logic when using the active record pattern, unit testing an active record object without a database becomes difficult. The negative effects on testability in the active record pattern can be minimized by using mocking or dependency injection frameworks to substitute the real data tier with a simulated one.
- Java Data Objects :
Java Data Objects
Java Data Objects (JDO) is a specification of Java object persistence. One of its features is a transparency of the persistence services to the domain model. JDO persistent objects are ordinary Java programming language classes (POJOs); there is no requirement for them to implement certain interfaces or extend from special classes. JDO 1.0 was developed under the Java Community Process as JSR 12. JDO 2.0 was developed under JSR 243 and was released on May 10, 2006. JDO 2.1 was completed in Feb 2008, developed by the Apache JDO project. JDO 2.2 was released in October 2008. JDO 3.0 was released in April 2010.
Object persistence is defined in the external XML metafiles, which may have vendor-specific extensions. JDO vendors provide developers with enhancers, which modify compiled Java class files so they can be transparently persisted. (Note that byte-code enhancement is not mandated by the JDO specification, although it is the commonly used mechanism for implementing the JDO specification's requirements.) Currently, JDO vendors offer several options for persistence, e.g. to RDBMS, to OODB, or to files.
JDO enhanced classes are portable across different vendors' implementation. Once enhanced, a Java class can be used with any vendor's JDO product.
JDO is integrated with Java EE in several ways. First of all, the vendor implementation may be provided as a JEE Connector. Secondly, JDO may work in the context of JEE transaction services.
JDO vs. EJB3 vs. JPA
Enterprise Java Beans 3.0 (EJB3) specification also covered persistence, as had EJB v2 with Entity Beans. There has been standards conflict between the two standards bodies in terms of pre-eminence. JDO has several commercial implementations.
In the end, persistence has been "broken out" of "EJB3 Core", and a new standard formed, the Java Persistence API (JPA). JPA uses the javax.persistence package, and was first specified in a separate document within the EJB3 spec JSR 220, but was later moved to its own spec JSR 317. Significantly, javax.persistence will not require an EJB container, and thus will work within a Java SE environment as well, as JDO always has. JPA, however, is an object-relational mapping (ORM) standard, while JDO is both an object-relational mapping standard and a transparent object persistence standard. JDO, from an API point of view, is agnostic to the technology of the underlying datastore, whereas JPA is targeted to RDBMS datastores (although there are several JPA providers that support access to non-relational datastores through the JPA API, such as DataNucleus and ObjectDB).
Leading JDO commercial implementations and open source projects also offer a JPA API implementation as an alternative access to their underlying persistence engines, formerly exposed solely via JDO in the original products. There are many open source implementations of JDO.
New Features in JDO Version 2 Not Found In Version 1
- Disconnected object graphs concept
- Standardized ORM mapping descriptors (for ORM-based JDO implementations)
- JDOQL Enhancements (Single String Form; more String, Map & Math methods support mandated)
- Get e.g. a Connection from javax.jdo.PersistenceManager
- More: Named Queries (pm.newNamedQuery), FetchPlan, Sequence, Delete by Query, multiple User Objects on PM
JDO Reference Implementations
- JDO 1.0 : FOStore
- JDO 2.0 : JPOX 1.1
- JDO 2.2 : DataNucleus AccessPlatform 1.0.1
- JDO 3.0 : DataNucleus AccessPlatform 2.1.0
- Service Data Objects :
Service Data Objects
Service Data Objects is a technology that allows heterogeneous data to be accessed in a uniform way. The SDO specification was originally developed in 2004 as a joint collaboration between BEA and IBM and approved by the Java Community Process in JSR 235. Version 2.0 of the specification was introduced in November 2005 as key part of the Service Component Architecture.
Relation to other technologies
Originally, the technology was known as Web Data Objects, or WDO, and was shipped in IBM WebSphere Application Server 5.1 and IBM WebSphere Studio Application Developer 5.1.2. Other similar technologies are JDO, EMF, JAXB and ADO.NET.
Service Data Objects denote the use of language-agnostic data structures that facilitate communication between structural tiers and various service-providing entities. They require the use of a tree structure with a root node and provide traversal mechanisms (breadth/depth-first) that allow client programs to navigate the elements. Objects can be static (fixed number of fields) or dynamic with a map-like structure allowing for unlimited fields. The specification defines meta-data for all fields and each object graph can also be provided with change summaries that can allow receiving programs to act more efficiently on them.
The specification is now being developed by IBM, Rogue Wave, Oracle, SAP, Siebel, Sybase, Xcalia, Software AG within the OASIS Member Section Open CSA since April 2007. Collaborative work and materials remain on the collaboration platform of Open SOA, an informal group of actors of the industry.
The following SDO products are available:
- Rogue Wave Software (HydraSDO)
- CodeFutures Software (FireStorm/SDO)
- Xcalia (for Java and .Net)
- BEA (AquaLogic Data Services Platform) - Now Oracle Data Service Integrator
- IBM (Virtual XML Garden)
- IBM (WebSphere Process Server)
- There are open source implementations of SDO from:
- The Eclipse Persistence Services Project (EclipseLink)
- The Apache Tuscany project for Java and C++
- The SCA and SDO for PHP project
- Java Persistence API :
Java Persistence API
The Java Persistence API, sometimes referred to as JPA, is a Java programming language framework managing relational data in applications using Java Platform, Standard Edition and Java Platform, Enterprise Edition.
The Java Persistence API originated as part of the work of the JSR 220 Expert Group. JPA 2.0 is the work of the JSR 317 Expert Group.
Persistence in this context covers three areas:
- the API itself, defined in the javax.persistence package
- the Java Persistence Query Language (JPQL)
- object/relational metadata
The final release date of the JPA 1.0 specification was 11 May 2006 as part of JSR 220. The JPA 2.0 specification was released 10 Dec, 2009. The JPA 2.1 specification was released 22 April, 2013.
A persistence entity is a lightweight Java class whose state is typically persisted to a table in a relational database. Instances of such an entity correspond to individual rows in the table. Entities typically have relationships with other entities, and these relationships are expressed through object/relational metadata. Object/relational metadata can be specified directly in the entity class file by using annotations, or in a separate XML descriptor file distributed with the application.
The Java Persistence Query Language
Further information: Detailed information is available at Wikibook's Java Persistence/Querying article The Java Persistence Query Language (JPQL) makes queries against entities stored in a relational database. Queries resemble SQL queries in syntax, but operate against entity objects rather than directly with database tables.
Motivation for creating the Java Persistence API
Prior to the introduction of EJB 3.0 specification, many enterprise Java developers used lightweight persistent objects, provided by either persistence frameworks (for example Hibernate) or data access objects instead of entity beans. This due to the fact that entity beans, in previous EJB specifications, called for too much complicated code and heavy resource footprint, and they could be used only in Java EE application servers because of interconnections and dependencies in the source code between beans and DAO objects or persistence framework. Thus, many of the features originally presented in third-party persistence frameworks were incorporated into the Java Persistence API, and, as of 2006, projects like Hibernate (version 3.2) and TopLink Essentials have become themselves implementations of the Java Persistence API specification.
The EJB 3.0 specification (itself part of the Java EE 5 platform) included a definition of the Java Persistence API. However, end-users do not need an EJB container or a Java EE application server in order to run applications that use this persistence API. Future versions of the Java Persistence API will be defined in a separate JSR and specification rather than in the EJB JSR/specification.
The Java Persistence API replaces the persistence solution of EJB 2.0 CMP (Container Managed Persistence).
Java Data Objects API
The Java Persistence API was developed in part to unify the Java Data Objects API, and the EJB 2.0 Container Managed Persistence (CMP) API. As of 2009 most products supporting each of those APIs support the Java Persistence API.
The Java Persistence API specifies persistence only for relational database management systems. That is, JPA focuses on object-relational mapping (ORM) (note that there are JPA providers who support other database models besides relational database, but this is outside the scope of what JPA was designed for). Refer to JPA 2 spec section 1 introduction for clarification of the role of JPA, which states very clearly "The technical objective of this work is to provide an object/relational mapping facility for the Java application developer using a Java domain model to manage a relational database."
The Java Data Objects specification supports ORM, as well as persistence to other types of database models, for example flat file databases and NoSQL databases, including document databases, graph databases, as well as literally any other conceivable datastore.
Service Data Object API
The designers of the Java Persistence API aimed to provide for relational persistence, with many of the key areas taken from object-relational mapping tools such as Hibernate and TopLink. Java Persistence API improved on and replaced EJB 2.0, evidenced by its inclusion in EJB 3.0. The Service Data Objects (SDO) API (JSR 235) has a very different objective to the Java Persistence API and is considered complementary. The SDO API is designed for service-oriented architectures, multiple data formats rather than only relational data, and multiple programming languages. The Java Community Process manages the Java version of the SDO API; the C++ version of the SDO API is managed via OASIS.
Hibernate provides an open source object-relational mapping framework for Java. Versions 3.2 and later provide an implementation for the Java Persistence API.
Gavin King founded Hibernate. He represented JBoss on JSR 220, the JCP expert group charged with developing JPA. This led to ongoing controversy and speculation surrounding the relationship between JPA and Hibernate. Sun Microsystems has stated that ideas came from several frameworks, including Hibernate and JDO.
Development of a new version of JPA, namely JPA 2.0 JSR 317 was started in July 2007. JPA 2.0 was approved as final on December 10, 2009.
The focus of JPA 2.0 was to address features that were present in some of the popular ORM vendors but couldn't gain consensus approval for JPA 1.0.
The main features included in this update are :
- Expanded object-relational mapping functionality
- support for collections of embedded objects, linked in the ORM with a many-to-one relationship
- multiple levels of embedded objects
- ordered lists
- combinations of access types
- A criteria query API
- standardization of query 'hints'
- standardization of additional metadata to support DDL generation
- support for validation
- Vendors supporting JPA 2.0
- DataNucleus (formerly JPOX)
- EclipseLink (formerly Oracle TopLink)
- JBoss with Hibernate
- IBM, via its OpenJPA-based Feature Pack for OSGi Applications and JPA 2.0 for WebSphere Application Server
- Versant JPA (not relational, object database)
- Java Object Oriented Querying (jOOQ) :
Java Object Oriented Querying (jOOQ)
Java Object Oriented Querying, commonly known as jOOQ, is a light database-mapping software library in Java that implements the active record pattern. Its purpose is to be both relational and object oriented by providing a domain-specific language to construct queries from classes generated from a database schema.
jOOQ claims that SQL should come first in any database integration. Thus, it does not introduce a new textual query language, but rather allows for constructing plain SQL form jOOQ objects and code generated from a database schema. jOOQ uses JDBC to call the underlying SQL queries.
While it provides abstraction on top of JDBC, jOOQ does not have as much functionality and complexity as standard object-relational mapping libraries such as Hibernate and JPA.
jOOQ's closeness to SQL has advantages over typical object-relational mapping libraries. SQL has many features that cannot be used in an object oriented programming paradigm; this set of differences is referred to as the object-relational impedance mismatch. By being close to SQL, jOOQ helps to prevent syntax errors and type mapping problems. Also, variable binding is taken care of. It is also possible in jOOQ to create very complex queries, that involve aliasing, unions, nested selects and complex joins. jOOQ also supports database-specific features, such as UDTs, enum types, stored procedures and native functions.
- Ebean :
Ebean is an object-relational mapping product written in Java. It is designed to be simpler to use and understand than JPA (Java Persistence API) or JDO (Java Data Objects) products.
Ebean has a simpler API than JPA. It achieves this through its 'Session Less' architecture. Ebean does not require a JPA EntityManager or JDO PersistenceManager and this removes the concepts of detached/attached beans and the issues associated with flushing/clearing and 'session management' of EntityManagers. This adds up to make Ebean's API much easier to learn understand and use.
Although Ebean has full ORM features (equivalent to JPA) it also has incorporated 'SQL/Relational' features. The idea being that many development efforts require control over the exact sql, calling stored procedures or are more simply solved with 'Relational' approaches. The ultimate goal for Ebean is to combine the best ORM features from JPA with the best 'Relational' features from products like MyBatis into a single persistence framework.
- iBATIS :
iBATIS is a persistence framework which automates the mapping between SQL databases and objects in Java, .NET, and Ruby on Rails. In Java, the objects are POJOs (Plain Old Java Objects). The mappings are decoupled from the application logic by packaging the SQL statements in XML configuration files. The result is a significant reduction in the amount of code that a developer needs to access a relational database using lower level APIs like JDBC and ODBC.
Other persistence frameworks such as Hibernate allow the creation of an object model (in Java, say) by the user, and create and maintain the relational database automatically. iBATIS takes the reverse approach: the developer starts with an SQL database and iBATIS automates the creation of the Java objects. Both approaches have advantages, and iBATIS is a good choice when the developer does not have full control over the SQL database schema. For example, an application may need to access an existing SQL database used by other software, or access a new database whose schema is not fully under the application developer's control, such as when a specialized database design team has created the schema and carefully optimized it for high performance.
On May 21, 2010 the development team decided to move from ASF to Google Code, changing the project name to MyBatis and making new releases there. As a consequence the Apache iBATIS project became inactive and was moved to the Apache Attic in June 2010.
- MyBatis :
MyBatis is a persistence framework available for Java and .NET that couples objects with stored procedures or SQL statements using an XML descriptor or annotations.
MyBatis is free software that is distributed under the Apache License 2.0.
MyBatis was formerly known as iBATIS.
Unlike ORM frameworks MyBatis does not map Java objects to database tables but methods to SQL statements.
MyBatis lets you use all your database functionality like stored procedures, views, queries of any complexity and vendor proprietary features. It is often a good choice for legacy or de-normalized databases or when it is required to have full control of SQL execution.
It simplifies coding compared to JDBC. SQL statements are executed with a single line. This saves time and prevents common mistakes like leaving a connection opened, coding a wrong data mapping, exceeding the limits of a result set or getting more than one result when just one was expected.
MyBatis provides a mapping engine that maps SQL results to object trees in a declarative way.
SQL statements can be built dynamically by using a built-in language with XML-like syntax or with Apache Velocity by using the Velocity integration plugin.
MyBatis integrates with Spring Framework and Google Guice. This feature allows to build business code free of dependencies and even without any call to MyBatis API.
MyBatis supports declarative data caching. MyBatis integrates with: OSCache, EHcache, Hazelcast and Memcached and supports custom integration with other cache tools.
- MyBatis provides a code generator. MyBatis Generator will introspect a database table (or many tables) and generate MyBatis artifacts needed to perform CRUD operations (Create, Retrieve, Update, Delete).
- It will preserve any custom code in case of regeneration.
- An Eclipse plugin is available.
MyBatis integrates with Spring Framework. This module allows MyBatis to participate in Spring transactions. It will also build MyBatis mappers and sessions and inject them into other beans.
Google Guice Integration
MyBatis integrates with Google Guice. This module provides a set of Modules and Providers that will build MyBatis mappers and sessions and will inject them into other beans. It also adds transactional support based on @Transactional annotation.
The Velocity plugin lets you use Apache Velocity to generate your dynamic SQL queries on the fly.
MyBatis Migrations is a Java command line tool that keeps track of database schema changes managing DDL files (known as migrations). Migrations allows to query the current status of the database, apply schema changes and also undo them. It also helps to detect and solve concurrent database schema changes made by different developers.
In 2001 a project called iBATIS was started by Clinton Begin. Originally the focus was on the development of cryptographic software solutions. The first product to be released by iBATIS was Secrets, a personal data encryption and signing tool much like PGP. Secrets was written entirely in Java and was released under an open source license.
That year Microsoft published a paper to demonstrate that its recent .NET 1.0 framework was more productive than Java. For that purpose Microsoft built its own version of Sun's Web "Pet Store", a Web project that Sun had used to show Java best practices (Java BluePrints). Microsoft claimed that .NET was 10 times faster and 4 times more productive than Java.
In 2002 Clinton developed an application called JPetStore to demonstrate that Java could be more productive than .NET and could also do so while achieving a better architecture than was used in the Microsoft implementation.
JPetStore 1.0 had a big impact and the database layer that Clinton used attracted the attention of the community. Soon, iBATIS Database Layer 1.0 project started, composed by two components: iBATIS DAO and iBATIS SQL Maps.
iBATIS 2.0 was released in June 2004. It was a complete redesign while keeping the same features. Clinton donated the iBATIS name and code to Apache Software Foundation and the project stayed in the ASF for six years.
Eventually iBATIS DAO was deprecated, considering that better dao frameworks were available, such as Spring Framework.
On May 19, 2010 iBATIS 3.0 was published and simultaneously the development team decided to continue the development of the framework at Google Code. Given the iBATIS name was donated to the ASF the project acquired its new name MyBatis. It was the first time a TLP (Top Level Project) moved from Apache.
MyBatis 3.0 is a complete redesign with some clear objectives: test driven development, code cleanliness over performance, simple design over flexible design, one JAR file, no required 3rd party dependencies and better plug-in support.
- Hibernate (Java) :
Hibernate is an object-relational mapping (ORM) library for the Java language, providing a framework for mapping an object-oriented domain model to a traditional relational database. Hibernate solves object-relational impedance mismatch problems by replacing direct persistence-related database accesses with high-level object handling functions.
Hibernate is free software that is distributed under the GNU Lesser General Public License.
Hibernate's primary feature is mapping from Java classes to database tables (and from Java data types to SQL data types). Hibernate also provides data query and retrieval facilities. It also generates the SQL calls and attempts to relieve the developer from manual result set handling and object conversion and keep the application portable to all supported SQL databases with little performance overhead.
Mapping Java classes to database tables is accomplished through the configuration of an XML file or by using Java Annotations. When using an XML file, Hibernate can generate skeletal source code for the persistence classes. This is unnecessary when annotations are used. Hibernate can use the XML file or the annotations to maintain the database schema.
Facilities to arrange one-to-many and many-to-many relationships between classes are provided. In addition to managing associations between objects, Hibernate can also manage reflexive associations where an object has a one-to-many relationship with other instances of its own type.
Hibernate supports the mapping of custom value types. This makes the following scenarios possible: Overriding the default SQL type that Hibernate chooses when mapping a column to a property.
Mapping Java Enum to columns as if they were regular properties.
Mapping a single property to multiple columns.
Hibernate provides transparent persistence for Plain Old Java Objects (POJOs). The only strict requirement for a persistent class is a no-argument constructor, not necessarily public. Proper behavior in some applications also requires special attention to the equals() and hashCode() methods.
Collections of data objects are typically stored in Java collection objects such as Set and List. Java generics, introduced in Java 5, are supported. Hibernate can be configured to lazy load associated collections. Lazy loading is the default as of Hibernate 3.
Related objects can be configured to cascade operations from one to the other. For example, a parent such as an Album object can be configured to cascade its save and/or delete operation to its child Track objects. This can reduce development time and ensure referential integrity. A dirty checking feature avoids unnecessary database write actions by performing SQL updates only on the modified fields of persistent objects.
Hibernate Query Language (HQL)
Hibernate provides an SQL inspired language called Hibernate Query Language (HQL) which allows SQL-like queries to be written against Hibernate's data objects. Criteria Queries are provided as an object-oriented alternative to HQL.
Hibernate can be used both in standalone Java applications and in Java EE applications using servlets, EJB session beans, and JBI service components. It can also be included as a feature in other programming languages. For example, Adobe integrated Hibernate into version 9 of ColdFusion (which runs on J2EE app servers) with an abstraction layer of new functions and syntax added into CFML.
Entities and components
In Hibernate jargon, an entity is a stand-alone object in Hibernate's persistent mechanism which can be manipulated independently of other objects. In contrast, a component is subordinate to other entities and can be manipulated only with respect to other entities. For example, an Album object may represent an entity but the Tracks object associated with the Album objects would represent a component of the Album entity if it is assumed that Tracks can only be saved or retrieved from the database through the Album object. Unlike J2EE, it can switch databases.
The Hibernate software includes the following components:
- Hibernate ORM (known as Hibernate Core before release 4.1) - the base software for an object-relational mapping solution for Java environments
- Hibernate Annotations (merged into Hibernate Core/ORM since version 3.6)
- metadata that governs the transformation of data between the object-oriented model and the relational database model according to the JSR 317 Java Persistence API (JPA 2)
- Hibernate EntityManager - together with Hibernate Annotations, a wrapper that implements a JSR 317 Java Persistence API (JPA 2) persistence solution on top of Hibernate Core
- Hibernate Envers - auditing and versioning of persistent classes
- Hibernate OGM (Object/Grid Mapper) - an extension to store data in a NoSQL store
- Hibernate Shards - horizontal partitioning for multiple relational databases
- While Hibernate Shards is not compatible with 4.x releases of Hibernate Core, some of the Shards capability was integrated into Core in the 4.0 release
- Hibernate Search - integrates the full text library functionality from Apache Lucene in the Hibernate and JPA model
- Hibernate Tools - a set of tools implemented as a suite of Eclipse plugins and Ant tasks included in JBoss Developer Studio
- Hibernate Validator - the reference implementation of JSR 303 Bean Validation
- Hibernate Metamodel Generator - an annotation processor that creates JSR 317 Java Persistence API (JPA 2) static metamodel classes using the JSR 269 Pluggable Annotation Processing API
- NHibernate - an object-relational mapping solution for the .NET Framework
- Spring Data Access Framework :
Spring Data Access Framework
Spring's data access framework addresses common difficulties developers face when working with databases in applications. Support is provided for all popular data access frameworks in Java: JDBC, iBatis/MyBatis, Hibernate, JDO, JPA, Oracle TopLink, Apache OJB, and Apache Cayenne, among others.
- For all of these supported frameworks, Spring provides these features
- Resource management - automatically acquiring and releasing database resources
- Exception handling - translating data access related exception to a Spring data access hierarchy
- Transaction participation - transparent participation in ongoing transactions
- Resource unwrapping - retrieving database objects from connection pool wrappers
Abstraction for BLOB and CLOB handling
All these features become available when using template classes provided by Spring for each supported framework. Critics have said these template classes are intrusive and offer no advantage over using (for example) the Hibernate API directly. In response, the Spring developers have made it possible to use the Hibernate and JPA APIs directly. This however requires transparent transaction management, as application code no longer assumes the responsibility to obtain and close database resources, and does not support exception translation.
Together with Spring's transaction management, its data access framework offers a flexible abstraction for working with data access frameworks. The Spring Framework doesn't offer a common data access API; instead, the full power of the supported APIs is kept intact. The Spring Framework is the only framework available in Java which offers managed data access environments outside of an application server or container.
While using Spring for transaction management with Hibernate, the following beans may have to be configured:
- A Datasource like com.mchange.v2.c3p0.ComboPooledDataSource or org.apache.commons.dbcp.BasicDataSource
- A SessionFactory like org.springframework.orm.hibernate3.LocalSessionFactoryBean with a DataSource attribute
- A HibernateProperties like org.springframework.beans.factory.config.PropertiesFactoryBean
- A TransactionManager like org.springframework.orm.hibernate3.HibernateTransactionManager with a SessionFactory attribute
- An AOP configuration of cutting points.
- TopLink :
In computing, TopLink is an object-relational mapping (ORM) package for Java developers. It provides a framework for storing Java objects in a relational database or for converting Java objects to XML documents.
TopLink Essentials is a reference implementation of the EJB 3.0 Java Persistence API (JPA) and a product of Oracle.
- The Object People (that's the "Top" in the Name) originally developed TopLink in Smalltalk in the 1990s. In 1996-1998 a Java version of the product was created named "TopLink for Java". After the joint acquisition of The Object People in April 2000 by BEA Systems and WebGain, the TopLink product-line became the property of WebGain
- In 2002 Oracle Corporation acquired TopLink, which continues to be developed in the Oracle Fusion Middleware product.
- In 2006, Oracle donated source code from the TopLink product and development resources to the open-source Sun Microsystems java.net GlassFish project. It became the Java EE EJB 3.0 JPA reference implementation.
- In 2007, TopLink source code was donated to the Eclipse Foundation and the EclipseLink project was born.
- In March 2008 the Eclipse Foundation announced that Sun Microsystems had selected the EclipseLink project as the reference implementation for the JPA 2.0, JSR 317 standard.
As well as functioning as an object-relational mapping tool, TopLink has other features including:
- query framework that supports an object-oriented expression framework, Query by Example (QBE), EJB QL, SQL, and stored procedures
- an object-level transaction framework
- caching to ensure object identity
- a set of direct and relational mappings
- object-to-XML mappings, in addition to JAXB support
- EIS/JCA support for non-relational datasources
- visual mapping editor (Mapping Workbench)
- limited support for query in memory
- Java Pro Readers' Choice Award for Best Java Data Access Tool or Driver (July 2003).
- Editor's Choice JavaWorld 2003 Award for Best Java Data Access Tool (2003).
- 4th-best Java persistence architecture (as voted by Java Developer's Journalreaders in 2004).
- EclipseLink :
EclipseLink is the open source Eclipse Persistence Services Project from the Eclipse Foundation. The software provides an extensible framework that allows Java developers to interact with various data services, including databases, web services, Object XML mapping (OXM), and Enterprise Information Systems (EIS). EclipseLink supports a number of persistence standards including:
- Java Persistence API (JPA)
- Java Architecture for XML Binding (JAXB)
- Java Connector Architecture (JCA)
- Service Data Objects (SDO).
EclipseLink is based on the TopLink product from which Oracle contributed the source code to create the EclipseLink project. The original contribution was from TopLink's 11g code base, and the entire code-base/feature set was contributed, with only EJB 2 Container-Managed Persistence (CMP) and some minor Oracle Application Server specific integration removed. This differs from the TopLink Essentials GlassFish contribution, which did not include some key enterprise features. The package names were changed and some of the code and configuration was moved around.
The TopLink Mapping Workbench user interface has also been contributed to the project.
EclipseLink is the intended path forward for persistence for Oracle and TopLink. It is intended that the next major release of Oracle TopLink will include EclipseLink as well as the next major release of Oracle Application Server.
EclipseLink supports usage in an OSGi environment.
Sun Microsystems has selected the EclipseLink project to be the reference implementation for JPA 2.0
- DataNucleus :
DataNucleus (formerly known as Java Persistent Objects JPOX) is an open source project (under the Apache 2 license) which provides software products around data management in Java.
DataNucleus Access Platform is a fully compliant implementation of the Java Data Objects (JDO) 1.0, 2.0, 2.1, 2.2, 3.0, 3.1 specifications and the Java Persistence API 1.0, 2.0, 2.1 specifications, providing transparent persistence of Java objects. It supports persistence to the widest range of datastores of any Java persistence software, supporting all of the main object-relational mapping (ORM) patterns, allows querying using either JDOQL, JPQL or SQL, and comes with its own byte-code enhancer. It allows persistence to relational datastores (RDBMS), object-based datastores (db4o, NeoDatis ODB), document-based storage (XML, Excel, OpenDocument spreadsheets), web-based storage (JSON, Google Storage, Amazon Simple Storage Service), map-based datastores (HBase, Google's BigTable), document stores (MongoDB) as well as other types of datastores (e.g LDAP). It is designed using OSGi technology.
DataNucleus Access Platform is the persistence layer behind Google App Engine for Java, and VMForce (cloud offering from Salesforce.com and VMWare).
- Ojb :
Apache ObJectRelationalBridge (OJB) is an Object/Relational mapping tool that allows transparent persistence for Java Objects against relational databases. It was released on April 6th, 2005.
As of January 16, 2011 Apache ObJectRelationalBridge has been retired.
OJB is an open source project. It is lightweight and easy to use requiring simply configure two files to implement a persistence layer. It is easy to integrate into an existing application because it does not generate code. It allows the use of different patterns of persistence: owner (PersistenceBroker API), JDO and Object Data Management Group (ODMG).
OJB uses an XML based Object/Relational mapping. The mapping resides in a dynamic MetaData layer, which can be manipulated at runtime through a simple Meta-Object-Protocol (MOP) to change the behaviour of the persistence kernel.
At least two files are required to configure OJB: OJB.properties and repository.xml
For mapping a 1-1 relationship, for example, you have two tables: person and account. In this case, a person has an account and vice versa.
- Apache OpenJPA :
OpenJPA is an open source implementation of the Java Persistence API specification. It is an object-relational mapping (ORM) solution for the Java language, which simplifies storing objects in databases. It is open source software distributed under the Apache 2.0 Licence.
Kodo, a Java Data Objects implementation, was originally developed by SolarMetric, Inc in 2001. BEA Systems acquired SolarMetric in 2005, where Kodo was expanded to be an implementation of both the JDO (JSR 12) and JPA (JSR 220) specifications. In 2006, BEA donated a large part of the Kodo source code to the Apache Software Foundation under the name OpenJPA. The donated source code will be the core persistence engine of BEA Weblogic Server, IBM WebSphere, and the Geronimo Application Server. In May 2007, OpenJPA graduated from the incubator to a top-level project and also passed Sun's Technology Compatibility Kit compliant with the Java Persistence API.
- Apache Cayenne :
Apache Cayenne is an open source persistence framework licensed under the Apache License, providing object-relational mapping (ORM) and remoting services. Cayenne binds one or more database schemas directly to Java objects, managing atomic commit and rollbacks, SQL generation, joins, sequences, and more. With Cayenne's Remote Object Persistence, those Java objects can even be persisted out to clients via Web Services. Or, with native XML serialization, objects can be further persisted to non-Java clients - such as an Ajax-capable browser.
Cayenne supports database reverse engineering and generation, as well as a Velocity-based class generation engine. All of these functions can be controlled directly through the CayenneModeler, a fully functional GUI tool. No XML- or annotation-based configuration is required. An entire database schema can be mapped directly to Java objects quickly, all from the comfort of the GUI-based CayenneModeler. These things together make Cayenne interesting for a user who is new to the enterprise world.
Cayenne supports other features, including caching, a complete object query syntax, relationship pre-fetching, on-demand object and relationship faulting, object inheritance, database auto-detection, and generic persisted objects. Most importantly, Cayenne can scale up or down to virtually any project size.
Cayenne started as a project run by Objectstyle and led by Andrus Adamchik. It was released under the Apache license from its first release in July 2002. In early 2006 the project moved from Objectstyle to the Apache Software Foundation and in December 2006 was promoted to be a top level project of Apache.
- ObjectDB :
ObjectDB is an object database for Java. It can be used in client-server mode and in embedded (in process) mode.
Unlike other object databases, ObjectDB does not provide its own proprietary API. Accordingly, working with ObjectDB requires using one of the two standard Java APIs - JPA or JDO. Both APIs are built-in in ObjectDB, so an intermediate ORM software is not needed.
ObjectDB is a cross platform software and can be used on various operating systems with Java SE 5 or higher. It can be integrated into Java EE and Spring web applications and deployed on servlet containers (Tomcat, Jetty) as well as on Java EE application servers (GlassFish, JBoss). It was tested on various JVMs, including HotSpot, JRockit and IBM J9.
The maximum database size is 128 TB (131,072 GB). The number of objects in a database is unlimited (except by the database size).
All the persistable types of JPA and JDO are supported by ObjectDB, including user defined entity classes, user defined embeddable classes, standard Java collections, basic data types (primitive values, wrapper values, String, Date, Time, Timestamp) and any other serializable classes.
Every object in the database has a unique ID. ObjectDB supports both traditional object database IDs, as well as RDBMS like primary keys, including composite primary keys and auto value generation and assignment, as part of its support of JPA, which is mainly an API for RDBMS.
Two query languages are supported. The JDO Query Language (JDOQL), which is based on Java syntax, and the JPA Query Language (JPQL), which is based on SQL syntax. JPA 2 criteria queries are also supported.
ObjectDB automatic schema evolution handles most changes to classes transparently, including adding and removing of persistent fields, changing types of persistent fields, and modifying class hierarchy. Renaming persistable classes and persistent fields is also supported.
Tools and Utilities
- The following tools and utilities are included in the ObjectDB distribution :
- Database Explorer - GUI tool for querying, viewing and editing database content.
- Database Doctor - Diagnoses and repairs possible database problems.
- Replication - Master-Slave replication (clustering) with unlimited number of slave nodes.
- Online Backup - Database backup by a simple query on an EntityManager.
- Class Enhancer - Boosts performance by preparing classes for persistence.
- BIRT Reports Driver - Adds ObjectDB as a BIRT data source and JPQL / JDOQL queries as data sets
- QuickDB ORM :
QuickDB is an object-relational mapping framework for the Java software platform. It was developed by Diego Sarmentero along with others and is licensed under the LGPL License. Versions for .NET, Python and PHP are also being developed.
QuickDB allows a developer to focus on the definition of the entities that represent the tables of the database and perform operations that allow the interaction between these entities and the database without having to perform tedious configurations, leaving to the library the task to infer the object structure and make the mapping of the object to the Database.
The software aims not only to simplify the task of mapping the attributes between a traditional relational database and the objects from the data model, but in turn, make the use of the library intuitive for the developer, leaving aside configuration tasks. Where each operation involves only the task (save, modify, ...) and the subject where it should apply to (the object).
QuickDB, like other tools for object-relational mapping, seeks to resolve the differences between the two co-existing data models: Object-Oriented Model and the Relational Model. To address this problem, it takes a fully object-oriented approach, where structures like "Objects composed of other objects", "Inheritance", "Collections" (one-to-many and many-to-many) are recognized by default as common entities, and also other features such as automatic table creation and modification of tables dynamically if the structure of the object change over time (addition of new attributes) are included. QuickDB not require the implementation of any interface, or the use of inheritance by the data model to be persistent, it is based simply on certain naming conventions for attributes to infer relevant information about the Object. However, it is possible to use annotations to set certain characteristics of the object, which gives the assurance that everything that QuickDB recognize by default, can be also managed completely by the developer. For queries, QuickDB pretends to maintain this approach where the developer works with the data model in a fully object-oriented way, and therefore the SQL statements (although they are permitted) are not necessary, and can be used by default a Query system where the condition to be evaluated is specified with a simple reference to the attributes in the objects from the data model.
QuickDB also provides the possibility of allowing the developer to create the data model extending the AdminBinding Class (but this is not required, this is another available resource to simplify some processes), which serves as a "link" between the entities and AdminBase to allow the operations that interact with the database to be executed from the object itself and not use AdminBase intermediary as directly.
AdminBinding not cover all the functionality that AdminBase provides, as it only handles those operations that are specific to the object that contains them, leaving out those that refer to collections, etc.
- .NET Persistence API :
.NET Persistence API
The .NET Persistence API, also referred to as NPA, is a persistence and Object Relational Mapping (ORM) specification for the .NET framework. NPA is based on the Java Persistence API (JPA), which is the standard persistence API in the Java world. NPA follows JPA by providing a complete persistence API and a rich set of ORM features.
The main purposes of the .NET Persistence API (NPA) are:To provide a vendor free persistence API for .NET, making switching from one persistence provider to another easier (avoiding vendor lock-in). To provide a cross language persistence API by extending the popular Java Persistence API (JPA) to all the .NET programming languages.
The main features of NPA include:
- Object oriented API for working against databases (usually RDBMS).
- Query language, based on SQL, for retrieving data from the database in an object oriented manner.
- Support of persisting POCO (plain old CLR objects) objects (entities).
- Two methods for marking classes as entity classes and for specifying other settings:
- Using attributes - meta data is embedded in class definitions in the source code.
- Using external XML - meta data is specified in external XML resource files.
NPA is a persistence specification. To use NPA an implementation of the specification is required. Persistence and ORM vendors can provide their own implementations of NPA.
First implementation, NPA for NHibernate, was released in December 2011.
- Entity Framework :
ADO.NET Entity Framework (EF) is an open source object-relational mapping (ORM) framework for the NET Framework.
The Entity Framework is a set of technologies in ADO.NET that support the development of data-oriented software applications. Architects and developers of data-oriented applications have struggled with the need to achieve two very different objectives. They must model the entities, relationships, and logic of the business problems they are solving, and they must also work with the data engines used to store and retrieve the data. The data may span multiple storage systems, each with its own protocols; even applications that work with a single storage system must balance the requirements of the storage system against the requirements of writing efficient and maintainable application code.
The Entity Framework enables developers to work with data in the form of domain-specific objects and properties, such as customers and customer addresses, without having to concern themselves with the underlying database tables and columns where this data is stored. With the Entity Framework, developers can work at a higher level of abstraction when they deal with data, and can create and maintain data-oriented applications with less code than in traditional applications. Because the Entity Framework is a component of the .NET Framework, Entity Framework applications can run on any computer on which the .NET Framework starting with version 3.5 SP1 is installed.
The architecture of the ADO.NET Entity Framework, from the bottom up, consists of the following:
- Data source specific providers, which abstract the ADO.NET interfaces to connect to the database when programming against the conceptual schema.
- Map provider, a database-specific provider that translates the Entity SQL command tree into a query in the native SQL flavor of the database. It includes the Store-specific bridge, which is the component responsible for translating the generic command tree into a store-specific command tree.
- EDM parser and view mapping, which takes the SDL specification of the data model and how it maps onto the underlying relational model and enables programming against the conceptual model. From the relational schema, it creates views of the data corresponding to the conceptual model. It aggregates information from multiple tables in order to aggregate them into an entity, and splits an update to an entity into multiple updates to whichever table(s) contributed to that entity.
- Query and update pipeline, processes queries, filters and updates requests to convert them into canonical command trees which are then converted into store-specific queries by the map provider.
- Metadata services: which handle all metadata related to entities, relationships and mappings.
- Transactions: to integrate with transactional capabilities of the underlying store. If the underlying store does not support transactions, support for it needs to be implemented at this layer.
- Conceptual layer API: the runtime that exposes the programming model for coding against the conceptual schema. It follows the ADO.NET pattern of using Connection objects to refer to the map provider, using Command objects to send the query, and returning EntityResultSets or EntitySets containing the result.
- Disconnected components: which locally cache datasets and entity sets for using the ADO.NET Entity Framework in an occasionally connected environment.
- Embedded database: ADO.NET Entity Framework includes a lightweight embedded database for client-side caching and querying of relational data.
- Design tools, such as Mapping Designer, are also included with ADO.NET Entity Framework, which simplifies the job of mapping a conceptual schema to the relational schema and specifying which properties of an entity type correspond to which table in the database.
- Programming layer: which exposes the EDM as programming constructs which can be consumed by programming languages.
- Object services: automatically generate code for CLR classes that expose the same properties as an entity, thus enabling instantiation of entities as .NET objects.
- Web services: which expose entities as web services.
- High-level services: such as reporting services which work on entities rather than relational data.
- NHibernate :
NHibernate (ORM) solution for the Microsoft .NET platform: it provides a framework for mapping an object-oriented domain model to a traditional relational database. Its purpose is to relieve the developer from a significant portion of relational data persistence-related programming tasks. NHibernate is free as open source software that is distributed under the GNU Lesser General Public License. NHibernate is a port of Hibernate.
NHibernate's primary feature is mapping from .NET classes to database tables (and from CLR data types to SQL data types). NHibernate also provides data query and retrieval facilities. NHibernate generates the SQL commands and relieves the developer from manual data set handling and object conversion, keeping the application portable to most SQL databases, with database portability delivered at very little performance overhead.
NHibernate provides transparent persistence for Plain Old CLR Objects (POCOs). The only strict requirement for a persistent class is a no-argument constructor, which does not have to be public. (Proper behavior in some applications also requires special attention to the Equals() and GetHashCode() methods.)
- J2ee Solutions
- Spring -Spring Mvc-Hibernate
- Java Server Faces-Hibernate
- Struts 1.3 - Hibernate
- Struts 2.0 - Hibernate
- Xml based Web Services
- Liferay Portal - Hibernate
- Php Joomla - Mvc Framework
- Socket Prog - Swings/JFace
- RMI - Swings/Swt/JFace
- EJB 2.0 - Swings/Swt/JFace
- EJB 3.0 - Swings/Swt/JFace
- Jms - Ejb -Swings/Swt/JFace
- CORBA - JCA - Swings
- Spring Remote Access
- Active JDBC
- iBATIS / MyBatis
- Java Data Objects (JDO)
- Java Object Querying (jOOQ)
- Java Persistence API (JPA)
- Apache Tomcat
- Apache Geronimo
- Sun One
- BEA Weblogic
- IBM Websphere
- SAP Netweaver
- Jasper Reports
- Eclipse Birt
- JFree Report
- Open Reports
A solid working knowledge of productivity software and other IT tools has become a basic foundation for success in virtually any career. Beyond that, however, I don't think you can overemphasise the importance of having a good background in maths and science.....
"Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture)... A step in thr development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points. "
"All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change"
"The ultimate measurement is effectiveness, not efficiency "
"It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. "Architecture-centric methods and agile approaches." Agile Processes in Software Engineering and Extreme Programming.
"Java is C++ without the guns, knives, and clubs "
"When done well, software is invisible"
"Our words are built on the objects of our experience. They have acquired their effectiveness by adapting themselves to the occurrences of our everyday world."
"I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby. "
"The best way to predict the future is to invent it."
"In 30 years Lisp will likely be ahead of C++/Java (but behind something else)"
"Possibly the only real object-oriented system in working order. (About Internet)"
"Simple things should be simple, complex things should be possible. "
"Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines."
"Model Driven Architecture is a style of enterprise application development and integration, based on using automated tools to build system independent models and transform them into efficient implementations. "
"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. "
"Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making. "
"Ultimately, discovery and invention are both problems of classification, and classification is fundamentally a problem of finding sameness. When we classify, we seek to group things that have a common structure or exhibit a common behavior. "
"Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world. "
"The entire history of software engineering is that of the rise in levels of abstraction. "
"The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist "
Core Values ?Agile And Scrum Based Architecture
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration.....more
Core Values ?Total quality management
Total Quality Management / TQM is an integrative philosophy of management for continuously improving the quality of products and processes. TQM is based on the premise that the quality of products and .....more
Core Values ?Design that Matters
We are more than code junkies. We're a company that cares how a product works and what it says to its users. There is no reason why your custom software should be difficult to understand.....more
Core Values ?Expertise that is Second to None
With extensive software development experience, our development team is up for any challenge within the Great Plains development environment. our Research works on IEEE international papers are consider....more
Core Values ?Solutions that Deliver Results
We have a proven track record of developing and delivering solutions that have resulted in reduced costs, time savings, and increased efficiency. Our clients are very much ....more
Core Values ?Relentless Software Testing
We simply dont release anything that isnt tested well. Tell us something cant be tested under automation, and we will go prove it can be. We create tests before we write the complementary production software......more
Core Values ?Unparalled Technical Support
If a customer needs technical support for one of our products, no-one can do it better than us. Our offices are open from 9am until 9pm Monday to Friday, and soon to be 24hours. Unlike many companies, you are able to....more
Core Values ?Impressive Results
We have a reputation for process genius, fanatical testing, high quality, and software joy. Whatever your business, our methods will work well in your field. We have done work in Erp Solutions ,e-commerce, Portal Solutions,IEEE Research....more
Why Choose Us ?
The intellectual commitment of our development team is central to the leonsoft ability to achieve its mission: to develop principled, innovative thought leaders in global communities.Read More
Today's most successful enterprise applications were once nothing more than an idea in someone's head. While many of these applications are planned and budgeted from the beginning.Read More
We constantly strive to redefine the standard of excellence in everything we do. We encourage both individuals and teams to constantly strive for developing innovative technologies....Read More
If our customers are the foundation of our business, then integrity is the cornerstone. Everything we do is guided by what is right. We live by the highest ethical standards.....Read More