Upcoming Monday High-Performance Decisions

["David C. Niemi" <dcn0@salliemae.com>]

I'd like to have about 1/2 hour at the end of the Monday conference call
to call a couple of votes on issues relating to the high-performance
channel.  I'd like to have each proposed transport architecture
summarized (10-15 minutes with chief advantages and disadvantages
listed); and then proceed to vote on each architecture to decide, one by
one, whether to continue actively researching that architecture as a
group.

I intend that only 1 or 2 architectures will make the cut, and the
others will go "dormant" or become unofficial side-projects.  The main
high-performance group will then concentrate on the "winning"
architecture(s) and hash out design, implementation, and scoping issues
through the Jacksonville JAD.  If we encounter major problems with the
"winning" architecture(s) we may reactivate one of the dormant
architectures, but in the mean time we need to focus our efforts.

Please note that we will be primarily specifying the inter-organization
protocol, and most of the details of how this front end system connects
to the rest of the internal architecture will be up to the implementor.
For example, it is quite plausible that other transport protocols may be
used internally to connect the front end to the organization's back end
system(s).  Per JAD and conference call discussions we do not intend to
support multi-hop transport-level routing or fallback routes;
acknowledgements are only required to confirm successful transfer via
the current hop (though some implementors might perhaps choose to
transfer the file to the next internal hop prior to acknowledging the
transfer).  In all cases, sending of files will be initiated by a client
capability on the sender side, not polled for by the receiver.

For the record, I'll now propose 2 architectures; if anyone wants to
modify or add additional ones please speak up prior to the Monday call
and be prepared to present your proposal.

1) MQSeries.

Data and metadata would be formatted via XML, and a separate encryption
product would be plugged in.  Primarily an IBM product, available for
nearly all conceivable platforms; a compatible product from Microsoft
also exists.  MQSeries makes client and server side implementations more
similar than for most protocols, and automates the transport itself to a
high degree.

2) Secure HTTP.

This would consist of XML formatting for metadata inside MIME encoding
using the HTTP protocol, which is carried over session encryption (SSL).  
Available from many vendors for many platforms, but the most popular
implementations are Apache (All major UNIX platforms and Windows NT),
Microsoft IIS (Windows NT only), and Netscape (All major UNIX platforms
and Windows NT) for the server side.  The client side (used by servers
when pushing files to another organization) would generally use a canned
client or client library.  Very widely used and very rich development
tools are available for both server and client side, though these are
not necessarily consistent from platform to platform or between client
and server side.

David C. Niemi         dcn0@salliemae.com        (703) 810-5538
Network and Communications    SallieMae    Reston, Virginia USA