client-server

[Tyson Dowd]

[sorry for the second send, Derek, I forgot to CC the list]

On 28-Dec-2000, Derek Atkins <warlord@MIT.EDU> wrote:
> Tyson Dowd <trd@cs.mu.OZ.AU> writes:
> 
> > > Actually, I was looking at RPC/Corba/etc. over TCP, not over UDP.  The
> > 
> > I got the impression that you were advocating RPC over UDP.
> 
> Well, you can certainly use RPC over UDP, however you don't get a
> reliable transport, and encryption data becomes much more challenging
> (you need to encrypt per-packet rather than just encrypt a stream).
> This implies you need to be much more careful with replay attacks as
> well as constantly changing initialization vectors.
> 
> Keep in mind that with any RPC (TCP or UDP) you first open the
> connection and then make as many RPC calls as you wish.

Err, much the same as HTTP 1.1 then.

> > SOAP/XML provides this too, using HTTP as the transport and XML to
> > define the call site and pass data.
> 
> SOAP/XML (sic) is still a very young solution.  It's actually two
> pieces, SOAP and XML-RPC, however both are still very young.  Indeed,
> XML-RPC and SOAP we BOFs at the IETF, but never even made it beyond
> that.  Or, at least, I can't find any current Working Groups that
> seem to have SOAP as a working item.

Yes, SOAP is definitely young, and it's not permanent.  But it's very
simple if you already have XML support.

And SOAP (and all other XML message protocols in time) will probably
give way to XP, see
	http://www.w3.org/2000/xp/
and for more info on the various XML based protocols:
	http://www.w3.org/2000/03/29-XML-protocol-matrix

> Keep in mind that age-old, tested technologies have their benefits.
> RPC has been around for 20 years, CORBA has been around at least 6.

Sure, it is nice and stable.  But they were developed before firewalls and 
masquerading/NAT became widespread, and before the internet
became a huge household application.  Maybe we should apply the AOL
test: does RPC or CORBA work over AOL?

OMG is also working on integrating SOAP into CORBA.  I think
this is nice solution -- you can get all the services of CORBA
but using SOAP over HTTP as the transport.  So you get all the nice
connectivity SOAP offers too.

See
	http://www.omg.org/news/releases/pr2000/2000-09-20.htm

> The other problem is that I do not believe that you can effectively
> compress a SOAP or XML-RPC request.  And XML is absolutely HUGE.  I
> was assured that once the XML portion was stabilized we would turn on
> compression; that mostly satisfies my on-disk local storage concerns.
> However I don't believe you can compress a SOAP request (or response).

If you are sending a small amount of data, it doesn't matter.

If you are sending large chunks, it's better to use mime-encoded
attachments (which are a proposed extension of SOAP).  And you can
compress them all you like.

HTTP 1.1 supports compression.  

See
	http://apachetoday.com/news_story.php3?ltsn=2000-10-13-002-01-NW-HE-SW

However mod_gzip only works on static pages.  For dynamically generated 
pages you have to do a little more work.  E.g. this PHP
	http://leknor.com/code/php/view/class.gzip_encode.php.txt

At any rate the technology exists, the standards support it, all you
have to do is use it.  Well actually, the difficult bit is deciding
*when* to use it, since compression increases latency.

> 
> > The CGI could either be long-running, or it might just be a simple
> > handler whose job is to keep the TCP connection open, it and forks of
> > a "real" CGI to do the work. 
> 
> Define CGI however you wish..  The CGI is the CGI is the CGI... The
> CGI is the program (or programs) that sit behind the web server and
> process the requests and return the reponses.  You can define this
> however you wish, but even if you split the functionality you still
> have one CGI.

Your statement was that it is unclear how the CGI interfaces with
HTTP/1.1 extended connections.  I was just trying to propose how this
could work.  Personally I don't care how many CGIs there are or how
it is defined.

> > HTTP does not require desiging your own IDL, you can use XML for that.
> 
> You're doing exactly what I warned, trying to push the problem off to
> somewhere else and claiming it isn't a problem.  You STILL need to
> define an IDL..  You just need to define it in terms of XML.

Please don't cut out the rest of what I said!

	If you really need the descriptive abilities of IDL, you can use
	web services -- but this is only really going to come into play
	when you are working with "unknown" interfaces.  But this is
	only really necessary in situations where you would be using DII
	or DSI in CORBA.

You still don't need to design your own IDL, you can use WSDL.  If you
need it.

> > There is no right way.  There are only tradeoffs.  It's certainly not
> > something you can expect to be even moderately sure of with until you
> > have a working prototype or better still a full implementation.
> 
> True.  Except we can learn by example; looking at other systems that
> have used existing technologies and see how they behave.

Yep.  But that's a little hard.  Everyone seems to put on a brave face
and say that their stuff is working fine.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd@cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #