Explore topic-wise InterviewSolutions in .

BPMS core is the heart of the BPM. The illustration depicts the BPMS core and its components. 

The Semantic MODULE

The semantic module defines the language semantic (what each word means) and how it will be translated for the process engine's internal structures that are ready to be executed. This module basically contains the essentials to understand the BPMN2 language.

The Process Engine

The process engine is the one responsible for actually executing our business processes. The process engine is in charge of creating new process instances and keeping the state for each of them. Inside the process engine code, the internal structures are defined to represent each activity that is in our process definitions. All the mechanisms that are being used to instantiate these process definitions will execute them as defined in the process engine.

Persistence and TRANSACTIONS

In most enterprise applications, all the interactions must run inside a transaction boundary, and we must deal with different systems, APIs, and designs. Also, we must have a flexible mechanism to define −

• How to handle long-running processes
• How and when we can we store information about the process STATUS and the information that the process is handling
• How and when we need to create, commit, or roll back the process engine transactions
• Which business EXCEPTIONS can roll back or compensate already executed business actions

All the above points are COVERED by persistance and transactions component inside the jBPM.

Audit/History Logs

This module is in charge of giving the user a way to query about how our processes are being executed. This information includes historic information about processes that have already ended and the latest information about the processes that are being executed.

BPMS core is the heart of the BPM. The illustration depicts the BPMS core and its components. 

The Semantic Module

The semantic module defines the language semantic (what each word means) and how it will be translated for the process engine's internal structures that are ready to be executed. This module basically contains the essentials to understand the BPMN2 language.

The Process Engine

The process engine is the one responsible for actually executing our business processes. The process engine is in charge of creating new process instances and keeping the state for each of them. Inside the process engine code, the internal structures are defined to represent each activity that is in our process definitions. All the mechanisms that are being used to instantiate these process definitions will execute them as defined in the process engine.

Persistence and Transactions

In most enterprise applications, all the interactions must run inside a transaction boundary, and we must deal with different systems, APIs, and designs. Also, we must have a flexible mechanism to define −

All the above points are covered by persistance and transactions component inside the jBPM.

Audit/History Logs

This module is in charge of giving the user a way to query about how our processes are being executed. This information includes historic information about processes that have already ended and the latest information about the processes that are being executed.

The FOLLOWING are the Prerequisites to INSTALL jBPM PLUGIN −

• Java 1.5 (or higher) SE JDK
• ECLIPSE 4.2 or any version and the jBPM plugin

As jBPM is written in Java, we will be covering how to add the desired plugins.

The following are the Prerequisites to install jBPM Plugin −

As jBPM is written in Java, we will be covering how to add the desired plugins.

jBPM is a lightweight, open source, fully embeddable PROCESS engine written in Java. Its most notable features are listed below −

• jBPM executes business PROCESSES which are designed using the BPMN 2.0 specifications.
• jBPM can be fully integrated with Eclipse and similar IDEs to provide drag and drop support to create a workflow.
• jBPM has UI tools available to involve business analysts and users right from the design phase.
• jBPM supports persistence and TRANSACTION MANAGEMENT with the help of JPA and JTA.
• One can define custom work item handlers to create a user-defined task which can be used as a component later on for other workflows.

jBPM is a lightweight, open source, fully embeddable process engine written in Java. Its most notable features are listed below −

By definition, a business process is a SEQUENCE of tasks that takes place in a repeatable order, executed by HUMANS and/or systems to ACHIEVE a business goal. It describes the order (using a FLOWCHART) in which a series of STEPS needs to be executed. A business process can significantly improve the visibility and agility of a business logic.

By definition, a business process is a sequence of tasks that takes place in a repeatable order, executed by humans and/or systems to achieve a business goal. It describes the order (using a flowchart) in which a series of steps needs to be executed. A business process can significantly improve the visibility and agility of a business logic.

iBATIS is a Data Mapping tool. Its role is to map the columns of a database query (including a stored procedure) to the properties of an object. If your APPLICATION is based on business objects (including Maps or IDictionary objects), then iBATIS can be a good choice. iBATIS is an even better choice when your application is layered, so that that the business layer is distinct from the userinterface layer.

