|This page uses a small but representative sample application (shown at right), to demonstrate how Espresso Logic enables you to eliminate a significant obstacle in building and running modern systems for integration and mobile data access.
Problem: Servers are hard to build - particularly the business logic
REST/JSON Servers are the accepted approach for mobile app access to integrated data. But these are slow and complex to build. In a Java stack, you might need to use Jersey, Jackson, JPA etc.
Such frameworks can reduce coding, but these are complex and time-consuming. And worse, they don't address Business Logic and Security, which can comprise significant effort.
So we pose the question:
what is the absolute fastest and easiest way
to build a REST Server?
Instant REST Server - Espresso Logic
This video demonstrates building a server in about 5 minutes that would otherwise require weeks (really). It's further described in the sections below.
Here's the core idea:
- Observe that business logic requirements which can be expressed in 5 lines - clear to IT and Business Users alike - require hundreds of lines of code to implement...
- So, make the requirements executable, meaning...
Provide a Logic Designer that accepts spreadsheet-like expressions that express what your data means - how it is computed, validated, including actions (auditing, deep copy, etc), and so forth.
Provide an Espresso Logic that directly executes this spreadsheet-like logic on all RESTful update requests (Put, Post and Delete).
1 - Expose Database Tables as REST Resources
To build a REST server, we connect Espresso Logic to our database. Since it's a service, there's no installation / configuration hassles. It's all done through the browser, using the Logic Designer.
This automates our Web Service Layer and our Data Access, so you are up in seconds. Our tables, views and Stored Procedures are REST Resources. We can build client apps for "admin" tables that do not require logic or retrieval with related data. Even faster, we can test them with the Rest Lab without writing a program. The Logic Sample database is automatically created in your account. You can examine (or repair!) it with the schema / data here.
Custom Multi-Table REST Resources
But if we use these resources for presenting related data, there will be 1 message for each table (Customer, Order, Items). That can result in latency and affect performance.
You can define Custom, Multi-Table Resources that deliver such data in a single JSON response. Simply select the tables. The system defaults the SubResource join (Customers / Orders) from the Foreign Key Validations.
After you define your Resource, you can test it in the Rest Lab (click the thumbnail):
Business Logic must be addressed
But the real work involves the Business Logic. Let's see why by considering Place Order.
Analysis reveals we need to check credit - the balance cannot exceed the credit limit, where the balance is the sum of the unpaid order totals, which is the sum of the Line Item amounts, derived as the quantity times the parts' price.
This is a nice clear requirements spec. But it represents quite a lot of business logic.
First, we must identify all the related Use Cases that must also respect these rules. If we miss one, serious bugs will result.
Each of these must be then designed for change detection, and propagation to dependent data. And optimized. Pretty soon, the simple 5 line spec becomes 500 lines of code.
And yet, the requirements (pictured here as the venerable cocktail napkin), were so simple. If only they were executable...
2 - Declare Business Logic
Presumptions can hide opportunities. Consider the presumption that domain-specific logic requires domain specific code.
It's a big assumption - we're talking 500 lines of code. That's weeks of work to build and test, and a huge web of dependencies to maintain. That's not fast, and it's not simple.
What if, instead of programming our server for each Use Case/dependency, we could just directly enter the requirements from the cocktail napkin?
Now that would be simple and fast. And it's exactly what you do.
This screen shot shows all the logic required to supplant 500 lines of code. You can explore logic here.
Note especially the multi-table derivations, such as the customers' balance. Such derivations can be chained - used in related logic (used by the credit limit check, uses the amount_total result). They are highly optimized to dramatically eliminate and simplify SQL access.
3 - Declare Security for a Public API
We are very nearly done. To make our API public, we of course require Security - fine-grained, down to the row and column instance.
You can define 1 or more roles for a user. Roles are very powerful: you can associate them data rows in your database, and use their column values to filter queries against other tables. For example, you might filter orders for a sales rep to just the ones assigned to them, without the ability to alter the paid flag, as described here. As with logic, security is point and click, not code.
- Espresso Logic fits into your Enterprise / Web Architecture, with Enterprise class support for pagination, optimistic locking and refresh.
- We solved all the Use Cases - even though we targeted only Add Order. Re-use is automatic - and so is quality.
- Our logic is unordered - the system takes care of that through logic dependency analysis. This is repeated on every change, so maintenance is simple - just change the logic.
- We did not optimize our logic - that is also the system's responsibility. So our logic is pruned based on actual changes, and SQLs are eliminated / optimized to reduce server traffic. As for ordering, these optimizations are repeated on each change.
- Our logic is transparent - business users can read it and spot errors / omissions. So we finally have a common business / IT language, that is both transparent documentation and maintainable implementation. A corporate asset.