Watch the demo.
REST is ideal for data access
Most engineers agree that a Service Oriented Architecture is the ideal solution for mobile database access. A Rest Server, delivering JSON objects, has become the common approach, servicing mobile apps, web apps, other corporate systems, and partners.
Of special interest is the business logic. In this context, a Rest Server provides
- Retrieval Services - get requests assemble the desired data from the database (e.g., a Customer with their Payments, Orders and LineItems), subject to security (only return Customers in my region, and balances only in my district).
- Update Services - put/post requests send updates to the server. The server applies the transaction logic to ensure database integrity. For example, adding an order might require sending congratulatory emails to the sales rep and customer, a credit check service call, and ensuring the updated customer balance does not exceed the credit limit. If no validations are violated, the server writes the results to the database.
Transactional business logic is complementary to other aspects of business logic such as work flow, decision logic, analytics, and enterprise application integration.
Live Data: Security and Integrity are key requirements
Rest APIs are public, enabling business partner access to data. Such public APIs demand that the Web Services enforce your policies for security and integrity. Building a "dumb" server that provides Rest access to a raw database data is not sufficient, your API needs "live enforcement" for security and integrity.
But not so easy to build - particularly the business logic
While it's easy to see what Web Services do and where they fit in, it's not so easy to build them. As illustrated here, a conventional approach involves multiple sub-projects:
- A REST Services Layer to analyze the request, unpack parameters, and invoke the business and data access layers
- A Business Logic Layer to execute the security and business logic
- A Database Layer to perform physical read/write. For example, a Java stack might include
Data Access Objects for read / write interfaces, which invoke JPA operations on annotated
The most obvious point is the time and expense to build a Web Services server. The Service and Data Layers are tedious, but the real work lies in the Business Logic Layer.
Business Logic must be enforced over multiple Use Cases, so our credit limit check logic must also be applied to other transactions such as changing Order LineItems, re-assigning Orders to a different customer, and so forth.
Each Use Case must then address complex, multi-table dependencies, So, 5 simple requirements explode into 500 lines of code. For real-world applications, tens of thousands of lines of code are required.
But there are more subtle implications of the traditional "just code it" approach
- Code is slow to build and costly to maintain, often requiring a different skill set. This is more than an IT problem - it can represent a brake on the business.
- Code is manual, so there are inevitable quality issues (was the discount applied to changed orders, not just new ones?). It is remarkably difficult to establish compliance to regulations or company policy.
- Code is not transparent, so there is no common Business / IT language to address requirements risk
Live Data means you simply connect to get a fully operational User Interface and default Restful API.
- Resource Definitions - define multi-table Resources to reduce latency and provide application-friendly document-model JSON results
- Security - fine-grained authorizations that control access down to the row and column level
These are illustrated below.
Rest retrievals can
return complex data, such as set of Customers with their Orders, Items and Payments. You define multi-table Rest Resources as shown here using your Browser.
Multi-table resources reduce latency by delivering all the required data in one transmission (with pagination for large results). Also, note that provisions for resource / attribute alias names protect the application from underlying database changes.
Once you have defined resources, your API is ready to use. Client development can proceed in parallel with Logic and Security specification as described below.
Until now, organizations have simply had to put up with manual approaches, suffering excessive time and expense, with poor agility and transparency. After all, it's domain-specific logic, surely it must require domain-specific code...?
Not any more.
Business Logic is declared as a series of spreadsheet-like expressions (rules). This diagram shows an actual example of fully executable logic.
These expressions automate complex multi-table transaction logic. They address:
- derivations, including multi-table derivations such as the customer
amountTotal shown here
- validations, such
- actions, such as auditing, sending email, copying data, etc (example not shown)
are non-procedural, business-oriented statements of what to do
, not how to do it.
You might regard such logic as the requirements document ordinarily input to the development process (architectural design, detail design, coding, and testing).
Automation means that the business-oriented logic declarations are directly executed by the Espresso Logic Server. This ensures database integrity, based on clear and concise statements that serve as both transparent documentation and maintainable implementation.
- Enforcement is active - the Espresso Logic Server automatically executes your logic on every Rest-based transaction. Database integrity is not dependent on remembering to invoke the logic before updating the database.
- Re-use is automatic, so, for example, the rules conceived for Place Order are automatically applied to Change Order Line Items, Re-assign Order, etc. Logic is defined for "base resources", so is automatically applied for all resources defined above.
- Multi-table dependency management is automatic, so maintenance is simply changing the logic. Unlike manual code, the system recomputes a correct order of operations based on dependencies.
- Optimizations are automatic, so logic is pruned based on actual updated data. SQLs are optimized for aggregate operations by using 1 row "adjustment" updates, rather than expensive aggregates which may be chained.
While this example is simplified for communication, logic is quite powerful. For example, it requires only a few specifications to perform auditing, or even complex logic such as a deep copy, or a bill of materials explosion - see more examples here.
Finally, logic is also extensible
. You can use Java Script to handle events, or to define new functions or rule types.
When End Users log in, they are authenticated which authorizes them to access information per the roles they play. Administrators can define role-based authorization for each table, including:
- Predicates that control which rows are returned
- Columns specifications that allow you to enable, for example, only managers to see salaries in their department
As for logic, the underlying Security provisions are enforced regardless of which defined Resource is used.
Espresso Logic can provide significant advantage to your project in automating your REST Web Services, with unique automation for business logic
and security. Espresso Logic fits into your existing architecture
, is extensible, and crafted for performance.