Domain-Specific Metacomputing for Computational Science: Achieving Specificity Through Abstraction By Steven Hackstadt

We seek to "synthesize" the area of domain-specific metacomputing for computational science in this chapter. We begin with a broad overview of the preceding chapters. Next, we integrate the component technologies of the area by discussing three key "integrating concepts" common to all of the technologies discussed earlier. These concepts are nonfunctional requirements, software frameworks, and abstraction. Each concept has a direct bearing on a specific stage in the lifecycle of software (i.e., design, implementation, and use). Given this foundation, we speculate on the actual construction and evaluation of domain-specific metacomputing environments and conclude by identifying the key open questions in the area.

Overview

We propose three broad requirements for domain-specific metacomputing for computational science in Chapter 2: high performance heterogeneous computing, software design and development, and domain-specificity. Subsequently, we suggest that three broad, enabling technologies collectively address these requirements: metacomputing, software architecture, and domain-specific environments. The intricate relationship between the requirements and technologies of domain-specific metacomputing for computational science is depicted in Figure 5, where each requirement is addressed in a primary way by one of the technologies and in a secondary way by another technology. Only together can these technologies fully address the needs of this emerging area. Chapters 3, 4, and 5 bear out these relationships in extensive detail. In addition, the chapters present other research that is relevant to domain-specific metacomputing for computational science.

Since performance is so central to a scientist's ability to conduct simulation-based research, we consider parallel and distributed computing to be the foundation of metacomputing for computational science. Chapter 3 examines the major development efforts in metacomputing and also explores several other projects addressing related issues such as real-time system information and application scheduling. The primary goal of the work in metacomputing is achieving high performance in heterogeneous computing environments. Many of the projects, though, also emphasize the software design and development process, employing modular frameworks or object-oriented approaches.

To address issues of software construction in a more direct way, Chapter 4 seeks out supporting research in software engineering. While ultimately focusing on software architecture and domain-specific software architecture, in particular, the chapter also explores the role that object-oriented technology plays in the parallel and distributed computing community. These techniques, in addition to offering improved methods for software design and development, also facilitate the integration of domain-specificity into software.

Finally, supporting efforts within (or at least targeting) the computational science community to develop computational support environments are discussed in Chapter 5. Two main technologies, problem-solving environments and domain-specific environments, are presented. These environments exhibit different types of domain-specificity, and we ultimately conclude that domain-specific environments are better suited to the challenging and exploratory problems in computational science. In addition to domain-specificity, though, access to and delivery of high performance computing capabilities is central to both types of environments.

The Role of Nonfunctional Requirements in Software Design

We consider parallel and distributed computing to be the foundational area for domain-specific metacomputing for computational science, with software engineering and computational science taking on supportive roles. With performance so central to many scientists' ability to conduct their work, this seems a reasonable enough approach. But actually, this only represents one perspective of domain-specific metacomputing.

In earlier chapters, we refer to nonfunctional requirements and their effect on design and implementation decisions. Sommerville ([Somm89], p. 101) describes nonfunctional requirements as restrictions or constraints placed on a software system and notes that nonfunctional requirements typically interact and conflict with the functional requirements of a system. Our view of nonfunctional requirements is consistent with this, if not somewhat more general.

The nonfunctional requirements of a software system are, by nature, often hard to recognize. They are even harder to express in a formal way. Sommerville ([Somm89], p. 88-89, 101-102) indicates that analyzing nonfunctional requirements can be difficult for several reasons: they are often expressed in natural language; the relationship between nonfunctional requirements and functional requirements is not always easy to discern; and, when the relationship is understood, nonfunctional requirements often relate to multiple functional requirements. Furthermore, failing to meet nonfunctional requirements results in what are generally accepted as being the most costly problems to fix once the software is complete. Yet, nonfunctional requirements have received relatively little research attention [MCN92].

