next up previous
Next: Design of a Multi-Protocol Up: Requirements for and Evaluation Computing Previous: Observations

Multi-protocol design

The experiments show that SOAP has a significant performance penalty. Some of this is inherent - SOAP must send larger amounts of data, and that cannot be reduced without changing the protocol. Some of it may be reduced by better implementation of phases like deserialization, although the constraint of handling arbitrary complex data objects will bound the performance enhancements. Furthermore, performance is only one capability to consider in selecting communication protocols. Java RMI has the advantage of allowing users to quickly incorporate capabilities like database interfaces, compression, encryption, and visualization, but Java RMI is limited to a single language. Earlier work [13] showed that Nexus can provide high-speed data transfers between two C++ components, but suffers from robustness problems for long-running applications. Java RMI has outstanding performance, but the limit on its recursion stack depth prevents it from being used on arbitrarily-sized data unless the application-level user does chunking - a significant burden to place on an applications scientist.

In distributed scientific computing component systems, applications are started up on remote machines and wired together dynamically while some parts are running. Components may be migrated to other machines during runtime based on resource availability and network load. In this context the choice of protocol depends on dynamically changing factors: size of the data, security policies, dynamic reconfiguration of component wiring, quality of service requirements, etc. A component may be connected to several components at any given time, each possibly using a different protocol. In this case, universal connectivity is important. As an example, the Common Component Architecture Toolkit (CCAT) system [5] is a framework that connects scientific computing components in C, C++, Java, and Fortran. Components are dynamically created, connected, disconnected, and terminated. A component also can be a remote instrument like an X-ray crystallography data collector, or distributed databases. Messages between components range from short packets for lifecycle maintenance or setting internal parameters up to gigabyte data transfers. Components can represent extremely long-running or expensive services, for which robustness is critical.



 
next up previous
Next: Design of a Multi-Protocol Up: Requirements for and Evaluation Computing Previous: Observations
SoapTeam: Extreme Computing Lab
2000-08-17