6. CAPS™ Layer 2: the Business Logic (BL)

CAPS™ Layer 2 works on top of the OODB capabilities provided by Layer 1. Layer 2 is known as the "Business Logic" layer (BL) because it builds full-fledged "business objects" that reflect the needs of specific applications and respect the "business rules" of those applications.

All "front-end" components (Layer 4) interact with the BL, never directly with the IFC™. Therefore, front-end components never have to deal with lower-level, implementation-related concepts: front-ends can always deal with application-oriented, higher-level concepts and terms.

Vice versa, the IFC™ does not have to deal with security issues, besides the obvious one that only a properly validated BL is allowed to connect. The BL handles all issues related to granting various access privileges to different users. If an application's needs require it, such privileges may be defined with very high (detailed) "granularity". In the future, such granularity will get down to specifying, for example, which users or groups of users can even _see_ that a certain attribute exists at all in a given class of objects (apart from being able to get the _value_ of that attribute for certain objects).

The BL has real-time enterprise capabilities comparable to that of the IFC™.

In the current version of CAPS™, only one BL process connects to the IFC™. However, CAPS™ is designed to allow multiple BLs to connect to the same IFC™. This functionality will enhance scalability in future versions of CAPS™, and the system architecture allows for such BL multiplicity.

When multiple BL connect to the same IFC™, they will be able to exploit the IFC™'s real-time enterprise capabilities to enhance cooperation. For example, a BL could cache queries and requests that are often executed by components further downstream. In such a case, the BL will be able to efficiently assure that the cache is always up-to-date, by exploiting the IFC™'s "subscription" mechanisms. Subscription-update messages will then be automatically triggered by all relevant changes to the database, including updates performed on the DB by other BLs simultaneously connected. Such messages will in turn allow the BL to update or flush the cache as and when appropriate.