Indeed, recognizing, expressing, and analyzing nonfunctional requirements poses a significant challenge to the software designer. In fact, our choice to "base" domain-specific metacomputing for computational science in parallel and distributed computing results from our (implicitly stated) perception that performance is a very critical nonfunctional requirement for this area. To that end, we naturally take a performance-centric view of the problem. However, we could equally well take a software-centric view and consider the software engineering problems to be the most crucial. Or, we could take a domain-centric view and approach the problem primarily from the standpoint of (a particular domain of) computational science.¹ The best approach to a given problem -that is, the perspective a software developer takes toward a system-ultimately depends on their perception of the relative importance of numerous (and possibly unstated) nonfunctional requirements.

A good example of how nonfunctional requirements can affect the design process is seen in how a developer might go about integrating domain-specificity into a metacomputing environment. Domain-specific software architectures and domain-specific environments each offer a means of addressing this requirement. DSSAs support a formal model for integrating domain-specificity into the fundamental design of software. With an emphasis on careful software design, this approach may be best suited to nonfunctional requirements like reusability and reliability. DSEs, on the other hand, support more informal methods of achieving domain-specificity and place a greater emphasis on the actual development of the underlying software. This tends to result in systems that better satisfy nonfunctional requirements like flexibility, extensibility, and interoperability. Similar scenarios surrounding the requirements of high performance heterogeneous computing (generic metacomputing systems vs. domain-/problem-specific support) and software design and development (informal, convenient use of basic software engineering techniques vs. formal application of software architecture) also exist.

In this way, our organization of requirements and technologies for domain-specific metacomputing, as depicted in Figure 5, creates a "solution space" within which nonfunctional requirements may be used to discriminate between various design and development options. As we have stated earlier, nonfunctional requirements often result in trade-offs, both with respect to other nonfunctional requirements as well as the functional requirements they impact.

There are numerous nonfunctional requirements that may be of interest to domain-specific metacomputing for computational science. Unfortunately, a complete list of nonfunctional requirements does not exist [MCN92], and it is beyond the scope of this work to determine and describe just the ones applicable to domain-specific metacomputing. Several examples of nonfunctional requirements, however, are derivable from our discussion so far: extensibility, flexibility, interoperability, performance, programmability, reliability, reusability, and usability. Sommerville ([Somm89], p. 101) offers a few more common nonfunctional requirements for software: speed, size, robustness, and portability. Mylopoulos et al. identify three broad categories of nonfunctional requirements. In addition, for each category, they list several user concerns and associated nonfunctional requirements. Their classification is recreated in Figure 9. In a separate dimension, they also classify nonfunctional requirements with respect to who observes them. For example, nonfunctional requirements like efficiency, correctness, and interoperability are "consumer-oriented"-that is, observable by the user. Other requirements, such as extensibility, reusability, and maintainability are "technically-oriented"-that is, they are apparent to the developer [MCN92].

FIGURE 9. Three categories of nonfunctional requirements showing examples of user concerns and the nonfunctional requirements that address them. (Figure adapted from Mylopoulos et al. [MCN92].)

Thus, nonfunctional requirements ultimately impact the design phase of the software lifecycle, "serving as selection criteria for choosing among myriads of decision" [MCN92]. An explicit consideration of nonfunctional requirements can assist in design decisions, but the method in which this happens can vary. Cuny et al. [CDHH96], for example, take a very informal approach in which three nonfunctional requirements (i.e., extensibility, programmability, and interoperability) act as guiding principles in the subsequent design and implementation of the components in their environment. Bruegge et al. [BRRM95] pursue a more explicit method, though much more formal approaches, such as those from the area of requirements engineering, also exist.

The Role of Frameworks in Software Implementation

Many of the tools, systems, and approaches discussed in the previous chapters are built as, or claim to support, a framework to do one thing or another. Like the informal and inconsistent use of the word "architecture" when describing software structure ([SG96], p. 16), this term, too, is widely used and means very different things to different people. While the word is not always intended to be a precise, well-defined term (that is, it may be used in a vague, descriptive sense), authors often do offer informal, or at least implicit, definitions. Only by sampling the literature can the diverse contexts of use be revealed.

