Leap Context Engine - LACE
Our LEAP framework plows forward into new territory with the addition of the LEAP Advanced Context Engine (LACE). For those who follow us, you are well aware that our team includes one half of the original designers of MOCA, the popular WMS architecture (now owned by JDA). For the past 15 years, we’ve been fending off people trying to get us to write an open-source version of MOCA. To us, MOCA is the past, it is history. Its roots are too founded in early 1990’s thought processes. So, that’s always been a non-starter for us.
Instead, we looked at the problems MOCA solves well, the roles in which it still makes sense as well as those it does not, and how you’d approach these problems 25 years later. Looking at MOCA objectively, you can divide it into a couple functional elements:
- Invocation and results-set processing. There were not a lot of standards for APIs, invocation and handling result data in general in the 1990s, so we create a SQL-like invocation mechanism and mimicked a relation database result set coming back. Fast forward to 2019, with structural standards like XML, JSON and SWAGGER (OpenAPI) for requests and responses, this core capabilities importance has been greatly minimized.
In addition to adding native support for XML, JSON (JSON Schema) and Swagger (OpenAPI 3.0), LEAP now supports its own official Internet (IANA) media-type called Leap JSON, providing very rich metadata and link processing abilities, which is used by the LEAP Form UI feature.
- Automatic Transaction Enlistment. Still today, there are varying abilities, and depending on one’s approach to dynamic definition of componentry, work in this area still feels important to us. LEAP fully supports dynamic transaction enlistment for things like vendor implementation (component substitution).
- Context. For anyone with any knowledge of MOCA, context is key to its success. Context enabled triggers, wrappers, and a whole host of dynamic end-points in ways still relatively unrivaled. To us, a lack of good context processing, in other systems, creates the need for additional architectural plumbing (ESB engines which serve the purpose, in a sense, to create this sort of functional context). Context can still play a very significant advantage in reducing the overall need for additional plumbing and, therefore, latency and support variability.
As our staff includes one half of the team which originally wrote the context engine in MOCA (which was subsequently taken over, and perfected by, the brilliant, Derek Inksetter), we have a keen appreciate of why and how context works the way it does. Simultaneously, we, maybe more than anyone outside of JDA, uniquely understand why it is no longer adequate. Don’t get us wrong, MOCA context is and was great. But, if you look at where you send your programming efforts now, and whether MOCA is involved in the creation of effect context for developers and their components, you see its native orientation toward row/column results-set is a huge limiter going forward.
Our new advanced context engine, called LACE, permits you to create context made up of rectangular data (SQL results) and non-rectangular, complex data in the form of both XML and JSON and process it without writing code. See a LACE case study here for an example of how we created two very different, native LEAP vendor integrations, with no additional code or outside plumbing.
- Data from just about anywhere. Designed to take data from just about any data providers (SQL, NoSQL, Messaging, Big Data) LACE eases the idea of integrating data from disparate sources.
- Service Execution Lifecycle. Finally, we have created new integration points by exposing the entire LEAP execution lifecycle to developers. By exposing various points along the execution lifecycle, we have created many more ways to insert transformations, context augmentations and asynchronous event generation.