Showing posts with label opensource. Show all posts
Showing posts with label opensource. Show all posts

Monday, November 1, 2021

open source security

  • software composition analysis (SCA) SCA, a term coined by market analysts, describes an automated process to identify open source components in a codebase. Once a component is identified, it becomes possible to map that component to known security disclosures and determine whether multiple versions are present within an application. SCA also helps identify whether the age of the component might present maintenance issues. While not strictly a security consideration, SCA also facilitates legal compliance related to those open source components. While development and security teams often use SAST (static application security testing) and SCA solutions to identify security weaknesses and vulnerabilities in their web applications, detection of many vulnerabilities is only possible by dynamically testing the running application, which led to the development of dynamic application security testing (DAST) tools. Despite similarities to traditional DAST and penetration testing tools, IAST is superior to both in finding vulnerabilities earlier in the software development life cycle (SDLC)—when it is easier, faster, and cheaper to fix them. Over time, IAST is likely to displace DAST usage for two reasons: IAST provides significant advantages by returning vulnerability information and remediation guidance rapidly and early in the SDLC, and it can be integrated more easily into CI/CD and DevOps workflows. https://www.synopsys.com/blogs/software-security/iast-sca-security-toolkit/ 

  • Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall Cyber Supply Chain Risk Management (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA). https://www.owasp.org/index.php/Component_Analysis
  • Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the National Vulnerability Database (NVD), Node Security Platform (NSP), and VulnDB from Risk Based Security.


  • Dependency-Check is a Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project’s dependencies.

https://owasp.org/www-project-dependency-check/
  • What is Open Source Security?
Open Source Security, commonly referred to as Software Composition Analysis (SCA), is a methodology to provide users better visibility into the open source inventory of their applications.

What is Open Source?
Open source refers to any software with accessible source code that anyone can modify and share freely.

Why Use Open Source Software?
Open Source Software (OSS) is distributed freely, making it very cost-effective. Many developers benefit by starting with OSS and then tweaking it to suit their needs. Since the code is open, it's simply a matter of modifying it to add the functionality they want.

Is Open Source a Security Risk?
Open source components are not created equal. Some are vulnerable from the start, while others go bad over time
Usage has become more complex. With tens of billions of downloads, it’s increasingly difficult to manage libraries and direct dependencies
Transitive dependencies: if you are using dependency management tools like Maven (Java), Bower (JavaScript), Bundler (Ruby), etc., then you are automatically pulling in third party dependencies – a liability that you can’t afford.

https://www.microfocus.com/en-us/what-is/open-source-security


  • Open Source Security Foundation (OpenSSF) 
Concise Guide for Developing More Secure Software

Ensure all privileged developers use multi-factor authentication (MFA) tokens. This includes those with commit or accept privileges. MFA hinders attackers from “taking over” these accounts.

Use a combination of tools in your CI pipeline to detect vulnerabilities.

