Weblogs Forum - I'd rather use a socket.

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
I'd rather use a socket.

16 replies on 2 pages. Most recent reply: Mar 4, 2005 12:11 PM by Patrick Bailey

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

I'd rather use a socket. (View in Weblogs)

Posted: May 19, 2003 4:56 PM

Reply

Summary
SOAP, RMI, CORBA, RPC, Middleware, yadda, yadda, yadda. I'd rather use a socket.

Advertisement

I was on a conference panel recently. Someone in the audience asked a question about the future of SOAP and other similar messaging middlewares. The panelists all answered in various interesting ways. When it was my turn I just said: "I'd rather use a socket." To my surprise I got a polite sprinkling of applause in response.

I think we have gotten framework happy. If a framework exists we feel honor bound to use it. We are like the construction workers in Don Adam's "Hitchiker's Guide to the Galaxy" who were building a bypass through Arthur Dent's house. When he asked them why they were building it they said: "You've got to build bypasses."

I think the industry should join frameworks anonymous and swear off gratuitous framework adoption. We should all start using sockets and flat files instead of huge middleware and enormous databases -- at least for those applications where the frameworks and databases aren't obviously necessary.

Sam Ruby

Posts: 1
Nickname: rubys
Registered: May, 2003

Re: I'd rather use a socket.

Posted: May 20, 2003 5:42 AM

Reply

Give http://www.intertwingly.net/blog/1420.html a try.

Paul Wujek

Posts: 7
Nickname: pw
Registered: May, 2003

Re: I'd rather use a socket.

Posted: May 20, 2003 6:39 AM

Reply

This is the kind of opinion that comes from having written and developed protocols over the years.

I also feel that SOAP and Web Services (as defined by IBM, Sun, BEA, et al) are an extremely complex way of doing something which is essentially very simple. Getting a message from point A to point B shouldn't require that many different configuration files, programs and intertwined services.

Now if you get me going on EJBs and IDEs I could keep this up for days.....

Brian Casiello

Posts: 1
Nickname: bcasiello
Registered: May, 2003

Re: I'd rather use a socket.

Posted: May 20, 2003 7:45 AM

Reply

