<?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>