BPM Integration with OSGi: JAX-RS and JPA


Multi-part Series:

  1. (this article)  BPM Integration with OSGI: JAX-RS and JPA
  2. 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

Why Integrate BPM with OSGI?

… Because it’s one of the best technologies available today for managing SOAP and ReST services:

  1. Very well contained and managed components
  2. Deployments never require a server restart
  3. Strong version control (Websphere also provides a console for on-the-fly version switching between deployments)
  4. Dovetails into Service Component Architecture (SCA)

What this means… basically, is that I worry less when enforcing OSGi technology requirements for BPM integration adapters and resource providers. Additionally, better encapsulation and version control means MORE deployments. And “more deployments” clears the path for agile methodology. Leading both BPM and integration teams towards a perfectly amicable relationship while struggling to keep up with the constantly changing demands of value-driven development.

BPM Integration with OSGi: JAX-RS and JPA

Process and UI implementation examples are from IBM’s BPM. I chose Websphere Server and Rational Application Developer (RAD) because IBM uses Aries Blueprint, openJPA, and SCA. Websphere also nicely encapsulates OSGI deployments from each other to help avoid potential collisions between bundles. And this is an important feature given that I chose to use CXF’s DOSGI as the JAX-RS implementation.

I also have an earlier version of this OSGI demonstration using Websphere Liberty. And, I did manage to get everything working… except for DOSGI (swapping out CXF for Wink). For Wesbsphere Server though… CXF’s DOSGI was just too irresistible a feature to leave behind. I’ll reference both Websphere and Liberty implementations to show the difference.

Platform and tools include:

  • Rational Application Developer – for building and deploying OSGI bundles for Websphere
  • Eclipse (Juno) – for building and deploying OSGi bundles for Websphere Liberty
  • Websphere Application Server – server platform
  • Websphere Liberty – server platform used for demonstrating Eclipse (Juno) tools
  • IBM-BPM – Business Process development and hosting environment

We’ll first start at the ORM/database layer with JPA object mapping before working our way up through JAX-RS.

Next: JPA OSGi Bundle Delivers (Java) Business Domain Objects

 

 

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.

ESXi 5.1 Server

My new ESXi (5.1) server:

This will help with pending research for 2013

 

NOTES:

Reasons behind going with the Xeon-E3 CPU (instead of Xeon-E5 or AMD-G34 ) :

  1. Price… E5 CPUs are “premium” priced. The E5 did more than required (don’t need x16 PCI-e, nor 8 DIMM slots). Why pay the premium price for unused features? A fast E3 appeared to cover CPU/processing requirements. And, a good SuperMicro board provided sufficient PCIe slots (2 @ 8x and 2 @ 4x)
  2. Following apparent standards. Though I wanted a AMD-G34… (quad memory channel, reasonably priced, etc.), most of my clients have Xeon servers. I needed something “standard” for testing/benchmarks.
  3. Though preferring dual CPU server motherboards – the E3 doesn’t support 2x configuration. And, the 2  x E5 setup is too expensive given all that extra horsepower just sits idle most of the time. I also wanted something that doesn’t heat up the office during the summer.
  4. Saving $$$ with the E3 supported rationalization for the more expensive RAID controller. The bottleneck on this server WILL NOT be I/O! The new RAID controller is fast. I’ll also be adding a 2x Intel Gigabit NIC for network pass-through (though motherboard does have two adapters).

Configuration

ESXi:
5.1.0

Motherboard:
Supermicro X9SCM-IIF-O
BIOS version: R 2.0a (shipped with current) – NOTE: VT-d is turned “off” by default (switched this “on” via BIOS-config)

CPU:
Xeon E3-1270 V2 3.5GHz

RAM:
4 x Samsung DDR3-1600 8GB/1Gx72 ECC M391B1G73BH0-CK0

RAID:
LSI 9260-8i

Hard Drives:
2 x WD VelociRaptor WD6000HLHX 600GB
2 x WD VelociRaptor WD5000HHTZ 500GB

