Network Computingwww.networkcomputing.com

The difficulty in developing salient criteria for evaluating middleware (besides the sheer complexity of the software and the multitude of products) is that middleware can, and should, be evaluated from the perspective of at least three distinct IT constituencies: application developers , network administrators and database administrators. These three groups evaluate middleware according to how well it "fits" their domain. Accordingly, organizations should involve all of these groups in their middleware selection process. A new IT discipline, infrastructure development, is evolving from such cross-disciplinary groups.

Unfortunately, the choice of middleware usually is made by application developers alone. Application developers tend to focus on a single middleware dimension: application transparency. Middleware is transparent to application developers to the degree its API matches the way they intuitively think about the data/service mediated by the middleware. A good example of this is embedded SQL, which enables application developers to think about relational data in terms of SQL (which is natural to them) and then simply write straight SQL expressions in the middle of their applications.

Another good example is the set of SAP business APIs (BAPIs), which offer business-level obj ects (customer, order and invoice, for example) via COM interfaces.

Application transparency is a continuum that ranges from the opaque network session layer up through the translucent RPC layer and out toward the ever-recedi ng horizon of absolutely transparent middleware. Although many pay lip service to the belief that APIs that are closer to the business-process level are better, there is a tension between an API that closely matches an organization's business-level needs and an API that is easy to learn. For example, consider a hypothetical application developer offered the choice between the entire SAP R/3 set of APIs and the APIs offered by Visual Basic. Even if some part of the SAP R/3 API directly addressed the application developer's needs, chances are she or he would pick Visual Basic because it's easier to learn.

A Multidimensional View of Middleware Although the application transparency dimension is an important one--perhaps the most important one--there are nine other dimension s along which middleware should be evaluated: Network and database performance, manageability, componentization, resource consumption (disk, memory, thread and process), reliability/availability/ scalability, standardization/portability, interoperability and services (naming and security).

These other criteria should be applied by individuals other than application developers, for they focus not simply on middleware's impact on application development, but also on its impact on other parts of the organization's infrastructure--including desktops, networks and databases. Given these additional analytic dimensions, the popular practice of buying an enterprise application package such as SAP does not offer any real escape from middleware complexity. Although such a purchase eliminates (or at least overwhelms) the middleware selection issue. Since one is buying a middleware framework as well as an application suite, it intensifies the middleware configuration issue.

Although application developers and in tegrators should look to middleware to provide transparent access to data and services, such transparency will never come shrink-wrapped. Organizations must develop and consolidate middleware expertise in individuals and groups who wil l work with application developers, network administrators and database administrators to select the appropriate middleware attributes for an application and who will then tailor the middleware to fit that application's distributed structure and pattern of use. Such middleware expertise will ensure that RPC mufflers fit MOM exhaust pipes.

Please welcome my new In The Middle co-conspirator Nick Gall. Nick and I often work together at META Group on middleware and application networking issues, with Nick's focus on the details of application-centric requirements and particular middleware products complementing my focus on networkability. Nick will alternate writing this column with me, adding to the scope and depth of this column devoted to middleware and client/server de velopment issues.

--Bruce Robertson

Nick Gall can be reached at Nick.Gall@metagroup.com.