Search This Blog


Friday, April 27, 2012

JDK7: Using join/fork framework in Java

If you have read my previous article about concurrency "(Fork and Join) Java solves the painless parallel programming!" you will get the full understanding and an overall idea about the Fork and Join framework.

Here I will give a workable example on how this framework is working in java 7.

The join/fork framework is an approach that supports breaking a problem into smaller and smaller pieces, solving them in parallel, and then combining the results. The new java.util.concurrent.ForkJoinPool class supports this approach. It is designed to work with multi-core systems, ideally with dozens or hundreds of processors. Currently, few desktop platforms support this type of concurrency, but future machines will. With fewer than four processors, there will be little performance improvement.

The ForkJoinPool class is derived from the java.util.concurrent.AbstractExecutorService making it an ExecutorService. It is designed to work with ForkJoinTasks, though it can be used with normal threads. The ForkJoinPool class differs from other executors, in that its threads attempt to find and execute subtasks created by other currently running tasks. This is called work-stealing.

The ForkJoinPool class can be used for problems where the computation on the sub-problems is either modified or returns a value. When a value is returned, a java.util.concurrent.RecursiveTask derived class is used. Otherwise, the java.util.concurrent.RecursiveAction class is used. In this recipe we will illustrate the use of the RecursiveTask derived class.
Getting ready for lap:

To use the fork/join framework for a task that returns a result for each subtask:
1. Create a subclass of RecursiveTask that implements the computation needed.
2. Create an instance of the ForkJoinPool class.
3. Use the ForkJoinPool class' invoke method with the instance of the subclass of the RecursiveTask class.

How to do it...

This application is not intended to be implemented in the most efficient manner, but is used to illustrate the fork/join task. As a result, on systems with a small number of processors, there may be little or no performance improvement.

1. Create a new console application called ForkJoinExample. We will use a static inner class that is derived from RecursiveTask to compute the sum of squares of the integers in the numbers array. First, declare the numbers array in the main class as follows:

2. Add the SumOfSquaresTask class as follows. It creates a subrange of array elements and either uses an iterative loop to compute their sum of squares or breaks the array into smaller pieces based on a threshold size:

3. Add the following main method. For comparison purposes, the sum of squares is computed using a for loop and then using the ForkJoinPool class. The execution time is calculated and displayed as follows:

4. Execute the application. Your output should be similar to the following. However, you should observe different execution times depending on your hardware configuration:

Sum of squares: 18103503627376
Iterative solution time: 5
Sum of squares: 18103503627376
Fork/join solution time: 23

Notice that the iterative solution is faster than the one using the fork/join strategy.

As mentioned earlier, this approach is not always more efficient, unless there are a large number of processors.

Running the application repeatedly will result in different results. A more aggressive testing approach would be to execute the solution repeatedly under possibly different processor loading conditions and then take the average of the result. The size of the threshold will also affect its performance.

How it works...

The numbers array was declared as a 100,000 element integer array. The SumOfSquaresTask class was derived from the RecursiveTask class using the generic type Long. A threshold of 1000 was set. Any subarray smaller than this threshold was solved using iteration. Otherwise the segment was divided in half and two new tasks were created, one for each half.

The ArrayList was used to hold the two subtasks. This was strictly not needed and actually slows down the computation. However, it would be useful if we decided to partition the array into more than two segments. It provides a convenient way of recombining the elements when the subtasks are joined.

The fork method was used to split up the subtasks. They entered the thread pool and will eventually be executed. The join method returned the results when the subtask completed. The sum of the subtasks was added together and then returned.

In the main method, the first code segment computed the sum of squares using a for loop. The start and stop time were based on the current time measured in milliseconds. The second segment created an instance of the ForkJoinPool class, and then used it's invoke method with a new instance of the SumOfSquaresTask object. The arguments passed to the SumOfSquaresTask constructor, instructed it to start with the first element of the array and end with the last. Upon completion, the execution time was displayed.


The ForkJoinPool class has several methods that report on the state of the pool, including:

getPoolSize: This method returns the number of threads that are started but are not completed.
getRunningThreadCount: This method returns an estimate of the number of threads that are not blocked but are waiting to join other tasks.
getActiveThreadCount: This method returns an estimate of the number of threads executing tasks.

The ForkJoinPool class' toString method returns several aspects of the pool.

Add the following statement immediately after the invoke method is executed:

When the program executes, you will get an output similar to the following:

forkJoinPool: java.util.concurrent.ForkJoinPool@18fb53f6[Running, parallelism = 4, size =55, active = 0, running = 0, steals = 171, tasks = 0, submissions = 0]

1.(Fork and Join) Java solves the painless parallel programming!
2.ForkJoinPool class documentation.
3.Fork/Join Java SE concurrency tutorial.

Saturday, April 21, 2012

Architecture: Modeling & Designing Software Projects Architecture

When I model and design the architecture of software project, first thing I consider is what is the software project type?

My experience in this field of projects architecture has taught me that most applications fails into seven software types, each type has its own technology's, communication patterns, architectural patterns and design steps.

The software categories are:

1. Object oriented Software:
The object-oriented design uses the concepts of information hiding, classes, and inheritance. This results in the design of a sequential object-oriented software architecture, which would be implemented as a sequential program with one thread of control.
2. Client / Server Software.
In these systems, a client is a requester of services and a server is a provider of services. Typical servers are file servers, database servers, and line printer servers. Client/server architectures are based on client/service architectural patterns, the simplest of which consists of one service and multiple clients. This pattern has several variations, which will be described next. In addition, certain decisions need to be considered about the design of client/server architectures, such as whether the server should be designed as a sequential or concurrent subsystem, what architectural structure patterns to use for the design of the client/server architecture, and what architectural communication patterns to use for interaction between the clients and the services.