To begin, the term "framework" is often applied to collections of interoperable tools.² The software infrastructure that maintains open interfaces, provides tool access and control, and supports functionality common to the entire toolset is called a framework:

Vendors of these tools increasingly support some framework³ that defines the relationships among tools, whereby tools from different vendors can be intermingled by a user in a plug-and-play manner.... (Rover et al. [RMN96])

We discuss the development of an integrated framework for heterogeneous network computing, in which a collection of interrelated components provide a coherent high-performance computing environment. (Dongarra et al. [DGMS93])

[We] hope to provide a common framework with a graphical user interface from which [users] can access all the data management, analysis, visualization, and computational tools and services they need.... [The system should] serve as a framework tying together the underlying pieces and providing a coherent interface. (Bruegge et al. [BRRM95])

A framework is a reusable object-oriented analysis and design for an application or subsystem. An application framework provides a template for an entire application.... A subsystem framework provides a set of services that are relatively independent of the rest of the system. (Coleman et al. [CABD94])

A framework provides an integrated, layered system of objects. Each object in the framework is composed of or utilizes objects from lower layers. [It] defines an interface in which the users, who need not be familiar with object-oriented programming, express the fundamental scientific content and/or numerical methods of their problem.... (Reynders et al. [RHCA97])

The common framework that enables a coherent solution to these problems is object-orientation. (Grimshaw and Wulf [GW96])

Frames... provide support for the programming of distributed memory machines via a library of basic algorithms, data structures and so-called programming frames (or frameworks). The latter are skeletons with problem dependent parameters to be provided by the user. Frames focus on re-usability and portability as well as on small and easy-to-learn interfaces. (Romke and Silvestre [RS97])

[A framework is] an object-oriented style of programming where a pre-existing environment provides a top-level object or objects within which all others are nested.... It is intended that the user... instantiate, modify, and "frame" together objects... to create a numerical application.... A frame-based system is designed to drive the user code. (Armstrong and Macfarlane [AM94])

Basically, a framework can be seen as a semi-finished program that not only packages some reusable functionality, but also defines a generic software architecture in terms of a set of collaborating, extensible object classes. (Demeyer et al. [DMNS97])

The objective of this work is to design a framework for building computer environments that provide all the computational facilities needed to solve a target class of problems.... (Weerawarana et al. [WHRC94])

Amplifying this capacity for architecture reuse, we also provide a framework for developing software components that can be reused and reconfigured easily in a large domain of applications. (Hayes-Roth et al. [HPLM95])

[We] present... a representational framework that captures the structure of heterogeneous applications and the interactions between their components. (Anglano et al. [ASWB95])

Design patterns are frameworks that software engineers can use to communicate the pros and cons of their design decisions to others. (Ramamoorthy and Tsai [RT96])

Certainly, the excerpts suggest a variety of benefits that can be derived from frameworks, regardless of the particular type being used. These benefits include properties like abstraction, communication, customizability, extensibility, interoperability, productivity, retargetability, and reusability. Indeed, Demeyer et al. [DMNS97] point to the important role that frameworks play in constructing open systems that exhibit high degrees of interoperability, distribution, and extensibility. Not coincidentally, many of these characteristics correspond to the nonfunctional requirements of the previous section. To that end, we argue that frameworks facilitate the implementation of the nonfunctional requirements most important to the contributing technologies of domain-specific metacomputing for computational science.

First, we already know that a system's nonfunctional requirements and the designer's perception of the software are closely related. Second, each of the possible perspective views toward a domain-specific metacomputing environment-performance-, software-, and domain-centric-has a natural correspondence to one or more of the framework types described above.

For example, a performance-centric perspective would likely result in the use of a tool framework, allowing individual tools and components to be optimized for maximum performance while still participating in a larger computational environment. Examples of this perspective/framework pairing include the Globus metacomputing toolkit [FK96], AppLeS application-level schedulers [BW96], the p2d2 parallel debugger [CH94, Hood96], the DAQV distributed data access system [HM96, HM97], the PVM message-passing library [DGMS93], and the GEMS [BRRM95] and TIERRA [CDHH96] domain-specific environments. In addition, Rover et al. [RMN96] consider the differences between "integrated environments" and "toolkits" (both of which are framework-like approaches) as they pertain to tools for high performance computing.

A software-centric view, depending on the nonfunctional requirements motivating it, might utilize a software construction programming framework or a more formal design framework to support the desired software engineering paradigms. Relevant literature to these pairings include Manola's concern for interoperability in distributed object-systems [Mano95], Heiler's work on semantic interoperability [Heil95], a DSSA-based adaptive intelligent system by Hayes-Roth et al. [HPLM95], models for composing multiple (software) architectural styles [AB96], issues related to software composition [NM95], and the approach for constructing scalable software libraries put forth by Batory et al. [TBSS93].

Finally, a domain-centric system view might focus on the rapid creation of real application codes, making a program template or object-oriented programming framework most applicable. Systems meeting this description include parallel object-oriented plasma simulation by Norton et al. [NSD95], POET [AM94], POOMA [ABCH95, RHCA97], the programming frames approach by Romke and Silvestre [RS97], and the Concurrent Archetypes project [Chan94].

It is most definitely the case that other system views and framework types exist-if not for domain-specific metacomputing, then certainly for other problem areas. The views and types described here are merely derived from the component technologies and requirements of domain-specific metacomputing. In general, we simply propose that frameworks provide a means of implementing nonfunctional requirements and that the best type of framework for the task is a product of those requirements and the developer's perception of the system.

The Role of Abstraction in Software Use

An abstraction reveals the salient features of an entity and simultaneously hides unnecessary, underlying detail. Abstraction is a dominant theme in the evolution of computer system hardware, programming languages, and software development. Indeed, many of the systems and concepts discussed in earlier chapters exhibit various types and layers of abstraction.

For example, the Globus metacomputing project [FK96] proposes a "metacomputing abstract machine" to which applications and services may be targeted. This abstraction is layered on the Nexus communication library [FKT96, FGKT97] (among other components), which supports several lower level abstractions (e.g., nodes, contexts, threads, links, etc.) for interprocess communication, data sharing, and remote function invocation. At a higher level, the PVM/HeNCE environment for heterogeneous computing [DGMS93, BDGM96] interacts with the user via a graph-based abstraction to parallel programming, where nodes represent procedures and arcs represent data dependencies and control flow. Object-orientation is often touted for its ability to support abstraction, as in the Legion metacomputing project [GW96], object-oriented parallel computing [NSD95], and the POOMA framework [ABCH95, RHCA97]. As illustrated by these examples, we are particularly interested in the use and purpose of abstraction in the development of software. Figure 10 illustrates the numerous and increasing levels of abstraction for programming and software development that have emerged over time (and continue to do so).⁵

FIGURE 10. The level of abstraction for programming and software development is continually increasing, yielding larger conceptual "building blocks" ([SG96]. p. 12) for constructing software systems.

The figure reveals an interesting trend. Many of the modern developments in programming languages and software engineering have been motivated by the desire to work at a higher conceptual level. Abstraction is both a driving force behind the development of, and a powerful tool for using, the new technologies that allow us to do this. With respect to programming languages, Sebesta defines abstraction as "the ability to define and then use complicated structures or operations in ways that allow many of the details to be ignored" ([Sebe93], p. 15). The same definition largely applies to software engineering as a whole. The purpose of abstraction is to preserve access to the most relevant features and make the details which enable them wholly irrelevant. We often distinguish between interface and implementation; abstraction is what creates this separation.

Computer science is replete with examples of abstraction, which is often motivated by the insight that a repeated, complex operations can be represented symbolically. For example, assembly language first allowed the programmer to use symbolic names in place of machine operation codes and addresses ([SG96], p. 12). Eventually, certain useful patterns of execution emerged like evaluating arithmetic expressions, conditional statements, and loop constructs. These patterns were reflected in early high-level languages like Fortran ([SG96], p. 13). Each of these advances represents an increase in the level of abstraction.

The introduction of high-level languages and abstract data types, however, began to shift the target of abstraction from the language itself to language constructs. Procedures and functions serve a role that is analogous to assembly language commands and language statements for loops: they replace commonly used, unimportant, and/or complex details with a single symbol. Objects and classes refine the technique further, providing a more explicit distinction between interface and implementation.

Finally, as the need for abstraction exceeds what is possible for primitive language constructs to address, attention is shifting to a broader view of overall software structure. Libraries are, of course, a well-established, well-understood abstraction for software construction. Class hierarchies, too, have become a common software abstraction. Libraries and class hierarchies both represent yet larger conceptual building blocks for software developers. But many of the proposed abstractions remain topics of active research. The development of a module-based abstraction, which is to libraries and class hierarchies what objects and classes are to procedures and functions, continues to be refined today despite its origins in the 1970s and continued work throughout the 1980s ([SG96], pp. 13-14). Template-based and archetype abstractions are being applied with limited success (e.g., Armstrong and Macfarlane [AM94], Chandy [Chan94], and Romke and Silvestre [RS97]) though their wide-spread acceptance and use remains at large. Finally, frameworks, while already being applied in a variety of ways (as described in the previous section), have yet to emerge as a well-defined abstraction for software development, though research results are beginning to appear (e.g., Demeyer et al. [DMNS97]). Likewise, efforts are being made to promote abstractions within software architecture (e.g., the analysis and use of software styles), but this, too, remains an area of active research.

As the level of abstraction increases, so does the target audience. For example, many of today's "end users" of high performance computing systems could fill in the stubs of a template to instantiate a parallel program (e.g., as in the POET system [AM94]), but the vast majority of them could certainly not create the assembly code, much less the machine code, to effect the same functionality.

Abstraction is by no means unique to programming and software development. Other areas of computer science also embrace abstraction. Graphical user interface creation tools allow interfaces to be constructed from a palette of predefined "widgets." (XForms by Zhao and Overmars [ZO97] is an example of such a system.) While this type of programming is similar to a component-based approach, the user's interactions with the system are at the user's level. That is, the environment allows the user to interact with important functionality (e.g., scroll bars, dialog boxes, buttons, etc.) without having to explicitly deal with the low-level details (e.g., windowing library calls, event loops, callbacks, etc.).

Indeed, abstraction can have a significant impact on the usability of software by end users. It is not surprising, then that the concept also thrives in commercially produced software. Scientific visualization environments, for example, support many levels of abstractions. Low level graphics primitives are accessible through higher level visualization abstractions like surfaces, contours, and glyphs. Visualization programs can be created by wiring together preprogrammed modules to create a data flow network that loads, formats, analyzing, and renders user data. Similarly, applications for creating multimedia presentations often employ user interface metaphors that reflect a high degree of abstraction. For example, the user might be able to compose a "cast" of "actors" and write a "script" to "direct" the presentation. Later, "set changes" and "special effects" could be also added. In theory, metaphors like this engage the user and give them a vehicle to understanding the software's functionality. In this way, abstraction functions as a lens through which users can see how software can be used to address their needs. Thus, abstraction ultimately impacts software usability.

Given this, we now consider the role that abstraction plays in domain-specific metacomputing for computational science. In fact, abstraction is applicable in all of the ways we have just described. Clearly, the construction of metacomputing environments already benefits from existing programming and software abstractions. We feel that emerging abstractions like software architecture and frameworks should also be brought to bear on this problem. But an equally important role for abstraction is to improve scientists' access and use of future metacomputing systems. We state domain-specificity as a requirement for this area, but "domain-specificity" is really just a type of abstraction. Domain-specific abstractions can be layered on top of metacomputing environments to convey the salient functions and characteristics of the environment (e.g., performance capability) in terms of, and with respect to, the domain in which the scientist works.

Specificity Through Abstraction

Thus, it is ultimately through a process of abstraction that metacomputing can be brought to bear on specific domains of computational science: specificity through abstraction.

The notion that software can be made more precise, more specific, and ultimately more usable through a process that seeks to replace lower-level details with higher-level concepts-that is, achieving specificity through abstraction-is somewhat counter-intuitive. The key to understanding this is a consideration of the perspectives from which software is viewed.

Developers typically take a bottom-up approach, seeing the underlying mechanisms and specific technologies which make up the software. That view may be performance-centric, software-centric, or even domain-centric, but as developers they possess intimate knowledge of the system and understand how to use it.

Users, on the other hand, look at software first for what it can do for them and how it fits into the problems they are trying to solve. Parallel and distributed computing has proven difficult enough for scientists to exploit; metacomputing technology represents an order of magnitude increase in the problem. The capabilities must be delivered in a domain-specific way that scientists can actually use. A process of abstraction builds up the "domain-specific lens" through which a user-a scientist-can determine how to apply a particular system to their problems. Or, to employ another metaphor, Figure 11 illustrates how abstraction creates a bridge between low-level system detail and low-level domain knowledge.

FIGURE 11. Software abstractions form a bridge between the low level system details that developers understand and the low level domain knowledge that scientists (users) possess.

The work on problem-solving environments, domain-specific environments, and domain-specific software architectures represents only the beginnings of a domain-specific approach to metacomputing for computational science. Just as this chapter attempts to synthesize the main concepts of this area, the technologies themselves must be synthesized to address, in a collective manner, the three broad requirements we propose: high performance heterogeneous computing, software design and development, and domain-specificity. In this section, we briefly speculate on how that implementational synthesis might occur and how candidate environments might be evaluated. The steps in the informal and speculative model we present below, like the sections above, correspond to the lifecycle stages of software design, software implementation, and software use.

Design: Identifying the Domain and Nonfunctional Requirements

Building any kind of domain-specific environment must begin with the identification of the domain to be addressed. Through a collaborative process, both functional and nonfunctional requirements must be identified. This collaboration can be a formal one like that used to build domain-specific software architectures or informal like the process used in the TIERRA domain-specific environment. The nonfunctional requirements and the developer's perspective of the environment, as suggested above, should play a role in determining the best approach. Obviously, existing techniques for software specification, modeling, and requirements engineering could also be applied.⁶

It is important to make nonfunctional requirements explicit at this stage because they (1) often affect multiple functional requirements, (2) play a significant role in implementation strategies, (3) may change over the development (and subsequent use) of the environment, and (4) are usually only evaluated subjectively. Even the best understanding of nonfunctional requirements at the beginning of the development process is not a guarantee that the environment will be a success. Like most software design and development, an iterative process is ultimately required.

Most software engineering approaches to addressing nonfunctional requirements attempt to develop formal definitions and then measure the degree to which a finished software product meets the requirement. Mylopoulos et al. [MCN92] propose a technique that is much more amenable to domain-specific metacomputing. In their "process-oriented" approach, nonfunctional requirements are viewed as criteria for making design decisions. Thus, rather than evaluating a finished product, they attempt to "rationalize the development process in terms of nonfunctional requirements" [MCN92]. They point out that each design decision affects each nonfunctional requirement in either a positive or negative way. An analysis of the "positive and negative dependencies" can be used to argue that a system meets a given nonfunctional requirement or to explain why it does not. In a broad sense, their approach formalizes that taken by Cuny et al. in the development of the TIERRA domain-specific environment.

Implementation: Using Frameworks or Software Architectures

We believe that a frameworks-based approach holds particular promise for implementing systems in this area. Frameworks, as described above, address a range of nonfunctional requirements important to domain-specific metacomputing, and they can also facilitate the creation of appropriate abstractions (see next section). If existing technology is to be used, a framework may improve the ability to integrate it into the environment. If a more formal approach is desired, methodologies from software architecture and domain-specific software architecture should be employed.

