OSGi and JPA Delivery Business Objects to BPM
- June 24, 2013
- 0 Comments
[Editor’s note: This is the second in a four-part series of posts that Gary has been kind enough to share. ]
- BPM Integration with OSGI: JAX-RS and JPA
- (this article) JPA OSGi Bundle Delivers (Java) Business Domain Objects
- JSON Formatted Business Information through DOSGi (JAX-RS ReST Services)
- BPM dojo Widget Consumes JSON/ReST Response
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!
Object Relational Mapping (ORM) must be seamless – incurring little to no resistance between business intent and delivered value from services.
Premium qualities include:
- Transparency of features and implementation – Supports testing. And, if it misses expectations or simply breaks… we need source-code visibility and access.
- 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.
- 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:
- Eclipse (Juno) with Websphere Liberty deployment (example and tutorial)
- Rational Application Developer for Websphere Application Server (example and tutorial) [estimated publication date: 6/10/13]