The Application Engine Runtime
|
The Service Application Engine™ runtime is a compact Java-based micro kernel. A runtime may function as an independent service hosting container or may be embedded into a user application turning such components into full-functioning fabric nodes. A node may function as an independent runtime process. Alternatively, the fabric provides an open API that allows Java developers to embed the engine’s runtime context into their programs as a library or an embedded database via JDBC, turning such applications into full-functioning fabric nodes. A light-weight client context is also supported allowing client applications to connect to a fabric node using a variety of network protocols such as HTTP, XMPP and the TruLink™ Protocol (TLP). Regardless of application context the API for accessing platform resources remains the same allowing developers to easily move application logic between client programs and the fabric node’s runtime. |
 |
|
At the heart of the application engine is the Service Event Fabric™, a self organizing event cloud that provides facilities for adaptive peer-to-peer communications. The event fabric’s architecture consists of a network of light-weight messaging agents, referred to as sysplex nodes. A node may function as an independent container for service components or may be embedded as a runtime context into Java programs turning such applications into full-functioning fabric nodes. A discovery configuration service allows for ad hoc, user-defined topologies or dynamic, UDP based discovery. The event fabric allows components to easily communicate with each other using Publish/Subscribe, Direct (point-to-point) Links, Queues or task oriented (cooperative worker) communication models. The fabric's Moderator facilities allow participants to discover each other, query membership and roles as well as the data structures (event prototypes) that are being used by their peers. |
 |
In contrast with messaging systems that utilize subject-based addressing to match producers and consumers, the event fabric implements content-based addressing and routing between participants. Unlike subject-based addressing, an event id does not represent a concrete communication channel or destination the way a subject, topic or queue does but rather, identifies the content and structure of the data.
Content based addressing allows fabric components to engage in direct exchange of data without a need to define and reference intermediate communication channels such as queues, topics or subjects. Developers no longer need to manage or maintain an abstract name space that often consists of hundreds of destinations. Correlation between communication channels and their content is managed by the system, eliminating the most time consuming and error prone aspects of messaging application development and deployment.
|
The application fabric provide facilities for hosting business logic. Users may register plain old Java objects (POJO) as fabric services. A Java class is ‘wrapped’ within the application fabric by it's service container context. The context provides event dispatching and dynamic method invocation facilities allowing events to be mapped to class methods. The service’s container context also includes facilities for life cycle management, exception handling, metrics and state advisories. Developers may register existing Java classes as services simply by exposing their methods as event handlers or develop new services using the open service framework and take advantage of advanced event processing capabilities. Results of method invocation are mapped to an appropriate event type and raised as actionable events. event triggers may then act on results of method calls, organising services into discrete event flows or simply generating event streams. A service bean may have any number of event handlers and triggers configured, thereby exposing multiple methods as event consumers or producers. The framework supports synchronous and asynchronous method invocation as well as the standard request/reply. |
 |
|
The application engine offers a set of robust facilities for hosting data collections called Application Data Spaces™. Data collections group multiple data elements of similar format into a single entity such as a table, queue or map. A data space is a scalable, distributed general-purpose data storage system capable of storing structured, semi-structured or binary (blob) data and exposing such data as service engine resources to any component, including other data space collections. Data spaces are a hybrid data caching mechanism that may store data, decomposed objects or object sets depending on the collection’s definition. Developers may use memory in a flexible fashion according to application needs, choosing from several usage models including all memory, logged or persistent. Data spaces support several collection types including tables, queues, maps, arrays and files and allow transactional modification of in-memory data, providing access to information via a collections API or industry standard SQL queries. |
 |
Structured Data Objects (SDO) are a flexible, efficient and automated way for serializing user-defined data structures. SDO may be used by a variety of applications and languages to exchange structured data, for data storage, custom API definition and more. Binary, XML and JSON formats for serialization are supported and may also be used to affect fast, extensible data mapping and transformation of objects and documents. Additionally, developers may specify relationships between objects types, thereby defining data ontology.
Structured data objects implement aspect-driven serialization. No special interfaces, code generation or pre-processing is required, making serialization a simple activity. The fabric runtime keeps track of object versions and dynamically generates serialization support classes at application start-up. As long as data producers and consumers keep their own class libraries synchronized, application interfaces remain durable. Applying any format changes simply means keeping versions of objects up to date, making change management faster and more reliable.
The application fabric uses passive governance mechanisms to collect and present information about application fabric clients and hosted components. The central facility for participant governance is the Exchange Moderator. The moderator interface and API provide vital statistics and information about communicating end-points, allowing applications to take actions and make informed decisions based on the state of fabric participants and resources.
The moderator can provide information about event type usage, describe the topology of a particular sysplex and present information about specific event producers or consumers. Membership views, process state and data flow may likewise be queried by via the moderator interface providing end-point governance and resource use reporting.
The application engine provides a syntax building and query execution facility called SLANG allowing users to develop their own domain specific language (DSL) for interacting with fabric resources through interactive script. Using the API developers can define a DSL syntax processor for their language statements. The statement object is self-documenting and may be queried to show the expected syntax. Once defined, the syntax parsing module is able to generate a list of parameter tokens from text and dynamically build a language request object for a given SLANG statement. As such the language processor may be set up to generate user-defined data objects or events.
SLANG is a powerful tool for both developers and users. Developers may define simple commands for calling service logic or a more complex, script-like syntax for composite service invocation. The pseudo-language may target a specific user community or application domain and may be executed using any protocol supported by the fabric runtime. Users may access fabric resources and invoke service logic by combining multiple language commands into a single script that may be executed in a location-transparent fashion. The language environment is session-based and may be used to coordinate resource access between participants in a collaborative fashion.
Service Application Engine™ components exchange data by using Event Datagrams or simply, events. The fabric handles all aspects of event passing between participant components, allowing applications to raise and process critical business events in a location-transparent fashion.
Event triggers provide an extensible way for developers to produce business events that may be processed by service components or complex event processing engines, facilitating an adaptive response to varying business needs.