Slashdot Mirror
HTTP's Days Numbered
dlek writes: "ZDNet is running an article in which a Microsoft .Net engineer declares HTTP's days are numbered. (For those of you just tuning in, HTTP is the primary protocol for the world-wide web.) Among the tidbits in this manifesto is the inference that HTTP is problematic primarily because it's asymmetric--it's not peer-to-peer, therefore it's obsolete. Hey everybody, P2P was around long before Napster, and was rejected when client-server architecture was more appropriate!"
The article is especially funny since .NET is built upon SOAP which uses HTTP as its primary transport. Maybe MS realizes that .NET is a stupid idea and they want to set up HTTP as the scapegoat when it fails miserably
This sounds like wishfull thinking. Http is over used. Every time someone wants to implement a new protocal latly , it seems that they do it over http, as opposed to implementing there own. esp, if it can be async.
-jj-
There are obvious reasons to replace HTTP - the most obvious being the creation of true stateful transactions. That said, there will be support for HTTP until 2025 at least, and ultimately legacy support for HTTP will be painful and necessary for coders.
from the article: "I need a way to send a request to a server and not the get result for five days"
Why does it need to be done at a protocol layer? If I need to submit something to a server that is going to take 5 days to get back to me, I should probably have an account with that server, and when I log back in, can get that information.
It sounds to me like he's fishing for an excuse to design a new protocol for a need no one really has.
ChuckyG
The article just points out that using HTTP as a basic transport for more higher level concepts such as a Microsoft Web Service is problematic because:
a) The way most of the Internet's IP infrastructure treats port 80 traffic will not allow long durtation web service transactions to work reliably (presumably because things like NAT mapping tables will get cleaned up before the transaction finishes)
b) Because the server can't initiate a connection to a client.
It's NOT talking about HTTP being unsuitable for pushing web server content around the Internet.
HTTP does have it's problems, and it's one of the reasons that Jabber has it's own internal transport protocol to accomplish IM.
I've seen other proposals for HTTP replacements and have been less-than-pleased by their complexity and design. Based on what I've learned from Jabber, and great feedback from many in the open source and standards communities, XATP was born:
http://xatp.org/
XATP, the eXtensible Application Transport Protocol is very simplistic and geared to operate at a layer below content, identity, framing, and other application-level issues. Check it out and offer feedback or participate if your interested.
Jer
Didn't Cringely claim several months ago that they were going to try to do this? Well, not quite, but back in August he wrote:
So they decided to go up one level of abstraction. Hell why not, that way they break even more competing products.
Nope, no sig
If he was such a guru maybe he'd have realized that http is "hypertext transport protocol" or something like that, not "heavenly total treatment protocol"
It was designed to --- get this, kids --- deliver WEB PAGES!!! I once heard rumors of this other evil, called ftp, that was once used as a "file transfer protocol!!" The nerve of some of those early networking types!
Really, though... there are just about as many potential protocols as their are potential uses. So http doesn't lend itself to your insecure privacy invading microsoft-enriching wet dream of global domination. GET OVER IT or LEARN TO USE AN APPROPRIATE PROTOCOL. Really!
I don't see my linux box making http requests every time I want to mount an NFS share, so why should microsoft's next weapon use it to rob me of my money? HAH! Guru indeed...
seem to remember that some time in the past MS claimed that the Internet was obsolete and the MicroSoft Network was the future. I think Unix is also obsolete according to MS.
And of course I am obsolete since I refuse to view MS products as anything else than toys. Admittedly by now toys that actually have some level of stability and can be used for some (limited) tasks without too much hassle. But as long as they insist on sitting on their island (admittedly a large one, but instable and plagued by document-rot), I will not consider their products "professional" in any sense.
Incidently the only argument in the article (aside from the "argument" that P2P is better than client-server, given as dogma) is that there are problems with transactions that have several minutes connection time. I am sorry, but I don't see how that makes http obsolete. First these long transaction are not that common and second they work fine. Or are we going towards an Internet where a telnet/ssh connection will be terminated after 3 minutes, because the backbone cannot cope?
Pure FUD, as far as I can tell.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
The great thing about HTTP to me is all the stuff that was left out. And if you really want that stuff, there's WebDAV, which also seems to be a decent protocol - but I'd have to look into it more to get a better idea.
For those people who don't like a gajillion different services running on port 80, then don't run them on port 80! You could have a user-facing webserver responding to port 80, and an XML-RPC server responding on port 8080, and a SOAP server on 8081 - there you go, problem solved.
The real problem presented by this article - of long-running transactions - definitely is outside of the scope of HTTP. But the best solution to this might be another protocol on top of HTTP. I imagine something that initiates some transaction with a transaction-id, then closes the connection, and waits (possibly days) for a connection to come back with that same transaction-id. Voila. Problem solved. Of course there'd be more to it than that, but that's the basic idea.
"If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests--I need a way to send a request to a server and not the get result for five days."
If I am reading his statement correctly, Box feels HTTP is not suitable for processes that take long period to get a response. Even if you remove HTTP layer from SOAP, you would still have a problem. Say some one decides to by pass HTTP, use raw sockets and establish persistent connections. This means a stateful application has to be built on top of SOAP. I'm just guessing, but if Box is saying RPC has to have sessions and be stateful, that isn't a full solution. If a process like "place a stock order for MSFT when the price is less than 50.00 buy," a stateful application may not be the best solution. It might take 1 day or 2 months for the price to drop below $50.00.
Microsoft is a supporter of XLang which tries to address the problem of stateful transactions. One of the problems of this approach that I can see is it is limited in scalability and timeout. Once you say all transactions need to be stateful, what is an acceptable timeout? Do all transaction require the same timeout period? What are the rules governming timeout, persistence, and garbage collection of invalid/expired states?
Why not use event based protocol with rules to provide a higher level of abstraction than XLang. The way XLang treats transaction is with case statements. On the surface that sounds fine, until you realize for every company you do business with, you will have to add cases to handle new situations, which rapidly makes the system harder to maintain. EBXml in my mind uses a better approach, which divides business and functional logic and suggests rules as a possible mechanism. HTTP isn't really the problem for long processes (as in weeks and months). A better solution is event based protocol, so using HTTP isn't a big deal. This doesn't mean there are cases where HTTP is really bad for transactions. Cases where response time is a huge factor in processing a transaction, a persistent connection would be more suitable. Things like day trading applications where response time affects the price, you would be better off using persistent connections for RPC. It would suck for a day trading application to loose a buy order because there was a sudden spike in requests and the system couldn't reconnect to send confirmation. Having a persistent connection in this case is the best solution, because response time has to be rapid.
Actually there is a need for this type of protocol to support applications talking with applications on different computers, otherwise known as web services. SOAP addresses this and Microsoft's .NET goo simply takes this approach. Their marketing department has "hyjacked" the whole purpose of XML (SOAP is a XML schema) as their own. Typical for large corporations.
.NET v.s. ___.
We now enter the era of XML schema wars, which is essentially a "data format" battle. i.e. XML based Word v.s. XML based PDF.
It's clear that there are enough companies and people out in the world who won't choose Microsoft goo of the week, leaving the practicality of effective open and vendor neutral standards a reality.
What Microsoft does is completely irrelevant since there are various alternative systems evolving. Simply ignore Microsoft and implement your solutions as YOU see fit adopting whatever standards you find appropiate. A beautiful aspect of reality is that anybody can create their own "world view", shared with others or not, within the framework reality. This is especially true in computing. If people find your "world view" or "system" more valuable and more useful than someone else's, they will adopt it. Evolution in action.
In a course I took years ago (when Interop was a small show for net-heads that fit easily in the San Jose convention center), Marshall Rose was talking about security and transports and showed us how some really twisted grad student had implemented PPP over a DNS transport just to prove it could be done.
Sadly, pretty much everyone agrees that HTTP isn't suited for the things it's being used for today, but everything gets built on top of it because port 80 is pretty much the only thing that's guaranteed to get through firewalls, most of which are stupidly configured and require the corporate equivalent of an act of Congress to get opened up.
By the way, Marshall Rose is relevant here for another reason, too: his proposed BEEP protocol is (IMO) a far better way to deal with providing a multipurpose transport suitable for a wide variety of things. There's a good BEEP Q&A document by Rose on the beepcore.org site. We should be using things like BEEP to avoid having the same arguments and reinventing the same wheels over again every few years/months/weeks. BEEP seems to be gaining traction: The IESG recently approved APEX4 the application datagram protocol over BEEP as a proposed standard, and SOAP over BEEP was similarly approved last summer. Let's hope these get through the grinder in time to do some good, and that the true Internet standard of "Rough Consensus and Running Code" prevails over corporate landgrabs by Microsoft, et al.
"The future's good and the present is nothing to sneeze at." - Roblimo's last
that may or may not exist.
Just because I get an email from some machine, doesn't mean that it really originated there or that it wasn't maliciously crafted or altered by some sleeper virus.
You know why M$ wants to get rid of the TCP/IP stack don't you. They didn't write it, and it works. It replaced their own, which didn't work.
They want to stamp out any trace of non M$ code in their OS.
Maybe BelCore or Multics organization, or even IBM should sue them for copyright or patent violation on the use of recursive structures like sub-directories.
If they rip out the stack, I predict a wave of new virus exploits the likes of which hasn't been seen yet.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Let me state right off that I'm probably at least somewhat wrong, but here's how I remember the timeline.
.NET became an idea. You're absolutely right that they're trying to do the same with .NET, ie get everyone to cave in. But I can also kind of see the performance arguments they had, as almost every Java app or applet I have ever used was slow or crashed.
- MS realizes that Java will be huge, makes Visual J++ tool.
- Tool not too bad compared to what's out at that point, but slow adoption rate.
- Many Windows developers hate performance of Java as compared to native apps.
- MS tries to get some extensions to Java when apps are compiled for native Windows code. Embrace and extend, sure, but also:
- Tries to get Sun to approve some functionality. Sun hates MS so drags its feet in approving anything MS does with Java.
- When MS does its own thing, Sun sues.
- MS loses, says Screw this, and drops JVM based on lawsuit result, and stops J++ tool development.
I think they did try to use Java, and when that didn't work,
I was a VUE testing administrator, and their whole system was in Java on Windows - oh, the humanity, the support issues, shudder. Anyway, I agree with you, I would prefer to see more Java support, but all I was saying is that their decision makes business sense. Java isn't like Linux, it was developed proprietary by their competitor, and only then became more open and popular. For them to go their own way is not completely unexpected.
Please subscribe to see the more insightful version of th
".NET is a framework and a set of tools"
.NET, because Microsoft themselves have not come forward with a clear definition and are using ".NET" to sell everything from last year's version of Exchange to Passport logins to business consulting services.
FYI -- You might want to surf around microsoft.com a bit. You will find that ".NET" is nothing more than a big gooey bowl of marketing mush that has no clear definition other than what's on Microsoft's current pricesheet. There is no clear technical definition, and the PHB Sell avoids discussion of CLR/IL/C#-based dev tools and sells the sizzle ("web services").
Thus you are completely off base for flaming people on the definition of
No, you don't. You are much more comfortable in believing that .NET is a grand masterplan invented by the evil geniuses at Microsoft to take over the world.
Reality is that Microsoft is just an ordinary company that makes a lot of mistakes and screws up a lot. Probably even more than other companies. Of course they make tons of cash because IBM gave them the x86-OS monopoly. But *anybody* no matter how incompetent can make tons of cash with that.
Some things that might change your mind:
- Windows was not an evil plot to take over everything. Windows was already abandoned after v2.0 and Microsoft's strategy was to go with OS/2. However a Microsoft employee played with it in his free time and laid the foundation for Windows 3.0 which was picked up after relations to IBM went worse and OS/2 was delayed and delayed. So Windows was essentially an accident, if that employee wouldn't have played with it, OS/2 and IBM would probably dominate today! (which would be much worse BTW, because it's hardware and software)
Most Microsoft projects were big failures: Windows/Mips, Windows/PowerPC, Windows/Alpha, "Homer" Project, Modular Windows, "Otto" Projekt, MMOSA (Set-Top-boxes Operating System), WebTV, Blackbird/Internet Studio (1995), proprietary MSN which should replace the Internet, COOl (C++ Object Orientated Language), PenWindows, Microsoft Bob.
In 12 Months we can also add "XBox" to the list. Just look at Japanese sales which were so low that retailors cancelled orders IN THE FIRST WEEK of the launch!!
And I'm also very excited to see the European launch where the XBox will cost nearly twice as much as the PS2.
(And unlike those other projects, XBox is very visible and will scratch Microsoft's reputation of being invincible.)
but I think that as you point out, reality does not include Windows being killed off "in a few years."
What's the point in running Windows if you can get all the apps on another platform, too? I don't think PC-makers would sacrifice 20% (and increasing) share of their revenue to go directly to Microsoft if there was an other OS that could run all the apps reliably.
And most people will use whatever comes on the PC. (as long as it runs their apps)
Nor do I understand why it necessarily has to die?
Did I say that? I said that it would die, not that it's necessary. I personally wouldn't care if Windows lifes forever if I could run all apps on Linux. But on a leveled playing-field, Windows simply doesn't have much of a chance. On a leveled playing-field Windows will die, not because I want it to, but because of basic market forces. It's not like there is a big community around Windows that writes drivers. If the hardware-maker doesn't do a driver, there will be no driver. Microsoft couldn't write all the drivers, even if they wanted to.
Just look at server and embedded system markets. On those, almost all apps are available on Linux, therefore Windows starts to fade, because there is no added value for the money. Of course a lot of companies use Windows on servers because they are used to it, but show me any startup-company that uses Windows on servers.
Companies grow and shrink, come and go. Without startups, a platform is doomed to fail.
The same is happening on embedded systems. Even in the PDA-sector (which is a tiny part of embedded) where WinCE should be strong, all new PDA-designs are Linux-based. Show me any company that has *started* to produce PDAs in the last 2 years that uses WinCE - there are none.
In non-PDA embedded areas, WinCE's situation is even worse.
I did a little searching based on the phrase "replace HTTP" and found the link
http://apachecon.com/2001/EU/html/speakers.html
Which points to decsriptions of workshops and seminars being discussed at Apachecon, the parts relevant to this discussion being:
Roy Fielding
Sessions: waka: a replacement for HTTP
Roy T. Fielding is chairman of the Apache Software Foundation and chief scientist at eBuilt, Inc.
He is a founder of several open-source software projects (including Apache httpd), architect of the current Hypertext Transfer Protocol (HTTP/1.1), and co-author of the Internet standards for HTTP and Uniform Resource Identifiers (URI). He received his Ph.D. in Information and Computer Science at the University of California, Irvine.
There is a popup link that says:
The waka protocol is designed to be a replacement for HTTP as the primary application-level protocol for the transfer of hypermedia information over the Web. It is based on the same architectural principles as HTTP/1.1, but without the baggage of preexisting syntax restrictions. Waka has a tokenized, self-descriptive syntax for communicating multiple asynchronous data streams over a single transport connection. This talk provides an introduction to the waka protocol and insights to its eventual impact on the Web Architecture.
Sounds impressive to me, does anyone else know more?
What I want to know is this; what is going to replace http? The article really doesn't say other than alluding to p2p as the way of the future.
Now, I may agree that p2p will be way cool as its uses are just barely beginning to be explored but I don't think we will see http disappear any time soon. I wouldn't be surprised if five years from now things are essentially the same as they are now in this respect and http is still a staple of many things web related.
And this;
Why? If you make a request and it takes you that long to respond... your clients will search for a different source for the data. How many customers do websites lose for loading slow in the first place? You might as well use snailmail for that kind of stuff.
So... mod me down if you must but somebody please explain what Box is talking about here.
Prospecting Stinks. Stop Wasting Time on Cold Calling.
As Bruce Schneier says, the cutting edge is always moving, but the low-end is here to stay.
Old standards have a way of hanging on, even when there are superior replacements. Look at all the strange, vestigial crap in PC hardware. Look at NTSC video, 8.3 filenames. You'd be amazed how many large companies keep important data in VSAM files instead of real databases. People might start using new standards for new applications, but the old standards will still cling in the old applications or eveb in new applications that must interact with old ones.
Are there exceptions where old technology was phased quickly? Sure. The cost of change can be high, and business people generally want technology that is Good Enough rather than following the latest and greates trends just for their own sake.
You should see the old tech that is still used in the finantial sector. In these parts, the rule of thumb is "If it ain't broke, don't fix it." When you are dealing with people's money (and government regulations therof), the cost of botching a change is very high.
--mkb
I've never heard Don Box described as just a .Net engineer. That'd be like calling Richard W. Stevens just a "C programmer."
/. is with the Windows world.
Thanks for the laugh. It's always good to be reminded just how out of touch
But how is MiscroSoft going to get .NET into the homes of the average computer user?
.NET into homes. Office has been their most recent candidate, but most users can either get by without it, or will use older versions (95, 97, 2000, XP) The latter having some, but not all, of the available infiltration functionality built in. Windows Media is a likely future choice, but if downloads become too bloated, user will likely turn elsewhere.
Most of them are still on Windows 98 -- and don't see any convincing reason to change. They've seen four "new" versions of windows and many have tried them and gone back to 98. MicroSoft's delivery mechanism has been the Windows Update (which most people without broadband or with a healthy sense of paranoia disable) and Internet Explorer. With IE 5.5 now fairly usable and standardized, they'll need a new app to get
Microsoft's only vehicle now seems to be new systems from OEMs. Unfortunately, hardware is no longer the limiting factor for most users.