Skip to main content

ESB As An Application Architecture

Printer-friendly version


What Is Required To Implement This Architecture
The OO features in 10.1A clearly have been a major leap forward in our ability to implement such architectures, particularly with respect to our ability to utilize proven design patterns from other OO languages. While there are certainly a variety of additional language features which could further facilitate such development, there are two significant problem areas that I see in integrating components into an overall application.

The first of these problem areas is fine-grained integration to create services where the obstacle is the single-threaded session. Here the requirement is for either a multi-threaded session or, at least, for a highly efficient fine-grained interprocess communication mechanism4 that would allow multiple sessions to behave as if they were part of a single service. See http://www.cintegrity.com/PDF/Multi-threadingUseCase.pdf for a discussion on the need for multi-threaded sessions.

The second of these problem areas is coarse-grained integration as is associated with ESB/SOA. From a technical perspective, this capability is clearly available, and available in exemplary form from Sonic, but the pricing of those products is geared toward the EAI market where per server prices of $10,000 or $50,000 can be easily justified in terms of the savings in development. In the context of the use of these technologies for a single integrated suite of applications on a single server, there is certainly still substantial value, but the additional infrastructure cost may well make the total cost excessive, especially if there are no EAI-type goals in the immediate development. Moreover, given the heavy use of tools in the proposed approach, the ESB products will not provide the same kind of development savings that would be experienced in a typical EAI project since the one time investment in MDA will be applied at many sites.

There seems to be two methods by which this problem of entry level price could be solved:

  1. Progress Software could elect to publish source code for the Sonic adapter or, at least, a generic JMS version of the adaptor so that developers with a need for ESB/SOA integration could utilize open source alternatives to Sonic. This still puts a lot of burden of development on the individual developer and results in the use of what is almost certainly an inferior tool.
  2. Sonic Software could offer a licensing solution which was tailored to this one application, one machine environment, but which also provided a graceful extension as new requirements were developed. This licensing solution needs to cover such added value products as the Orchestration Server in order to provide full value.

Of these options, the second is the far superior option since it provides the robust quality of Sonic software so that one may obtain the highest quality ABL solution. One should observe that the options are not mutually exclusive and there is some argument in favor of implementing the first solution, regardless of whether the second is implemented. The current IT environment is not one in which vendor lock-in is regarded favorably, especially when it is via a mechanism such as failing to provide source code for a key interface.

The obvious difficulty is in arriving at a licensing model that provides an equivalent or greater revenue stream to Progress while enabling small sites to use the products affordably. I think it is important to recognize:

  1. The primary difficulty is with respect to an initial licensing solution. Once a company has made a transition to a single application, single computer ESB/SOA implementation, it is highly likely that opportunities will be developed for distributed deployment, supply chain integration, and the like. As these will be new, some additional license cost will be justified and acceptable, especially since the modernized architecture will facilitate the implementation. Thus, there is a high probability of downstream new license revenue. Of course, this does require a structure in which there is no sudden painful jump in license cost in relation to one of these transitions.
  2. For customers who are not using CI’s whole application transformation service or not doing their own whole product transformations, the attraction of a low cost entry license would be that it would make a pilot project economically justified. If there is a graceful growth path, this is another context in which one can expect additional license revenue as additional projects are undertaken.
  3. Part of the licensing problem here is one that is common to a number of “enterprise” oriented products, i.e., if one has clearly established a need, determined that a product is the correct solution, and decided that one is committing substantial resources to that product, then a cost of $10,000 or even $100,000 can be justified, but if one is only intending a pilot project and does not know how extensively the product will be used, then these large expenditures are difficult to justify unless the context is one in which one can get payback on the first project. This contrasts with licensing models in which there is a more step-wise pricing which can scale according to the level of usage.
AttachmentSize
ESBAsAnApplicationArchitecture.pdf99.45 KB