Abstract
Reactive Programming can dramatically increase - even
guarantee - business logic reuse. This can afford remarkable advantages in controlling costs, and increasing quality / time to market. This article reviews the current state of the art, and introduces Business Logic via Reactive Programming.
Business Logic is Critical
Enterprise systems complement mobile and web front ends with ?back ends? that provide database access and enforce integrity. Within the back end, the business logic is a key cost component ? a significant portion of the total effort.
No matter how good the User Interface is, the application can fail if the data has no integrity. Therefore, Business Logic must be correctly implemented and, as this cartoon shows, must also be re-used for efficiency and quality .
Replicating logic sooner or later leads to embarrassment. Re-use is the key.
Let?s explore the major alternatives for implementing and re-using business logic, and how they map into the world of Mobile Apps and REST servers. At the end, we?ll preview some exciting technology that holds real promise for ensuring re-use, and for providing agility.
1. Client Code
It is a well-accepted anti-pattern to enforce business logic in clients (e.g., JavaScript). It has always been a bad idea. It impedes re-use: it is typically impractical to extract business logic code from a client to build a Web Service.
But it?s far worse for mobile apps. Latency is increased by requiring multiple server trips. And, there are major security risks with placing JavaScript logic in mobile devices, where it might be altered or by-passed.
2. Database
A tried-and-true approach is to use database triggers and stored procedures. This is effective, and can perform well by minimizing network traffic.
But there are issues. Mobile apps cannot directly invoke SQL, so you still need a REST server or equivalent. And server-side logic provides other advantages, such as more modern languages (debuggers, etc.), easy access to other services, and are non-proprietary.
And in more practical terms, trigger/Stored Procedure logic is difficult to maintain. It is often not well structured, so understanding what the code is doing becomes a challenge for large projects. And the code can be quite unreadable, resorting to unnatural acts for such simple tasks as determining what columns have changed.
3. Server side Logic ? Domain Objects
Most architects therefore prefer factoring out logic to the server. This makes the data available to web apps, mobile apps, and the Enterprise Service Bus (ESB). The question is: what layer should enforce the logic?
One approach is to place the logic in the service, using Domain Objects just for structure (e.g, attribute accessors). The problem is that this still does not centralize the logic, so it must be replicated (at least in part) in each service.
Domain Objects without logic are a well-documented anti-pattern, which Fowler characterizes as anemic data objects. Fowler argues correctly that the entire point of object oriented design is to encapsulate logic into the domain object, which represents both structure (attributes) and behavior (logic) for reuse.
4. Rich Object Model
A Rich Object Model is the preferred alternative to an Anemic Data Model (often called Active Record). Operating in the Server, this is basically an object for each table, providing data access and logic, resulting in ?thin? services. JavaScript is an increasingly common approach, since it the language all projects must eventually use.
As illustrated above, using an Object Model entails 3 efforts:
- Listeners, JSON conversions - The REST Listeners receive requests and parameters, map JSON objects to Rich Domain Objects, invoke the Domain Objects to read/update the database, translate the Rich Domain Objects back to JSON, and return the REST response.
- Resource/Object Mapping - Services typically don?t (and should not) expose raw data model objects. In the case of REST, properly defined services are exposed through Resources that may project and alias attributes, and combine (join) data from multiple underlying tables. These provide a friendlier API to clients, reduce latency, and can provide a basis for security.
So, there needs to be a layer that maps Resource objects onto underlying domain objects, so that domain object logic can be re-used. This can be tedious.
- Building Objects - An object model, at the very least, enforces the structure of data: the objects, attributes and relationships. It ensures that references are the correct names and types, typically through well-defined accessor methods.
This is where the real work lies. A modest sized object (table) is 150 lines of code for the structure, and the business logic is considerably more. The objects must be kept in sync with changes to the actual database schema.
5. REST Framework Support
Building a Rich Object Model is a substantial undertaking ? significant friction for the developers, repeating this task again and again. Except for the actual logic, the code is boring.
REST Servers can help enormously by automating an Object Model Framework. Such a framework means providing the following services to reduce boring / repetitive code:
- Build Object Model from database schema - Ideally, the REST server constructs a complete data model from the schema, including persistence automation behavior for reading/writing rows, with caching for performance and reliability. Such automation should be ?live?, so that schema changes are reflected automatically (i.e., no need to ?sync? object / data models).
- Resource/Object Mapping - The REST Server should also support Resource definition from objects, with related runtime services to map (de-alias / de-project) Resource objects onto Data Objects to re-use data object logic.
- Object method/event support - Minimal Object Model method support requires life-cycle methods for insert, update and delete. These can be packaged as events or methods, ideally in a commonly accepted language such as JavaScript.
- Old/New Values - The update event/method requires access to old/new values, so it can enforce logic such as the maximum change in a customers? balance.
- Commit-time logic - Finally, the REST server should provide services that enable objects to finalize logic after all updates are processed. This is required for cardinality constraints (?orders must have items?) that cannot be enforced until the end of the transaction.
6. Reactive Programming Logic
REST Server frameworks for business logic enforcement represent the current state of the art. This results in a solid implementation, providing logic that can be re-used for web apps, mobile apps, and integrations with Enterprise Service Buses.
A solid implementation, but not an agile one. Business Logic is simple to specify, but extremely costly to build and maintain. It is common that a 5 line ?cocktail napkin? specification can result in hundreds of lines of code.
At Espresso, we believe business demands not only integrity, but also agility. Beyond the automated REST Server framework described above, we have taken re-use one significant step further, by enabling you to express business logic using Reactive Programming.
This declarative approach eliminates remarkable amounts of dependency logic from events/methods, by enabling you to state the meaning of your data in expressions (rules) bound to table columns. This represents another major step in encapsulation, where behavior is directly bound into object definitions rather than object methods.
Logic support is a core element of Espresso Logic, which builds a REST server instantly from a SQL database, provides point and click Custom Resource Definition, and row/column data security. Espresso Logic is provided as a service, so there?s nothing to install or configure.
You can check out Reactive Programming Logic at our website (signup for the News Letter), and we?ll describe it in a future article. Or, you can explore it now with a free evaluation.
7. Conclusion
Business Logic reuse is core to integrity, agility, and time to market. REST servers make logic-enabled data available to your organization and partners in an architecture-neutral manner. Proper support for a Rich Object Model as part of a REST Server Framework can promote reuse. Reactive Programming Logic is the next big step in reuse, automating reuse while providing orders of magnitude advantages in expressive power for time to market and agility.
