Skip to main content

ESB As An Application Architecture

Printer-friendly version


The packages in use at sites needing modernization will typically be suites of integrated applications, like I/S, possibly with additional non-integrated packages, some of which may not be in ABL. This is a prescription for ESB/SOA, even if all applications are currently integrated because:

  1. Externalizing workflow will make the company far more nimble in responding to changed business circumstances;
  2. Encapsulation of applications as services in an SOA will allow on-going evolution of software components without disruption;
  3. New major and “mini” applications can be readily integrated via the ESB;
  4. Integration to web services will be extremely straightforward;
  5. Supply chain integration will be greatly facilitated; and
  6. If any non-ABL applications are in use, they can be integrated via the ESB and evolved as appropriate over time.

In short, every benefit of ESB/SOA that applies in an EAI context, also applies to an integrated collection of applications, even if they are entirely within the company, tightly integrated at the onset, and all written in the same language. One may not initially use all of the capabilities of an ESB, e.g., a tightly integrated suite will not need XML transform functions, but these capabilities are immediately available should they become necessary, e.g., when initiating supply chain integration.

Thus, it is my position, just as was argued in the context of the Forté tool set, that any time we have multiple interacting applications, it is appropriate and beneficial to use ESB/SOA as the underlying architecture. I believe this is where OERA is pointing us. Interestingly, one of the big advantages of Forté prior independent of Fusion was their highly flexible ability to configure distributed deployment of components. Fusion extended this to other applications and added the workflow engine. A modern ESB/SOA tool such as Sonic achieves a similar kind of distributed deployment flexibility combined with the workflow engine, but does so from “the other end” as it were. Thus, for me, Forté gave me distributed deployment in the base tool set and Fusion added workflow and the potential for interconnection with other applications, but in the present, the distributed deployment, workflow, and potential interconnection all come from the EAI toolset.

AttachmentSize
ESBAsAnApplicationArchitecture.pdf99.45 KB