Thursday, April 07, 2005
Key to combat hacking - Quantum Cryptography
Quantum cryptography could well be the first application of quantum mechanics at the individual quanta level. Quantum cryptography is an approach to securing communications based on certain phenomena of quantum physics. Unlike traditional cryptography, which employs various mathematical techniques to restrict eavesdroppers from learning the contents of encrypted messages, quantum cryptography is focused on the physics of information. The process of sending and storing information is always carried out by physical means, for example photons in optical fibres or electrons in electric current.
Eavesdropping can be viewed as measurements on a physical object---in this case the carrier of the information. What the eavesdropper can measure, and how, depends exclusively on the laws of physics. Using quantum phenomena such as quantum superpositions or quantum entanglement one can design and implement a communication system which can always detect eavesdropping. This is because measurements on the quantum carrier of information disturb it and so leave traces.
Some commercially-available products have appeared based on quantum cryptography, for example, ID Quantique or MagiQ.
Friday, April 01, 2005
REST - Second Generation Web Services
REST - Second Generation Web Services
REST stands for REpresentational State Transfer, and is an architectural style for large-scale software design. REST was first articulated by Roy Fielding in his dissertation, which describes Fielding's view of the architecture of the "best" subset of the Web.
The REST hypothesis is that the semantics of HTTP constitutes a coordination language that is sufficiently general and complete to encompass any desired computational communication pattern.
The REST hypothesis is that the semantics of HTTP constitutes a coordination language that is sufficiently general and complete to encompass any desired computational communication pattern. I.e., the hypothesis is that GET / PUT / POST / etc. can provide all coordination semantics between discretely modeled units of programs (and in case it's not all, or there's other practical reasons for it, HTTP is sufficiently extensible to support new methods being added). REST is comparable to message passing (provably completely general) or function calling with parameters in its ability to express any computational communication / coordination pattern. Obviously, there are other operations needed to actually do the work.
One interesting aspect of REST vs. these new XML-based web services is how REST jives with the Interface Segregation Principle (The dependency of one class to another one should depend on the smallest possible interface.)-- that interfaces are defined by the client's needs, not the server's needs... and for dependency management we need smaller, fewer protocols -- not more.
The premise of REST adherents is that HTTP in and of itself has the set of "verbs" (GET, POST, etc) we need to implement web services. All we need new are lots of "nouns" (URIs).
Interesting links on REST:
The REST hypothesis is that the semantics of HTTP constitutes a coordination language that is sufficiently general and complete to encompass any desired computational communication pattern.
The REST hypothesis is that the semantics of HTTP constitutes a coordination language that is sufficiently general and complete to encompass any desired computational communication pattern. I.e., the hypothesis is that GET / PUT / POST / etc. can provide all coordination semantics between discretely modeled units of programs (and in case it's not all, or there's other practical reasons for it, HTTP is sufficiently extensible to support new methods being added). REST is comparable to message passing (provably completely general) or function calling with parameters in its ability to express any computational communication / coordination pattern. Obviously, there are other operations needed to actually do the work.
One interesting aspect of REST vs. these new XML-based web services is how REST jives with the Interface Segregation Principle (The dependency of one class to another one should depend on the smallest possible interface.)-- that interfaces are defined by the client's needs, not the server's needs... and for dependency management we need smaller, fewer protocols -- not more.
The premise of REST adherents is that HTTP in and of itself has the set of "verbs" (GET, POST, etc) we need to implement web services. All we need new are lots of "nouns" (URIs).
Interesting links on REST:


