1. Overview
DoE2000 program develops, coordinates and integrates computing technologies in areas of advanced simulation and collaboration, preparing the 21st century software infrastructure for scalable high performance mission-critical DoE systems.
In the computing/simulation track, initial efforts were started in FY 1997 towards the Advanced Computational Testing and Simulation (ACTS) Toolkit, to be enabled by the Scientific Template Library (SciTL) that integrates numerical, parallel object and runtime libraries. An evolutionary approach was adopted in which: a) a set of existing or emergent promising software subsystems were identified; b) the overall coordination architecture was outlined including user application layer, high-level frameworks (POET, Overture, POOMA) over template (PETE) and data distribution (PADRE) engines, numerical libraries (PETSc, PVODE, OPT++, Aztec), and the runtime layer (PAWS, Tulip, Cumulvs, Nexus, PVMPI); and c) a set of specific integration and coordination efforts was initiated to increase reusability of individual subsystems and their interoperability.
In its FY'98 solicitation notice 97-14, Department of Energy calls for further extensions of the ACTS Toolkit strategies that would build on the SciTL and contribute new capabilities such as multi-language or parallel I/O support, and/or enhance portability, functionality or interoperability of the subsystems under development.
We have analyzed the current suite of the SciTL software subsystems and we observe that the current stage of the ACTS evolution can be viewed as moving from the specialized object to reusable component based programming. A natural next step is to provide visual programming support so that the generic components could be easily customized, optimized and interconnected using user friendly GUIs. In fact, for some SciTL packages such as POOMA or PETSc, the process of encapsulating the low level message passing constructs in terms of high level components is already advanced enough to start addressing systematic support for visual programming in the PDE software domain.
Building flexible and robust visual tools is a tedious and labor intense process which can be hardly carried through within limited budget HPCC research projects. Instead, we proposed to provide suitable linkages to the emergent visual programming technologies coming from the software industry. In fact, a similar transition as in ACTS from objects to visual components is already well advanced for the PC desktop computing and is now being extended towards distributed enterprise computing for intranets and the Internet.
A new revolution referred to as the Object Web, driven by the integration of CORBA/IIOP based distributed object and Java/JavaBeans based visual component technologies is around the corner. The development of ACTS could be boosted by adapting these new industry standards and augmenting them by suitable focused high performance implementations of selected critical functions.
At NPAC, we are monitoring the evolution of computational Web technologies within our Web based HPCC research program. In particular, based on previous DoE support within the WebSpace/LabSpace project, we developed recently an early prototype of an ObjectWeb-like system called WebFlow which offers Java based visual dataflow programming for Web distributed computing and it can act as a convenient experimentation platform for bringing the visual programming techniques to the DoE2000 program.
Based on our analysis of the current SciTL activities and our involvement in Web based HPCC, we propose here a systematic process of evolving the current heterogeneous collection of object libraries and tools within ACTS towards a more organized and interoperable ensemble of HP-CORBA based HP-Components, more easily composable towards HPCC applications in terms of Java/JavaBeans based visual programming tools coming from the industry.
2. Essential Ideas
We summarize here the key concepts exposed in this proposal and explained in more detail in the following sections:
3. The Role of Java in High Performance Computing
The Java platform, published in '95 and continuously expanding over the last two years is the most critical new software technology proposed here for the insertion into the DoE2000 systems.Given the current initiative by Sun to standardize the language specification through the ISO PAS process, the true explosion of new advanced Java APIs under continuous development by JavaSoft, and the rapidly growing community of dedicated Java programmers, one can expect Java to become soon a major, if not the leading general purpose programming language.
Inclusion of Java into the mainstream enterprise computing, so far dominated by large C/C++ codes, is a non-trivial challenge, addressed now by the industry along various strategic directions. Some agile companies with software assets in the control or GUI domains are already offering or developing pure Java versions of their products. Examples include the complete Java rewrite of CorelDraw available from Corel Corporation, or Netscape's ongoing effort on rewriting all their browser and server products in Java. Other major companies with assets in large specialized and highly optimized C/C++ codes such as Oracle are both investing in Java and form strategic alliances to purse open standards efforts such as OMG CORBA, seeking full interoperability between Java and current languages based legacy systems.
For the HPCC community, adoption of Java as a base language appears today still a dubious proposition, given the low performance of Java bytecodes and substantial investment into C, C++ or Fortran based HPCC tools and frameworks. However, it should be stressed that several efforts are underway to boost Java raw performance such as:
In our opinion, the DoE2000 program should therefore carefully evaluate and enable Java technology insertion within its long range strategic planning. Monitoring the similar ongoing efforts by the software industry, adopting the emergent interoperability standards in this area, and adapting them for the DoE2000 mission seems to be a practical evolutionary approach which forms the basis of our proposal.
4. New Industry Standards for the DoE2000 Program
Our proposed evolutionary approach builds on the existing ACTS/SciTL C/C++ libraries and it specifies an integration model with the new industry standards that effectively leads to better multi-language interoperability and accelerates HPCC applications development via visual component programming.
We adopt some visual programming methodologies for the previous generation systems such as AVS, Khoros, HeNCE or CODE and we enforce the visual authoring paradigm in terms of the following new industry standards:
5. Proposal Structure and Control Flow
We present the proposed process of integrating HPCC with Desktop/Enterprise Computing technologies on a 2-dimensional 3x3 chart in Fig. 1, exposing the evolution of user and system perspectives on new computing technologies. On the (vertical) system architecture axis, we start from PC desktop domain and we evolve towards distributed and finally HPCC computing. On the (horizontal) user interface axis, we start from objects and we evolve towards reusable components and finally their visual development and runtime environments.
The control flow in this proposal corresponds to the row-wise analysis of cells in the chart in Fig. 1. Chapters 6, 7 and 10 correspond to subsequent rows in the chart. Sections X.1, X.2, X.3 in Chapter X correspond to the subsequent columns in the chart. We start in Chapter 6 (Chart Row 1) with the summary of new visual component technologies for the PC Desktop, and we continue in Chapter 7 (Chart Row 2) with the discussion of new enterprise computing technologies that will enable Web based distributed computing.
We then summarize these developments in Chapter 8 where we outline an emergent common Object Web architecture to be used in the proposed work. In Chapter 9, we describe in more detail our early ObjectWeb-like prototype - WebFLow - developed within the previous DoE project at NPAC. WebFlow offers Java based visual programming support for distributed dataflow and we intend to use it as an experimentation platform for building the next generation HPCC prototype for DoE2000/ACTS/ScTL, proposed in this document.
Finally, we organize Chapter 10 based again on our Chart in Fig. 1: we now refer to the last third row in the Chart and we focus on our proposed HPCC extensions - HP-CORBA and HP-Components. The ultimate goal of our proposed effort, represented by the lower right cell in the chart, is to develop a prototype visual programming framework for a selected suite of HP-Components that are relevant for and would accelerate HPCC applications of interest to development within the DoE2000/ACTS program.
In Chapter 11, we quantify the proposed effort in terms of specific milestones and deliverables, and we summarize our proposal in Chapter 12.
6. PC Desktop Computing
We start our analysis of visual component-based programming from the PC desktop computing domain. PC componentware is already an established technology, especially in the area of flexible GUI builders. JavaBeans components can be plugged-in and are ready to play in any PC container, be it a Web browser, OpenDoc document or a VisualBasic/C++/J++ framework. In consequence, a variety of visual programming tools from the PC desktop arsenal will become available for scientific computing along our proposed JavaBeans < Java < CORBA < C/C++ < HPCC delivery pipeline.
6.1. Objects: from C++ to Java
Traditional (compiled) object-oriented languages such as C++ offer powerful development tools for expert programmers. However, C++ is often being found difficult as a delivery platform for high level reusable classes, suitable for visual interactive application development. Most typical problems with C++ based large scale and/or visual interactive development are: platform dependency, code maintenance, lack of code mobility, dangling pointers that are often difficult to debug, lack of introspection support for runtime code manipulation and inspection.
Java offers several attractive features missing in C++ and is now being considered a superior language by a rapidly growing community of Java programmers. In particular, new language capabilities brought recently by JDK1.1 such as event delegation/filtering, serialization, introspection and JavaBeans design patterns offer a solid foundation for reusable component based programming. Integrated multithreading, networking and advanced graphics (evolving from AWT to Java2D to Java3D) offers a foundation for visual interactive programming and IDE engineering.
6.2. Components: from ActiveX to JavaBeans
Componentware programming is already a popular and widely used desktop technology, so far dominated by Microsoft OLE/COM/ActiveX controls. ActiveX is so far restricted to the Windows programming environment, and therefor didn't make much impact on visual programming for scientific computing, which is traditionally UNIX based.
JavaBeans is a new powerful componentware technology from JavaSoft which, as based on portable and mobile Java, crosses the operating system and geographic boundaries and is likely to affect soon all computing domains.
JavaBean is a Java object with well defined lightweight methodology for providing hooks that enable design- or runtime composition of applications as collections of interconnected and fine-tuned beans. Unlike in the traditional object-oriented programming where the scope of true object reuse is often limited to individual developers or small development teams, Beans are designed to be reused across different vendors, programming cultures and geographic locations. With all these built-in flexibilities, the Beans design allows at the same time for fine tuned performance optimized implementations of required functionalities - a feature of great relevance for HPCC extensions discussed in Chapter 10.2.
Beans connectivity is implemented in terms of events which are fired by the source beans and selectively delivered to the destination or target beans that expressed interest in specific event classes. Interests are expressed by registering with the source bean a set of event handlers that implement event-specific EventListener interfaces. Listeners can be implemented either directly by the target bean or by an intermediate EventAdapter. In the former, tightly coupled case, the source beans invokes directly the event handling methods on the interested targets. In the latter, loosely coupled case, events are routed from sources to tarrgets via adapters that can act as filters or brokers, for example they can correct for event mismatches between sources and targets coming from different vendors.
Event delivery mechanism is under control of the bean developer: a source can fire events to all interested listeners in a blocked synchronous mode, ot it can port all or selected events on the custom event queue and delegate a customizied dispatcher thread for the asynchronous event delivery to the individual targets.
As seen, the overall beans programming model follows the event driven paradigm and it admits a spectrum of implementations with various tradeoffs between functionality, reusability and communication performance.
Beans are usually parametrized by a set of properties, used for customization and fine-tuning. Dynamic manipulation of bean properties by programmers or authoring tools (beanboxes) is facilitated by the bean design patters for naming property accessor methods. Java Reflection mechanism allows for dynamic introspection of the bean bytecodes and automated generation of the suitable GUI property editors. Specialized property editors or multi-parameter customizers can be also provided by the bean developer via standardized auxiliary classes.
Beans model comes with a well defined documentation and the JAR format based packaging and remote delivery support. In turn, each runtime configuration of a bean ensamble can be serialized, saved as a JAR snapshot and then restored when in subsequent sessions.
Web industry is embracing the JavaBeans framework and there is a growing number of companies, including Netscape, IBM and others, working with JavaSoft on developing a suite of Java Foundation Classes, packaged as a collection of cooperating beans.
Java Beans framework itself keeps evolving. New beans technologies in the decision or prototyping pipeline include: ActiveX bridge, hierarchical containment (beans of beans), standardized registry of communication objects (including all MIME types and other standard format), standardized catalog of polymorphic operators (such as view, edit, copy, print etc.) for the catalog objects.
6.3. Visual Component-based Design and Runtime Environments
Beans can be manipulated programmatically but their design focus and the most efficient use is within visual development or runtime environments. A typical PC desktop example is a GUI builder in which both the control buttons and the application-specific computation and graphics modules are represented as beans and suitably positioned and connected in the visual interactive mode. At the moment, JavaSoft offers a simple visual authoring tool called BeanBox as part of the BDK releases, and a broad suite of more sophisticated and powerful IDEs (or beanboxes) is under development by the Web industry. Most notable beanbox called InfoBus, developed by Lotus and used in their Kona product for Beans based electronic presentation tools will become part of future JDK releases. Another interesting BeanBox technology called BeanConnect will be offered by Netscape and will provide Dynamic HTML/JavaScript support for bean manipulation and connectivity.
An interesting feature of the Beans design is that the specific mechanics of the bean-bean and bean-user interaction is left open for the bean designers and vendors are in fact encouraged to experiment with various solutions. For example, the JavaSoft BeanBox operates as follows:
7. Distributed Computing
The discussion of Java/JavaBeans based visual authoring technologies presented above was restricted to a single Java VM and hence to a single PC desktop. However, since Java supports networking and Beans are naturally concurrent, Distributed Componentware is a natural next step, addressed in the second row on our technology evolution chart in Fig. 1.
Within the Sun philosophy of '100% Java', distributed Beans can and should be developed using RMI (Remote Method Invocation) interconnect, i.e. pure Java object broker technology, now part of JDK1.1. However, the rest of the industry tries to protect their C++ investments while converting to Java. Hence, in parallel with JavaBeans development, the Web industry explores now the linkage of Java with CORBA based distributed object technologies which offer an full C++/Java interoperability.
CORBA supports cross-language remote object invocation as well as IIOP (Internet Inter-ORB Protocol) based interoperability between object brokers from various vendors. Of particular interest are Java based ORBs or ORBlets which can be downloaded as applets to enable CORBA capabilities also at the client/browser side. An alternative, offered by Netscape, it a resident ORB support in all browser and server products. Java based ORBs will soon tun the Web, so far acting as a largely passive document publishing framework, into a powerful dynamic world-wide distributed object-based computing environment.
7.1. Distributed Objects: CORBA
Following the spirit of the evolutionary approach towards ACTS, we propose here an incremental process of bringing Java to the SciTL, using the approach explored right now by the software industry and based on the Common Object Request Broker Architecture (CORBA), coordinated by the Object Management Group (OMG). CORBA2 technologies are reaching today the level of maturity that attracts now a growing number of vendors (currently some 700 companies) to the OMG. In particular, it has been recognized recently that Java and CORBA were 'made for each other' and several new agile companies such as Netscape or Visigenic are joining now the established OMG members such as Sun, IBM or Oracle. Critical new technology brought by CORBA2 and viewed now by the Web industry as fundamental for the Object Web computing is Internet Inter-ORB Protocol (IIOP). Based on lessons learned from CORBA1 where various ORB vendors came with language interoperable but not ORB-interoperable (and in fact plainly competing) broker solutions, CORBA2 enforces now IIOP support for all compliant ORBs. This turns effectly the CORBA framework into a global multi-server computing infrastructure where ORBs from various vendors can cooperate and 'trade' their objects and services on the CORBA software bus.
Java appears to be a perfect language for ORB engineering due to a smooth IDL/Java language mapping and in fact the first generation of Java based ORBs is reaching now the Internet market. These include production quality ORBs such as Joe/NEO from Sun or OrbixWeb from IONA, lightweight ORBlets such as VisiBroker from Visigenic to be bundled with all Netscape browsers and servers, and some early public domain solutions under the GNU license such as JacORB or ROBIN.
The strength of CORBA is twofold. In its core technology sector, it enables, via a common intermediate IDL (Interface Data Language) mapping, a remote method invocation between objects from different programming languages, application domains and computer platforms. In particular, this assures in our case full Java/C++ interoperability and hence a linkage between JavaBeans and C++ based HPCC libraries. However, CORBA offers much more. On top of the base ORB layer, OMG provides an extensive set of specifications within an umbrella initiative called OMA (Object Management Architecture), recently also referred to as ORBOS, which is effectively equivalent to a high level object-oriented operating environment for world-wide distributed enterprise computing.
The high level OMA sector further splits into CORBA Services and CORBA Facilities. Services provide base functionality for creating, exporting, importing and maintaining objects. Current list of published services include: Naming, Event, Life Cycle, Persistency, Transaction, Concurrency Control, Relationship, Externalization, Query, Licensing, Property, Time, Security and Trading. Facilities represent yet higher level functions and further split into Horizontal (i.e. common to all domains, for example User Interface, Compound Documents or Mobile Agents) and Vertical (i.e. application domain specific, for example Medical or Financial) sectors. Several Facilities specifications are still in the formation or the RFP stage, whereas the services listed above are ready for production level implementation.
There is at the moment about ten commercial quality ORB products on the market which also offer some OMA components but none of the current products includes the whole OMA implementation. Java based ORBs discussed above offer a new promising framework for accelerated CORBA software engineering. Hence, building the whole OMA/ORBOS in Java by the Web community becomes in '97 a feasible, albeit still an ambitious task.
7.2. Distributed Components
A natural next step in the Object Web evolution will be reusable component based support for distributed objects and the associated BeanBoxes for authoring. This area is now actively explored by the software industry as a promising framework for the Intranet Enterprise Computing. Some prominent efforts include:
Hence, we can expect a variety of competing or cooperating models and
intermediate solutions to appear soon in the area od distributed componentware.
However, we can already extrapolate some generic features of such emergent
systems.
Fig X. illustrates the elements involved in building componentware
applications over a software bus such as CORBA. A domain specific
application development environment, represented as a dark shaded area,
includes some fraction of the bus bandwidth, some services, some
horizontal facilities, and finally an authoring toolkit with system provided
frameworks or
palettes of generic domain specific modules (drawn from the suitable
vertical facilities repositories) and user provided
ensembles of
application specific modules.
7.3. Visual Authoring with Distributed Components
The detailed nature of visual modules depicted in Fig X. is still being debated by the software industry with various design candidates listed in the previous Section. However, loosely speaking, we can expect a hierarchy of distributed componentware modules to start from JavaBeans wrappers over individual CORBA objects and then evolve towards compound multi-bean modules where individual beans and/or their computational objects can be located on various servers of an enterprise.
Integration of JavaBeans based visual component- and CORBA based distributed object technologies will result in a new generation of visual authoring and runtime environments for distributed computing. We expect a variety of specific models to appear soon, based on various distributed computing paradigm of relevance for the Object Web such as:
Such environments, provided by the Web Industry, will be naturally focused on Intenet commerce, entertainment and distance leaning. HPCC will add optimized support for high performance time stepped simulations and will use commercial technologies listed above for authoring, control, monitoring, visualization, steering, etc.
As discussed already in Section X, specific visual programming paradigms in the JavaBeans frameworks are currently in the formation stage and hence left for the bean developer's invention. In Chapter X, we will describe a specific dataflow based visual programming model of WebFlow - an early ObjectWeb-like prototype developed at NPAC. This presentation is preceeded in the next Chapter with an outline of the emergent Object Web architecture.
8. Object Web Architecture
Distributed Componentware is an emergent Web technology in its early stage. We will witness several specific prototype solutions as listed above, but one can expect some commonalities in these systems, typically based on the 3-tier Object Web Architecture as outlined below:
Since individual ORBs on the bus, even if coming from different vendors or geographically separated can now communicate via IIOP, the Object Web becomes effectively a new paradigm for Web based distributed computing. This process is being further accelerated by new OMG initiatives, pursued by alliances of major software vendors, such as a) integrating JavaBeans with CORBA business object component model; b) providing CORBA IDL support for passing objects by value; or c) integrating Message-Oriented Middleware (MOM) technologies with CORBA.
We believe that the rapid onset of the Object Web framework outlined above offers a promising opportunity for bringing Java to the mainstream ACTS/SciTL activities within the Doe2000 program via the CORBA IDL based Java/C++ language interoperability. We also note that our suggested approach will naturally enhance connectivity between the ACTS and National Laboratories thrusts of the DoE2000 program by leveraging substantial Web industry investment into Java based collaboratories under development in the interactive commerce and entertainment areas. In fact, we demonstrated in our WebFlow prototype discussed in the next Chapter that a visual component-based programming can naturally integrate collaboratory and computing modules.
9. Early prototype: WebFlow at NPAC
Within the DoE funded project WebSpace at NPAC, collaborating with Argonne's LabSpace and aimed at a Web based framework that integrates scientific computing and collaboration, we are currently developing a prototype of a 3-tier Java based distributed environment called WebFlow. It is based on a coarse grain dataflow paradigm and offers visual interactive Web browser based interface for composing distributed computing or collaboratory applications as networks (or compute-webs) of Internet modules. WebFlow front-end applet offers intuitive click-and-drag metaphor for instantiating and interconnecting middleware or backend modules. Middleware is given by a mesh of Java Web Servers with servlet based support for WebFlow Session, Module and Connection Management. WebFlow modules are specified as Java interfaces to computational Java classes or wrappers to backend services.
So far, we completed an early prototype of the WebFlow system and a small suite of proof-of-the-concept application demos such as: a) HPCC Potts model simulation where a WebFlow module wrapper connects to a PCRC runtime based application; b) pure Java imaging with a set of standard AVS-like 2D imaging filters for scientific visualization; c) support for setting simple (chat, whiteboard) real-time collaboratory sessions based on the Java Shared Data API (JSDA) from JavaSoft, to become part of the Java Media/Collaboratory API. In preparation are two VRML2 demos, already operational in the standalone mode and now being integrated into WebFlow: a) a VRML2+JSDA based interactive 'televirtual' (TVR) environment with 'avatars' moving in a multi-component room and mapped on the session participants mouse movements; b) a multi-vehicle DIS simulation based on the VRML2+Java code from Naval Postgraduate School and ported to the JSDA framework at NPAC.
WebFlow development started in '96, and hence in the pre-Beans, pre-ORBlets era but it contains nevertheless most aspects of the Object Web Architecture discussed above, emulated in terms of the JDK1.0 technologies and listed below:
In the proposed system, we intend to use WebFlow prototype and augment it by the currently emerging technologies: JavaBeans for visual graph authoring, servlet based orblets for IOOP connectivity, and CORBA Beans based (to be yet defined by OMG) WebFlow module API.
10. Proposed HPCC Technologies
In this Chapter, we discuss the proposed extensions and adaptations of the Object Web Architecture for HPCC, with the focus on DoE2000/ACTS/ScTL applications. We start with the concept of HP-CORBA, i.e. an optimized high performance mini-broker that will allow us to adapt and reuse CORBA services for HPCC domain. Next, we discuss the corresponding HP-Components, constructed as JavaBeans wrappers for HP-CORBA objects. Finally, we outline the overall framework of the proposed WebFlow based visual programming environment for user friendly HPCC application development in terms of suitable collections of HP-Components.
10.1. HP-CORBA
In Fig X, we illustrated the use of CORBA for coarse grain parallel modules which fully encapsulate chunks of HPCC computation and provide only sequential/serialized dataflow channels to other such modules. If the particular hardware supports parallel transport, such connectivity is highly inefficient. In general, the requirements of multi-language interoperability and composability in a diverse suite of SciTL tools can be met in the Object Web framework only if we provide fine grain ORBlet support in the individual nodes so that the individual parallel objects and their node components can be connected via IIOP channels. Such HP-CORBA platform would naturally offer multi-language support at the object level, object service publication at varying granularity, point-to-point communication between nodes of different parallel systems, and open systems standards based parallel I/O.
We therefore propose to adapt the CORBA model for the HPCC domain by developing a minimal high performance ORB on top of Nexus/MPI. Such HP-ORBlets, residing in the individual nodes of a parallel system (either as network daemons or as runtime libraries) would allow to hide explicit message passing calls in terms of higher level more user-friendly remote object invocations. HP-ORBlets would focus on high performance data/method communication support, whereas the lower bandwidth control communication would be passed to and handled by the full functionality lower performance commercial ORBs in the CORBA bus in the middleware layer. The split between data and control communication would be fully transparent at the programmatic level, i.e. both parallel object developers and integrators would be offered a uniform CORBA object based programming model. Two major advantages of the proposed approach are:
Building an ORB is a complex and tedious software engineering effort but due to CORBA2/IIOP interoperability, we don't need to address its full scope. In HP-CORBA nodes, we can focus on minimal functionality optimized performance ORBlets, delegating higher level object services to other ORBs, given by more complete public domain or full service commercial solutions. For example, a HP-ORBlet could support only the Core CORBA services (i.e. remote object invocation over high performance message passing channel), while delegating Naming, Interface Repository, Trading and other services to higher ORBs in some HP-CORBA hierarchy.
10.2. HP-Components
A current common trend in several HPCC domains is to encapsulate parallel constructs in terms of maximally reusable components.
We will work with researchers from DoE Labs to identify the most adequate ACTS/SciTL libraries for HP-CORBA/HP-Component experiments. Based on our current analysis, we see POOMA and PETCs as offering an attractive framework for extracting and encapsulating useful medium-to-coarse grain components such as node portions of parallel vectors, arrays, index sets, grids, solvers etc. It is conceivable that the whole process of building, testing, fine-tuning and then running, monitoring and visualizing specialized PDE solvers can be mapped on a collection of high performance Beans, composable interactively within some suitable visual programming metaphor.
10.3. Visual Authoring with HP-Components
Such high performance visual programming technologies represent the final corner of our technology evolution chart and the ultimate goal of our proposal. In the envisioned development environment, both parallel object developers and HPCC applications integrators will be offered intuitive visual tools to assemble node programs or computational graphs for HPDC applications in terms of iconic components of suitable grain size and connectivity. Our approach builds on anticipated convergence of Java/CORBA based object and component technologies and it offers guidelines for the design and development of the emergent Java Frameworks for Computing.
From the implementation perspective, we intend to build the proposed prototype by gradually augmenting WebFlow, discussed in Chapter X, towards the evolving Object Web architecture. WebFlow was started in '96, i.e. before the JavaBeans and Java based ORBs concepts appeared and so we used instead the corresponding '96 Java technologies: a JDK1.0.2 based applet for visual graph editor, a servlet based middleware broker, and a custom client-server and server-server inter-module communication protocol instead of IIOP. Based on lessons learned in this early prototype and the recent Object Web developments, we will develop the second generation WebFlow code which will be JavaBeans/CORBA compliant. Technically, the new WebFlow middleware will offer servlet based Java ORBlet support within the Java Web Server layer, communicating via IIOP with the client-side ORBlet, linked to the "beanbox" based visual editor, and with other middleware or backend ORBs that offer Java or C++ object services. This new WebFlow framework, to be constructed in Year 1 of the project, will be then used in Year 2 to develop a suite of HP-Components for PDE solver authoring, and in Year 3 for testing the whole framework in the context of some large scale DoE applications.
11. Statement of Work, Deliverables and Milestones
12. Summary
We believe that a successful implementation and deployment of the proposed JavaBeans/CORBA based visual programming environment for HPCC could lead to a breakthrough in large scale parallel software engineering. Global CORBA services such as Traders and their federates, augmented by the coming CORBA3 technologies such as mobile agents, would result in powerful infrastructure for Problem Solving Environments in which 'producers', i.e. individual libraries or tools publish their parallel object services written in Java or C/C++ on the CORBA bus, and 'consumers' i.e. parallel application developers shop for the most adequate components when assembling complex applications. With the emergent JavaBeans based visual infrastructure for CORBA components, significant portions of the complex process of parallel application development could be mapped on user-friendly visual graph editors.
We believe that our proposed framework offers a solid foundation for the interoperability among DoE2000 systems. It will protect the investment into parallel C++ software development and it will open a standards based way for a gradual inclusion of Java technologies. It will accelerate DoE software development by leveraging the emergent Object Web standards, and it will pioneer a novel framework for transferring the HPCC software solutions to the industry.
To summarize, we proposed an evolutionary process of developing user-friendly visual component based authoring tools for HPCC by integrating the current C++ and coming Java based parallel object technologies via CORBA with the JavaBeans based visual component technologies. Our proposed process starts from the existing parallel C++ object libraries and provides HP-ORBlet based interoperability with Java. Next, the CORBA/Enterprise Beans based server/backend side component technologies are incorporated in the Java server and adapted to the HPCC needs within the emergent Java Frameworks for Computing. Finally, the BeanBox based front-end visual tools provided by the industry are being linked via client-side ORBlets with the tier-2+3 components to offer visual authoring of HP-Components and HPCC applications.