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?
"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.
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.
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
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!
New Protocol Speeds Up Internet Resource Sharing
The new technology speeds to 10 times faster the allocation of Internet resources, said Park of his proposed Order-based Deadlock Prevention Protocol with Parallel Requests.
"In the near future, the demand for collaborative Internet applications will grow," Park said. "Better coordination will be required to meet that demand, and this protocol provides that."
Park describes his research in a paper, "A Scalable Protocol for Deadlock and Livelock Free Co-Allocation of Resources in Internet Computing," given Jan. 29 at the Institute of Electrical and Electronics Engineers' Symposium on Applications and the Internet in Orlando, Fla.
Park's proposed algorithm enables better coordination of Internet applications in support of large-scale computing. The protocol uses parallel rather than serial methods to process requests. That helps with more efficient resource allocation as well as solves the problems of deadlock and livelock caused by multiple concurrent Internet applications competing for Internet resources.
The new protocol also allows for Internet applications to choose among available resources. Existing technology can't support making choices, thereby limiting its utilization.
Its other advantage: Because it is decentralized, Park's proposed protocol can function with its own information. That allows for collaboration across multiple, independent organizations in the open environment of the Internet. Existing protocols require communication with other applications - not feasible in the open environment of the Internet.
Internet computing - the integration of widely distributed computational and informational resources into a cohesive network - allows for a broader exchange of information among more users than is possible today. Those can range from the military and government to businesses.
One example of such collaboration is Grid Computing that, much like electricity grids, harnesses available Internet resources in support of large-scale, scientific computing. Right now, the deployment of such virtual organizations is limited because they require a more sophisticated method to coordinate the resource allocation.
Park's decentralized protocol could provide that.
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.
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