Slashdot Mirror
A New Protocol For Faster Web Services?
Roland Piquepaille writes "Jonghun Park is an Assistant Professor of Information Sciences and Technology at Pennsylvania State University. He says that a new protocol can improve Web services. Sandeep Junnarkar broke the story. "Jonghun Park proposed a method for sharing information between systems linked on the Internet promises to speed collaborative applications by up to 10 times the current rates. The protocol is based on an algorithm that lets it use parallel instead of serial methods to process requests. Such a method boosts the efficiency of how resources are shared over the Internet. The new protocol is called Order-based Deadlock Prevention Protocol with Parallel Requests." Check this column for some excerpts or read the CNET News.com article for more details. More information about Jonghun Park's works can be found at his homepage."
Wasn't this reportedly the theory behind the Irish Young Scientists Xwebs project?
Wasn't that what ISDN was meant to do?
-Mark
I could find nothing about it on that dude's homepage, and the article is terse to say the least. Where's some actual information about this?
Daniel
Carpe Diem
Putting the entire story in the slashdot posting is an interesting solution to the slashdot effect. Of course the content is a little more bland....
I'd prefer if the article we picked had some actual information about the protocol... off to google....
"The new protocol is called Order-based Deadlock Prevention Protocol with Parallel Requests"
He should've spent more time on the name, no one will call it by it's full name, and think of the acronyms:
ODPPPR
OBDPPPR
OBDPPWPR
It's bad for the system when no one can talk about it.
GL
won't that make things more unsafe/unstable too?
because http is plain simple, it is easy to determine where resides what functionality.
if systems become more connected and integrated into each other, won't that make it much harder to determine what is going on on your system?
i can imagine that msft will have a go at running parts on your system on their registration servers. this seems to me like another step towards DRM.
i understand that this is just a protocol, but if people will start interconnecting systems, there will be (security issues)++
Int
Jonghun Park is an Assistant Professor of Information Sciences and Technology at Pennsylvania State University. He says that a new protocol can improve Web services. Sandeep Junnarkar broke the story. "Jonghun Park proposed a method for sharing information between systems linked on the Internet promises to speed collaborative applications by up to 10 times the current rates. The protocol is based on an algorithm that lets it use parallel instead of serial methods to process requests. Such a method boosts the efficiency of how resources are shared over the Internet. The new protocol is called Order-based Deadlock Prevention Protocol with Parallel Requests."
First, there is this whole climate fuelled by RIAA/MPAA that makes the very mention of collaborative applications something criminal.
Secondly, if there is to be a non p2p media sharing usage for this protocol, it has to get industry support. Read M$.
This looks like a solution looking to solve a problem that doesn't exist. Where have we seen this before?
Anybody who's done real database engineering knows the two points necessary to prevent deadlocks: (of course, most designers/programmers don't do this...)
1. Every process locks resources in the same order.
2. No process ever escalates a lock.
Enforce these two adages ruthlessly and you'll never get a deadlock.
So all this guy is saying is "Engineer your distrubuted databases properly." Woot.
That's called pipelining, right? We already have this in various protocol, including HTTP which is used quite frequently for various web services (think SOAP)
ATM networks have a high speed channel and low speed channel (I believe). We are implementing a new protocal in our systems at work. Basically data that needs to be blocked is sent on one channel and realtime data that cannot be blocked is on the other. The channel can be easily told apart by indicating it in th header of the message. Note this is different than have more than one port.
Yes but every time I try to see it your way, I get a headache.
And you'll notice the technology is for "Web services" not as in web pages, as in colaberative data bases or applications over the internet. Its not meant as a web server. And this protocol does have some advantages, as in the prevention methods of deadlock (read the article)
Jesus saves, everyone else takes full damage from the fireball.
Maybe you should actually read what you link to. As was pointed out several times, the article was based on *assumptions* regarding *inconclusive data* made several *years* ago, by a person who admitted that they *didn't* know much about what they where talking about. And further more, those people who did not ready to blindly board the anti-MS bandwagon the second it appeared, actually did testing to verify whether that theory held any water. Guess what, it didn't. IE was shown to operate in a completing normal manner.
The open source movement would be a lot better off if it *didn't* have the "support" of parrot mouth lamers who spout off the "MS bad, Linux good" line before they even know what is going on. Quality over quantity people.
This article is useless. This quote is the only information that is remotely informative in the entire article.
And to get to my point, the management of resource access is hardly the job of the protocol. It is the job of the underlying web Service implementation to deal with these issues. Why should the protocol even have knowledge of the the resource state?
This is cool and schmool, but where exactly are the collaborating applications that need to share and lock resources across Internet? Locking is useful only in preventing concurrent access to a critical nondivisible resource. Of course, web browsers share servers, but they don't need to lock them (well, sometimes they "lock" them, but this is only a side effect known as "slashdotting"). P2P apps? I don't think they need to lock anything in order to share files.
A-ha! Web services! Ok, what web services? Have you ever used a distributed web service application that needed to lock resources? I thought so.
I am not saying that this protocol is bogus, but it will probably be useful for apps that don't exist yet, at least on the Internet.
There appears to be a common misconception that the subject being discussed here is simple web hosting.
This is not the case.
Web _services_ are a set of programmatically-accessible services implemented on top of HTTP, using a protocol like XML-RPC or SOAP. These web services are being used in current Grid Computing prototypes, hence the references to "collaborative applications".
The eventual aim of Grid Computing is to provide a means to expose resources (such as computational clusters, network links, visualisation suites, data-collecting instruments, SAN clusters, etc.); then, when jobs get submitted, the Grid infrastructure should automagically allocate resources for the task, taking into account what resources the submitter is permitted access to, what resources the job requires, what other jobs are already scheduled and potentially even what the monetary cost of using each resource is.
See also here and here.
OBDPPWPR://www.slashdot.org
... ;)
that's a little too crazy
You got it all wrong, you need to look at the context of the quote.
What he meant by that is that the deployment of web services is held up by security and reliability, this has nothing to do with performance. Everyone that has worked with web services know that web services are not up to date with security and reliability yet, but it is being worked on. And this is what is keeping web services from being used on a broader scale.
or even better, read his publications. While deadlocks are deadlocks, his research isn't about databases but concurrency. If there wasn't technical merit to his work his peers would reject his publications.
So long, and thanks for all the Phish
Since many (if not most) applications for Web Services are b2b, the speed of your modem is fairly irrelevant. When you pull up sometravelsite.com, it will be gathering information from other systems more quickly -from it's servers to other servers- and the web service communication portion of the architecture doesn't run over your last mile at all.
May be the answer is to stay away from http.
:)
Web Services is basically describing the kind of services run over http. Excessive services result in http request saturation and thus people has to find some ways to circumvene the performance problems.
The reason why people nowaday mostly rely on http is the laziness of admins in handling corporate security. Services like RPC calls multiply the complexity of administration and it'd be easier if we all target the request on a single channel - http, which most enterprise has already opened it for normal web servers. Web Services beat CORBA in term of convenience in depolyment, not in term of its technical merit. (for more information, see this comparison)
The article and the links followed are insufficient to tell what's inside this research. If he could really find a solution to http saturation problem, that solution can absolutely be applied to everything else. I'm pretty skeptic on it.
Wait wait, OD-3P-R?? What is that, the long lost love child of R2-D2 and 3P-0??
Park said that he will seek to commercialize the next generation of his protocol that he has been fine-tuning over the past year.
Why? Didn't he look at HTTP at all? The reason it was so successful and widespread was because Tim Berners-Lee did not commericalize it. If Park makes this protocol commercial, it will either not be adopted at all, or it will be bought and proprietized by Microsoft. Neither of those are particularly desirable. If he keeps it open and free, it could eventually garner as much popularity as HTTP. Tis too bad he cares only for getting a check.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
The speed increase will be offset by the length of time it takes to type the url.
x xx
Hypertext Transfer Protocol
http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
versus
Order-based Deadlock Prevention Protocol with Parallel Requests
obdppwpr://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Remember that you are unique, just like everybody else.
Most developers of enterprise systems don't need this. Traditionally, the bottleneck of data driven medium-to-big apps is the database; Connecting, connection pooling, reading, caching, whatever.
.NET has similar bottlenecks, but I don't know, haven't worked with it.
I'm working on a large web-services product/project now using various J2EE technologies (JRun, Castor, Object Relational Mapping, Axis) and my biggest bottlenecks are the database (problem mostly solved through caching, and clustered caching), XML Serialization/Deserialization or marshalling/unmarshalling (problem solved using Castor XML) of the object graph to and from the SOAP body and Java objects, and simply the passing of large object graphs through XML protocols like soap.
Go read the server-side.com, or Bitter Java, they'll tell you what the common bottlenecks are, and this usually isn't one of them.
I assume
--Stupidity is Self Curing!
HTTP was designed to be efficient for cases where a relatively simple request is going to result in a relatively large result dataset. Distributed services don't follow that pattern. You often have a relatively complex request (save changes to customer information) producing a simple result (changes saved/lost.)
HTTP also was also designed as a stateless protocol, and does not have the facilities to ensure any time or order based serialization of requests and results. (Yes it can be cobbled in via back-end stateful servers and session context data, but it isn't used by the HTTP server itself to serialize anything.)
Abusing a simple protocol in order to make life "easier" for the network configuration and administration team is just a bass-ackwards way of dealing with things. Networks are an infrastructure service for providing information systems to business, as are databases, file servers, application servers, programming services, etc. Nothing ever seems to end up "easy" except with a loss of functionality, efficiency, or scalability.
I do not fail; I succeed at finding out what does not work.
- Next Generation Internet
- Large Scale Networking
- The Xanadu model
- Common HTTP Implementation Problems
- Web Services Architecture Requirements
- etc, etc, etc
HTTP is a very primitive protocol. I don't know when or if it will be overhauled or superseeded, but if it is, it needs more than this suggestion, much more, lot's of work, planning, forsight, architecture and engineering.I am not saying that this protocol is bogus, but it will probably be useful for apps that don't exist yet, at least on the Internet.
And when they do exist, they'll use XA, a (relatively) open protocol developed by IBM, which has been proven over decades of distributed, heterogenous transaction processing (banks, airlines, telcos, etc). You can already mix CICS, Tuxedo, Oracle and DB/2 transactions with XA. (Note to Slashbots: it's OK if you haven't heard of CICS and Tuxedo). What do we need some newfangled nonsense for?
Why do I need this protocol when I already bought a Pentium 4 processor to make the internet go faster? :)
"It's a tarp!" -- Dyslexic Admiral Ackbar