Wednesday, May 27, 2015

OpenJPA + JNDI Data Source + WebSphere + Oracle 11g

This is a simple example on how to setup a web application which uses OpenJPA on WebSphere v8.0 using a data source provided via jndi. The development environment is Eclipse and Apache Maven. The data source we are using will connect to an Oracle SQL Developer 11g Database using the Oracle Thin Client driver. Code for this can be found at https://github.com/jamie3/openjpa-jndi-websphere.

Pre-Requisites

  1. Eclipse
  2. Oracle SQL Developer 11g or equivalent database
  3. An existing database already setup in Oracle
  4. WebSphere v8.0
This assumes you already have the Data Source created in WebSphere.

Web Application Project

  • Create a new maven project called “openjpa-jndi-websphere" and set its packaging to "war". 
  • Update the pom by adding the following:



<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>openjpa-jndi-websphere</groupId>
  <artifactId>openjpa-jndi-websphere</artifactId>
  <version>1.0</version>
  <packaging>war</packaging>
  

 <properties>
  <openjpa.version>2.2.1</openjpa.version>
 </properties>
 
 <dependencies>
  <dependency>
   <groupId>org.apache.openjpa</groupId>
   <artifactId>openjpa</artifactId>
   <version>${openjpa.version}</version>
  </dependency>
  <dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>servlet-api</artifactId>
   <version>2.5</version>
   <scope>provided</scope>
  </dependency>
 </dependencies>
  
  
  <build>
   
  <plugins>
   <plugin>
    <groupId>org.apache.openjpa</groupId>
    <artifactId>openjpa-maven-plugin</artifactId>
    <version>2.2.2</version>
    <configuration>
     <includes>**/model/*.class</includes>
     <excludes>**/model/XML*.class</excludes>
     <addDefaultConstructor>true</addDefaultConstructor>
     <enforcePropertyRestrictions>true</enforcePropertyRestrictions>
    </configuration>
    <executions>
     <execution>
      <id>enhancer</id>
      <phase>process-classes</phase>
      <goals>
       <goal>enhance</goal>
      </goals>
     </execution>
    </executions>
    <dependencies>
     <dependency>
      <groupId>org.apache.openjpa</groupId>
      <artifactId>openjpa</artifactId>
      <!-- set the version to be the same as the level in your runtime -->
      <version>${openjpa.version}</version>
     </dependency>
    </dependencies>
   </plugin>
  </plugins>
  </build>
  
</project>



Note: Open-JPA Version should be set to 2.2.1 or whatever is provided by your IBM WebSphere container.

  • In the project properties select "Project Facets".
  • Select the WebSphere Web (Co-existence) and (Extended) boxes.



EAR Project

Here we will create the EAR which will allow us to deploy the WAR onto WebSphere.
  • Create a new maven project called "openjpa-jndi-websphere-ear" with packaging "ear".
  • Update the pom with the following:


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>openjpa-jndi-websphere</groupId>
 <artifactId>openjpa-jndi-websphere-ear</artifactId>
 <version>1.0</version>

 <packaging>ear</packaging>
 
 <dependencies>
  <dependency>
   <groupId>openjpa-jndi-websphere</groupId>
   <artifactId>openjpa-jndi-websphere</artifactId>
   <version>1.0</version>
   <type>war</type>
  </dependency>
 </dependencies>

 <build>
  <plugins>
   <plugin>
    <artifactId>maven-ear-plugin</artifactId>
    <version>2.10</version>
    <configuration>
     <version>6</version>
     <defaultLibBundleDir>lib</defaultLibBundleDir>
     <modules>
      <webModule>
       <groupId>openjpa-jndi-websphere</groupId>
       <artifactId>openjpa-jndi-websphere</artifactId>
       <contextRoot>/openjpa-example</contextRoot>
      </webModule>
     </modules>
    </configuration>
   </plugin>
  </plugins>
 </build>

</project>

Setup Data Source in Eclipse

