In August 2001 I first learned the details of an effort in Microsoft to rewrite COM+ using managed code. Nothing much happened after that. Then, in July 2002, during a C# 2.0 Strategic Design Review, the remoting program manager outlined in broad strokes plans to rework remoting into something that developers should actually use. At the same time, Microsoft was also working on incorporating the new security specs for web services into the ASMX stack and actively working with others on drafting a score of additional web services specs.
In July 2003 I was given access to a new transactional infrastructure that improved on the deficiencies in transactional .NET programming. As of yet, there was no cohesive programming model that unified these distinct technologies. Towards the end of 2003 I was privileged to be invited to join a small team of outside industry experts and participate in the strategic design review of a new development platform code- named Indigo. Some of the smartest and nicest people I know were part of that team. Over the next 23 years Indigo went through some three generations of programming models. The current declarative, endpoint-driven object model debuted in early 2005, was stabilized by August of that year, and was named the Windows Communication Foundation (WCF).
It is difficult to get a consistent answer from different people on what WCF is. To the web service developer, it is the ultimate interoperability solution, an implementation of a long list of industry standards. To the distributed application developer, it is the easiest way of making remote calls and even queued calls. To the system developer, it is the next generation of productivity-oriented features, such as transactions and hosting, that provide off-the-shelf plumbing for applications. To the application developer, it is a declarative programming model for structuring the application. And to the architect, it is how one can finally build service-oriented applications. WCF is in actuality all of those, simply because it was designed that wayto be the unified next generation of Microsoft's disparate technologies.
After the fourth edition of JavaScript: The Definitive Guide was published, the Document Object Modelthe fundamental API for client-side JavaScript™ programmingbecame widely, if not completely, implemented in web browsers. This meant that web developers had a stable, mature language (JavaScript 1.5) and a common API for manipulating web pages on the client. Several years of stability followed.
But things have started to get interesting again. Developers are now using JavaScript to script HTTP, manipulate XML data, and even draw dynamic graphics in a web browser. Many JavaScript developers have also started to write longer programs and use more sophisticated programming techniques, such as closures and namespaces. This fifth edition has been fully revised for the new world of Ajax and Web 2.0 technologies.
I love getting started on new projects (and I include working on new editions of existing books in that general category). It is the perfect opportunity to say to myself: "I am going to get it right this time!"
That fantasy usually persists only for days (or maybe weeks) into a project before it fades, but in the case of the second edition of Oracle PL/SQL Best Practices, I managed to live out my fantasy all the way through. You are holding the result in your hands, and I hope you enjoy reading and learning from it as much as I enjoyed writing it.
Here's how I managed this remarkable feat: I took a vow to not let best practices get boring.
Now, don't get me wrong. I liked the first edition of this book, and so did its many readers. Yet in hindsight, I feel as if I took a right turn when I should have kept going straight. My first book, Oracle PL/SQL Programming, has been extremely popular over the years, and many people have told me how much they like the sense of humor, the anecdotes, and the many detailed examples.
Several years after the publication of Oracle PL/SQL Programming, I wrote Oracle PL/SQL Best Practices. And somehow, for reasons I cannot recall, I managed to make this book a somewhat preachy and rigidly structured text. Luckily for me, developers seem to like lots of structure and don't mind too much being preached at by people they trust!
But as I considered revamping this book for its second edition, I found myself thinking: best practices are really important, but that doesn't mean they have to be serious—they can be fun and entertaining (as much for me to write as for you to read)!
So that's what I did: I had fun writing this book. I sacrificed some of the rigidity of structure, emphasized practicality over theoretical usefulness, and generally came down off my perch (don't worry—there are still more than enough rants and soapboxing!). In this second edition, I've tried to make the discussion a lot more interesting by sharing many of my ideas about best practices through stories about the successes and failures of the employees of the fictitious company, My Flimsy Excuse, Inc., and the adventures of its development team (the members of the team are described later in the Preface). Of course, I have also updated the text to keep pace with Oracle Corporation's implementation of new PL/SQL features, including those in Oracle Database 11g.