Reliability in the face of rapid change
Bad protocol, bad politics
A discussion with Kiran Prasad, Kelly Norton, and Terry Coatta
"Not invented here" syndrome is not unique to the IT world.
A proposal to improve the performance and availability of streaming video and other time-sensitive media
A study of the technology and sociology of Web services specifications
Instead of simply imagining what your users want or need, it's always a good idea to first get their input.
Google Maps, Yahoo! Mail, Facebook, MySpace, YouTube, and Amazon are examples of Web sites built to scale. They access petabytes of data sending terabits per second to millions of users worldwide. The magnitude is awe-inspiring. Users view these large-scale Web sites from a narrower perspective. The typical user has megabytes of data that are downloaded at a few hundred kilobits per second. Users are not so interested in the massive number of requests per second being served; they care more about their individual requests. As they use these Web applications, they inevitably ask the same question: "Why is this site so slow?"
When it comes to achieving performance, reliability, and scalability for commercial-grade Web applications, where is the biggest bottleneck? In many cases today, we see that the limiting bottleneck is the middle mile, or the time data spends traveling back and forth across the Internet, between origin server and end user.
At the foundation of Amazon's cloud computing are infrastructure services such as Amazon's S3 (Simple Storage Service), SimpleDB, and EC2 (Elastic Compute Cloud) that provide the resources for constructing Internet-scale computing platforms and a great variety of applications. The requirements placed on these infrastructure services are very strict; they need to score high marks in the areas of security, scalability, availability, performance, and cost effectiveness, and they need to meet these requirements while serving millions of customers around the globe, continuously.
In the early days of the Web we severely lacked tools and frameworks, and in retrospect it seems noteworthy that those early Web services scaled at all. Nowadays, while the tools have progressed, so too have expectations with respect to richness of interaction, performance, and scalability. In view of these raised expectations it is advisable to build only what you really need, relying on other people's work where possible. Above all, be cautious in choosing when, what, and how to optimize.
Can AMQP enable a new era in messaging middleware? AMQP (Advanced Message Queuing Protocol) was born out of my own experience and frustrations in developing front- and back-office processing systems at investment banks. It seemed to me that we were living in integration Groundhog Day - the same problems of connecting systems together would crop up with depressing regularity. Each time the same discussions about which products to use would happen, and each time the architecture of some system would be curtailed to allow for the fact that the chosen middleware was reassuringly expensive.
Many think of Amazon as 'that hugely successful online bookstore.' You would expect Amazon CTO Werner Vogels to embrace this distinction, but in fact it causes him some concern.
Tim Bray's Waterloo was no crushing defeat, but rather the beginning of his success as one of the conquerors of search engine technology and XML. In 1986, after working in software at DEC and GTE, he took a job at the University of Waterloo in Ontario, Canada, where he managed the New Oxford English Dictionary Project, an ambitious research endeavor to bring the venerable Oxford English Dictionary into the computer age.
Stu Feldman, Queue board member and vice president of Internet technology for IBM, interviews the chief executive officer of the nonprofit Internet Archive.
Google is one of the biggest success stories of the recent Internet age, evolving in five years from just another search engine with a funny name into a household name that is synonymous with searching the Internet. It processes about 200 million search requests daily, serving as both a resource and a challenge to developers today.
Web services are emerging as the dominant application on the Internet. The Web is no longer just a repository of information but has evolved into an active medium for providers and consumers of services: Individuals provide peer-to-peer services to access personal contact information or photo albums for other individuals; individuals provide services to businesses for accessing personal preferences or tax information; Web-based businesses provide consumer services such as travel arrangement (Orbitz), shopping (eBay), and e-mail (Hotmail); and several business-to-business (B2B) services such as supply chain management form important applications of the Internet.
As web services become increasingly sophisticated, their practitioners will require skills spanning transaction processing, database management, middleware integration, and asynchronous messaging. IBM Lightweight Services (LWS), an experimental hosting environment, aims to support rapid prototyping of complex services while insulating developers from advanced issues in multi-threading, transactions, and resource locking. To achieve this we adapt a high-level, event-driven, single-threaded scripting environment to server-side application hosting. Developers may use this freely available environment to create robust web services that store persistent data, consume other services, and integrate with existing middleware.
Adam Bosworth's contributions to the development and evolution of Web Services began before the phrase "Web Services" had even been coined. That's because while working as a senior manager at Microsoft in the late '90s, he became one of the people most central to the effort to define an industry XML specification. While at Microsoft, he also served as General Manager of the company's WebData organization (with responsibility for defining Microsoft's long-term XML strategy) in addition to heading up the effort to develop the HTML engine used in Internet Explorer 4 & 5.
Common wisdom has it that enterprises need firewalls to secure their networks. In fact, as enterprise network practitioners can attest, the "must-buy-firewall" mentality has pervaded the field.
Much of web services' initial promise will be realized via integration within the enterprise, either with legacy applications or new business processes that span organizational silos. Enterprises need organizational structures that support this new paradigm.
The name of the game is web services - sophisticated network software designed to bring us what we need, when we need it, through any device we choose. We are getting closer to this ideal, as in recent years the client/server model has evolved into web-based computing, which is now evolving into the web services model. In this article, I will discuss Sun Microsystems' take on web services, specifically Sun ONE: an open, standards-based web services framework. I'll share with you Sun's decision-making rationales regarding web services, and discuss directions we are moving in.
While detractors snub XML web services as CORBA with a weight problem, industry cheerleaders say these services are ushering in a new age of seamless integrated computing. But for those of us whose jobs don't involve building industry excitement, what do web services offer?