Coarse-grained COTS Software Component Architecture, Integrated by Programmable Middleware; New Human Computer Interactions.

John A. Bayless, Ph.D.

Introduction

This paper describes Software Component Architecture using programmable middleware to integrate entire COTS (commercial-off-the-shelf) software products as components. It possesses new qualities of HCI (human-computer-interactivity) synthesized by properties of the architecture, and supports new actionable cognitive-behavioral HCI possibilities, not anticipated before they emerged during system observation. These HCI phenomena have become visible for the first time, having apparently been initialized in the concrete realization of the architecture, because of properties specific to the inclusion and role of programmable middleware in the design.

Initial objectives of the project were to [1] greatly simplify design and development of software to do systematic, asynchronous, user-driven work, such as research users need in long involved tasks requiring frequent expert user judgment, [2] enable computer-capable, but non-computer science professionals, to design and build software suites to do complex practical tasks advancing their work. The model is a workbench, and bench tools devised and needed by intellectual craftsmen, for idiosyncratic, personal, expert professional use. Version 1.0 described here is one example. Other COTS components can be quickly installed to create radically different suites, the major objective of the method. Executable software components and elements already in the user’s repertoire can be integrated into an overall architecture with the COTS components as well.

The architecture concept was successfully built, and the software and methodology were exercised over 10 following months of producing experimental application prototypes. The unanticipated actionable properties of the architecture were noted and observed, which are of interest in computer science and computational cognitive science. They appear to be a fruitful new research area, and are discussed in the last two sections.

History, Rationale, and Methodology

The writer became interested in the potential of programmable middleware to accomplish the practical objectives stated above in mid 1995, on being exposed to a primitive early version of such software, and began monitoring emerging products, and computer science and engineering literature. These objectives were refined and a development strategy formulated. A proposal presented to US Army Logistics Integration Agency in February 1998 was funded in August 1998. The concept, middleware, and components were demonstrated in November 1998, prior to an integration accomplishment and architecture build. Work funded privately in April 1999 enabled reduction to practice and prototype development. It was rolled out at a Federal CIO Council Expo February 23, 2000.

Rationale for a middleware approach to a COTS-component architecture was visualized almost immediately upon initial exposure in 1995. Although the component architecture model initially appeared in terms of objects as components, the main reason discouraging consideration of stand-alone commercial products as components has been the daunting complexity of structural architecture matching and mating such components. In systems dealing with user interaction, the programmable middleware sidesteps this issue. Second, ‘products’ are unambiguous concepts to users for whom the model was evolved. Third, the practical technology for facilitating application products in large computer systems evolved as middleware. Its functionality varies, but in client-server settings middleware provides services between operating systems and application software including [1] internal messaging and communication, [2] environment application links analogous to APIs, [3] transaction monitoring or auditing, [4] gateways to other services and applications, and [5] data connection. Services vary as one goes up or down scales of cost and scope, but these are typical. The writer’s insight was that programmability could potentially extend any attribute of architecture virtually, into a particular middleware’s other native capability.

Programmable middleware as such, receives very scant mention in computer science literature, which was a major surprise. A review in 2000 by Bachman, et al., of the SEI at Carnegie-Mellon, cites only 2 (!) articles, a 1995 paper by J. Bergstra at the University of Amsterdam describing a scripted “toolbus” in an early stage of design at the time, and a 1998 paper by Berry on Finesse, a language for manipulating abstract bindings among large scale components. The writer verified in Mar 2001 by a search for ‘programmable middleware’ and related terms on multiple search engines, that this is still the case.

A research commitment was to create the entire architecture model infrastructure from COTS products. Inventing infrastructure and new tiers in infrastructures is too difficult. Paramount questions are: Is this objective practical? Is it feasible to hope to empower technically capable, non-computer science professionals thus, given the technology limits of the market? Is architecture possible within those limits? The critical path had to lead to COTS infrastructure with features supporting interesting workbenches and commercial vitality to ensure practical longevity and successive technology upgrades.

Analysis of OEM (original equipment manufacturer) mid tier products revealed products with some or all integrating functions of middleware not described as ‘middleware’ by OEMs for business model reasons. Products with long user experience, stable platform support, and ubiquity, possessing integrating functions, plus programmability, did exist.

The COTS product selected was a programmable support platform tier produced by the OEM as infrastructure for their own manufactured large-scale enterprise software. The OEM business model focuses on sale of their vertical market products supported by the platform, and only incidentally on sale of the middleware itself. The term ‘middleware’ is not used in their product literature, but the descriptions following will make clear how it meets the rule. Personal communication between the writer and many of the OEM top technical and engineering design managers agree this is an accurate characterization.

