Skip to main content

ESB As An Application Architecture

Printer-friendly version


Historical Background
In the early to mid-90s I made a substantial effort at recruiting officers and locating investment capital. I was looking to make a major enhancement of Computing Integrity’s suite of applications called Integrity/Solutions (I/S). I/S is a sophisticated, integrated suite of applications for automating central business functions of distribution companies. It has competed successfully head-to-head with Oracle Financials, PeopleSoft, and SAP. The primary goals for the enhancement were creating a browser client to replace the ChUI interface and to facilitate distributed deployment of the applications. To distinguish us from “yet another company selling distribution software” (YACSDS), the “sizzle” in our funding proposal was our Specification-Driven Development (SDD) tool that allowed us extremely rapid generation of very high quality P4GL.

At one point, I came very close to bringing in a very attractive VP Sales/CEO, but eventually he decided that the prospect was not sufficiently compelling. During the regrouping that followed, I came to decide that it appeared that it would be many years before the Progress product evolved to provide me with the development platform I wanted for distributed deployment, so I began looking at alternatives. This brought me to look at Forté.

In the early to mid 1990’s, prior to the coining of the SOA and ESB terms as such, Forté Software was a strong proponent of a focus on “services” as a primary structuring element in software architecture design. At the time, this did not strike me as a particularly radical approach in the context of a single, integrated application written in TOOL, the Forté OO4GL, but rather just as the fulfillment of a long term move toward modularization and encapsulation. One could, of course, say the same about services in an SOA, but in the end there is more significance to this focus on services and this was largely present in the Forté recommended architecture. One of the really compelling strengths in the Forté development environment was their ability to rapidly configure the deployment of these services across a distributed network for optimum performance and capabilities.

In the mid-1990s, Forté also introduced a product called Fusion aimed at the EAI market. Fusion integrated to applications using “adapters”, which utilized XSLT transforms to convert the native API of the application to and from standardized XML. The XML was then transmitted across a reliable messaging bus called the Fusion Bus to other applications. A workflow engine was responsible for directing traffic so that a sender did not need to know which recipient would receive a message or which sender had generated a message. The workflow engine also provided sophisticated logic for recognizing offline services, alternate routing, restarting of services, time-dependent routing, etc.1 The parallels with a modern ESB system and an orchestration engine are obvious.

In exploring this technology, I developed the idea that I could implement I/S as series of encapsulated applications that interfaced through the Fusion Bus. This would provide me with a number of significant advantages, including:

  1. A workflow engine to control the interaction between applications;
  2. The ability to run a mixture of P4GL and TOOL applications during the development process, thus allowing us to continue to have a product to deliver while the new product was being developed (a classic SOA benefit);
  3. The ability to substitute an external package for one of our applications, e.g., selling to a division of a larger corporation which mandated the use of SAP for the GL;
  4. A very direct way to implement distributed deployment, including multiple instances of some components, without any special development;
  5. A context in which it would be very straightforward to integrate with web applications; and
  6. An environment in which it would be easy to add specialized “mini-applications” to supplement the core offering.
AttachmentSize
ESBAsAnApplicationArchitecture.pdf99.45 KB