The sections below are a transcript of the video at right.
We developers know our technology: a few weeks to prepare the pages and controllers, and another couple of weeks to build the service layer to deal with all the multi-table dependencies across all the Use Cases (insert, delete, make ready, re-assign).
So, rather than focusing on improving code, we target its elimination through model-based automation.
So, instead of building a complex set of html pages and controllers, you simply add annotations to a standard JPA model. The Openxava engine uses these to build a complete User Interface - no code generation - using Hibernate/JPA for database access.
Let’s see how...
We have created an Openxava project in Eclipse, using an Ant script. The familiar project structure is visible here on the left.
All we need to do to build our project is to define some JPA Domain Objects, shown on the right. We’ve used Groovy, eliminating the tedious accessors.
So here we see the Customer Domain Object, and the Purchase Order Domain Object, with annotations defining their attributes, relationships, and database mappings (for the moment, imagine this without the presentation annotation such as shown Customer line 15-17 or Purchaseorder line 47 - we'll discuss these in just a moment).
And that’s all we do...
To get this application. You see we have a multi-column List, including capabilities to sort and filter data. The list is paginated, so a large query will not destroy system performance.
Here we see a detail area, including foldable Lists for related Purchase Orders and Audits.
We can click on a Purchase Order to drill down and see its data, including its Line Items. And you can continue on down to edit a Line Item.
So, it’s a remarkable application. All this functionality is built from our default model, which compares very favorably to other “scaffolding”.
But - of course - this is not a polished application.
On the UI, side, we want to better layout - group the fields, use tab sheets. And we want our Line Item List to show Product Names (not numbers), and enable us to choose a Product.
And, we need business logic! We need to compute the Purchase Order / Customer totals, and ensure they don’t exceed the Credit Limit.
The modern way to define models is by Annotations, just as we did for JPA. Openxava provides a rich set of annotations for Presentation, such as the one here that groups Customer Attributes and defines Tab Sheets.
Just defining 7 such annotations, along with a Style Sheet, results in the following very polished User Interface.
Here we see the
Opening a Purchase Order, the diagram below shows that
All this from our annotated Domain Model - no html, no controllers, no code.
And, the technology independence inherent in this approach enables Openxava to render the same app on an iPad:
But what about the Business Logic?
ABL uses exactly the same Annotation-based approach for Business Logic.
As you can see on the left, we declare a Logic class for each Domain. The Logic classes are shown on the right. Let’s look a bit closer.
Here we see the Customer Constraint that the balance cannot exceed the credit limit. The balance is derived as a sum of the related Purchase Order’s amountTotal for unpaid / ready orders.
The amountTotal is itelf derived as the sum of the Line Item amounts, which is the quantity times the Products’ price.
And that’s it - our annotations correspond exactly to our cocktail napkin - executable requirements. No code, in fact, more like the spreadsheet our User had in mind.
Let’s see how our customized UI and our Logic work in execution. The obvious case is creating a new order, but there are other use cases that need to be taken care of also.
So, how does this all work. Well, it's a simple and elegant architecture.
As a Developer, you simply define your Annotated Domain Objects and Logic classes. That’s all we have done here.
The Openxava controller issues updates through Hibernate. The transaction logic engine plugs into the hibernate event model - it finds your business logic, analyzes its dependencies, and executes it in a correct and efficient order.
Note this logic is enforced regardless of the transaction source, so in addition to Openxava applications, you also have the same automated logic for Web Service transactions.
We characterize logic as declarative, often described as “what” vs. procedural “how”. To be a bit more specific, declarative has some very important implications:
So, Openxava and ABL can make your organization much more agile in responding to business change. This entire app took 9 annotations. By contrast, the business logic alone required 500 lines of code using a traditional approach for dependency management over multiple User Cases.
It’s very easy to adopt – automation eliminates the complexity of the Java stack, so you are productive immediately, with a very small learning curve to master the declarative approach. Both products are Open Source. Importantly, the declarative services can be extended using standard Java.
And you get Enterprise-class applications, with the expected levels of polished User Interface, adherence to standards, automatic integrity, and scalable performance.