The exploratory nature of many computational science problems demands a flexible implementation that can evolve with the problem-solving requirements. The properties of domain-specific environments-extensibility, programmability, and interoperability-should all be targeted as critical nonfunctional requirements for domain-specific metacomputing environments.

However, the challenge in implementing frameworks is achieving an appropriate balance between "flexibility-packaging software components that can be reused in as many contexts as possible-and tailorability-designing software architectures that are easy to adapt to targeted requirements" [DMNS97]. In this regard, flexibility and tailorability are inherently at odds with each other. A greater degree of flexibility results in more opportunities for adapting the framework to particular needs; however, having additional opportunities for adaptation requires the developer to possess a better understanding of the framework in order to adapt it; and a framework that requires more comprehensive knowledge ends up being less tailorable. We noted a similar problem in the Legion metacomputing project [GW96] where attempts to maximize flexibility impinge on the extent to which developers can actually implement the system. This, in turn, makes it very difficult for others just to grasp how the system may be tailored. Demeyer et al. [DMNS97] conclude, "although flexibility is, in general, a good thing, too much flexibility can result in decreased tailorability"-yet another trade-off among nonfunctional requirements. The situation is particularly critical for domain-specific metacomputing since the optimal degree of flexibility almost certainly can never be determined ab initio.

Use: Creating Appropriate Abstractions

Ultimately, the adaptation of a framework must involve a consideration of how the end user interacts with the system, including the identification of appropriate metaphors and abstractions. The most likely place for these to be used is in a graphical interface. However, abstractions can also be applied to framework components that are open to replacement, extension, or customization by the user. Again, DSEs provide examples of how, through the use of frameworks, environments can be tailored to meet user needs. Similarly, DSSAs can incorporate domain abstractions into the design of the software itself, perhaps facilitating the extension of that abstraction to how the user interacts with the system.

Another important issue is how the underlying computational resources are (or are not) presented to the user. The literature supports a spectrum of possibilities. Raw message-passing libraries like PVM [DGMS93] make few attempts at abstraction in this regard. But the extension to PVM, HeNCE [BDGM96], does support the configuration and cost estimation of target virtual machines. Other systems, like Legion [GW96] and Globus [FK96], envision supporting a range of resource-level access. At one extreme, users simply submit an application and rely on the system to figure out when and where to run it. At the other extreme, a user could exert full decision-making control over the resources used. The problem, though, is that these approaches are not really abstractions: they fail to communicate in meaningful terms the important features of the system and at the same time conceal the unnecessary details. So, what abstractions are appropriate to accomplish this for metacomputing?

At best, this is a difficult question to answer. First, metacomputing systems are primarily intended to be generic systems that enable a wide range of computing activities. Discovering and defining widely applicable abstractions for these generic systems may not even be tractable, nor is it consistent with the goal of domain-specific metacomputing. Second, since current metacomputing systems primarily target application developers and system software programmers, an abstraction relevant to their needs (if one exists at all) is not necessarily an abstraction that will help the end user better understand or interact with the system.

This remains a challenging issue. To begin to understand its implications, one must consider a simple question: what is meaningful and important to the scientist? With respect to computational resources, one can imagine that a scientist might have questions like the following:

How long will the application take to run?

How accurate will the results be?

What could be done to make the code run faster (or be more accurate)?

Does the compiler on node X automatically parallelize the code?

Do nodes X and Y use compatible data representations?

What is the communication latency between node X and node Y

Evaluation

The nature of domain-specific metacomputing environments for computational science makes them difficult to evaluate in the same way other software systems are. The process of software testing and evaluation has long been split into two categories ([Somm89], p. 406):

Validation: Are we building the right product?

Verification: Are we building the product right?

