These are some of the questions we often get about ABL. We also have a separate list of FAQ's for very technical issues.
Can I use existing Technology?
Rete-based inference engines
provide valuable services that enable Business Users to manage (safely
selected) elements of their system, by-passing the need to contact IT. While valuable in that sense, Rete engines are quite inappropriate for
the transaction processing elements of Business Logic:
- Inadequate 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, Automated Business Logic integrates with the ORM services, enabling it to automate key pruning and optimization logic.
- Inadequate (non active) integrity
Unlike Spreadsheet Business Logic where rules are automatically
invoked for all updates, Rete rules require explicit calls. Integrity that is elective
is not reliable, and does not meet the requirements of regulatory
compliance or system integrity
- Inadequate Expressive Power
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
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 Grails Constraints sufficient for Business Logic?
No, Grails constraints are static - they do not constrain the results of declarative derivations), and they are single field. Automated Business Logic supports multi-table derivations, constraints, 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 Groovy.
Is this a Domain Specific Language?
Yes. Domain Specific languages are characterized by:
- Precise domain focus (here, Business Logic for Hibernate/JPA)
- Small Language (here, less than a dozen language constructs)
- Excellent Abstraction, facilitating transparence between Domain Experts (here, 5 transparent business rules are formulas - clear to business users - that replace 500 lines of opaque code)
In particular, we have targeted a very high integration to reduce adoption barriers:
- Expressed in Java / Groovy - Business Logic is an internal DSL, hosted in Java and Groovy. This provides familiar syntax, leverages tooling (Editors, Debuggers, Source Control etc), and provides extensibility to blend the automation and abstraction of a DSL with the full expressiveness of a general purpose language
- Integrated into Hibernate / JPA - use of Hibernate / JPA entity definitions reduces language size and re-uses a sizable body of definitions, and integration via runtime events preserves existing APIs for invocation
Aren't there Automation Trade-offs?
Automation technology has some clear cautions; these are listed below.
Is Performance a casualty of automation?
The heart of a relational database engine is the optimizer, which is now accepted to deliver performance equivalent to manual coding. In fact, many would argue that is vastly superior, since you can add indices and existing data retrieval logic is automatically faster.
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?
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?
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 Automated Business Logic with:
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.
Automated Business Logic does not generate code. We provide logging, debugging and extensibility to make it easy to manage, as described above.
New Technology always brings issues
Any new technology has implications. Some typical questions are answered below.
What is the Learning Curve?
Presuming you have made a decision to use Hibernate, Automated Business Logic does not impact your architecture. You use Hibernate as usual, and automatic invocation
is used to execute Business Logic.
Of course, you do have to declare it, so there is a learning curve associated with that:
How do I Manage a project using Business Logic?
Can I use Business Logic on an Existing Project?
This means you can dramatically increase your business agility and logic transparence for new Business Logic, without requiring migration of existing Hibernate-based Business Logic.
It also means you can utilize Business Logic on your existing data to verify that it conforms to your rules. It is quite common that legacy applications have simply ignored business logic enforcement due to time pressures, resulting in database containing orphans (e.g., Purchaseorders without a corresponding Customer), or errors in stored data (the Customer balance does not match the sum of the related Purchaseorder amounts).
What problems are suitable for Business Logic?
Business Logic is the processing you execute on save/submit: derivations, constraints, 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.
ABL logic is architected so it supports any Hibernate-based transaction, whether interactive or message-based.
Automated Business 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 Automated Business Logic.
What are the limitations?
How does Business Logic fit into my architecture?
Is a separate Services Layer required?
No. A Service Layer, often motivated by the complexities of multi-table logic, is optional for most cases. If desired (e.g., to publish APIs for SOA access), services can be thin since they invoke the logic encapsulated into the Rich Domain Objects.
Is Business Logic consistent with the DAO pattern?
Yes. Data Access Objects encapsulates your persistence and business logic, providing a separation of concerns from other application logic. In effect, the logic-injected Domain Objects become DAOs, accessed via Hibernate. Of course, you can build separate DAOs if you prefer this pattern; like SOA services, such objects can become thin by delegating to the underlying Active Domain Objects.
Is Business Logic consistent with the SOA pattern?
Yes. A Service Oriented Architecture provides a coarse-grained, loose coupling between calling applications and the services they use. This can enable applications to use remotely available heterogeneous services, discover new / alternative services, without re-inventing their logic or their access.
Business Logic can integrate with SOA-based architectures both as a consumer and as a producer:
Your Business Logic can invoke such services since tooling provides Java wrappers.
You can build new services by invoking Business Logic-based Domain Objects. This hides the underlying persistence/logic implementation. Unlike services that must be built with large amounts of Java code, you will be able to write thin services since they are re-using your automated business logic.
We have a hodge-podge - can Business Logic help?
Yes, provided you are able to utilize Hibernate.
We understand that business pressures, technology change, organizational changes and a host of other factors can result in systems that use a variety of technologies, from triggers and stored procedures, to DAO objects, service objects, etc. Confusion / inconsistency is often the least of the problems - quite often, database integrity is marginal.
Business Logic can help you migrate to a more consistent architecture based on Java and Hibernate, accepted standards in the industry today. Business Logic can add the agility and transparence required for your business, and integrate with accepted architectural patterns such as those noted above.
Not only can Business Logic assist in building new logic, but it can capture your intended Business Logic, and identify issues in your existing data that do not conform to your rules. Even if you do not envision adopting Hibernate, validating your existing data can be a useful service.
Is Hibernate required?
Yes. Hibernate provides significant value in persisting (reading, writing) your Java objects to SQL databases, while preserving their objected oriented value (inheritance etc). Hibernate has become the de facto standard for persistence, and has been adopted into Java 5.
Automated Business Logic is activated as a Hibernate event, so Hibernate is required. If you are not using Hibernate, it is worth considering:
Many architects prefer a clean separation between data, business logic and presentation tiers. Hibernate provides this, while preserving a non-intrusive utilization of POJOs for Domain Objects.
Given its wide adoption as a de facto standard, you get the classic benefits of mature tooling, familiarity over a broad class of developers, quality, etc.
- Basic Integrity enforcement
Hibernate provides some basic integrity, such as referential integrity including cascade delete/nullify.
Automated Business Logic extends these advantages with a declarative, spreadsheet-like level of power for Business Logic.
Does it integrate with my UI Framework?
As described above, Business Logic invocation is automatic. So, if your UI Framework can work with Hibernate, you can use it with Business Logic.
How do I update my model to show Computation Results?
It is important to consider updating the model objects presented to your framework to show computation results arising from business logic. The Business Logic Engine provides APIs to determine which objects have changed, enabling you to perform efficiently (e.g., only for actual changes, and partial page updates).
How does it interact with my methodology, such as Agile?
Automated Business Logic does not require you to change your methodology. However, it is especially complementary to Agile approaches, providing automation to support rapid and high-quality iterations, rules to enhance cross functional communication and make requirements transparent, and testing integration with jUnit including useful database diff tools.
Does it integrate with my modeling framework?
Why isn't logic defined in Domain Classes?Encapsulating logic into Domain objects is an attractive approach, a good solution to the anti-pattern of Anemic Data Objects. Domain objects themselves play a key role in your architecture - they often are required to be serializable, and Hibernate can be affected by introducing additional capabilities.
To avoid these adverse effects, Business Logic Architecture defines logic not in Domain Classes, but in corresponding Logic Classes. Encapsulation is provided by the Logic Engine, operating as a Hibernate listener to enforce logic for all Hibernate transactions.
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 where. So maintenance will be more like development, not archaeology.
- Creativity - why would you want to build code a machine can build? On the contrary, 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 often?
- Tools Preserved - you're still using your IDE to write code, debuggers to fix it, Java/Groovydoc to document it, and logging to monitor it. There are no impacts to your source control system - business logic is just another set of classes.
- Standards-based - you're not leaving the world of Hibernate/JPA, Java/Groovy, services, frameworks, etc - these all remain fully in place and unchanged.
- You're not being replaced by a machine - the fear factor is that automation is often employed to eliminate labor costs. But the overwhelming majority of businesses have a large IT backlog, and simply want to build more systems, build them faster, respond to business change with greater agility (faster maintenance).
- You'll make more money - you'll be able to command a premium by being highly productive and engaged with Business Users, rather than reducing yourself to a replaceable coder. Businesses are always happy to pay a premium for time to market, reduced costs (even while paying each programmer more), and reduced TCO / maintenance costs.
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.
How can rules in Java/Groovy be "declarative"?
Declarative approaches can provide enormous value, automating the invocation, ordering, re-use and optimization of your logic. Declarative approaches capitalize upon recurrent patterns to automate them. While extraordinarily productive, this can lead to limitations in expressive power (a "closed" language), and transparency (possible challenges in debugging, logging etc).
Automated Business Logic provides the Declarative Power with Procedural flexibility by enabling you to specify your logic as simple methods:
- These are declarative, in that the method logic is invoked, ordered, re-used and optimized automatically - on initial specification, and on subsequent change.
You will discover that most of your logic is either a simple annotation, or essentially a spreadsheet-like expression.
- When you are unable to express your logic declaratively, there is seamless transition to procedural logic. Importantly, such procedural logic can leverage extensibility, enabling its re-use across your organization.