Next: Design of a Multi-Protocol
Up: Requirements for and Evaluation Computing
Previous: Observations
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: Design of a Multi-Protocol
Up: Requirements for and Evaluation Computing
Previous: Observations
SoapTeam: Extreme Computing Lab
2000-08-17