Cyberinfrastructure in New York State - Grid Computing: Infrastructure, Service, and Applications - page 42

another exactly. When message portions match, the deserializer can avoid
duplicating the work of parsing and converting the SOAP message
contents in that region.

2.3.3 Binary XML

XML provides l exible, extensible data models and type systems for structured
data, and has found wide acceptance in many domains. XML processing can
be slow, however, especially for scientii c data, which has led to the widely
held belief that XML is not appropriate for such data. Instead, data are stored
in specialized binary formats and are transmitted via workarounds such as
attachments and base64 encoding. Although these workarounds can be use-
ful, they nonetheless relegate scientii c data to second-class status within the
Web services framework, and they generally require yet another API, data
model, and type system. An alternative solution is to use more efi cient encod-
ings of XML, often known as “binary XML.” Using XML uniformly through-
out an application simplii es and unii es design and development. We have
developed a binary XML format and implementation for scientii c data called
Binary XML for Scientii c Applications (BXSA) (Chiu, 2005; Lu et al., 2006b;
Devadithya et al., 2007). Our tests demonstrate that performance is compa-
rable to that of commonly used scientii c data formats such as netCDF. These
results challenge the prevailing practice of handling control and data sepa-
rately in scientii c applications, with Web services for control and special-
ized binary formats for data.

2.3.4 Uniform Dynamic Service Deployment

Building, deploying, and evolving Web and grid services are difi cult
and inconvenient because different containers require that the services
they host be written in specii c languages to target particular internal
interfaces (e.g., for state management). Therefore, services must be
built and deployed differently for each hosting environment. Our
uniform dynamic service code deployment solution works with three
Web services containers (Tomcat, ASP.NET, and a gSOAP based C++
container), and two grid service containers (GT4 and WSRF.NET).
Containers receive service code in an XML-based standard intermediate
form, and then generate container-specii c native code in different
languages, without exposing these details to applications and grid
services programmers. The dynamically deployed code can access states
managed by the hosting container, utilize functionalities exposed by
statically deployed services, and communicate with other dynamically
deployed modules, running either in the same container or in different
containers. Mobile code can run nearly as efi ciently as it would if it had
been deployed statically, through container-specii c mechanisms.