article

Abstract

Develop a database web app with a polished User Interface and complex, multi-table business logic with no code, just 15 annotations?  Impossible?? But we need to. Here's how. 

 

Agility / Complexity are business / technology challenges

Convention over Configuration and Scaffolding for database web apps are big steps over starting from scratch.  But it still requires far too much slow and complex coding to deliver deployable apps, with polished User Interfaces and complex, multi-table business logic.

The impact is significant.  At the business level, IT is failing to deliver the agility required to support the business.  Business Users are frustrated - they often envision these apps as scarcely more complex than spreadsheets.  At the technology level, the complexity is eroding the value of the Java ecosystem, as teams are forced to other faster/simpler technologies. 

 

Solution requires full-scale automation

Turning to a new language is undesirable, since it does not preserve the valuable Java ecosystem.  And it does not solve the problem - code is, after all, just code.

A solution requires we move beyond the presumption of code, raising the abstraction level from technology to business, so that building a system is as easy as imagining it.

We can do this by extending 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 it works.

 

Sample Target Application

To make things definite, let's consider a representative database web app.  It has the following database design:

 

The User Interface (shown below) is expected to support:

• Browsing: filtering, multi-column paginated lists, and detail drill down to view related data
• Rich Interface: including groups, tab sheets, ajax interactivity, and advanced controls such as calendars, rich text and images
• Multi-table: Master/Detail (e.g., a Purchase Order with a set of Line Items), with services to Choose referenced data (e.g., the flashlight provides filterable lists to choose the Customer for a Purchase Order). 

Reassigning a Purchase Order to a new Customer requires the application adjust the balances of the old / new customers - raising the topic of complex, multi-table business logic.  Note such logic is transactional.  Business Logic always seems so simple, as summarized on the familiar cocktail napkin.  

 

What makes things tougher is that we need to enforce the logic across a set of Use Cases.  So, beyond the obvious Use Case like Place Order, logic must address:

• paying an order
• unpaying 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
• changing a Line Item price
• re-assigning a Line Item's Product
• and all of our multi-table derivations are governed by constraints, so for example the balance cannot exceed the credit limit

Moreover, each of these 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 begins with Domain Driven Design + Convention over Configuration

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

 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 on the left.

Domain Driven Automation - Presentation Annotations for polished User Interfaces

So OpenXava extends the state of the art by introducing Presentation 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 @DescriptionsList specifies the use of a combo box to choose the Product.

 

 Domain Driven Automation - Business Logic Annotations for complex, multi-table logic

Which brings us to the Business Logic.  ABL uses the exact same annotation-based approach to automate complex multi-table business logic.  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.

Below 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 below.  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 that are handled by the ABL runtime, which locates your logic, analyzes its multi-table dependencies, and executes it in a correct and efficient order.  

While remarkably simple, automation is extremely powerful:

• Reuse is automatic. So, 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:

  

 

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. 

ABL automates Advanced Examples with remarkable power, including

• 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 (how many bolts remain in stock after building n planes?)
• An Allocation of a Payment to a Customer (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.

 

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:

Application Element	Domain Driven Automation	Conventional	Notes
JPA Data Model	150	150
Screen code / html	10	300
Business Logic	5	500

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

While not addressed here, it is important to note that automation does not require sacrifices in performance or extensibility.  It is 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.

 

Summary

So, OpenXava and ABL can enable you to contribute agility so your organization can respond to business change.  As shown above, this entire app took 15 annotations. 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.

To explore these concepts further, click here, including a Tutorial.