Need to go faster? You can install the completed Tutorial by following these instructions.

Introduction: agility / complexity challenges require automation

Slow, complex coding of database web apps is preventing us from being responsive to the strategic need for business agility.

Indeed, Business Users view such apps as scarcely more complicated that a spreadsheet.

We must ask

Why can't it be as simple to deliver applicationsas it is to imagine them?

This requires we leave behind the presumption of code. We must dramatically extend Convention Over Configuration to Model Driven Automation, where JPA Model Annotations automate polished User Interfaces and complex multi-table business logic in all but the exception cases.

Let's see how!

Target Application

Let's have a quick look at our target - a representative database web app, starting with Part I, the User Interface:

Multi-table: Master/Detail (Purchase Order with a set of LineItems, with joined Product data), with services to Choose referenced data (e.g, the flashlight provides filterable lists to choose a Customer for a Purchase Order).

Consider what the system must then do when a new Customer is chosen - it must adjust the balance of both the old and new customer.

Which brings us to Part II - the business logic - often half the effort in a database oriented application. Summarized by the familiar cocktail napkin, it governs a set of Use Cases. So beyond the obvious Use Case like Place Order, logic must address:

paying an order

deleting an order

reassigning a Purchase Order to a new Customer

adding a Line Item

deleting a Line Item

changing a Line Item Quantity

re-assigning a Product

And all of our multi-table derivations are governed by constraints, so for example the balance cannot exceed the credit limit.

Moreover, each these of Use Cases goes well beyond JSR-303 single-attribute validations. They are complex multi-table transactions, involving multi-table derivations that must be ordered and optimized. Such multi-table requirements often lead to a complex service layer. For example, re-assigning a Line Item's product requires we recompute the partPrice, the amount, the amountTotal, and the balance - and ensure this is within the credit limit.

Domain Driven Automation

So, how does Domain Driven Automation enable us to build such an application?

Domain Driven

Automation starts with a Domain Driven Design. To leverage Java, we express this as a standard JPA Model - a set of annotated Domain Objects (POJOs), such as Customer, Purchase Order and so forth. We have used Groovy since it eliminates the accessors and makes the model quite apparent. You can also use Java.

Click the thumbnail at right to see the detail.

Convention over Configuration

From just this model, OpenXava employs Convention over Configuration to build a complete web application. This requires no code, no code generation, not even html/jsp files. The entire app is derived from the model.

But, it is not a polished application. Users would expect to see groups and tabs, rich text, images, and better presentation / choosing of related data.

Automate Presentation from Annotations

So OpenXava extends the state of the art by introducing annotations, used to automate the entire application we saw above. For example, this Purchaseorder @View annotation defines the groups and tab sheets presented on the Purchaseorder form. The @ListProperties annotation defines the content of the lineitems list, and the Lineitem @DescriptionsList specifies the use of a combo box to choose the Product.

Automate Complex Business Logic From Annotations

For the Business Logic, ABL uses the exact same annotation-based approach to automate complex multi-table transactions. In fact, the annotations correspond exactly to the cocktail napkin we saw above.

We declare a Logic class for each Domain Object. The Logic classes are shown - in their entirety - below. 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 itself derived as the sum of the Line Item amounts, which is the quantity times the Products’ price. Complex Business Logic - chained, multi-table derivations.

And that’s it - our annotations correspond exactly to our cocktail napkin - executable requirements. No code, in fact, more like the spreadsheet our Business User had in mind.

Architecture

The basic architecture is shown here. You simply supply your annotations for presentation and business logic. OpenXava uses these to automate the complete User Interface, using the JPA Model for both meta data (including the annotation extensions) and data access.

JPA updates publish events which are handled by the ABL runtime, which locates your logic, analyzes its multi-table dependencies, and executes it in a correct and efficient order. Event-driven logic enforcement applies to al updates, whether from OpenXava, or from a Services layer.

While remarkably simple, automation is extremely powerful:

Reuse is automatic. So, as we saw in the demo, logic imagined for place order is automatically re-used for choose Product, delete Line Item, pay order and so forth. Integrity is automated, since it does not depend on manual programming calls.

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.

Logic is extensible and debuggable using conventional Java/Groovy approaches. It does not interfere with decisions regarding a Service Layer - in fact, it can make your service layer thin by factoring out complex multi-table logic.

Mobile Ready

The higher level of abstraction (business / declarative vs. technology / procedural) enables the same app to be rendered on a mobile platform, without changes:

Perspective

Model Driven Automation is best suited to "in-house" applications where the User Interface must be polished and easy to learn, but need not be "gold plated" for a customer-facing application. For such in-house applications, there is well over an order of magnitude reduction in the scope of the development effort:

Note these raw code counts do not take into account expertise difference, or implications for maintenance effort.

What about Real World complexity?

The example above is designed to communicate the point as simply as possible. But of course, your application will likely contain more complicated requirements, so it's important to understand whether these are addressed.

A Bill of Materials Price Rollup with 4 rules (a bolt is used in a Wing, Engine, etc - how does a price change affect the cost of a plane?)

A Bill of Materials Part Explosion with 3 rules (how many bolts remain in stock after building n planes?)

An Allocation of a Payment to a Customer with 4 rules (which Purchase Orders are paid off, and what is the resulting balance?)

Copy examples, such as auditing or cloning a Purchase Order and its Line Items

ABL logic can be expressed not only in annotation, but also in Java/Groovy methods. There are thus no restrictions on the scope of your logic, enabling you to address enterprise concerns such as application integration.

Summary

So, OpenXava and ABL can make your organization much more agile in responding to business change. As shown above, this entire app took 15 annotations - completely transparent to Business Users. By contrast, the business logic alone required 500 lines of code using a traditional approach for dependency management over multiple User Cases. With Domain Driven Automation, in 20 minutes you can rebuild this entire application (starting with the data model).

It’s very easy to adopt – automation eliminates the complexity of the Java stack while preserving its value, 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 automation results in Enterprise-class applications, with the expected levels of polished User Interface, adherence to standards, automatic integrity, and scalable performance.

Finally, annotations are simple enough to be transparent to Business Users, enabling a new era of partnership between IT and the business.