It’s just data

Benefit of human readable protocols

Robert C. Martin: I'd rather use a socket

Go ahead.  Try sending this to here.  In fact, here's the program to do exactly that.


Ha!  Now of course, HTTP POST over the wire doesn't look all that much better.  ;-)  But at least I've got a bunch of easy-to-use clients out there that I can use to test functionality.

Great example.  And yes virginia, I have done a telnet to port 80 to type in a simple HTTP request as part of a debugging session...

Dave

Posted by David Sifry at

I think you missed Bob's point.  Insofar as I understand it, he's saying that we (developers) glom onto new protocols (and languages, for that matter) for no good reason.  Why SOAP instead of CORBA, for instance?  CORBA exists, it works, and yes, you could slap a listener on port 80.  Instead, everyone ran to a slower text based protocol.  Ditto languages - the frenzy to port "everything" to Java over the last few years was just stupid.  Sometimes, I think that IT shops and developers are just sheep, ready and willing to be led to the next great fad, regardless of the value.  And by value, I mean business value.

Posted by James Robertson at

And another point - I was doing remote debugging of CORAB apps back in the early 90's.  Whether the protocol is text or binary is irrelevant.  If you have good tools, you can get a lot done.  If you insist on using sharp rocks and pointy sticks, go ahead and revel in text based protocols.

Posted by James Robertson at

CORBA works great if you own both ends of the wire.

It seems to me that Bob's point is exactly the opposite of yours, James.  He advocates sockets and flat files instead of large frameworks.  SOAP is sockets and flat files (albeit XML ones, but files nevertheless).  CORBA is a large framework.

Posted by Sam Ruby at

No, he's using those as examples, I think.  What he's advocating is simplicity.

Posted by James Robertson at

import socket
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('api.google.com', 80))
s.send("absurd obfuscation")

Posted by Aaron Swartz at

I like the way Aaron thinks.  One nit: in the code snippet shown, the receiver has no way of knowing whether the sender is done or merely pausing.  Something like a \0 at the end is required.

Posted by Sam Ruby at

Sigh.

Sure the receiver knows when to stop looking.  The same as any other protocol, there's a defined end of message character (or characters).  Also a timeout interval after which you consider it a failure.  HTTP, after all, is just a protocol.  And you are all taking Bob Martin literally - and I seriously doubt that he meant to be taken literally.  It was a set of examples - along the lines of the XP approach that he advocates - that one should do "the simplest thing that could possibly work".  So, for instance - if you have two apps that need to communicate, and you control the wire, you might try something simpler than SOAP or CORBA - the basic RPC mechanism for the language/library you use, for instance (RMI for Java, Opentalk for VisualWorks, whatever).  You guys are reading way more into this....

Posted by James Robertson at

James: Aaron's code fragment is not HTTP.  Adding a well defined end of message character (I suggested \0) makes his example the simplest thing that could possibly work.

XP relies heavily on the notion that one can always refactor later.  This is fine for code, but for data structures requires a bit of planning for extensibility.

Posted by Sam Ruby at

my thoughts... all over the place as usual... dat's de slopynes dat Marc pointied oot...

Proprietary Non-XML streams v. XML

Advantage of using XML instead of proprietary data streams is that you don't have to write a parser, because there are already too many good XML parsers. The proprietary stream may seem simpler, but requires more code to get off the ground (i.e. RSS 3.0). Also proprietary streams lead to parser hell, where input and output parsers have different expectations, whereas XML is well defined.

IIOP v. SOAP (or other XML)

Advantage of using SOAP instead of IIOP is that you can write small scripts that use existing HTTP and XML classes and produce readable working samples in record time, as per Sam Ruby's comments. The same is not even conceivable in IIOP.

Is SOAP a slower text based protocol?

Yes, if you read the specs and stick to the examples. No if you think outside the box. Don't limit yourself to the textual tag-heavy serialization of the XML dataset. Consider binary XML. I use to use SGML (ya, the good old days) until we got the protocol correct, then we switch to BXML for efficiency. .NET remoting does provide the capability of using alternate serializers. I'm surprised the development of efficient XML representations hasn't progressed these last 5 years.

Posted by Randy Charles Morin at

More fun over on Sam Ruby's blog. My response. Proprietary Non-XML streams v. XML Advantage of using XML instead of proprietary data streams is that you don't have to write a parser, because there are already too many good XML parsers. The...

Excerpt from iBLOGthere4iM at

My blog - http://www.cincomsmalltalk.com/blog/blogView - and BottomFeeder - http://www.cincomsmalltalk.com/BottomFeeder - both use binary objects serialized to disk for storing data.  In neither case did I give ANY thought to extensibility ahead of time.  in BOTH cases I have had to change the shape of the objects, and sometimes the form of the objects.  See <a href="http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3230532908">http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3230532908</a> for how I managed it without planning.