Evaluate software before selecting it as a direct dependency. Only add it if needed, evaluate it (see Concise Guide for Evaluating Open Source Software, double-check its name (to counter typosquatting), and ensure it’s retrieved from the correct repository.

Use package managers. Use package managers (system, language-level, and/or container-level) to automatically manage dependencies and enable rapid updates.

Implement automated tests. Include negative tests (tests that what shouldn’t happen doesn’t happen) and ensure the test suite is thorough enough to “ship if it passes the tests”

Monitor known vulnerabilities in your software’s direct & indirect dependencies. E.g., enable basic scanning via GitHub’s dependabot or GitLab dependency scanning. Many other third party Software Composition Analysis (SCA) tools are also available. Quickly update vulnerable dependencies.

Keep dependencies reasonably up-to-date

Do not push secrets to a repository. Use tools to detect pushing secrets to a repository.

Review before accepting changes. Enforce it, e.g., GitHub or GitLab protected branches.

Improve your OpenSSF Scorecards score (if OSS and on GitHub). You can read the Scorecards checks. Use the Allstar monitor.

Improve your Supply chain Levels for Software Artifacts (SLSA) level. This hardens the integrity of your build and distribution process against attacks.


Publish and consume a software bill of materials (SBOM). This lets users verify inventory, id known vulnerabilities, & id potential legal issues. Consider SPDX or CycloneDX.

Onboard your project into LFX Security if you manage a Linux Foundation project.
Apply the CNCF Security TAG Software Supply Chain Best Practices guide.
Implement ASVS and follow relevant cheatsheets.
Apply SAFECode’s Fundamental Practices for Secure Software Development.

https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software

  • Guide to Security Tools

Two main tool categories

There are two main technical categories of verification tools:

    Static analysis is any approach for verifying software (including finding defects) without executing software. This includes tools that examine source code looking for vulnerabilities (e.g., source code vulnerability scanning tools). It also includes humans reading code, looking for problems.
    Dynamic analysis is any approach for verifying software (including finding defects) by executing software on specific inputs and checking the results. Traditional testing is a kind of dynamic analysis. Fuzz testing, where you send many random inputs to a program to see if it does something it should not, is also an example of dynamic analysis.


Types of Tools

This section will cover some of the most common application security tools including linters, SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators.

Quality scanners (linters)

Quality scanners, also called "linters", examine source code, byte code, or machine code to look for generic “quality” problems. For example, they may look for misleading indentation, combinations of constructs that usually indicate a defect, or overly-long methods that may be hard to understand later. There are a large variety of these, including style checkers and external type checkers.

For our purposes we will include compiler warning flags in this category.

These tools often don’t focus on security, but using them can still help improve security:

Security Code Scanners (Static Application Security Testing (SAST) Tools)

Some tools analyze code specifically looking for vulnerabilities. They go by a variety of names, such as security code scanners, Static Application Security Testing (SAST) tools, security source code scanners (if they examine source code), binary code scanners (if they only examine executables), or sometimes just static code analyzers. Some people use the term SAST only when the tool analyzes source code.

Secret scanning tools

Secret scanning tools look for secrets (passwords, stored keys, etc.), typically in a repository's code and/or configuration. These are typically static analysis tools. These tools typlically detect the secrets in code by grepping (simple text based searching) or regex searches.

Software Bill Of Materials (SBOM) tools

A Software Bill Of Materials (SBOM) is an artifact that may accompany the release of a software package. The SBOM includes an inventory of the software components and dependencies that are included in a parent software. This may include both open source and proprietary components and dependencies. It may also include additional information such as more in-depth package information, file information, licensing, authors, contributors, security checksums or references, copyright information, as well as their hierarchical relationships.

Machine-readable formats for SBOMs grant the opportunity for this information to be shared throughout the software supply chain; thus increasing transparency of and confidence in the final delivered software artifact. The machine readable formats for SBOMs currently include SPDX, CycloneDX, and SWID.

SBOMs are quickly becoming a necessity for software products and services to include in their software delivery practices. SBOMs are being recommended by several security frameworks, organizations, and security requirements such as the White House Executive Order 14028, NIST, NTIA,the OpenSSF Mobilization Plan, and SLSA.

Software Component Analysis (SCA)/Dependency Analysis tools

Software component analysis (SCA) tools, also called dependency analysis or origin analysis tools, determine the reused components used by code (source code or executable). To be security-relevant, these tools also determine which of those reused components have publicly-known vulnerabilities (CVEs).

Dependency Updating & Hygiene Tools

SCA tools help identify the known vulnerable OSS components used in your project, but other tools exist to help ensure that OSS hygiene becomes an automated process. As required in the OpenSSF Secure Supply Chain Consumption Framework (S2C2F) maturity level 2, tools such as Dependabot or Renovate bot will auto-submit Pull Requests (PRs) to update your known-vulnerable dependencies. All a developer has to do is choose to accept the PR to keep their dependencies up-to-date.

Fuzzers

A fuzzer is a tool that implements a dynamic analysis approach called fuzz testing or fuzzing. In fuzz testing, you generate a large number of inputs, run the program, and see if the program behaves badly (e.g., crashes or hangs). A key aspect of fuzzing is that it does not generally check if the program produces the correct answer; it just checks that certain reasonable behavior (like “does not crash”) occurs

Web Application Scanner

A web application scanner (WAS), also called a web application vulnerability scanner, essentially pretends it is a simulated user or web browser and tries to do many things to detect problems. Think of a WAS as a frenetic and malicious web browser user; the WAS will try to click on every button it finds, enter bizarre text into every text field it finds, and so on. In short, it attempts simulated attacks and odd behavior to try to detect problems. This means that WASs often build on fuzzers internally, but they are specifically designed to analyze web applications.

There are many of these tools. OSS tools include OWASP ZAP, W3AF, IronWASP, Skipfish, and Wapiti. Proprietary tools include IBM AppScan, HP WebInspect, and Burp Suite Pro. If you have no idea, you might check out OWASP ZAP at least; it is easy to use, and it can find many things. But tools change over time, and it is best to look at your options before picking one (or several).

The term Dynamic Application Security Testing, or DAST, is often seen in literature. However, the meaning of DAST has a lot of variation:

    For some, DAST is dynamic analysis for finding vulnerabilities in just web applications, making DAST the same as a web application scanner.
    For others, DAST includes web application scanners and fuzzers for programs other than web applications.


https://github.com/ossf/wg-security-tooling/blob/main/guide.md#readme

  • About secret scanning
 your project communicates with an external service, you might use a token or private key for authentication. Tokens and private keys are examples of secrets that a service provider can issue. If you check a secret into a repository, anyone who has read access to the repository can use the secret to access the external service with your privileges. We recommend that you store secrets in a dedicated, secure location outside of the repository for your project.

Secret scanning will scan your entire Git history on all branches present in your GitHub repository for secrets. 
https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning



Saturday, January 3, 2015

Dozer framework

  • Dozer framework
Dozer is a Java Bean to Java Bean mapper that recursively copies data from one object to another. Typically, these Java Beans will be of different complex types.
Dozer supports simple property mapping, complex type mapping, bi-directional mapping, implicit-explicit mapping, as well as recursive mapping. This includes mapping collection attributes that also need mapping at the element level.
http://dozer.sourceforge.net/

Wednesday, April 23, 2014

pojo id in hibernate

  • Suppose you are developing a course management system for a training center.
The first class you create for this system is Course.
This class is called an entity class or a persistent class because it represents a  real-world entity and its instances will be persisted to a database.
Remember that for each entity class to be persisted by an ORM framework, a default constructor with no argument is required.


public class Course {
private Long id;
...
// Constructors, Getters and Setters
}

For each entity class, you must define an identifier property to uniquely identify an entity.
It’s a best practice to define an auto-generated identifier because this has no business meaning and thus won’t be changed under any circumstances.
this identifier will be used by the ORM framework to determine an entity’s state.
If the identifier value is null, this entity will be treated as a new and unsaved entity.
When this entity is persisted, an insert SQL statement will be issued; otherwise, an update statement will.
To allow the identifier to be null, you should choose a primitive wrapper type like
java.lang.Integer and java.lang.Long for the identifier

Spring Recipes: A Problem-Solution Approach

Connection pooling

  • Hibernate's own connection pooling algorithm is, however, quite rudimentary.
You should use a third party pool for best performance and stability.
Just replace the hibernate.connection.pool_size property with connection pool specific settings.
This will turn off Hibernate's internal pool.

C3P0 is an open source JDBC connection pool distributed along with Hibernate in the lib directory.
Hibernate will use its org.hibernate.connection.C3P0ConnectionProvider for connection pooling if you set hibernate.c3p0.* properties.
If you would like to use Proxool, refer to the packaged hibernate.properties

The following is an example hibernate.properties file for c3p0:
hibernate.connection.driver_class = org.postgresql.Driver
hibernate.connection.url = jdbc:postgresql://localhost/mydatabase
hibernate.connection.username = myuser
hibernate.connection.password = secret
hibernate.c3p0.min_size=5
hibernate.c3p0.max_size=20
hibernate.c3p0.timeout=1800
hibernate.c3p0.max_statements=50
hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect

http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/session-configuration.html#configuration-optional


  • hibernate.c3p0.min_size – Minimum number of JDBC connections in the pool. Hibernate default: 1
hibernate.c3p0.max_size – Maximum number of JDBC connections in the pool. Hibernate default: 100
hibernate.c3p0.timeout – When an idle connection is removed from the pool (in second). Hibernate default: 0, never expire.
hibernate.c3p0.max_statements – Number of prepared statements will be cached. Increase performance. Hibernate default: 0 , caching is disable.
hibernate.c3p0.idle_test_period – idle time in seconds before a connection is automatically validated. Hibernate default: 0

Toad test to see connections
http://www.mkyong.com/hibernate/how-to-configure-the-c3p0-connection-pool-in-hibernate/


  • Using a properties (flat text) file. For instance

jdbc-0.proxool.alias=property-test
jdbc-0.proxool.driver-url=jdbc:hsqldb:.
jdbc-0.proxool.driver-class=org.hsqldb.jdbcDriver
jdbc-0.user=sa
jdbc-0.password=
jdbc-0.proxool.maximum-connection-count=10
jdbc-0.proxool.house-keeping-test-sql=select CURRENT_DATE

http://proxool.sourceforge.net/configure.html



hibernate.hbm2ddl.auto

  • Automatically validates or exports schema DDL to the database when the SessionFactory is created. With create-drop, the database schema will be dropped when the SessionFactory is closed explicitly.
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html#configuration-optional


  •     validate: validate the schema, makes no changes to the database.
    update: update the schema.
    create: creates the schema, destroying previous data.
    create-drop: drop the schema at the end of the session.
http://stackoverflow.com/questions/438146/hibernate-hbm2ddl-auto-possible-values-and-what-they-do


  • Hibernate creators discourage doing so in a production environment in their book "Java Persistence with Hibernate"

excerpt:
We've seen Hibernate users trying to use SchemaUpdate to update the schema of a production database automatically. This can quickly end in disaster and won't be allowed by your DBA.

http://stackoverflow.com/questions/221379/hibernate-hbm2ddl-auto-update-in-production

Code Bubbles

  • Code Bubbles
Code Bubbles is a front end to Eclipse designed to simplify programming by making it easy for the programmer to define and use working sets.
http://cs.brown.edu/~spr/codebubbles/

Tuesday, March 4, 2014

Spring using JDBCDaoSupport

Example Without JdbcTemplate
you have to create many redundant codes (create connection , close connection , handle exception) in all the DAO database operation methods – insert, update and delete. It just not efficient, ugly, error prone and tedious.

Example With JdbcTemplate
With JdbcTemplate, you save a lot of typing on the redundant codes, becuase JdbcTemplate will handle it automatically.

Example With JdbcDaoSupport
By extended the JdbcDaoSupport, set the datasource and JdbcTemplate in your class is no longer required, you just need to inject the correct datasource into JdbcCustomerDAO. And you can get the JdbcTemplate by using a getJdbcTemplate() method.


http://www.mkyong.com/spring/spring-jdbctemplate-jdbcdaosupport-examples/

HibernateTemplate and HibernateDaoSupport these classes should be considered deprecated since the release of hibernate 3.0.1
JdbcTemplate (and all other *Template classes) intend is to make it easier to work with the underlying technology. Once upon a time this was also needed for Hibernate (< 3.0.1), now it isn't.

JdbcTemplate makes it easier to work with plain JDBC code. You don't have to get a connection, create a (Prepared)Statement, add the parameters, execute the query, iterate over the resultset and convert the ResultSet. With the JdbcTemplate much of this is hidden and most of it can be written in 1 to 3 lines of code, whereas plain JDBC would require a lot more.

The *Support classes make it easier to gain access to a template but aren't a must to use. Creating a JdbcTemplate is quite easy and you don't really need to extend JdbcDaoSupport. But you can if you want

http://stackoverflow.com/questions/20256787/spring-transaction-of-jdbctemplate-hibernatetemplate-and-hibernatedaosupport-jdb


Spring JDBC DaoSupport
Spring provides convenient classes to perform functions on the database. It handles creating a connection to a database, performing clean up and handling exceptions. The user creates a datasource and injects it into a jdbctemplate. The jdbctemplate is then injected into the spring Dao. The user can also inject a datasource directly into the Dao. The Dao is an abstract class and the user extends this class to create his own Dao. The advantage of this class is that the user does not have to inject the JdbcTemplate into all of his DAO classes. The user creates a common Dao class that can be extended by all the DAO classes. Spring provides two DAO classes JdbcDaoSupport and NamedParameterJdbcDaoSupport. There is a third class called SimpleJdbcDaoSupport but this is now deprecated in favor of JdbcDaoSupport and NamedParameterJdbcDaoSupport

http://www.studytrails.com/frameworks/spring/spring-jdbc-dao-support.jsp

Spring Hibernate integration using HibernateDaoSupport


Using HibernateDaoSupport/HibernateTemplate is not recommended since it unnecessarily ties your code to Spring classes.
Using these classes was inevitable with older versions of Hibernate in order to integrate support of Spring-managed transactions.
Since Hibernate 3.0.1 you don't need it any more - you can write a code against a plain Hibernate API while using Spring-managed transactions
All you need is to configure Spring transaction support, inject SessionFactory and call getCurrentSession() on it when you need to work with session.
Another benefit of HibernateTemplate is exception translation.
Without HibernateTemplate the same functionality can be achieved by using @Repository annotation
This will wire in the same exception translation (one of the big benefits of the HibernateTemplate) and allow you to either use your own super class or just simply to avoid extending a third party framework class.


@Repository
public class YourFooDao {

    @Resource
    private SessionFactory sessionFactory;

    private Foo get(long id){
        return (Foo) sessionFactory.getCurrentSession().get(id);
    }

   
    http://stackoverflow.com/questions/5104765/hibernatedaosupport-is-not-recommended-why
   
   
     HibernateTemplate - Spring provides a class called org.springframework.orm.hibernate3.HibernateTemplate that helps in accessing the database via hibernate. One of its main features is mapping of hibernate exceptions to DataAccessExceptions. The main method in HibernateTemplate is the execute method that takes in a hibernate callback. HibernateTemplate also takes care of obtaining or releasing sessions and hence the callback function or invoking function does not have to manage sessions. The SessionFactory is injected into HibernateTemplate using a LocalSessionFactoryBean. Spring manages the creation and shutting down of the factory. HibernateTemplate provides methods such as find, saveOrUpdate, persist, delete etc that performs the corresponding function in hibernate but manages sessions and exceptions.

LocalSessionFactoryBean - This is a spring factory bean that creates hibernate sessionfactory. The main purpose of this class is to set up the Hibernate SessionFactory in a spring context. The hibernate configuration properties can be passed within the XML. The configuration properties include the hibernate mapping resources, hibernate properties and a datasource. The SessionFactory can handle both pure hibernate session management with single database or transactions that span multiple databases using JTA .

AnnotaionSessionFactoryBean - This is a subclass of LocalSessionFactoryBean but supports annotation based mappings.

HibernateDaoSupport - This class is a convenience class for hibernate based database access. This is a wrapper over HibernateTemplate. It can be initialized using a SessionFactory. It creates the HibernateTemplate and subclasses can use the getHibernateTemplate() method to obtain the hibernateTemplate and then perform operations on it. The class can also be initialized using a preconfigured HibernateTemplate. Create your own DAO by extending this class, provide a SessionFactory or HibernateTemplate and start performing operations using the getHibernateTemplate() method.

http://www.studytrails.com/frameworks/spring/spring-hibernate-dao-support.jsp


Spring is a general-purpose framework that plays different roles in many areas of application architecture. One of these areas is persistence. Spring does not provide its own persistence framework. Instead, it provides an abstraction layer over JDBC, and a variety of O/R mapping frameworks, such as iBATIS SQL Maps, Hibernate, JDO, Apache OJB, and Oracle TopLink. This abstraction allows consistent, manageable data-access implementation. 

http://java.dzone.com/articles/spring-hibernate-persistence

Wednesday, August 7, 2013

jakarta commons logging


  • When writing a library it is very useful to log information. However there are many logging implementations out there, and a library cannot impose the 

use of a particular one on the overall application that the library is a part of.

The Logging package is an ultra-thin bridge between different logging implementations. A library that uses the commons-logging API can be used with any 

logging implementation at runtime. Commons-logging comes with support for a number of popular logging implementations, and writing adapters for others 

is a reasonably simple task.

Applications (rather than libraries) may also choose to use commons-logging. While logging-implementation independence is not as important for 

applications as it is for libraries, using commons-logging does allow the application to change to a different logging implementation without 

recompiling code. 

Note that commons-logging does not attempt to initialise or terminate the underlying logging implementation that is used at runtime; that is the 

responsibility of the application. However many popular logging implementations do automatically initialise themselves; in this case an application may 

be able to avoid containing any code that is specific to the logging implementation used.



http://commons.apache.org/proper/commons-logging/

Thursday, March 7, 2013

Apache POI


Apache POI - the Java API for Microsoft Documents
The Apache POI Project's mission is to create and maintain Java APIs for manipulating various file formats based upon the Office Open XML standards (OOXML) and Microsoft's OLE 2 Compound Document format (OLE2). In short, you can read and write MS Excel files using Java. In addition, you can read and write MS Word and MS PowerPoint files using Java. Apache POI is your Java Excel solution (for Excel 97-2008)
http://poi.apache.org/

Tuesday, February 12, 2013

Dynamic JavaBeans



  • Dynamic JavaBeans

By creating a DynamicBean, you can reduce the effort to the definition of an interface and create instances using a bean factory like
http://lib.ribomation.com/riboutils/dynamicbean/

Monday, November 12, 2012

Apache Struts 2


Apache Struts 2

Apache Struts 2 is an elegant, extensible framework for creating enterprise-ready Java web applications. The framework is designed to streamline the full development cycle, from building, to deploying, to maintaining applications over time.

Apache Struts 2 was originally known as WebWork 2. After working independently for several years, the WebWork and Struts communities joined forces to create Struts2. This new version of Struts is simpler to use and closer to how Struts was always meant to be.

http://struts.apache.org/2.2.3/index.html

Thursday, November 8, 2012

JDO

JDO is
- a persistence technology
-allows you to create POJOs (plain old java objects) and persist them to the database


If you are an application programmer, you can use JDO technology to directly store your Java domain model instances into the persistent store (database). Alternatives to JDO include direct file I/O, serialization, JDBC, Enterprise JavaBeans (EJB), Bean-Managed Persistence (BMP) or Container-Managed Persistence (CMP) entity beans, and the Java Persistence API.

http://www.oracle.com/technetwork/java/index-jsp-135919.html



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


persistence has been "broken out" of "EJB3 Core", and a new standard formed, the Java Persistence API (JPA). JPA uses the javax.persistence package


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)

http://en.wikipedia.org/wiki/Java_Data_Objects


Apache JDO
Java Data Objects (JDO) is a standard way to access persistent data in databases, using plain old Java objects (POJO) to represent persistent data

The approach separates data manipulation (done by accessing Java data members in the Java domain objects) from database manipulation (done by calling the JDO interface methods).

http://db.apache.org/jdo/

Tuesday, October 23, 2012

Hibernate



  • Relational Persistence for Java and .NET


Historically, Hibernate facilitated the storage and retrieval of Java domain objects via Object/Relational Mapping.  Today, Hibernate is a collection of related projects enabling developers to utilize POJO-style domain models in their applications in ways extending well beyond Object/Relational Mapping.
http://www.hibernate.org/


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.
http://en.wikipedia.org/wiki/Hibernate_%28Java%29





  • Component

Refers to the UML modeling term ofRefers to the UML modeling term of
composition
Commonly referred to as a “has a”
relationshipeato s p
– An AccountOwner has an Address
Does not exist on its own; dependentDoes not exist on its own; dependent
on a parent object

‘Address’ is a component
• Address  is a component of ‘AccountOwner’
– Non-existent without AccountOwner
– No id of its own

Entity
lives on its own
Can be made components
Can be related/associated to other entities

‘AccountOwner’ is an Entity
– Can lives on its own
– Has its own id


Using Components
1. Determine your domain model
Which objects are best suited to be a component?
2. Create your database tables
Model your components accordingly within entity tables
Create your Java classes
• One for each entity, and one for each component
• Setup your components within the entity classes
Write the Hibernate mapping file for the
entity, using the embedded component tag
ithi it t id tif th t lwithin it to identify the component class


Nested Components
Component  Address  has nested component ‘ZipCode’



Inheritance
Commonly referred to as an “is a”Commonly referred to as an  is a
relationship
Polymorphism
– Dynamic realization of subclass behavior while
treating the object as an instance of its superclass


Inheritance Realization
Easy to do in an object oriented language
– Java: Use ‘extends’ or ‘implements’ keyword
Not so easy to do in a relational database
– Tables do not ‘extend’ from each other
– Part of the ‘impedance mismatch’ problem
How do we get around this?
– Four approaches through Hibernate
• Hibernate implicit polymorphism
• Table-per-concrete class
• Table-per-class-hierarchy
• Table-per-subclass


Modeling Inheritance

1.Determine your domain model
What objects have hierarchical relationships?
2. Choose your inheritance strategy
• Hibernate implicit polymorphismHibernate implicit polymorphism
• Table-per-concrete class
• Table-per-class-hierarchy
• Table-per-subclassTable per subclass
3. Create your database tables based on the
chosen strategy
4. Code your Java objects, using ‘extends’ or
‘implements’
5. Write your Hibernate mapping file using
the appropriate subclass tags



Implicit Polymorphism
Database
– One database table per concrete class

Hibernate Mapping Files
– Separate mapping files for each inherited class
• Like normal, including any inherited properties

Default Behavior
– Out of the box Hibernate will automatically
recognize any Java inheritance associations



Implicit Polymorphism
Advantages
– Get it for free. Hibernate automatically scans classes
on startup (including inheritance); No additional
configuration/mapping neededconfiguration/mapping needed
– Not a lot of nullable columns (good for integrity)
Queries against individual types are fast and simple– Queries against individual types are fast and simple

Disadvantages
– Makes handling relationships difficult
• One-to-many relationships typically require a foreign key, but
inherited associations can’t key to both tables; Databases y
don’t support it  (Example:  AccountOwner:Account)
– Polymorphic queries are process intensive
• For queries against the superclass, Hibernate executes o que es aga s e supe c ass, be a e e ecu es
multiple queries
– SELECT * FROM CHECKING_ACCOUNT WHERE
ACCOUNT_OWNER_ID=?
– SELECT * FROM SAVINGS_ACCOUNT WHERE
ACCOUNT_OWNER_ID=?
– Database schema evolution more complexp
• Need to add the same column to multiple tables
• Integrity constraints might have to span multiple tables





Table-per-concrete class

Database
– One database table per concrete class
Hibernate Mapping
– Single mapping fileg pp g f
• Based on superclass
• Includes ‘union-subclass’ definitions for inherited classes


Table-per-concrete class

• Advantages
Shared mapping of common elements
• Shared database id
– Not a lot of nullable columns (good for integrity)Not a lot of nullable columns (good for integrity)
– Queries against individual types are fast and simple
– Less SQL statements generated with use of ‘Union’ for
polymorphic queries
• Disadvantages
– Still have difficulty with relationships
• Foreign keying to two tables not possible
– Database schema evolution still more complexp
• Need to add the same column to multiple tables
• Integrity constraints might have to span multiple tables



Table-per-class-hierarchy

Database
– One database table for all subclasses
– Denormalized table has columns for all attributes

Hibernate Mapping
– Single mapping file still based on superclass
– Includes ‘subclass’ definitions for inherited
classes
– Use ‘discriminator’ column/field to identity
concrete type


Table-per-class-hierarchy
• Advantages
– Simple
– Fast reads/writes, even across types
• Disadvantages
– Lots of nullable columns
• Possible data integrity concern
– Denormalized table generally considered bad
database design


Table-per-subclass
Database
– One database table for the superclass AND
one per subclass
• Shared columns in superclass table
• Subclass tables have their object-specific
columns

Hibernate Mapping File• Hibernate Mapping File
– Single mapping file based on the superclass
Includes ‘joined subclass’ definitions for– Includes  joined-subclass  definitions for
inherited classes



Table-per-subclass
• Advantages
– Normalized schema
• Schema evolution and integrity are straight
fdforward
– Reduced number of SQL statements produced
• Hibernate uses inner joins for subclass queries• Hibernate uses inner joins for subclass queries,
outer joins for polymorphic ones
• Disadvantages
– Can have poor performance for complex systems
• Requires many joins or sequential reads for queries



When to use Which
• Leave implicit polymorphism for queries against interfaces (based on behavior not differentinterfaces (based on behavior, not different
attributes)

• If you rarely require polymorphic queries, lean towards table-per-concrete-class.

• If polymorphic behavior is required, AND subclasses have only a few distinct properties, try table-per-l hi hclass-hierarchy

• If polymorphic AND many distinct properties, look atIf polymorphic AND many distinct properties, look at table-per-subclass or table-per-concrete-class,
weighing the cost of joins versus unions



Summary
Components are different from Entities
• Enties have their own IDs
• Component are dependant on Entities

the different methods of modeling inheritance relationships through Java/Database/Hibernate, and where each one is best
suited
Hibernate implicit polymorphism
• Table-per-concrete class
• Table-per-class-hierarchy
• Table-per-subclass


04-hibernate-Component_and_Inheritance_Mapping
http://courses.coreservlets.com/Course-Materials/hibernate.html




  • Relationship Types

Association
– Mapping relationships between two objects
– Example
• Account and AccountOwner
• Collection• Collection
– Collection of values representing individual
pieces of data
– Example
• Map of holidays
• String array of months



Relationship Dimensions

Relationships between entities can p
exist in multiple ways
– Multiplicity
• How many on each side of the
relationship?p
– Directionality
• From which side(s) of the relationship canFrom which side(s) of the relationship can
you access the other?



Relationship Multiplicity


One-to-Many
A il Ath Tti– A single Account has many Transactions
– Reverse of a many-to-one relationship
• Many-to-Oney
– Multiple Transactions belong to a single account
– Reverse of a one-to-many relationship
One to One• One-to-One
– A single AccountOwner has a single HomeAddress
– A single HomeAddress has a single AccountOwnerg g
• Many-to-Many
– Multiple Accounts have multiple AccountOwners
Oft li d th h t t lti hi– Often realized through two one-to-many relationships
• A single Account has multiple AccountOwners
• A single AccountOwner has multiple Accounts



Relationship Directionality
Unidirectional
Cl bjf idfh– Can only traverse objects from one side of the
relationship
– Example: Account : Transaction
• Given an Account object, can obtain related
Transaction objects.
• Given a Transaction object, cannot obtain related
Account object.
• Bidirectional
– Can traverse objects from both sides of the relationshipCan traverse objects from both sides of the relationship
– Example: Account : Transaction
• Given an Account object, can obtain related
Transaction objectsTransaction objects.
• Given a Transaction object, can obtain related
Account object



Java vs. Database
Objects are inherently directional
• An object has a reference/pointer to another
object
– Transition by walking a networked graph of
object references


Database
– Relations are not inherently directional
A t bl bit il j i it l ith• A table can arbitrarily join its columns with
columns of other tables (not just those keyed
to)
– Transition by joining tables together through
joins/foreign keys



Relationships in Database
Denormalized table
• Record repeated in same table each time capturing• Record repeated in same table, each time capturing
different relationship data.
– Foreign keys
• Follow identifiers to related records on other tables
– Join tables
• Tables specifically setup to maintain a relationship pyp p
between two identities (usually for M:M)
– Ad hoc joins in a query
• Arbitrary joins between columns relating data


Relationships in Java
For ‘Many’ side, Collections API
– Set
• No duplication allowed• No duplication allowed
• Objects organized with or without order
– Map
• Duplicate values allowed using different keysDuplicate values allowed, using different keys
• Can be organized with or without order
– List
• Duplication allowedDuplication allowed
• Objects expected to be organized in an order
– Arrays
• Duplication allowed
• Objects expected to be organized in an order
• Strongly typed to particular object type, and lacks ability to resize



Relationships in Database
Denormalized Table
P– Pros
• Very fast
• Easy to query against
– Cons
• Contains redundant data
• Requires many nullable columns

Foreign Keys
P– Pros
• Reduce redundancy
• Better modeling of data
– Cons
• Slower than denormalized table
• Slightly more complicated to query against

Join Tables
Pros– Pros
• Built on foreign key model, enables many:many relationships
– Cons
• Slower yet and even more complex querying

Joins
– Pros
• Allows for any possible query a user can think of without having
to predefine the requirements in the schema design
C– Cons
• No model enforcement
– Can join ‘age’ and ‘office floor’ columns – but does it make sense?
• Can be complicated/confusing to write; results may not appear
as desired



Java-to-Database Through Hibernate

Association & Collection mapping tags practically identical
Hibernate Collection Types

-<set>
• Unordered/Ordered, requiring value column
– <map>
• Unordered/Ordered, requiring key and value
lcolumns
– <list>
Ordered requiring an index column on the• Ordered, requiring an index column on the
referenced object table
– <array>
• Map to Java Type and Primitive Arrays• Map to Java Type and Primitive Arrays
• Ordered, requiring an index column on the
referenced object table
– <bag>
• No direct implementation available in Java
• Unordered/ordered collection allowing duplicatesUnordered/ordered collection allowing duplicates
• Realized through Collection/List
• Requires value column
idb– <idbag>
• Used for many-to-many relationships
• Same as Bag but with additional identifierSame as Bag, but with additional identifier
column used for surrogate keys
• Requires an ID Generator just like Entity classes



03-hibernate-Association_and_Collection_Mapping
http://courses.coreservlets.com/Course-Materials/hibernate.html



  • Building a Hibernate Application

Define the domain model
2. Setup your Hibernate configuration
– hibernate.cfg.xml
3 C t th d i bj t i fil3. Create the domain object mapping files
– <domain_object>.hbm.xml
4 Make Hibernate aware of the mapping files4. Make Hibernate aware of the mapping files
– Update the hibernate.cfg.xml with list of mapping files
5 Implement a HibernateUtil class5. Implement a HibernateUtil class
– Usually taken from the Hibernate documentation
6. Write your code


02-hibernate-A_Simple_Example
http://courses.coreservlets.com/Course-Materials/hibernate.html




  • N-Tier Architecture


Application is made up of layers or tiers
– Each layer encapsulates specific responsibilities
– Enables changes in one area with minimal impact to other
areas of the applicationareas of the application

• Common tiers
– Presentation
• ‘View’ in model-view-controller
• Responsible for displaying data only.  No business logic
Service– Service
• Responsible for business logic
– Persistence
• Responsible for storing/retrieving data


01-hibernate-Introduction_to_Hibernate
http://courses.coreservlets.com/Course-Materials/hibernate.html




  • impedance mismatch

The object-relational impedance mismatch is a set of conceptual and technical difficulties that are often encountered when a relational database management system (RDBMS) is being used by a program written in an object-oriented programming language or style; particularly when objects or class definitions are mapped in a straightforward way to database tables or relational schema.


Mismatches

Object-oriented concepts
Encapsulation
Object-oriented programs are designed with techniques that result in encapsulated objects whose representation is hidden. Mapping such private object representation to database tables makes such databases fragile according to OOP (object-oriented programming) philosophy, since there are significantly fewer constraints for design of encapsulated private representation of objects compared to a database's use of public data, which must be amenable to upgrade, inspection and queries

Accessibility
In relational thinking, "private" versus "public" access is relative to need rather than being an absolute characteristic of the data's state, as in the OO model. The relational and OO models often have conflicts over relativity versus absolutism of classifications and characteristics.


Interface, class, inheritance and polymorphism
essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems


Mapping to relational concepts
Data type differences
A major mismatch between existing relational and OO languages is the type system differences. The relational model strictly prohibits by-reference attributes (or pointers), whereas OO languages embrace and expect by-reference behavior. Scalar types and their operator semantics are also very often subtly to vastly different between the models, causing problems in mapping.

For example, most SQL systems support string types with varying collations and constrained maximum lengths (open-ended text types tend to hinder performance), while most OO languages consider collation only as an argument to sort routines and strings are intrinsically sized to available memory. A more subtle, but related example is that SQL systems often ignore trailing white space in a string for the purposes of comparison, whereas OO string libraries do not. It is typically not possible to construct new data types as a matter of constraining the possible values of other primitive types in an OO language.



Structural and integrity differences
Another mismatch has to do with the differences in the structural and integrity aspects of the contrasted models. In OO languages, objects can be composed of other objects—often to a high degree—or specialize from a more general definition. This may make the mapping to relational schemas less straightforward. This is because relational data tends to be represented in a named set of global, unnested relation variables

Manipulative differences
The relational model has an intrinsic, relatively small and well defined set of primitive operators for usage in the query and manipulation of data, whereas OO languages generally handle query and manipulation through custom-built or lower-level, case and physical access path specific imperative operations


Transactional differences
relational database transactions, as the smallest unit of work performed by databases, are much larger than any operations performed by classes in OO languages




Solving impedance mismatch

Minimization
There have been some attempts at building object-oriented database management systems (OODBMS) that would avoid the impedance mismatch problem. They have been less successful in practice than relational databases however, partly due to the limitations of OO principles as a basis for a data model

Alternative architectures
The rise of XML databases and XML client structures has motivated other alternative architectures to get around the impedance mismatch challenges. These architectures use XML technology in the client (such as XForms) and native XML databases on the server that use the XQuery language for data selection. This allows a single data model and a single data selection language (XPath) to be used in the client, in the rules engines and on the persistence serve



http://en.wikipedia.org/wiki/Objecwt-relational_impedance_mismatch



  • Inheritance is one of the most visible facets of Object-relational mismatch. Object oriented systems can model both “is a” and “has a” relationship. Relational model supports only “has a” relationship between two entities. Hibernate can help you map such Objects with relational tables. But you need to choose certain mapping strategy based on your needs. 



1. Map one table per concrete class. Your mapping ignores the inheritance relationship and maps one table per concrete class. (implicit polymorphism)

2. Map one table per concrete class with union-subclass mapping. You still have one table per concrete class, but you use a “union-subclass” clause in your mapping. This helps mitigate some of the problems we will face in the previous strategy.

3. Map one table per class hierarchy. Here your table will have a row for all the fields in the full class hierarchy. You will have a lot of potential null values and you will have a discriminator column to hold type information.

4. Map one table per subclass. Here you convert the object oriented “is a” relationship into a relational “has a” relationship using foreign keys.


http://simsonlive.wordpress.com/2008/03/09/how-inheritance-works-in-hibernate/




  • inheritance models in Hibernate and describes how they work like vertical inheritance and horizontal



1. Table per concrete class with unions
2. Table per class hierarchy(Single Table Strategy)
3. Table per subclass
(omitting implicit polymorphism which is table per concrete class)


Example:
Let us take the simple example of 3 java classes.
Class TwoWheelerVehicle and FourWheelerVehicle are inherited from Vehicle Abstract class


1. Table per concrete class with unions
In this case there will be 2 tables
Tables: TwoWheelerVehicle, FourWheelerVehicle[all common attributes will be duplicated]

2. Table per class hierarchy
Single Table can be mapped to a class hierarchy
There will be only one table in database called 'Vehicle' that will represent all the attributes required for all 3 classes.
But it needs some discriminating column to differentiate between TwoWheelerVehicle and  FourWheelerVehicle;


3. Table per subclass
In this case there will be 3 tables represent TwoWheelerVehicle , FourWheelerVehicle and Vehicle



There are three possible strategies to use.
    Single Table Strategy,
    With Table Per Class Strategy,
    With Joined Strategy




http://www.dineshonjava.com/p/implementing-inheritance-in-hibernate.html#.UfoIF11jG70





  • There can be three kinds of inheritance mapping in hibernate


1. Table per concrete class with unions
2. Table per class hierarchy
3. Table per subclass

Example:
We can take an example of three Java classes like Vehicle, which is an abstract class and two subclasses of Vehicle as Car and UtilityVan.

1. Table per concrete class with unions
In this scenario there will be 2 tables
Tables: Car, UtilityVan, here in this case all common attributes will be duplicated.

2. Table per class hierarchy
Single Table can be mapped to a class hierarchy
There will be only one table in database named 'Vehicle' which will represent all attributes required for all three classes.
Here it is be taken care of that discriminating columns to differentiate between Car and UtilityVan

3. Table per subclass
Simply there will be three tables representing Vehicle, Car and UtilityVan


http://www.interviewjava.com/2007/10/explain-different-inheritance-mapping.html



  • Hibernate Object Lifecycle


hibernate considers objects it can
tl bi ffmanage to always be in one of four
states
Transient– Transient
– Persistent
– Removed
– Detached


Transient State
All objects start off in the transient
ttstate
– Account account = new Account();
• account is a transient object
Hibernate is not aware of the object
instance


Persistent State
Hibernate is aware of, and managing, the object
This is the only state where objects are saved to the
database


Persistent State
Session session =
SessionFactory getCurrentSession();SessionFactory.getCurrentSession();
// ‘transient’ state – Hibernate is NOT aware that it exists
Account account = new Account();Account account  new Account();
// transition to the ‘persistent’ state. Hibernate is NOW
// aware of the object and will save it to the databasej
session.saveOrUpdate(account);
// modification of the object will automatically bejy
// saved because the object is in the ‘persistent’ state
account.setBalance(500);
// it th t ti// commit the transaction
session.getTransaction().commit();


Removed State
A previously persistent object that is
deleted from the database
– session.delete(account);



Detached State
A persistent object that is still referenced
after closure of the active sessionafter closure of the active session
– session.close() changes object’s state from persisted to
detached


Saving Changes to the Database
Session methods do NOT save changes to
the databasethe database
– save();
– update();p ();
– delete();
These methods actually SCHEDULE
changes to be made to the databasechanges to be made to the database
Hibernate collects SQL statements to be
issued
Statements are later flushed to the database
– Once submitted, modifications to the database are not
permanent until a commit is issuedpermanent until a commit is issued
• session.getTransaction().commit();



Flushing the Context
Submits the stored SQL statements to
th d t bthe database
• Occurs when:
– transaction.commit() is called
– session.flush() is called explicitly
Before a query is executed– Before a query is executed
• If stored statements would affect the results of the quer



Cascading
Hibernate represents domain object
• Propagate the persistence action not only to
the object submitted, but also to any objects
associated with that object



05-hibernate-Object_Lifecycle_Persistence_and_Session_Management
http://courses.coreservlets.com/Course-Materials/hibernate.html




  • Transactions

Represents a single unit-of-work
All or nothing – either all of the actions get committed or the entire effort fails

Other resources can also participate in• Other resources can also participate in
transactions
– Java Messaging Service (JMS)gg ( )
• Roll back a message if something fails
– Legacy Systems
– Anything that leverages JTS (Java Transaction Service)
• TransactionManager Interface



  • Walked through Query by Criteria (QBC) and Query by 
Example (QBE) querying methods, and learned about the 
core Hibernate classes involved in querying
• Criteria
• Criterion
• Restrictions
• Property
• Order
• Projections


07-hibernate-Querying_QBC_and_QBE
http://courses.coreservlets.com/Course-Materials/hibernate.html


  • three ways of handling inheritance
– Single table per class hierarchy 
• InheritanceType.SINGLE_TABLE 
Tbl i l– Table per concrete entity class 
• InheritanceType.TABLE_PER_CLASS 
“join” strategy where fields or properties that are– join  strategy, where fields or properties that are 
specific to a subclass are mapped to a different 
table than the fields or properties that are pp
common to the parent class
• InheritanceType.JOINED 
MiiHib t’Iliit• Missing Hibernate’s Implicit 
Polymorphism

10-hibernate-JPA.pdf
http://courses.coreservlets.com/Course-Materials/hibernate.html



  • What is Connection Pooling? In many of our applications we need to connect to the database for various purposes such as inset, update , delete and retrieve the data from the DB. For each of these activities the application needs to connect to the database which is expensive in terms of resource as well as time. Instead of connecting to the database each time a user makes a request which requires database operation an application should use a pool of connections. Then each application thread that needs to access the database can request a connection from the pool and returns the same to the pool when all the database operations have been executed. This mechanism is called connection pooling.


Hibernate supports various types of connection pooling mechanisms such as C3P0, Apache DBCP, Proxool. C3P0 is an Open source connection pool that comes bundled with hibernate.


http://www.mindfiresolutions.com/How-to-configure-C3P0-connection-pooling-in-Hibernate-1649.php