Case:
LIAN LI PC-7HX Black Aluminum ATX Mid Tower

 

Bench-test
(notice that I missed 4 pins on the power connector? The board booted regardless…)

e3_build

 

 

 

Installed

SuperMicroLianLee

BPM Mobility: Server Architectures Reviewed

Forward

If you haven’t already done so I highly recommend you “tool up” for iOS (iPhone) or Android development. Speaking more on the Android platform with this point, but Android is based on Linux – meaning that the Android “smartphone” is a small, pocket-sized Linux computer. And, behind this tiny, touch-screen UI, we have an event-driven framework suited for wireless IO (communication) and  distributed client (end-user) services. This makes a good fit for BPM mobility as it applies focused, via platform constraints, user-to-process interaction.

So, in warming up to enterprise-scale BPM Mobility, I want to first walk through a few system architectures – this prior to diving into the details of Android computing. Goal being a build-up towards mobile device UI/IO requirements: from current state to future capabilities.

 

BPM Desktop Client: Web-portal, JSP Struts/Tiles

JSP Struts/Tiles Workhorse of BPM (Lombardi)

The portal has been with BPM practically from the very beginning and it exists today mostly in its original form as a jsp STRUTS/Tiles web-application.

Though somewhat dated in its technology, we must give credit as it has been and still is the BPM workhorse: delivering process execution, management, tracking, and reporting to our end-users. However, the portal leaves us wanting. Today’s users require a “rich web” experience – something beyond the reach of traditional architectures (form based: HTTP get/post). And, though the BPM Portal remains unsurpassed in features it simply cannot function as a mobile application.

For example, with the portal loaded into a 10″ tablet web-browser, there are just too many active features and UI elements for reasonable touch-screen interaction. I found myself constantly zooming in for navigation and then back out again to review effects and options. However, dashboard and charting elements do work well when broken out on their own as separate elements.

 

 

 

 

IBM-BPM v751 – Advanced: Dojo, Widgets, ReST API

With BPM 751-Advanced, we now have dojo v1.6, Business Space, and ReST APIs

Business Space enhances end-user experience with iWidgets and supporting dojo infrastructure.  Users now have rich web-applications without the downside of additional overhead costs required for custom in-house web development.

New BPM ReST APIs also opens the door to previously unattainable (within reason) web capabilities. Fully in-browser, JavaScript libraries now have direct access to process management. This leads to better performing web applications with reduced UI-interrupting side-effects caused by (legacy) HTML “post” and “get” operations.

Though very close, I’m not sure that we’re at mobile computing. I need to qualify this however because Business Space runs well on Tablets. The catch is that it requires screen real-estate, network bandwidth, and additional CPU. Honestly, these are negligible on today’s desktop/laptop computers. Even reasonably powerful tablets are fully capable of running Business Space over wifi.

Business Space on a smart-phone though does spot-light a few problems.

Screen real-estate is tight on smart-phones! Slow performance is also noticeable as the phone’s CPU just doesn’t seem to keep up and deliver on the same snappy performance previously experienced on both desktop and tablet execution.

Phones require their own native BPM application.

 

 

Mobile Applications for Mobile Process Management

With Android hosting activity services, external BPM requests flow through ReST APIs

Writing native applications feels counter-intuitive but it’s our only alternative given the constraints and limitations for mobile computing. Moving task services to Android (for example) significantly improves performance. Execution latency and UI “lag” disappear as timings drop into sub-second range.

With local execution, we’re looking at:

  • Reduced IO traffic via local application loading
  • Discrete JSON server requests via ReST APIs.
  • Native (java) run-time execution
  • Local device data-storage. For example, Android includes a database usable for both caching and offline process execution.
  • Local application services. These include: notification, document viewers, contacts, identity, and geo/mapping.

 

 

 

Conclusion

In working towards an architecture suitable for mobile BPM we take into account accompanying constraints and capabilities. We’re on a different path in that we’ve re-focused on building native phone applications.