Posted by James Robertson at

The barrier to entry with SOAP is low. That is better than CORBA. Although the barrier to CORBA was getting pretty low before the SOAP storm clouded the vision, I doubt many Perl, Python, etc. developers would be jumping in with their own implementations.

The entire WS stack will be at least as big as the OMG repertoire before long. With an unclear organization or roadmap, the result may be more confusing for some time. The OMG organization and roadmap was more mature. Again, OMG was just becoming effective in its promotion of interop and modularity/framework architecture.

Meanwhile I interpret Bob's general message as "don't assume, instead evaluate". Maybe he'll jump in and clarify what he really meant.

Posted by Patrick Logan at

Patrick, I agree that the entire WS stack will be as big as the OMG repertoire before long.

What I like about the WS stack is that if all you need is SOAP document literal, all you need to implement is extremely small.  One doesn't need huge middleware.  One doesn't need enormous databases.

My problem is that Bob gave the appearance that he assumed that SOAP did require one or both of these.  My pointing to the Google API is meant to encourage him and others to question this assumption and to evaluate.

Later in the same presentation I pointed to is the actual SOAP implementation for the server side of the RSS validator.

Posted by Sam Ruby at

Here's my theory as to why SOAP caught on where CORBA didn't.

SOAP was created by people who develop applications, so it didn't suffer from a lack of applications to pull it through.

In other words it had a viable developer proposition.

So many proponents of various protocols and formats have no idea how their protocol and format is going to be used. Such P&F's always languish.

One man's opinion. Have a nice day.

Posted by Dave Winer at

Sam writes:
What I like about the WS stack is that if all you need is SOAP document literal, all you need to implement is extremely small.

Yes, a great boon for adoption.

Dave Winer writes:
SOAP was created by people who develop applications, so it didn't suffer from a lack of applications to pull it through.

Yes, a great boon for adoption! 8^) You folks were not about to create a CORBA first and then build apps later.

And this is a problem, as far as I can see, with the WS-xxx stuff taking place today, which is more like CORBA than it is like XML-RPC. Shouldn't the WS-xxx folks be working with OMG on that stuff?

Posted by Patrick Logan at

Sorry to disagree Dave, you are one of my heros, but I think the problem with CORBA is that it started without a standard wire protocol. By the time IIOP was introduced, the standard was already beyond ridicule.

Posted by Randy Charles Morin at

Sam

Have a look here[1].  What do you think?

[1] http://www.freeroller.net/page/cbeust/20030522#i_d_rather_use_a

Posted by Dilip at

Dilip.  I like sockets and XML.  That's also why I like SOAP.

To the extent that Cedric and Robert see the issue as "SOAP vs Sockets", I disagree with both of them.

Posted by Sam Ruby at

Socket?

import httplib
headers = { 'Content-type': 'text/xml' }
c = httplib.HTTPConnection('api.google.com')
c.request('POST', '/search/beta2', message, headers)
r = c.getresponse()
print r.read()
c.close()

Posted by Arien at

Arien: that is http which is one thin layer above sockets.  A perfect example of why I like both sockets and web services: you can program at whatever layer you like, without harming the ability of the person on the "other side" from programming at the layer they like.

Applications and protocols which treat the data being tranmitted as opaque and only intended for computer consumption miss out on this big advantage.

Posted by Sam Ruby at

Sam, my point was that the you cannot infer the fact that a socket is being used from the code given. (HTTP  doesn't have to run on top of TCP/IP, although there's obviously some remapping to be done if you choose another reliable transport protocol.)

You seem to explicitly reveal the socket layer. Why? The point of the layering is, after all, the exact opposite.

Also, I can't help but feel you are making Robert C. Martin's point for him: why SOAP on top of HTTP? This proves there is no need for the SOAP layer. What does SOAP add in this situation?

Or, conversely (to avoid REST vs SOAP), why HTTP between sockets and SOAP? The way it's used here, it adds next to nothing: TCP/IP already does the transport. What does HTTP add here?

Posted by Arien at

Arien, for starters, I agree with RCM up to the point where he seems to imply that sockets are an alternative to SOAP.

Now as to your specific points... layers leak.  What SOAP adds is orthogonal extensibility.  And the possibility of transport independence... which is simultaneously both a key strength and a weakness.

What does HTTP add?  A way of encoding header information independent of the content type.  Is that a good thing?  Depends on whether you want to be content type agnostic or not.

Posted by Sam Ruby at

I'd rather use a GET

Benefit of human readable protocols Give this a try The browser configuration string to do it: <a... [more]

Trackback from Bill de hÓra

at

Add your comment