These are some of the questions we often get about Espresso Logic.
Aren't there Automation Trade-offs?
Automation technology can entail trade-offs; these are listed below.
Can automation deliver Enterprise-class performance?
Yes. Espresso Logic was designed and engineered to deliver enterprise-class performance.
Espresso Logic Server leverages Cloud technology for Elastic Scalability, so that server instances can be dynamically added to meet demand.
A key consideration is latency, addressed in multiple ways. You can choose the location of your server to minimize latency. You can define Resources that deliver multi-table results in a single response, with provisions for pagination and refresh automation.
Database overhead is reduced by eliminating / minimizing SQLs, caching, and careful lock management. Client results are delivered with paginated, optimistic locking. Update processing is highly tuned to prune and optimize SQLs, and defer write locks until late in the transaction.
Direct capture of declarative, end-case requirements enable such global optimization, just as a SQL optimizer is now relied upon to deliver retrieval performance equivalent to manual coding. And the same maintenance / iteration value is provided - you can alter the storage configuration, and all of your Use Cases accrue the benefits.
We have made similar investments in business logic performance
. And the same maintenance / iteration value is provided - you can alter the storage configuration, and all
of your Use Cases accrue the benefits.
Are all problems automated? If not, is it extensible?
Logic automation is extensive
Automation is inevitably based on identifying key patterns, and providing simple ways to declare their use. Business Logic is no different in this respect. Our approach has been to keep the language small and easy to learn
, and provide extensibility
to enable you to add new patterns, as well as solve one-of-kind problems.
Is it opaque - difficult to debug, extend?
Espresso Logic is designed to be completely transparent, so you can easily diagnose issues.
This is because even when automation is impressive, there are always issues. We have all been in the unpleasant situation when a piece of software just doesn't seem to be able to do what we want, or worse, it apparently provides the needed service but silently fails ("what is it doing"?).
We agree. So we have designed Espresso Logic with:
- Extensive Logging - the console always lists what rules fired
- Debugging - you can use the Logic Designer to review rule and sql execution
Will I have to deal with ugly code?
Automation often depends on code generation, which can be very difficult to read, to debug, and to extend.
Espresso Logic does not generate code. We provide logging, debugging and extensibility to make it easy to manage, as described above.
We cannot open a firewall port - can I still use Espresso Logic?
Yes. You can use a Virtual Private Cloud, or install on-premise as a war file or an appliance. You can also access on-premise data from the cloud, as further described here.
Can I use Espresso Logic with NoSql databases?
Not currently - our transactional logic depends on DBMS transaction support.
You might want to consider newly architected databases such as NuoDB, which provide "big data" performance while preserving SQL.
I see other products with Business Logic - what's the difference?
While using a familiar language, Espresso Logic rules are fully declarative
, exhibiting the following key characteristics not present in procedural languages:
- ordered - the system parses your logic, and orders it per dependencies.
- re-used - your logic is automatically executed whenever referenced data is altered
- optimized - conversely, your logic is not executed when its dependencies are not changed
- automated data access - your SQL is fully automated, and fully leverages the cache
Can I use existing Technology?
Do all of my existing Database apps and tools work with Espresso Logic?
Yes. We do not replicate your schema - we acquire it from the database, eliminating synchronization issues. The DBMS manages locking and concurrency, so existing apps continue to work without change.
Are Rete Business Rule Engines appropriate for Business Logic?
RETE inference engines are a complementary technology, suitable for decision logic. Espresso provides a superior choice for transaction logic, since it is SQL-aware, is high performance, and provides active integrity - all within a RESTful interface.
- Performant aggregate processing
Aggregate processing is a well-known challenge for Rete engines. The root cause is that Rete engine interfaces do not presume a transaction that can be compared to an existing database to compute adjustments, and use these to prune processing logic. So, to define a sum, they must bring all the child rows into memory. Particularly when such aggregates are Forward Chained on other aggregates, this can be prohibitively expensive. By contrast, Espresso Logic injects logic into all updates, enabling it to automate key pruning and optimization logic.
Espresso Business Logic rules are automatically invoked for all updates. By contrast, Rete rules require explicit calls. Integrity that is elective is not reliable, and does not meet the requirements of regulatory compliance or system integrity.
Rete engines do not have concepts like old values, so there is no natural way to express state transition logic. They also do not provide advanced logic such as copy and allocation.
Espresso logic provides full logging for all logic / SQL, and a debugger for detailed diagnosis.
Business Logic automates - and optimizes - all of the read/write SQL, so your app is focused on a higher level of abstraction.
We believe these technologies are complementary. Decision-oriented applications often operate without update transactions, and are quite appropriate for Rete engines. Further, Rete engines often include services such as Decision Tables, which can be invoked from Transaction Business Logic to provide End User access.
Are Process Business Rule Engines appropriate for Business Logic?
Process Engines provide excellent value in workflow and system integration processes, where a sequence of steps is inherently manually ordered. They are a poor fit for transactional Business Logic, which provides great value in automatic ordering.
Are Visual Rule Designers are better alternative?
No. Visual Rule Designers provide a graphical (flow-chart like) way to program your business logic. While visually appealing, these are really totally procedural, suffering from all the liabilities of programming:
- Ordering: your diagram is inherently ordered, so changes must reconsider dependencies
- Re-use: your logic is not called without explicit invocation, so re-use is not guaranteed. Worse, re-use is of the procedural variety, not re-use of declarative logic (such as a sum, which is automatically re-used over inserts, updates and changes)
- SQL: such engines typically require you to manually invoke SQL calls. This is a very low level of abstraction and obviates the possibility of optimizations
- Optimization: such procedural approaches require you to manually code optimization techniques such as pruning or adjustment, which must be reconsidered on each maintenance change
Are JPA Validations sufficient for Business Logic?
No, JPA validations are static - they do not constrain the results of declarative derivations, and they are single field or, at best, single-table. Espresso Logic supports multi-table derivations, validations, and actions.
Is this a 4GL? Can't I use an existing language?
No, Business Logic is not a 4GL. Business Logic is declarative, providing automated ordering, re-use and optimization. 4GL languages are procedural languages extended with "power verbs", a dubious objective with the advent of extensible languages such as Java or C#.
What problems are suitable for Espresso?
Business Logic is the processing you execute on save/submit: derivations, validations, and actions such as auditing, copying, messaging, business process initiation, etc. Such logic should be architected so that it is shared for multiple User Interfaces and Message-based transactions.
Espresso Logic addresses only save (transaction) processing. It does not address other familiar forms of business logic such as presentation logic (data retrieval / update processing, screen flow), Enterprise Application Integration, Business Process Flow, or Decision Logic commonly associated with Rete engines. In most cases, you will find these technologies to be synergistic with Espresso Logic.
As noted above, Espresso Logic is focused on SQL data. In some cases, you might consider it as part of a Polyglot DB approach, wherein an application might often employ both SQL and NoSQL technologies.
Data Retrieval RESTful APIs - including multi-database and ERP integration
Create RESTful APIs for SQL data that integrate multiple databases and ERP Systems. You can create these in minutes, while providing Enterprise-class scalability.
Basic Data Management RESTful APIs - create, read, update, delete
Advanced Data Management - enterprise-class extensibility
New Technology always brings issues
Any new technology has implications. Some typical questions are answered below.
What is the Learning Curve?
Espresso Logic fits into your existing architecture, using well-accepted principles of SOA, REST and JSON. There is a learning curve associated with logic:
Can I use Business Logic on an Existing Project?
Yes. The SOA architecture is particularly effective in dealing with multiple languages and architectures. As with any multi-tiered architecture, you will need to ensure consistency between applications that use the logic server, and those that do not.
Is Business Logic a Wizard? Just for the Coding Phase?
Business Logic is not a Wizard. In fact, there is no Design Time component - all of the processing occurs at runtime.
It is relevant to far more of the Project Life Cycle than coding:
- It provides some value at Analysis Time, by introducing high level abstractions such as allocation.
- It provides considerable value during Design, by automating design issues such as re-use, ordering, optimizations, and partitioning.
- It provides considerable value during Maintenance, automating re-ordering and re-optimization, and with Logicdoc provisions for transparency and Rules Traceability.
I am a Developer - what's in it for me?
Though we stress the value to the business of Agility and TCO, there are many benefits for developers:
- Automated Maintenance - we're developers too, and we understand -- nobody likes maintaining old code. Automated Ordering eliminates the bulk of drudgery of maintenance, since you can just introduce the new logic without worries about dependency management. You'll also be able to find the business logic, without having to hunt through controllers, domain objects, services, and who knows what. So maintenance will be more like development, not archaeology.
- Automated Documentation - logic is transparent to business users, so is executable documentation. So it's built as a by-product of development, and does not "drift" away like manual documentation
- Quality - automated re-use means that your logic is always re-used. No more corner cases discovered during Final Test (or worse: later).
- Creativity - why would you want to build code a machine can build? It is much more creative - and valuable - to identify new patterns, and build re-usable extensions to automate them.
- Delivering - the "kick" of programming is to deliver new functionality that delights your users. Why not do it more quickly and more often?
- Transparent - logs make the logic and SQL clear. Metrics enable you to detect APIs that are failing or running too slow.
- Integrated - Espresso Logic is an SOA-based implementation, so it integrates with your current technology.
- Less Hassle - no need to install / maintain a server. No need to deal with SQL.
Does Business Logic benefit Package Development?
Yes. Business Logic can make your Package Development more agile, can reduce customization costs, and can reduce merge costs for subsequent release cycles.
Does Business Logic benefit Integrators with Frameworks?
Yes, Integrators can enhance their business practice, provided they are focused on a value-based relationship with their clients.