Gunther Birznieks writes:
> eg if we were a world that said HTTP is "it" and we should do everything 
> over HTTP, then would you really see SMTP over HTTP? SNMP over HTTP? 
> telnet over HTTP? Why?

All the protocols you mention are built on IP, a protocol.  HTTP is
being used more and more (SOAP, WebDAV, etc).  The reason is
simplicity.  It's easy to write an HTTP implementation.

> a) I don't think it is fair to pick on Java specifically for the number 
> of protocols when there are equivalent and arguably greater "explosion" 
> of protocols in the CPAN.  

Fair?  Sun invented Jini.  When there have been quite a number of other
proposals around longer, e.g. http://salutation.org/.  Sun invented
RMI.  Even though CORBA does everything RMI does, and there was an
existing implementation.  Sun invented EJB.  Yet there were plenty of
solutions in CORBA, which, of course, were better.

On top of all these, there are equivalent numbers of custom
implementations of protocols in Java, just like there are on CPAN.
(I have implemented several. :-) The one difference is that the Perl
community encourages people to contribute open source, and Sun
squashes any non-official attempts.  You aren't allowed to contribute
to J2EE.

> b) If you don't use "standard" application-layer protocols, then you are 
> actually creating your own protocol explosion but just with fewer users 
> using your own proprietary system over HTTP. So in a way it is a matter 
> of semantics.

My argument is that there is always a non-standard protocol, that is,
the domain protocol.  You are going to define application interfaces
that nobody else but you will be able to use.  No one sells "stock
components".  Even the "standard" J2EE auth beans are not used very
much (if at all?) in real applications.  Given that, whether you
choose HTTP or SOAP or EJB really doesn't matter.  I choose HTTP,
because I have to anyway, and I'd rather not introduce more protocols
for no gain.

Another factor in this is that I don't believe in distributing
components for most applications.  If you need scalability, you need
statelessness, and then all your servers can be used interchangeably.

Rob


Reply via email to