Openxava ABL Video


The sections below are a transcript of the video at right.

You can 

  • translate this page if your native language is not English, and

  • use the hyperlinks to explore these concepts further

  • get more insight by using this Tutorial based on this same example



Requirements

We begin with the familiar cocktail napkin requirements spec.  We need a database web app - the familiar Customer, Purchase Orders, Line Items and Products.





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).


But Business Users see things a bit differently. They see this as just barely more complicated than a spreadsheet, so expect business results in hours.

Openxava and AB

At Openxava and ABL, we ask - why can’t it be as simple and fast to build an application as it is to imagine it?

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...


Openxava Domain Objects

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...

Openxava Default Application

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.


Great Start

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.


Customized UI

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

  • Grouped Customer Attributes, and

  • Tab Sheets for Purchase Orders and Audits. 

Opening a Purchase Order, the diagram below shows that 

  • The Line Item List now contains the Product Name

  • The Edit Line Item form provides a Combo Box to choose the Product

  • Also, note the tab sheet for the Notes, a Purchase Order attribute rendered by a rich text editor.

  • Finally, note that the Purchase Order also displays the joined Customer data, via the ReferenceView annotation enabling it to show a designated subset of Customer attributes

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?

Business Logic Annotations

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.

.

Business Logic Execution

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.

  • If we pay an Order, the system will recognize the dependency from the Customer’s balance, so it adjusts the balance.

  • If we delete an Order, the same dependency again adjusts the balance.

  • These dependencies chain over multiple tables in a natural way. If we choose a different Product, the system recomputes the Line Item amount, which adjusts the order total, which in turn adjusts the customer’s balance.

  • And finally, if we try to alter the quantity improperly, we see that our derivation results are governed by our constraints, resulting an error message (this is easily customized).

Logic Operation

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.

Declarative Logic means...

We characterize logic as declarative, often described as “what” vs. procedural “how”. To be a bit more specific, declarative has some very important implications:

  • Reuse is automatic. So, as we saw in the demo, logic imagined for place order is automatically re-used for delete order, pay order and so forth.

  • Optimizations are also automatic. For example, the customer balance is computed by 1 row adjustment updates, avoiding the geometric reads of all the orders and the related line items. And logic is pruned to eliminate database overhead - changing the order Notes does not activate adjustment logic.

  • Finally, ordering is automated, based on automatic dependency analysis. So, for maintenance, you simply change the logic - no more archaeology to decipher the ordering of a previous implementation.

Business Value

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.

We encourage you to download the product, and review the Evaluation Guide.

Comments