Frequently Asked Questions

Is the Service Application Engine™ a Complex Event Processing engine?

No. The application engine is a technology that is complementary to CEP engines. It provides a data and services fabric that acts as a stream source to Complex Event Processing technologies, simplifying event stream creation and exposing service logic, data and other application fabric resources as events.  The engine's services and data collections can act as stream producers or a stream consumers. Although it is possible to correlate, aggregate or develop time-boxing facilities (time-sensitive window frames) using th engine, this is not part of the core functionality of the product. The application engine expands the value of actionable information by providing a way to dynamically discover what events are available in the enterprise, query their structure or schema and infer who the producers and consumers of such events actually are.

What is a ‘Data Space’?

The term refers to a physical holding area for logical groupings of similar data.  Although similar in concept to a relational database the ‘space’ does not require that data be organized into strict tables or even Tuples (name/value pairs).  Data may be binary, keyed, simple sequential or hierarchical.  The term is closer to a data collection with the caveat that each element must have some type of structure definition or description (even if it is a simple binary object). Unlike an arbitrary data cache, spaces are organized into a distributed name space allowing for relationships and potentially dependencies to be defined between data collections.

Is this another database?

The purpose of a ‘data space’ is to organize structured and semi-structured data common to applications, into collections that can be accessed via a standardized API.  While the mechanism performs many of the same functions that a conventional database performs its main goal is to provide light-weight state persistence for applications rather then serve as a central repository for concurrent data access.  It is an alternative data management system that may be complementary to a database.   We refer to this concept as a Structured Data Collection.

What is a Queue Space?

The Q-Space is a specific flavor of ‘data space’ implementation that organizes information into first-in-first-out queues.  Queues behave in the same way that a messaging system’s queues behave and may be accessed using standard queue operations found in the Java Collections API.  Q-Space objects  also provide some  capabilities not found in either a messaging system or the collections API.

Is this another messaging system?

Not exactly. The application fabric is built up into a cluster of peer-computing nodes called a Sysplex with each node being capable of functioning independantly and hosting it's own data and logic services. Communication between nodes occurs using a the TruLink Protocol™ whcih is a specialized communications and remoting framework that utilizes Contend-Based Addressing to pass event objects between participants.  Althought there are many similarities between the event fabric and conventional messaging systems, there are significant differences as well. 

Do Application Data Spaces integrate with SOA technologies?

Yes.  The purpose of data spaces is to extend any standard stateless Service Oriented Architectures by adding data and state persistence into the mix.  This is some times referred to as Service Oriented Data Architecture or a Data Fabric.  Additionally, due to its hybrid nature the data space allows for queue-based processing and staging when needed but exposes the data collections as SQL, allowing developers to infer relationships between application data elements and processes.  

How big is the Application Engine library?

The core binary runtime is under 7 MB.  

Why use a Queue Space?

The hybrid and embeddable nature of this component makes it ideal for solving certain problems.  In situations where state of a process must be preserved between executions and monitored at run-time Q-Space objects provide the ability to model ‘what-you-see-is-what-you-get’ process flows.  This is critical for systems that require accurate process state reporting without impact to the actual process.

For situations where data must be presented in entry-sequence, but potentially processed out-of-sequence or via indexed retrieval the Q-Space supports both models. Messages may also be updated in place.  For query the space allows cross-queue lookups and the combining of correlated elements into a single result set.

In cases where multiple recipients must acknowledge receipt the Q-Space can support a list of certified recipients acting like a certified publish/subscribe mechanism.  This allows developers to easily build very sophisticated data distribution mechanisms without writing a lot of code or investing in costly data distribution software.

In cases where queue state requires proactive notifications such as notifications on Enqueue or Dequeue operations the space supports ‘Event Triggers’ on queue objects.  This dramatically simplifies the development of monitoring tools that can react to state changes without consuming or destroying the changed element (unlike conventional messaging systems).