blob: 78e4ea7f7b6e0f5cd5062bc23cd85cbc8924963f [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more contributor
license agreements. See the NOTICE.txt file distributed with this work for
additional information regarding copyright ownership. The ASF licenses this
file to you under the Apache License, Version 2.0 (the "License"); you may not
use this file except in compliance with the License. You may obtain a copy of
the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations under
the License.
-->
<document>
<properties>
<title>Web Grid</title>
<author email='Sean.Kelly@jpl.nasa.gov'>Sean Kelly</author>
</properties>
<!-- Sirius Isness - Irrational Substance -->
<body>
<section name='Web Grid'>
<p>The OODT <a href='/grid/'>grid services</a>
(<a href='/grid-product/'>product</a>
and <a href='/grid-profile/'>profile</a> services) use CORBA
or RMI as their underlying network transport. However,
limitations of CORBA and RMI make them inappropriate for
large-scale deployments. For one, both are procedural
mechanisms, providing a remote interface that resembles a
method call. This makes streaming of data from a service
impossible, because there are limitations to the sizes of data
structures that can be passed over a remote method call.
Instead, repeated calls must be made to retrieve each block of
a product, making transfer speeds horribly slow compared to
HTTP or FTP. (Block-based retrieval of profiles was never
implemented, resulting in out of memory conditions for large
profile results, which is another problem.)
</p>
<p>Second, both CORBA and RMI rely on a central name registry.
The registry makes an object independent of its network
location, enabling a client to call it by name (looking up its
last known location in the registry). However, this requires
that server objects be able to make outbound network calls to
the registry (through any outbound firewall), and that the
registry accept those registrations (through any inbound
firewall). This required administrative action at
institutions hosting server objects and at the institution
hosting the registry. Often, these firewall exceptions would
change without notice as system adminstrators changed at each
location (apparently firewall exceptions are poorly documented
everywhere).
</p>
<p>Further, in the two major deployments of OODT (PDS and EDRN),
server objects have almost never moved, nullifying any benefit
of the registry. This project, OODT Web Grid, avoids the
prolems of CORBA and RMI by using HTTP as the transport
mechanism for products and profiles. Further, it provides a
password-protected mechanism to add new sets of product and
profile query handlers, enabling seamless activation of
additional capabilities.
</p>
</section>
<section name='Documentation'>
<p>Further documentation on Web Grid is forthcoming. In the
mean time, check out these <a href='./slides.pdf'>presentation
slides</a>. (Don't worry, they're not in PowerPoint format.)
</p>
</section>
</body>
</document>