Four Large-grained COTS Components were selected. They include [1] a portal to data, work groups and workflow, [2] support for geospatial work display and logistics user workflow cognition, [3] EDI mapping with services across many commercial domains, and [4] automated records management (which is DoD Standard 5015.2 compliant.)

Choices reflected the writer’s desire to create a demonstration that could be programmed to show off applications to a wide audience. A capable-user should be able to produce specifications from the user’s domain of applications, at the same level of abstraction. Design at the level of selecting COTS products determines the features and code base of the system. The end user thereby has detailed specification influence not typical of “big” software design.

With infrastructure and components chosen, their resource connections are now the nodes of many possible user layouts, with fluid native capabilities. This is the desired result. Design is now adaptable to the capableuser’sexpertise: Design always structures the user’s process. Instead of conforming user process detail to structural detail necessity, this process known best to the user can be laid out in large fluid chunks bytheuser. This design model now acceptsuser choice uncertainty. The user can now think about interventions, and create required access to the run-time process. The product evaluation is for suitability to userprocess, rather than infrastructure plumbing. The expert user’s workbench preferences can now structure a bench-tool process design, almost completely idiosyncratically.

The following figure summarizes the architecture as defined after the technology review, at the end of the design phase.

Figure 1. Characteristics of the Suite at the End of the Design Phase

The first three bullets characterize the design attributes as ‘system’ in summary. Bullets at the bottom list Coarse-grained Architecture Component capabilities. COTS product components and summaries of their features are identified in Figure 2.

Architecture Overview

Architecture is designed structure and infrastructure that ‘stands up’ components of an entity and permanently establishes relationships between them. In software engineering, architecture applies to tiers of permanent logical and electronic structure for logical data and meta-data ‘piping’ between software and hardware components. The following is a summarized structural image of the suite. It is an as-built example of the possibilities afforded by programmable middleware integrating COTS components. This approach to establishing the architecture, successfully avoided the problem of designing and building a new tier of permanent structural logic to mate plumbing and wiring differences of fully completed COTS software components. It also has synthesized and virtual aspects that support new HCI qualities, which appear to have been synthesized from within the suite as built, and establish additional value, or raison d’être, for application and study.

Figure 2. The Coarse-grained COTS Component Architecture Suite As Built

The architecture components are named here, as well as characterized, to emphasize that this is truly an architecture of COTS commodity software products. These are out-of-the-shrink-wrapped-box, unmodified, standalone, commercial products. They do not need each other, or the middleware, in their regular business lives. Not included here, but part of the system, is Microsoft Back Office, mounting the middleware and products on NT Server 4.0, providing MS Exchange e-mail services, Outlook e-mail client, Microsoft IIS web server, Internet Explorer 5.5 browser client, and SQL Server, data base to workflow resources, all of which are also employed in the suite. This was a convenience since NT 4.0 Server platforms the middleware. Other e-mail servers, ODBC databases, web servers, and browsers are equally workable.

Drawing on the functionality of the four integrated components, a runtime engine native to the middleware, serves process-centric, agent-triggered, middleware-built, workflow automation to the users of the system,. With different COTS software components using the same middleware and methods, the suite functionality would be totally different.

Many possibilities are afforded by the model. New levels of access to design, software system building, and application development is now exposed to capable users who are not software engineers or computer science professionals. Self-initiated capable-users are not required to see interior plumbing to add components, or with minimal assistance and mentoring, to specify, design, build, program, and use a kind of ensuite software based on attributes of the architecture, provided by the middleware.

The architecture’s centrally positioned attributes, native to the middleware, include:

  • Resource links to data anywhere in the world, reachable through LAN or WAN and TCP/IP, or dialup telephony.
  • Links that integrate external application software—the COTS components.
  • Application building/programming environment creating ‘suite-oriented’ application building perspective. The application builder has a view from which to program all integrated COTS products simultaneously, from the highest level in the system.
  • Comprehensive suite applications use and control the executable resources of all COTS software components at runtime, from one central middleware runtime engine.
  • Centralized workflow programming tools in the application builder, referencing the entire data environment, enable the embedding of inter-component runtime data messaging within every user application program.
  • End-to-endprocess automation service to all users, draws on any linked data and integrated software. Different users instantiating different applications software are served data messaging and inter-component workflow automatically.
  • User interaction GUIs are web browser screens. The middleware application builder authors web sites and built-on-the-fly interactive web pages, sent by the runtime engine to an IIS or Netscape web server, supporting runtime user interaction
  • ActiveX controls and Javascript are not required or used for web automation by the middleware application builder. They are available as extra automation features, or may be omitted entirely, should user security so require.
  • Computer-telephony integration also provides voice-enabled services, optionally including high-end voice, speaker, and natural language recognition,.
