Plans for AGTk 3.0 and Globus

[Ivan R. Judson]

Hey,

Here's the final plan, with one possible conservative twist if we find out
more information. The twist involves whether we can rely on getting the
requisite globus libraries for windows and OS X that we use for certificate
management as part of the standard Globus Toolkit. If we can, then we have
to figure out how to build and package them. Both of these tasks are
non-trivial amounts of work and should be considered highly likely to cause
delays in our release schedule.

After chatting with Lisa and Sam, Tom and I have come to the following plan,
this affects AGTk 3.0. Moving forward we can consider other options and
leveraging other parts of Globus, as the users desire and GT stabilizes.

#1) We stop using GSITCP for our SOAP, Event, Text, and Data services. 

This is the only use of GSITCP in our system, but it's the place that the
existing problems have caused us no end of pain. This choice will
immediately gain us stability improvements, cleaner design, and significant
performance gains. The following illustrates the situation:

Protocol		Min Latency		Complexity
GSI			600ms			No Socket Timeout, Hanging
Bugs
SSL			200ms			Standard Socket Semantics,
Well tested by community
TCP			20ms			Standard Socket Sementics

So, the plan is to back down to SSL, from GSI, and design our system to
assume Standard Socket Semantics. If/when GSI implements those semantics we
can trivially slide it back in and it should not be able to cause us
problems.

#2) We continue to develop our Certificate Management and include the
ability to use Globus credentials, including proxies.

This is no change, but it's the only place in our software that GT would be
present. 

NOTE:
We require C libraries, exposed via pyGlobus to do this. 

* SECURITY MODULE
./globus-makefile-header --flavor=gcc32dbg globus_gss_assist | grep PKG_LIBS
GLOBUS_PKG_LIBS = -lglobus_gss_assist_gcc32dbg -lglobus_gssapi_gsi_gcc32dbg
-lglobus_gsi_proxy_core_gcc32dbg -lglobus_gsi_credential_gcc32dbg
-lglobus_gsi_callback_gcc32dbg -lglobus_oldgaa_gcc32dbg
-lglobus_gsi_sysconfig_gcc32dbg -lglobus_gsi_cert_utils_gcc32dbg
-lglobus_openssl_gcc32dbg -lglobus_proxy_ssl_gcc32dbg
-lglobus_openssl_error_gcc32dbg -lssl_gcc32dbg -lcrypto_gcc32dbg
-lglobus_common_gcc32dbg

* UTIL MODULE
./globus-makefile-header --flavor=gcc32dbg globus_common | grep PKG_LIBS
GLOBUS_PKG_LIBS = -lglobus_common_gcc32dbg

We also require those libraries to be fully supported (now and moving
forward for Windows, Linux, and OS X)
We have asked for simplified packaging, to make the effort of getting these
libraries (without the rest of the GT), and package them into our software.

If the answer is no, then the solution for us is to remove our dependency on
the GT altogether and fallback to being SSL secured. We'll have to consider
the difficulty and engineering to provide a "mostly secure" solution that
keeps the usability up, but I believe by leveraging some of Bob's time to
discuss the problem we can come up with a solution that will be as easy to
use as what we have today. We will need to start that work immediately if we
need to do it.

#3) We are developing AGTk using standard Web Services Technology, WSDL and
Schemas, in document/literal form.

This should provide us with BP1.0 compliance (that's interop speak for we
should be interopable).

We are watching the WSRF developments with an eye for minimizing interface
design changes *when* wsrf emerges as something of value for us. As of now,
it appears to be fairly content free, with some of the major issues like
publish/subscribe not solved for real world, cross-enterprise, solutions. We
are addressing these issues both with Lisa and Same, and with the greater
GGF community.

So the sum of the plan is that we're removing GSITCP support from the AGTk
and designing AGTk 3.0 to be standards compliant and interoperable. That
should significantly improve our stability. We are making other design
changes that are unrelated to the GT that should also improve scalability,
but they have not caused instability.

The question that remains to be answered by Lisa is whether we'll get the
support we need with respect to the libraries specified above (or their
modern equivalents). 

We need to know that already, since we're a month later than our 9/15
deadline. My call would be if we can't get an answer by this Friday, we need
to pull the plug on that and be yet more conservative. The 3.0 cycle is a
massive undertaking, with reducing resources and increasing work we need to
rely on well-supported prerequisite software, we don't have the cycles to do
software development on others software this cycle.

--Ivan