This creates an interesting situation for domain-specific metacomputing environments. Verification, in its purest form, is complicated by the fact that complete specifications for such environments are rarely feasible. Thus, how can developers know if they are building the product correctly if they do not have a specification for what "correct" is?

Part of the reason complete specifications are so difficult is that these environments are intended to evolve with the scientist's process of exploration and discovery. In other words, domain-specific environments effectively assume that validation-prior to actual use of the system by the end user-is impossible. That is, how can developers build the correct product if the whole point of the product is to change over the course of its use?

What this suggests is that some form of "meta-level" evaluation must take place. If the point of a system is to change and evolve in light of emergent requirements and problem-solving needs, then what software features can be examined that might yield insight in this regard? In other words, can some higher-order aspect of the software be evaluated to determine if it does (or will) address this need? We already have a term for these characteristics: nonfunctional requirements.

That domain-specific metacomputing environments for computational science must place so much emphasis on nonfunctional requirements clearly complicates the evaluation process. Methods for guaranteeing the fulfillment of nonfunctional requirements are not yet widely used (or known) ([Somm89], p. 101-103). This relegates the evaluation of domain-specific metacomputing environments to be a largely subjective process. Rather than asking, "Is the environment portable?" Evaluators must ask, "Is the environment portable enough?" And they must continue to ask such questions throughout the life of the environment because the scientist's need for portability might change. The answers to such questions are subjective, dependent on the particular user's needs at a given time.

It is largely for this reason that collaboration is such a critical component of the domain-specific metacomputing process. That is, formal methods for designing, implementing, and evaluating domain-specific metacomputing environments for computational science do not yet exist. Collaborative approaches play an important role in the development of these techniques. In this way, the area can be viewed as a driver of advancements in several key areas of computer science, including high performance computing, software engineering, and especially computational science.

Open Problems

Throughout the course of this and previous chapters, several open problems for the area of domain-specific metacomputing for computational science have been revealed. This section consolidates and summarizes these issues by posing them as questions and, where possible, briefly speculating on answers and possible research directions. Consistent with other sections in this chapter, we organize our discussion according to the software lifecycle stages of design, implementation, and use.

Design

How are the important features of computational science domains extracted?

How are nonfunctional requirements determined?

How are domain-knowledge and nonfunctional requirements integrated into software implementation and software use?

Should formal software engineering methods for specification, requirements engineering, and software testing be applied to this area? If so, how?

Implementation

How is a software architecture or framework type chosen?

How are frameworks built?

How are properties like extensibility, programmability, and interoperability actually "implemented"?

How is access to computational resources to be improved and automated so that both performance and ease of use are maximized?

Use

How are appropriate domain-specific abstractions for metacomputing systems identified and built?

How can high-level abstractions be built so that they simultaneously support the process of scientific exploration?

A potential problem with high-level abstractions, though, is that they can lock the user into a particular way of thinking. This may not be conducive to the processes of exploration and experimentation required for scientific advancement. Achieving the optimal balance between abstraction and flexibility, with respect to how the user interacts with a system, pushes software engineering and the study of user interfaces to the limit.

How do you evaluate instances of domain-specific metacomputing environments?

Conclusion

The emerging area of domain-specific metacomputing for computational science stands to revolutionize the way in which scientists conduct their computer-based research. A promising collection of technologies already exists and need only be organized and applied in a collective manner to begin this revolution. Numerous pitfalls and problems must be confronted, but this is, to a large extent, reflective of the methods of experimental computer science. Experimental computer scientists must continually confront the development of larger and larger software systems-and on an experimental basis. That is, the scale of experimentation is growing. And with that growth, researchers are confronted with new challenges of software design, implementation, use, and evaluation. Like the very domain scientists for which they construct systems, experimental computer scientists are ultimately engaged in their own exploratory process of experimentation and discovery. It is only through this process that revolutions like domain-specific metacomputing for computational science can take place.

Domain-Specific Metacomputing for Computational Science: Achieving Specificity Through Abstraction By Steven Hackstadt