A. The Middleware View

The middleware view is in the bottom half of the following graphic.

Figure 3. Summary Structure and Features of the Programmable Middleware.

The two outside blocks in the top row are user connection functionality. The two inside blocks are data connection resources and a software agent pool, respectively.

  • The middleware creates user interaction GUIs through a native web site publishing capability, producing built-on-the-fly pages, with control, text, and data input for real-time user interaction and manual workflow intervention. Pages served to the user’s PC browser provide the primary GUI interface and user screens. They afford users text and graphic work output from the functionality created by the entire suite and its applications, and interactive input controls and data entry fields for entering human judgments and interventions in the runtime automation.
  • The application builder includes a web page editor among its tools. Most third party tools such as DreamWeaver can also be used for authoring. Their HTML files are re-opened in the native editor to have middleware-specific control tags added. The use of outside tools especially, affords the capable user/designer state-of-the-art control over every multimedia detail of interactive system GUIs. The middleware publishes pages at run-time to IIS or Netscape web servers.
  • In addition to this PC-and-browser interface, the middleware provides computer-telephony integration and has telephony, fax, pager, WAP resource connections, and optional high-end interactive voice recognition and text-to-speech capability. The voice recognition features include speaker recognition, vocabulary to 200,000 words and phrases, and recognition through regional accents and imperfect grammar. In a group research setting the workflow can generate and complete remote telephone or pager messaging to team members who may be across a campus or across the world, in real time, in correlation with workflow events. For example, to wake up and logon to observe crucial experimental events. Fax and pager text can be sent in the same way, composed dynamically by the workflow and transmitted to a single recipient or to a hundred-member research team.
  • ODBC database client and host-terminal access to hosted legacy data are provided. Major RDBMS products such as Oracle can be accessed directly with middleware registered clients. Product with registered ODBC drivers, from Excel spreadsheets to statistical analysis products such as SPSS or Systat, can be reached as data sources, or to receive computed data from the full suite. Terminal emulation products such as NetManage provide mainframe host access via 3270, 5250, VT-100, other emulated terminals. The system learns and retains host screen navigation to provide networked hosted data and application connections.
  • Basic software agent services are allocated from a pool to monitor web job logon pages, allocated telephony job phone and fax lines, clocks, database conditions, the integrated application conditions, other triggering events. When an event such as a user logon occurs, the agent instantiates and runs assigned stored workflow services, initiates services and actions requested by the user, interprets user trigger events such as the mouse clicks on web page controls, and supervises jobs internally according to the evolving conditions created by the user. When simultaneous users are logged on, separate agents are assigned to each user, instantiating entirely separate conditions and jobs for each user. In a single middleware-server node system, up to 30 users can be accommodated simultaneously. In multiple node systems each middleware server node can accommodate from 250 to 280 simultaneous users. Some large commercial OEM installations have in excess of 850 or more nodes, deployed worldwide, able to serve well over 225,000 simultaneously logged-on, distributed users..
  • Integrated COTS product architecture components are lumped in the red block. Although this effort focused on COTS product components, any well-behaved executable software reachable through the system links can be integrated, including legacy, custom-built, or experimental software in the user’s portfolio, and COM objects.
B.Component Mating and Data Messaging

Each product is linked to the middleware, which functions as the backbone of the suite, through an idiosyncratic combination provided by the product’s native APIs, shared databases, and the DLL and NT Command objects of the of the application builder and runtime engine. Registering COTS product DLLs and their functions in the middleware library services, allows the application builder to reference, and the runtime engine to directly access, product DLLs and their functions through DLL objects in compiled automated workflow jobs, created in the application builder. This software application integration linkage, analogous to an API, is common to all application software in the middleware environment, i.e., the COTS product components

Similar application builder reference and runtime engine access is provided by an NT Command object. Command objects in the workflow stream cause NT commands to be executed, and make it possible to wrap command line scripts within Command objects. This enables construction of original command line scripts embedded in compiled C++, callable as primary tasks, or as workflow subroutines.

Abstract and practical design factors arise from the locale of DLL integration and Command Line objects as resources situated in the middleware application builder and runtime engine, as follows:

[1] They enablejust-in-time coupling of component resource connections,

[2] to data connections allocated just-in-time by a runtime code stream,

[3] exchanging application run-time values between components and workflow