OSGi and JPA Deliver Business Objects to BPM


Multi-part Series:

  1. BPM Integration with OSGI: JAX-RS and JPA
  2. (this article) JPA OSGi Bundle Delivers (Java) Business Domain Objects
  3. JSON Formatted Business Information through DOSGi (JAX-RS ReST Services)
  4. BPM Service and Web-client Consumers for JSON over ReST

Forward

OSGi and JPA provide the means for rapid turn-around on integration features. I won’t deny the fact that there’s still complexity out there swimming beneath our mixed up, legacy back-office systems. But, no matter how complicated the waters may be there is no excuse for avoiding continuous integration.

OSGi encapsulates new code with tight control on version management. Websphere, at the server layer, allows real-time switching between integration bundles. JPA (with annotations and JAXB) makes database integration easy… relatively speaking.

OSGi and JPA Deliver Business Objects to BPM

In context: JPA marshals Java objects between JAX-RS and database.

View from BPM

From a BPM perspective, “business objects” are “java objects”. The relationship, or glue, between the ReST service and everything else below that layer is… technically inconsequential from a business-value perspective (overlooking DBMS properties and performance for now).

A good metaphor is the relationship between your cell phone and a conversation. What’s important is that we’re able to make contact and talk. In terms of relationships and outcomes – the cell-phone itself acts as a bridge. A bridge that’s only noticed when it fails to meet expectations.

Ironically, something that “just needs to work” really MUST work. And here’s the inverse relationship between infrastructure and BPM:

If infrastructure gets noticed then… it’s not getting enough attention!

 

Technical View

Object Relational Mapping (ORM) must be seamless – incurring little to no resistance between business intent and delivered value from services.

Premium qualities include:

  1. Transparency of features and implementation Supports testing. And, if it misses expectations or simply breaks… we need source-code visibility and access.
  2. Fine grain visibility and control for version and configuration management (again) If it breaks… we need to find out where, who, and when. Goal is discrete application of: features, fixes, and reversal of poor configuration or code.
  3. Reasonable and well understood technology Open source typically makes this happen. Meaning that an open/adopted standard brings with it a small army of followers, shared ideas, and ubiquitous documentation.

 

OSGi with JPA Technology and Tools

For this exercise I used both Eclipse and Rational Application Developer (RAD). Eclipse Juno was used for building a deployment for IBM’s new Websphere Liberty server and RAD for Websphere Application server v8.5 (WAS). Both Eclipse (Juno) and RAD incorporated Dali Java Persistence tools though RAD added a few additional features – notably a code generator for Entity Manager.

Eclipse and RAD examples:

Walk-through showing Eclipse Juno with IBM’s Liberty tools. Deployment is Liberty

Walk-through using Rational Application Developer (RAD) v9 beta. Deployment is on Websphere v8.5. This is the most complete (and well-written) tutorial. Includes a JPA test harness and transactions for OSGi. Both Eclipse (Juno) and RAD tools are almost identical. RAD does offer a code generator for “entity manager” – however, the generated code required some slight re-work. See “appendix” (at end-of page) for code listings.

Comments are closed.