Rob Nagler wrote:
I disagree. I think it depends on the protocol. A well designed protocol for an application will spread and stand the test of time. Sometimes the protocol doesn't have to be well designed, but just that it's standard can help tremendously.
I'm not advocating this. Rather, I am recommending using a
well-known, and arguably the most widely-used protocol:
application/x-www-form-urlencoded--and it's near cousin
multipart/form-data. However, that's messy, we can just call it HTTP,
and our implementation is LWP and Apache.
At least with J2EE, for every major standard or protocolThere are equivalent number of ways in both languages. If you are
implemented, there is only one way to do it. With Perl, you
actually have more confusion because there are many more ways to do
it. More ways to do templating, more ways to do middleware, more
ways to do serialization of objects, etc...
saying that you could build a "standard component" in, say, EJB, and
sell it, well, that's just not the case. That's the pipe dream of
CORBA. The only thing close to portable protocols is HTTP. Sabre,
for example, gives you a library, and you have to interface to it.
However, authorize.net's interface is HTTP, and I can write my own
library in < 100 lines of Perl, which matches my application, and
doesn't require me to install anything.
There's such a thing as standard protocols, but every application uses
them differently.
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?
This doesn't really make sense to me.
While it's nice to think that it's fun to write a protocol over HTTP, different protocols may be designed for different reasons. In the case of RMI for Java, it is really primarily a serialization issue than a protocol issue (in fact it is supposed to be implementable over HTTP to go through firewalls). If I have a Java front-end and a Java middleware, I much prefer using RMI for expediency than having an HTTP based protocol like SOAP.
But whether you agree whether you like a given protocol or not, my primary points are that
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.
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.
I find it hard to agree that it is always a good idea to create your own protocol all the time if others exist that are published and even more importantly, documented. I think it depends on your project or product that you are developing.