Nitpick: DOUGLAS Adams (http://www.douglasadams.com/) wrote "The Hitchhiker's Guide to the Galaxy. DON Adams (http://www.wouldyoubelieve.com/dona.html) is an actor, probably best known for the TV series "Get Smart".

Dale Brayden

Posts: 1
Nickname: herodotus9
Registered: May, 2003

Re: I'd rather use a socket.

Posted: May 20, 2003 11:35 AM

Reply

My first reaction to this is "here here!". But I think my objection to frameworks is not that they are complex (though SOAP certainly is) but that often too many distinct decisions are bound up in the framework. For example, though XML-RPC is not nearly as complex as SOAP, it suffers from the same problem as SOAP: it is bound to HTTP transport. SOAP and XML-RPC would both be more widely usable if the transport decision were distinct from the message representation.

Another issue with many frameworks (and I'm thinking SOAP and CORBA now) is that the framework designers adopt too narrow a view of how the framework might be used. For example, in the very early drafts of the SOAP protocol there was some attention paid to interaction models other than "synchronous method call". For example, fire-and-forget, event notification, and asynchronous send/reply were all mentioned (if memory serves). But now SOAP provides nothing other than synchronous method call. Perhaps this is a result of the HTTP orientation of SOAP. But whatever the cause, the absence of event notification (i.e. unsolicited server to client messages) and asynchronous messaging makes SOAP unusable for many applications.

I have to assume you were being somewhat facetious when you say "why use databases instead of flat files". Under the principle of doing "the simplest thing that could possibly work" I would agree that prototype implementations of certain software should be done with flat files (or dbm's or whatever). But that approach does not scale up well, in general. In any case, using a database (especially via DBI or similar wrappers) does not contort one's application in the way that a messaging framework does. I mean - the database access code can be conveniently tucked away and 'modularized' in a way that IPC / messaging code cannot.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: I'd rather use a socket.

Posted: May 20, 2003 8:50 PM

Reply

> Nitpick: DOUGLAS Adams (http://www.douglasadams.com/)
> wrote "The Hitchhiker's Guide to the Galaxy. DON Adams
> (http://www.wouldyoubelieve.com/dona.html) is an actor,
> probably best known for the TV series "Get Smart".

What'dya say Chief?

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: I'd rather use a socket.

Posted: May 20, 2003 8:54 PM

Reply

> I have to assume you were being somewhat facetious when
> you say "why use databases instead of flat files". Under
> the principle of doing "the simplest thing that could
> possibly work" I would agree that prototype
> implementations of certain software should be done with
> flat files (or dbm's or whatever). But that approach does
> not scale up well, in general.

Agreed. However, I like starting with flat files and encapsulating them so that I can switch to a <i>real</i> DB when, and if, I have to. I've found that the <i>if</i> doesn't happen as often as I fear.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: I'd rather use a socket.

Posted: May 21, 2003 10:38 AM

Reply

I agree that plain sockets (or even HTTP) is often a more effective way to develop applications than SOAP. In developing Web services, I found that the task of simply passing messages back and forth involves relatively small amounts of code. The bulk of the code in developing Web services clients comes from having to deal with partial and unexpected network failures, etc. - i.e., with making an application robust. Given that SOAP addresses the message-passing layer, it introduces an overhead that is sometimes counterproductive. I've also found that debugging Web services clients is often much easier when plain XML is sent over HTTP than when SOAP is involved, since that way one gets a lower-level access to the network.

SOAP is perhaps useful when there are complex ways to access a Web service: For instance, it might sometimes make sense to define polymorphic interfaces to a WS such that invoking different methods affects the result messages. In that case, tools can generate Java interfaces from WSDL definitions, and those interfaces would likely be simpler to work with than complex socket-based protocols.

That said, many Web services today are single response-requests. In those simple cases, SOAP is often an unnecessary overhead.

Here's an article I wrote about that issue:

http://www.artima.com/webservices/articles/whysoap.html

Erik Price

Posts: 39
Nickname: erikprice
Registered: Mar, 2003

Re: I'd rather use a socket.

Posted: May 23, 2003 5:20 AM

Reply

> Agreed. However, I like starting with flat files and
> encapsulating them so that I can switch to a <i>real</i>
> DB when, and if, I have to. I've found that the <i>if</i>
> doesn't happen as often as I fear.

Isn't it easier to encapsulate a simple [JDBC] data insertion/access implementation than to roll your own file-based system? I think this is similar to what you're suggesting, since you can always switch the data insertion/access implementation to EJB or JDO or whatever later on down the road, but it just seems (to me) that it would still be easier to use a Reddi-Wip DB api than to write a file-writing/parsing mechanism.

Unless you're talking about a Reddi-Wip file-writing/parsing mechanism like JAXB or Properties files or something...

Steve Holden

Posts: 42
Nickname: holdenweb
Registered: Apr, 2003

Re: I'd rather use a socket.

Posted: May 23, 2003 7:09 AM

Reply

> I also feel that SOAP and Web Services (as defined by IBM,
> Sun, BEA, et al) are an extremely complex way of doing
> something which is essentially very simple. Getting a
> message from point A to point B shouldn't require that
> many different configuration files, programs and
> intertwined services.
>
The thing that concerns me about SOAP and other HTTP-based services is precisely the use of the HTTP protocol - chosen not because it's the best protocol for the job, but because firewalls are normally configured to pass it through.

The promoters of SOAP don't seem to realise that once you start to use port 80 for generic application services, you make the business of protecting port 80 suddenly much more complex - request filtering will be needed to ensure that only "approved" SOAP requests get through, and so on. Or maybe they don't care.

I'd be also happier if SOAP had better representational flexibility, but that's a minor nit.

Yet again, large organizations band together to produce a solution to a problem that was already solved (by CORBA) so that they can implement proprietary solutions rather than use an open framework. The reason we have TCP/IP rather than the ISO OSI protocols is because large users got together to place pressure on vendors to provide conforming implementations. Can we say "Not Invented Here"? Biztalk? Just say no ...

Bill de hÓra

Posts: 1137
Nickname: dehora
Registered: May, 2003

Re: I'd rather use a socket.

Posted: May 25, 2003 2:32 PM

Reply

Who needs a socket?

http://www.dehora.net/journal/archives/000277.html#000277

Maurizio Turatti

Posts: 12
Nickname: mkj6
Registered: Jun, 2003

Re: I'd rather use a socket.

Posted: Jun 26, 2003 4:43 PM

Reply

>
> Isn't it easier to encapsulate a simple [JDBC] data
> insertion/access implementation than to roll your own
> file-based system? I think this is similar to what you're
> suggesting, since you can always switch the data
> insertion/access implementation to EJB or JDO or whatever
> later on down the road, but it just seems (to me) that it
> would still be easier to use a Reddi-Wip DB api than to
> write a file-writing/parsing mechanism.
>

Maybe it's better starting with a Row or Table Data Gateway, which encapsulates the plain file or, *if* necessary, the JDBC code. I 'm reading the famous Bob's book and I just started a new project following some of his advices. One very useful was: "consider the database an implementation detail". Now I have quite a working domain model, without any database involved. Delaying the database stuff let me concentrate on the "real" thing. But this could hurt your boss: "Aren't you using our expensive RDBMS? Are you crazy?"

todd hoff

Posts: 2
Nickname: toddhoff
Registered: Jul, 2003

Re: I'd rather use a socket.

Posted: Jul 20, 2003 9:00 PM

Reply

Beware of idiots using sockets. What, other people use this port number? What, we ran out of file descriptors? Why do i get this bind error? How do i get my timer and input from my socket at the same time? What's this pipe thing? I thought tcp was reliable, how come i lost data? So i connected to over 256 machines, what's the big deal? My packet doesn't look right. How come we don't know the connection died? Why is my performance so bad? I could write a similar list for databases as well.

Please spare me more people using raw sockets.

Thomas Gagne

Posts: 3
Nickname: tgagne
Registered: Aug, 2003

Re: I'd rather use a socket.

Posted: Aug 6, 2003 9:40 AM

Reply

I agree. Except that network programming is itself a challenge for many people and distracts their code (and the programmer) away from the problem at hand, which is getting messages from point A to point B.

There are middleware packages available that are /very/ lightweight, including some that are opensource and available to multipile languages at all levels, and not just OO ones.

I've been maintaining one for a while at <http://isectd.sourceforge.net>. I think this (and other middlewares like it) are about as close to programming with sockets as you can get without the headache of using sockets.

J. B. Rainsberger

Posts: 12
Nickname: jbrains
Registered: Jan, 2004

Re: I'd rather use a socket.

Posted: Jan 6, 2004 1:44 PM

Reply

> Beware of idiots using sockets.

Beware of idiots bearing code. Period. Not a "sockets" problem.

Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use