BPM Task List on Samsung Galaxy S II, Android v2.3.6 (Gingerbread), Dual Core Qualcomm CPU – 1.5GHz

Smartphones require discrete UIs, optimized coding techniques, and light-weight network IO. These challenges though are well worth the investment as mobility advances user-to-process interaction to near-personal proximity.

Acknowledging the tens of millions of new users purchasing smartphones, new expectations are set/re-set on almost a daily basis. Now’s the time to revisit our architecture and build-in these future capabilities.

 

BPM Methods: A Change in Software LifeCycle

 

As in business, BPM projects either produce or fail. And, in varying degrees, BPM honestly tries. Maintaining net-value is an effort of direct participation. To remain relevant… one must keep up with the pack – speed counts. This demands agile, quick development iterations and, consequently, a serious weaning from project fat.  Cutting corners gets us ahead of the game. Knowing when, how, and which ballast to cut throughout keeps us in the game.

Evolution

Focus on the relationship between software development methodology and business success.

The catalyst behind change is our drive towards increasing efficiency. The tools and methods behind process management effectively short-circuits communication channels and re-wires the organization. Brought into focus are traditional gaps in execution between business leaders and software development. Otherwise impeding the flow of evolutionary progress, and spotlighted for what they are, progress forces its way around unnecessary bureaucracy.

Obvious like highway congestion and air-travel delays – we need change. It’s our impatience. It’s nearby, within reach, and forces itself as matter-of-fact: keep up or be left-behind.

 

A Spotlight on Bureaucracy: Tradition

“There are protocols that must be followed, regardless of their cost or waste.”

Let’s take a look at a more traditional methodology.

The Business Owner communicates values to our Requirement Analyst who, in turn, produces documentation which is then, in turn, handed over to the Process Architect.

Process models flow into software which then become rooted within operations via services (SOA) and general integration architecture.

The “playback”, or software demo’, provides a theater where our Business Owner communicates direction back into the next cycle. Iterations repeat until we find usability.

In theory we have a fairly good working methodology. In practice we do not.

 

Short-circuit Communication and Evolve

No barriers. No handoffs. One team.


Our new model has the Business Owner working directly with the Process Architect.

Reasons:

  • Direct communication between Business Owner and Process Architect is simply more efficient. This efficiency produces working, executable process in a fraction of the amount of time that would have otherwise been spent on traditional, time intensive, requirements documentation and review cycles.
  • As business feedback (aka requirements) now flow directly into development there’s neither room nor slack for misunderstanding.
  • Reduction in administrative overhead (requirements documentation) allows shorter iteration cycles and early delivery.

 

Business Value

Work occurs with the immediacy of market conditions.

Value-driven methods and purpose force efficiency. From the Business Owner’s perspective, “value” is executing process:

  • Strong User Interface
  • Valued Process Outputs
  • Supporting Services
  • Shows Strategic Direction while supporting tactical agility

We now understand the nature of process development. BPM projects DO NOT build systems because “systems” lack context – technology isn’t the point. The effort behind building “systems” is as irrelevant as attempting to build a house before its blueprint… more so even before understanding the intended home owner’s perspective. The best approach then is to isolate our system builders – take them out of the picture.

 

Irrelevance

Those who once lead must now follow

Removing system builders removes distraction. Without this distraction we’re able to maintain business alignment and, consequently, remain focused on business process development.

So what does a roomful of system builders do when left on their own? They build an irrelevant system.  Frequent the result of specialized teams is competing effort – things created, with good intent (we hope), that offer much less support as interference.

We’re left with a dichotomy.

Our goal still focused on business process and yet diplomacy plays in as a key strategic requirement? Though completely outside the scope of process development, “change management” (politically correct term) is none-the-less required.

 

Rebuild The Team

NEXT WEEK’S PREVIEW…  (to be continued)

The best solution here is to break these specialized teams apart and reassemble as cross-functional units (aka “pods”). We keep our specialized skills, such as QA and integration, while maintaining orientation on process development.

As a BPM effort we have “process” goals on our plan. Competing milestones no longer receive management’s attention. Goals become aligned and focused on process development iterations.

New Mobile Workstation: i7 2630QM

Wanted to share these specifications as there will be some future entries proofed on this configuration:

Laptop: ASUS N53 Series N53SV-XV1 Intel Core i7 2630QM

  • Win7-64 Professional, SP1 (Host Operating System)
  • Crucial M4 256GB SATA III Solid State Drive (SSD)
  • 4 x G.SKILL 4GB 204-Pin DDR3 SO-DIMM DDR3 1333 (16GB total)
  • VMWARE: v8
  • Guest OS: RHEL 5.5.x (RedHat Enterprise v5.5x)

 

NOTES:

This laptop is easily 2x faster than my previous ASUS  i7 620M(2.66GHz). Key differences are 4 vs 2 core i7 and the new Crucial SSD. The new SSD reads at 415MB/s (average… peaks at 500BM/s) and writes at 260MB/s. This means that, for instance, I installed a local copy of Websphere 7 in less than 2 minutes! I didn’t time profile creation but it took much less than than anticipated. Installation and profile creation were so fast that had I though they exited early with an exception.

VM RHEL is also easly 2x faster on this laptop. Instance start/stop/pause executes much more quickly. The next key test is to see how the batteries hold-out during air-travel.

 

Surviving BPM and a Lesson on Racing

The image is getting across the finish line in less-than-optimal conditions. As first-timer BPM projects go, let’s think of engine smoke and a hopeful driver.

I need to remind myself on this point: not everything lands in one piece when focused on winning. Vision is just about everything in this race. Parts wear out, pieces come unglued, bad stuff happens. There will be lots of failures along the way. As BPM does it most certainly will test your infrastructure – weakness points itself out by design and discoveries as painfully obvious as a flat tire and engine smoke… these will show themselves. There’s no avoiding weakness on a BPM project. It’s better to understand limitations both going into and during the race. These can be fixed. The end-goal however cannot be un-done. We either win or lose – never forget the vision. Winning may not be graceful but there’s always a thousand reasons and rationalities for losing. Stay focused, save the apologies, and stow the complaints. We’re in this race until it’s over.

Ironically the race is between “us” on big, enterprise BPM projects. We only need to cross the finish line to win!

On The Direction of IBM’s Business Process Manager – Advanced

Quick Forward: In keen interest of fewer keystrokes-per-noun, I’ll refer to IBM Business Process Manager Advanced as “iBPM”.

Think of a phat buffet – a Las Vegas buffet. All good – yes? This is iBPM Advanced: a nicely packaged collection of deep technologies spanning light-weight dojo widgets, through aggregation and hosting platforms, and on into security and high-availability.

My first impression, though honestly skeptical, is good. We’re looking at the result of serious thinking and efforts on software tools and frameworks for building out and maintaining sustainable Business Process Management.

The individual pieces within iBPM are, by themselves, point-solutions. These bits aren’t new… Together though, in their aggregate form, a composite immerges with some voice and resonance as to direction…

An example?

In the BPM space we usually end up wanting and then building several custom web-UIs (pages and widgets). String these pages together and you get a user-facing process with various back-end service integrations. Moving forward – within “corporate client” each business unit has a need and each “need” gets its own: look, feature, and function. Into this mix add the voice-of-reusability. The same web-UI is then tweaked… re-factoring, and so on until we end-up spending more time in polish.

Measuring progress against business value (not building software), BPM projects tend to lose themselves early on low-value platitudes (look-n-feel and reusability) – all good for vision and heated debate but very bad on business. This isn’t to say such topics lack importance. All must be heard…

Now let’s approach the “UI-debate” with a brick… as in building structures – one brick at a time. IBM-BPM Advanced brings in “Business Space” – this technology allows for the use and re-use of “Web 2.0” widgets and functions. Rather than losing ourselves in debate, each end-user (literally) has the tools and building blocks for assembling their own uniquely personalized look-n-feel.

