From: Jeff Bone (jbone@jump.net)
Date: Mon Oct 02 2000 - 14:16:02 PDT
Okay, here's a basic sort of stream-of-consciousness description of this thing I've been
pondering for a long while. Assume the following: HTTP is the universal transport,
SOAP is the universal RPC, and firewalls are a "problem" in that it cannot be assumed
anywhere that an initiator will be able to establish an HTTP stream to a desired service
somewhere else. How can you ever build systems where clients (initiating peers) can
initiate contact with desired services, regardless of the location of the service, i.e.
across a firewall?
Enter SUDS. SUDS is basically the thing I described in the last message: a service
which provides a URL namespace rooted at some well-known location and allows its own
clients (the desired services mentioned above) to adopt subtrees within that namespace
via its own SOAP-based control interface. Imagine it as a sort of dynamic, web-based
inetd meets web proxy with connection management semantics layered on top.
Scenario: my IRC client wants to connect to an EFNet server, but the servers refuse
connection because the server cannot connect across my firewall to the identd on my
desktop. Imagine for a moment that identd is actually some kind of identd-like SOAP
user authentication service for the purposes of this discussion, and imagine that IRC
knew how to use SUDS. Here's what happens:
My "identd" registers itself with some SUDS service somewhere, say http://suds.foo.com,
and adopts a portion of the tree: jbone@jump.net/identd">http://suds.foo.com/jbone@jump.net/identd or
similar. This SUDS service is outside my firewall, so my identd maintains an open
connection to the SUDS service or periodically polls the service to see if any inbound
connections / requests are pending. (In the case where the SUDS server can initiate
inbound connections to my client, such as if the SUDS service was running on the
corporate firewall, the SUDS server will make on-demand connections to my client as
needed and neither persistent connections or polling are necessary. Or, in the case
where the service provider and requester can directly communicate, the SUDS service can
simply act as a referrer; in that case, SUDS merely acts as a symbolic nameservice and
provider of well-known names.)
My IRC client connects to the EFNet server and provides my information, with
authentication information, along with the SUDS address of my identification service.
EFNet contacts the indicated SUDs server, which then "connects" my identd service at the
provided SUDS address with EFNet. The SUDS server brokers this connection between my
identd service and the EFNet server and basically just proxies things back and forth at
that point.
Different services registering with SUDS, as well as different SUDS servers, could
support a variety of differing connection semantics to support a variety of cases:
persistent connection, polling, queued SOAP messages with return addresses, event
notification, SUDS-initiated callbacks to the service, etc.
Any thoughts about this?
jb
This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 14:33:19 PDT