Under these CIRCUMSTANCES, another good choice would be an Object/Relational Mapping tool (OR/M tool), like HIBERNATE or NHibernate. (Other products in this category are Apache ObjectRelationalBridge and Gentle.NET.) An OR/M tool generates all or most of the SQL for you, either beforehand or at runtime. These products are called OR/M tools because they try to map an object graph to a relational schema.

iBATIS is not an OR/M tool. iBATIS helps you map objects to stored procedures or SQL statements. The underlying schema is irrelevant. An OR/M tool is GREAT if you can map your objects to tables. But they are not so great if your objects are stored as a relational view rather than as a table. If you can write a statement or procedure that exposes the columns for your object, regardless of how they are stored, iBATIS can do the rest.

So, how do you decide whether to OR/M to DataMap? As always, the best advice is to implement a representative PART of your project using either approach, and then decide.

But, in general, OR/M is a good thing when you

1. Have complete control over your database implementation
2. Do not have a Database Administrator or SQL guru on the team
3. Need to model the problem domain outside the database as an object graph.

Likewise, the best time to use a Data Mapper, like IBATIS, is when:

1. You do not have complete control over the database implementation, or want to continue to access a legacy database as it is being refactored.
2. You have database administrators or SQL gurus on the team.
3. The database is being used to model the problem domain, and the application’s primary role is help the client use the database model.

In the end, you have to decide what’s best for your project. If a OR/M tool works better for you, that’s great! If your next project has different needs, then we hope you give iBATIS another look. 

iBATIS is a Data Mapping tool. Its role is to map the columns of a database query (including a stored procedure) to the properties of an object. If your application is based on business objects (including Maps or IDictionary objects), then iBATIS can be a good choice. iBATIS is an even better choice when your application is layered, so that that the business layer is distinct from the userinterface layer.

Under these circumstances, another good choice would be an Object/Relational Mapping tool (OR/M tool), like Hibernate or NHibernate. (Other products in this category are Apache ObjectRelationalBridge and Gentle.NET.) An OR/M tool generates all or most of the SQL for you, either beforehand or at runtime. These products are called OR/M tools because they try to map an object graph to a relational schema.

iBATIS is not an OR/M tool. iBATIS helps you map objects to stored procedures or SQL statements. The underlying schema is irrelevant. An OR/M tool is great if you can map your objects to tables. But they are not so great if your objects are stored as a relational view rather than as a table. If you can write a statement or procedure that exposes the columns for your object, regardless of how they are stored, iBATIS can do the rest.

So, how do you decide whether to OR/M to DataMap? As always, the best advice is to implement a representative part of your project using either approach, and then decide.

But, in general, OR/M is a good thing when you

Likewise, the best time to use a Data Mapper, like IBATIS, is when:

In the end, you have to decide what’s best for your project. If a OR/M tool works better for you, that’s great! If your next project has different needs, then we hope you give iBATIS another look. 

Hibernate and Ibatis both are the persistance FRAMEWORKS.

Hibernate will support for procedure invocations and to run normal sql but it is very difficult to make it possible with a normal developer. Where as iBatis is easy to develop and easy to call procedures and functions, no need to struggle for MAPPING and other things.

When we have multiple joins and complex queries in the application it will be difficult achieve with Hibernate. But it is very easy to handle in Ibatis.

Hibernate works if we have very well data model is well in sync with object model, because ORM solutions like Hibernate map objects to tables. If Object model is not in sync with the data model, in this case we have to do lot of additional coding and complexities are entering into your application.

When application becoming huge and complex our model starts breaking down.

One size does not FIT all. In such cases i like to use iBatis.

Ibatis MAPS maps results sets to objects. so no need to care about table structures. We can retrive the data the way we want. This solution words very well for stored procedures and works effectively for reporting applications etc…

Hibernate for every query result we should have a corrosponding mapping object. Ibatis we can use Collection objects like Map, List or ArrayList.