The BPM team can now better specialize and deliver on re-usable components within a framework built for this pattern. The “one-off” solution is over… iBPM Advanced provides a nice framework for us to quickly bridge across a common BPM pitfall. The UI and re-usability debate ends with “drop-in” Business Space (aka Mashup).

New VMWare Workstation is On-line!

The new workstation is on-line!

Overview:

– LIAN LI PC-A70F Black Aluminum ATX Full Tower
– SUPERMICRO MBD-X8DTi-F-O Dual LGA 1366
– PNY VCQFX1800-PCIE-PB Quadro FX 1800
– CORSAIR HX Series CMPSU-1000HX 1000W
– 2 x Intel Xeon E5620 Westmere 2.4GHz 12MB L3
– 2 x Patriot Signature 12GB (3 x 4GB) 240-Pin DDR3 (24GB ram)
– many WD raptor drives… (2 raids, etc.)
– Noctua NH-U12DX 1366 120mm SSO CPU (I don’t like noisy machines)

So Far?

4 VMs (testing clustered servers and DBs):

– Redhat 5, Suse 11, openSuse 11 (FYI: the new KDE desktop is incredible)

Quick Notes (more to follow): Ora 11g, Websphere 6 and 7, clustered servers, IBM/Teamworks (WLE), Messaging, Cloud, ESX

Process Modeling or Software Development (continued)

Which is the best path for building out new process models? Following the path of least resistance is your best bet in most circumstances. There are a few grey areas in this answer which I’ll cover later – the key point is that guidance is focused on rapid turnaround on process models. Advantage being that the sooner your business is hands-on new process models the better your odds on alignment to key values and business advantage.

How do we stay on path?

Process Modeling versus Software Development

Avoid Blindly Following Software Development Life-Cycle (SDLC) Best Practices

Use only those practices which  deliver on increased efficiencies. Process development is not software development. Process development, though thoroughly taking full advantage of the various components and services flowing out of SDLC, does NOT do SDLC. Process is exempt – reason is that once a process requires, for example, full QA support, it’s slipped into application “mode”. Meaning that your team has fallen into the practice of building-out point solutions as apposed to business process models. A process is not an application.

Measure Process Construction On Its Own Terms

Best example is “on time delivery” and “completeness”. If the BPM team falls behind on delivery, the WORST follow-up is corrective action on old-school software project management (PM) reporting. Seems obvious, from above, not following PM reporting methods on a project not… following SDLC. This is a common experience though – pushing the BPM team into wrong methods and practice via non-sequitur measurements and reporting.

The solution is to track/measure towards (reporting on) alignment to business value and vision. This requires the process model be “played back” (demonstrated) before a live business audience (this is not your QA team). The question is asked and answered, “is this the model you asked for and does it help our business?” Simple measurement on value – we only care about value. And, more importantly, the path towards good process construction demands the capability to discover, deviate, and remain on target – no exceptions to this rule! Success is business value.

Cut Unnecessary Complexity

A tight balancing act in that system architecture and user interface is important… to whom? This is hindsight. I’ve fallen into the trap more often than I care to admit. Situation is that key stakeholders often lack understanding on the problem-at-hand. In lacking clarity the “light” only shines on familiar items and patterns, though with reasonable history, lack application on BPM projects.

Examples are the fancy, if not beautiful user interface (UI), and wonderfully elegant system architecture. This is like speaking Latin. As the tribe (organization) hears what’s understood. And this understanding is unfortunately bound to irrelevant complexity.

There is no solution here – no courseware training, presentations, discussion…

I recommend the BPM team work in isolation and report only to key, knowledgeable business stakeholders. And, if discussion drifts, quickly rein the team – remind them of alignment, vision, and business value. You may need to drop and replace participants – better shift distractions out early rather than bog the project down on irrelevant complexities.