I don't think its a question of "unusable" but certainly things like a VPN are one way to add some security around physical connection, but lots of other scenarios require a bit more, or different, security. e.g. if you have 200 businesses connecting then the odds are that you won't be able to agree on one VPN solution and want to see identity more directly through the applications.
The point really is that well engineered systems have "ilities" and it is the engineering that matters, picking one software implementation approach or another will help (or hinder) in those decisions but ultimately there is no magic wand that means "use X and your system will meet all its ilities" On 04/06/07, Hitoshi Ozawa <[EMAIL PROTECTED]> wrote:
+1 Makes me remember a comment made by a customer some years back when he told me that he insists on using TR4 (token ring) over 1GB CDMA/CD because token ring was more "reliable". I, also, remember reading an article few years back on cache. Everybody wanted to put cache in their part of a product - e.g. chips, OS, and applications. The article debated on whether all these caches actually made the overall application to the enduser faster. I think security is like a cache. If my application servers are all going to be connected only by a private network segment or by a VPN, do I need another level of security? I do understand that there are some situations where there is no underlying security layers, but I was wondering how many such actual situations exists to warrant a technology as being labeled unusable. H.Ozawa Mark Baker wrote: > On 6/2/07, Steve Jones <[EMAIL PROTECTED]<jones.steveg%40gmail.com>> wrote: > >> To say that something that works over HTTP will exhibit "reliability" >> sounds a little bit odd, given that HTTP is by design an unreliable >> protocol. >> > > REST concerns itself with properties of an architecture as a whole, > not of individual features of the system. It has been understood for > decades, that it is possible to build reliable systems with unreliable > messages. > > Mark. > >