Use Hibernate : Your environment is DRIVEN by object model which is sync with data model and object model wants to generate queries automatially. It is bit complex to implement.

Use Ibatis: You have freedom to write your own queries and easy to maintain. Your environment is driven by relational model. You can work on existing and complex scemas. Easy to implement.

Hibernate and Ibatis both are the persistance frameworks.

Hibernate will support for procedure invocations and to run normal sql but it is very difficult to make it possible with a normal developer. Where as iBatis is easy to develop and easy to call procedures and functions, no need to struggle for mapping and other things.

When we have multiple joins and complex queries in the application it will be difficult achieve with Hibernate. But it is very easy to handle in Ibatis.

Hibernate works if we have very well data model is well in sync with object model, because ORM solutions like Hibernate map objects to tables. If Object model is not in sync with the data model, in this case we have to do lot of additional coding and complexities are entering into your application.

When application becoming huge and complex our model starts breaking down.

One size does not fit all. In such cases i like to use iBatis.

Ibatis maps maps results sets to objects. so no need to care about table structures. We can retrive the data the way we want. This solution words very well for stored procedures and works effectively for reporting applications etc…

Hibernate for every query result we should have a corrosponding mapping object. Ibatis we can use Collection objects like Map, List or ArrayList.

Use Hibernate : Your environment is driven by object model which is sync with data model and object model wants to generate queries automatially. It is bit complex to implement.

Use Ibatis: You have freedom to write your own queries and easy to maintain. Your environment is driven by relational model. You can work on existing and complex scemas. Easy to implement.

Yes, But it is called as COMPLETE HYBRID model. If application is already developed in Hiberante and if you want to achieve reporting moduels we can GO for ibatis.But such THINGS never exists in JAVA persistence WORLD.

Yes, But it is called as complete Hybrid model. If application is already developed in Hiberante and if you want to achieve reporting moduels we can go for ibatis.But such things never exists in JAVA persistence world.

• An ORM
  o Does not GENERATE SQL
  o Does not have a proprietary query language
  o Does not know about object identity
  o Does not transparently PERSIST objects
  o Does not build an object cache

Essentially, iBatis is a very lightweight persistence solution that gives you most of the semantics of an O/R Mapping toolkit, without all the drama. In other words ,iBATIS strives to ease the development of data-driven applications by abstracting the low-level details involved in database COMMUNICATION (loading a database driver, obtaining and managing connections, managing transaction semantics, etc.), as well as providing higher-level ORM capabilities (automated and configurable mapping of objects to SQL calls, data type conversion management, support for static queries as well as dynamic queries based UPON an object's state, mapping of complex joins to complex object graphs, etc.). iBATIS simply maps JavaBeans to SQL statements USING a very simple XML descriptor. Simplicity is the key advantage of iBATIS over other frameworks and object relational mapping tools.

Essentially, iBatis is a very lightweight persistence solution that gives you most of the semantics of an O/R Mapping toolkit, without all the drama. In other words ,iBATIS strives to ease the development of data-driven applications by abstracting the low-level details involved in database communication (loading a database driver, obtaining and managing connections, managing transaction semantics, etc.), as well as providing higher-level ORM capabilities (automated and configurable mapping of objects to SQL calls, data type conversion management, support for static queries as well as dynamic queries based upon an object's state, mapping of complex joins to complex object graphs, etc.). iBATIS simply maps JavaBeans to SQL statements using a very simple XML descriptor. Simplicity is the key advantage of iBATIS over other frameworks and object relational mapping tools.

• A JDBC Framework
  o Developers write SQL, IBATIS executes it USING JDBC.
  o No more try/catch/finally/try/catch.
• An SQL Mapper
  o Automatically MAPS object properties to PREPARED statement parameters.
  o Automatically maps result sets to objects.
  o Support for getting rid of N+1 queries.
• A Transaction Manager
  o iBATIS will provide transaction management for database operations if no other transaction manager is available.
  o iBATIS will use external transaction management (Spring, EJB CMT, ETC.) if available.
• Great integration with Spring, but can also be used without Spring (the Spring folks were early supporters of iBATIS).