Here we are going to setup the data source in Eclipse which will allow us to connect to the Oracle database and create our JPA Entities later.

  • In Eclipse open the “Data Source Explorer” Perspective.
  • Add a new database connection
  • Select Oracle connection profile. I’m using the Oracle SQL Developer 11g
  • Select Oracle Thin Driver 11g


  • Click the JAR List tab
  • Click  Add JAR/Zip button
  • Select the jar to use (E.g. C:\oraclexe\app\oracle\product\11.2.0\server\jdbc\lib\ojdbc6_g.jar

  • In the Properties section add your connection information.
  • Make sure the connection parameters are valid by clicking the "Test Connection" button.

  • Right click on the project and select “Configure > Convert to JPA Project”.
  • Under JPA Implementation select the Type = Disable Library Configuration. Doing this means you need to use Maven to enhance the JPA entities. If this prompt doesn't appear you can find it by right clicking on the project and selecting "Project Facets".


Create JPA Entities

Here we will create our JPA Entity beans using the Eclipse JPA tooling.
  • Right click on the project and create a new “JPA Entities from Table”




  • On the next screen make sure you select the Oracle connection followed by the schema and tables you want to generate the JPA entity classes. I have a table called sample table.



  • In the "Generate Custom Entities" wizard make sure you enter the "source folder" and "package". I usually put my entity classes in a separate package from all my other classes, in this case openjpa.example.model. Also, my database table has a primary key so I've also selected "identity" as the "Key generator".



  • In my example a file called SampleTable.java was created and also a persistence.xml.
  • Modify the persistence.xml file and add the following

YOUR_JNDI_NAME


In my example the YOUR_JNDI_NAME is "jdbc/myexample". In your case it will be whatever JNDI Data Source you have previously setup in WebSphere. 
  • Also set the transaction-type="RESOURCE_LOCAL" in the .

Create Servlet

Here we will create some Java code such that we can verify JPA is working properly.
  • Create a new Java class



package openjpa.example;

import java.util.List;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import openjpa.example.model.SampleTable;

public class MyServlet extends HttpServlet {

 private EntityManagerFactory emf;

 public void init() throws ServletException {
  super.init();

  System.out.println("Initializing servlet");
  
  this.emf = Persistence.createEntityManagerFactory("openjpa-jndi-websphere");
 }
 
 @Override
 public void destroy() {
  if (this.emf != null) {
   this.emf.close();
   this.emf = null;
  }
  
 }
 
 @Override
 protected void doGet(HttpServletRequest request, HttpServletResponse response) {

  try {
   EntityManager em = emf.createEntityManager();

   System.out.println("Fetching data from database");

   List results = em.createNamedQuery("SampleTable.findAll", SampleTable.class).getResultList();

   response.getWriter().write("Results: " + results.size());
   
  } catch (Throwable t) {
   t.printStackTrace();
  }
  
 }
}


web.xml

  • Create a new web.xml in the src/main/webapp/WEB-INF folder in your openjpa-jndi-websphere project.
  • Update the web.xml with the following:



  <servlet>
    <servlet-name>servlet</servlet-name>
    <servlet-class>openjpa.example.MyServlet</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>servlet</servlet-name>
    <url-pattern>*</url-pattern>
  </servlet-mapping>

Build

  • From eclipse or the command line build the openjpa-jndi-websphere project followed by the openjpa-jndi-websphere-ear project. Basically "mvn install".

Test


Afterwards you can deploy the EAR project onto WebSphere. I've chosen to do this in Eclipse by right clicking on the openjpa-jndi-websphere-ear and selecting "Debug > Debug on Server". This of course requires WebSphere to be setup as a J2EE server in Eclipse.

You can invoke the doGet() method on the MyServlet class by going to the following URL http://localhost:9080/openjpa-example/.

The servlet should query the database and output the results to the web browser.

Thursday, May 14, 2015

My first experiences with Camel and IIB9

This will be a quick post on my first experiences with Apache Camel and IIB9.

Apache Camel is really easy to install. In fact there is no installation required. Instead you simply need to download the camel-core.jar file and start using the API in your code (either manually or using Maven). Of course with Camel this means you need to know Java, and likely other APIs and Frameworks such as Spring, Maven, Eclipse, etc... So a good knowledge of the Java ecosystem is recommended if you are using Camel, but it is not required. I was able to get Camel up in running in less than 5 minutes with a Hello World example when I first used it 7+ years ago, and the process hasn't changed since then.

In comparison, IIB9 consists of many installations (IBM WebSphere MQ, MQ Explorer, IBM Integration Bus, FixPacs, IBM Integration Toolkit, Licenses, Integration Bus Explorer). This is expected because IIB9 is a full ESB. If you were deploying Camel onto an ESB (such as ServiceMix) then obviously you would need to download, install, and configure it as well. Installing ServiceMix is also as simple as downloading the tar file and unpacking it onto your computer. Similarly ActiveMQ if you needed message orientated middleware. Since IIB9 is a licensed product I spent many days downloading and installing the suite of applications. Although the IBM passport site provided everything I needed it was a lot of button clicks and searching for the correct download links. I would recommend if you are downloading this for your team that you host these files on a central Samba server so that other developers don't have to go through the same downloading headaches.

After installing IIB9 I had to create a Queue Manager and Integration Node and server. This is required in order to perform any Integration Bus development, since running the code requires deploying it onto an integration server. In some cases you might only need to install the IBM Integration Toolkit if your IBM Integration Bus and MQ is hosted on a remote server in your IT organization.

A few problems I had with IIB9 was the toolkit used an older version of Eclipse from 2012, which meant that support for many of the new plugins was a bit problematic to install. For example, it took a little while to find and get the EGit plugin working in the toolkit. A hiccup, but not a roadblock by any means.

Developing for the first time...

As a Java developer I personally found Camel to very easy to get started with. Since Camel is just Java code the process was no different than learning other APIs like I have in the past. The Camel website was very simple to navigate and finding tips and tricks on how to develop various routing and mediation logic was as simple as opening up Google, Stack overflow or the Apache Camel website. There are also lots of code examples on Github that can be downloaded.

When starting IIB9 it was fairly easy to get up and running. All I had to do was open the IIB9 toolkit and start drawing my message flows. My issue with IIB9 is that it seems to historically be very ESQL-centric. If you trace the roots of IIB9 back to its origins, I'm guessing that ESQL was used primarily as a platform independent functional language on top of MQSeries Integrator. From my experience when I searched for information on how to implement something in IIB9 it usually provides the coding as ESQL. Unless you are a seasoned ESQL developer you will often find yourself Googling information on how to perform various operations, or trying to figure out the ESQL syntax. You can develop code in Java however it seems most of the online examples and seasoned IIB9 developers are doing it in ESQL. Compare this with Camel which finding a coding example in Java easier since it has a much larger user base. While I do have a good background in other SQL related products (PostgreSQL, MySQL, etc..) I found searching for ESQL stuff to be very frustrating. Search results on ESQL often turned up results on SQL-Server, Oracle, which had no relation to IIB9. Also, there seems to be no books on Amazon specifically related to ESQL on IIB9. So unfortunately I always had to go to the IBM Knowledge base which often times was difficult to dig through finding the example I was looking for. The knowledge center is good but relying on a single resource for help is not always great. Needless to say the MQSeries help forums are very useful and the community is fantastic. Also if you decide to code in ESQL your custom logic will be locked in to IBM and it won't be re-usable if you ever decide to migrate to another integration product. If you code in Java I'm guessing some of that code could be ported over in the future if necessary. However this might not be a concern for some businesses.

One thing I should mention is that from my experience I always find most open source products (especially 100% Java products) to be much more simple to get going than the big players such as IBM, Microsoft, Oracle, etc... But the cons of a simple installation often means you need to spend a lot of time configuring the product to your liking. For example, IIB9 has a lot of security pre-built into it, which can be good for server installs but often a pain in the ass for developers because it often can be too restrictive. A good example of this is when I used Camel with ActiveMQ and subscribed to a JMS Queue, the queue would automatically be created. In comparison in WebSphere MQ out of the box requires you to manually create the queue and configure the authorization and authentication in may cases since security is built-in. So, in conclusion, from my experience, out-of-the-box Camel and the Apache products in general seem to be more developer-centric/friendly than IBM and other big vendors. But this is expected and I wouldn't see this as necessarily a bad thing, just means I need to learn more on these products to become more comfortable with them.

I hope in the next post I can discuss how to develop routing and mediation logic in both Apache Camel and IIB9.

Update - June 18, 2015

I found this post to be very useful on getting started with IIB

https://developer.ibm.com/integration/blog/2015/05/06/ibm-integration-bus-get-started-in-ten-minutes/

Friday, May 1, 2015

The 30,000 foot view of Apache Camel and IBM Integration Bus

This post I will be comparing Apache Camel and IBM Integration Bus. This blog series won't be focused on marketing buzz words but rather it will dive deep into a comparison between the two offerings. Today's blog post will provide a 30,000 foot view from a developers perspective.

Apache Camel

There are lots of descriptions on what Apache Camel is. Here is my take on it...

Apache Camel is an open source Java API consisting of a set of ready-to-use Enterprise Integration Patterns (EIP) that can be configured to execute complex routing and mediation logic to meet a wide variety of business integration needs. For example, splitting a file, or dynamically routing a message based on its content, aggregation, etc. If an EIP is not available custom code can be developer as a Processor. In my experience Camel has been shown to significantly reduce development costs in wide variety of areas such as systems integration.

Camel also provides a set of components that can be configured to interact with 3rd party APIs, systems, and protocols. For example, Camel has a set of components for interfacing with Files, TCP/IP protocol, Amazon Web Services, Java Messaging Service (JMS), JDBC, and more. There are over a hundred components available, and more components are being contributed every year from the community. In my opinion this is where Camel really outperforms all other integration offerings.

If your components consume or produce messages in various formats such as XML, binary, JSON, etc, Camel has really nice support for this using type converters. It can automatically detect when conversion between types is required via a type converter registry. This allows developers to easily convert between various object types with very little effort.

Camel also has a powerful Domain Specific Language (DSL) that can be developed in Java, XML, Scala, Groovy.

Although Camel is not an ESB it can be deployed onto and ESB such as Apache ServiceMix. This allows you to deploy Camel routes across the enterprise or in the cloud. I will talk in more detail later on this.

Camel was invented by James Strachan and has been around since 2007 and the community is rapidly growing. It is currently maintained by Apache and one of their PMCs is Claus Ibsen. Both are really great guys. I've had the pleasure sharing a beer with them at a previous Apache Camel conference.

IBM Integration Bus

I'm fairly new to IBM Integration Bus, so there might be cases where I write statements that could be inaccurate. If I do, please be courteous and let me know in the comments section below so I can make the appropriate corrections.

Here we go...

IBM Integration Bus (IB9) is a full fledged Enterprise Service Bus. IB9 has been around for a long time, originally as MQ Series Integrator, and Message Broker and recently Integration Bus. Wikipedia has more details on its origins and history.

IB9 provides an easy to use and very powerful toolkit which is based on Eclipse that developers can draw message flows to describe their routing and mediation logic. Message Flows contain inputs and outputs. There are a number of out of the box input nodes such as File, HTTP, Databases, FTP, TCP, and more. Message flows can be visualized by teams to help provide context of complex routing and mediation logic which is something that programming code cannot always do.

Similar to Camel, IB9 offers patterns that can be configured to execute complex routing and mediation logic to meet a wide variety of business integration requirements. Custom code can be implementing in a compute node using languages such as Enterprise SQL (ESQL), Java, PHP and .NET.

In addition to patterns, IB9 has a built in support for parsing text and binary data using DFDL and also has a nice tool for mapping data from one XML document to another.

Since IB9 is a full fledged ESB, it allows developers to deploy their routing and mediation logic onto integration nodes which host integration servers across the enterprise. This is an extremely powerful offering as it makes it easy for teams to hot deploy their integration solutions very easily without having to worry about painful class loading issues that driven me mad in IBM WebSphere Application Server. As mentioned, Camel is not an ESB it can be deployed on an ESB such as Apache ServiceMix and other containers. I will touch on this in later posts.

IB9 has seamless integration with IBM WebSphere MQ, which makes it a very attractive offering to people who already use MQ in their business. In fact, from my understanding, IB9 requires MQ Queue Managers as part of its deployment and coordination across integration nodes. So in retrospect its almost required that you need some kind of MQ running in order to use IB9. From my understanding this is not the case in IB10. Like IB9 Camel has seamless integration with Apache  ActiveMQ. Once again this will be part of later discussions.

There are many more features I will discuss about IB9 later on as it is quite comprehensive.

More to come...

In future blog posts I will talk more about Camel and IB9 and how they stack up to each other, while diving deep and comparing their features. I'll try not to be bias but I will certainly offer my opinion on what I like and don't like about each offering and share my experiences on each.

In this series of blog posts I hope to touch on (in no particular order) a wide variety of topics including but not limited to:

  1. Installation & Setup
    1. My first experiences with Camel and IIB9
  2. Documentation
  3. Apache Camel Routes vs IBM Integration Bus Message Flows / Sub Flows
  4. Apache Camel Components vs IBM Integration Bus Input/Outputs
  5. Apache Camel EIPs vs IBM Integration Bus Patterns and Compute Nodes
  6. Apache Camel Tooling vs IBM Integration Bus Toolkit
  7. Apache Camel JVM offering vs IBM Integration Bus ESQL/Java offering
  8. Data Mapping
  9. REST / SOAP
  10. Micro Services
  11. Cloud
  12. Database
  13. Black box, white box, unit testing
  14. Deployment & Migration
  15. Source Control and Versioning
  16. Enterprise Operations & Management
  17. Training & Support
  18. Cost
  19. My personal likes/dislikes
Stay tuned...

Updated May 1, 2015

On a side note. I know Apache Camel and IBM Integration Bus are apples and oranges and many folks will be questioning why I am comparing the two. This is point is really to showcase the differences in how developers use and develop integration solutions on the two offerings. I will try to provide more comparisons of IB9 with Camel and its sister projects such as ServiceMix, ActiveMQ and other open source projects. This will give people a more ESB-to-ESB comparison.