Also differentiates between a server and a service. A server is a hardware/ software system that provides one or more services for multiple clients. A service in a client/server system is an application software component that fulfills the needs of multiple clients. Because services execute on servers, there is sometimes confusion between the two terms, and the two terms are sometimes used interchangeably. Sometimes, a server will support just one service or perhaps more than one; on the other hand, a large service might span more than one server node. In client/server systems, the service executes on a fixed server node(s) and the client has a fixed connection to the server.
3. Service-Oriented Architecture.
SOA is a distributed software architecture that consists of multiple autonomous services. The services are distributed such that they can execute on different nodes with different service providers. With a SOA, the goal is to develop software applications that are composed of distributed services, such that individual services can execute on different platforms and be implemented in different languages. Standard protocols are provided to allow services to communicate with each other and to exchange information. In order to allow applications to discover and communicate with services, each service has a service description; the service description defines the name of the service, the location of the service, and its data exchange requirements.

A service provider supports services used by multiple clients. Usually, a client will sign up for a service provided by a service provider, such as an Internet, email, or Voice over Internet Protocol (VoIP) service. Unlike client/server architectures, in which a client communicates with a specific service provided on a fixed server configuration, this chapter describes SOAs, which build on the concept of loosely coupled services that can be discovered and linked to by clients (also referred to as service consumers or service requesters) with the assistance of service brokers. This document describes how to design SOAs, how to design services, and how to reuse services.
4. Distributed Component-Based Software.
In the design of software architectures for a distributed component-based software design; the component-based software architecture for the distributed application is developed. The software application is structured into components, and the interfaces between the components are defined. To assist with this process, guidelines are provided for determining the components. Components are designed to be configurable so that each component instance can be deployed to a different node in a geographically distributed environment.

Components are initially designed using the subsystem structuring criteria. Additional component configuration criteria are used to ensure that components are indeed configurable – in other words, that they can be effectively deployed to distributed physical nodes in a distributed environment.
5. Concurrent Real-Time Software.
The real-time software is a concurrent architecture usually, having to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control.

Real-time software architectures are concurrent architectures that usually have to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control. Thus, the design of finite state machines, state-dependent interaction modeling, and the control patterns, are very important in the design of real-time software architectures.
6. Software Product Line.
It is architectures for families of products that need to capture both the commonality and variability in the family.

A software product line (SPL) consists of a family of software systems that have some common functionality and some variable. Software product line engineering involves developing the requirements, architecture, and component implementations for a family of systems, from which products (family members) are derived and configured.

The problems of developing individual software systems are scaled upwards when developing SPLs because of the increased complexity due to variability management.

As with single systems, a better understanding of a SPL can be obtained by considering the multiple views, such as requirements models, static models, and dynamic models of the product line. A graphical modeling language such as UML helps in developing, understanding, and communicating the different views. A key view in the multiple views of a SPL is the feature modeling view. The feature model is crucial for managing variability and product derivation because it describes the product line requirements in terms of commonality and variability, and defines the product line dependencies. Furthermore, it is desirable to have a development approach that promotes software evolution, such that original development and subsequent maintenance are both treated using feature-driven evolution.
7. Framework Software.
A software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API). It is a universal, reusable software platform used to develop applications, products and solutions.

Software Frameworks include support programs, compilers, code libraries, an application programming interface (API) and tool sets that bring together all the different components to enable development of a project or solution.

Frameworks contain key distinguishing features that separate them from normal libraries:

7.1. Inversion of control - In a framework, unlike in libraries or normal user applications, the overall program's flow of control is not dictated by the caller, but by the framework.

7.2. Default behavior - A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops.

7.3. Extensibility - A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality.

7.4. Non-modifiable framework code - The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.
Last thing is very important should be considered when architecting any project. It is Non-Functional requirements and should be taken into consideration when designing such software types from the modeling and design stage not when implementing the project.

In my architecture document I called it Software quality attributes.

Software quality attributes:
Refer to the nonfunctional requirements of software, which can have a profound effect on the quality of a software product. Many of these attributes can be addressed and evaluated at the time the software architecture is developed. Software quality attributes include maintainability, modifiability, testability, traceability, scalability, reusability, performance, availability, and security.

Some software quality attributes are also system quality attributes because they need both the hardware and software to achieve high quality. Examples of these quality attributes are performance, availability, and security. Other software quality attributes are purely software in nature because they rely entirely on the quality of the software. Examples of these quality attributes are maintainability, modifiability, testability, and traceability.

Wednesday, April 11, 2012

JPA: Dynamic search builder, the power of annotation, reflection and generics.

JPA (Java persistence API) is a powerful tool for domain objects mapping, and object oriented view perspective of database.

Always I used to use JPA in my projects, but JPA2 introduces extra feature that facilitate the generic way of persisting, merging, deleting and searching. Also introduces dynamic criteria API, which I was looking for.

But with time I have to change the dynamic query or do it myself or else to create new dynamic one which the panic way.

I need a component to search dynamically based on passed object attributes value, and not changed by the time.

For example if I have Bank that has (id, name, address, and state object), and I have created a bank object with name and address has values construct the JPQL SELECT statement (SELECT b FROM Bank b where = :name AND b.address = :address) and search by it and so on.

I have developed a component to implement the above case called DynamicQueryBuilder with advanced techniques, and configurations.

In this article I will describe how I built this component with support of annotation, reflection and generics. In the code snippets you will find a brief description about each line of code and methods, the annotation developed to support the component and I will describe also the overall functionality of the component and how to call it to work dynamically…