I think I just coined a new term. Maybe it will catch on. You know, like "blog" or "tweet". But alas, only time will tell. So what do I mean by the phrase "universal encapsulation"? It's quite simple, actually. It refers to the concept that certain reusable services are centrally available on a worldwide basis for web application developers to use. This prevents duplication of code not only within a project or orgranization, but within the entire application development community at large. The concept of universal encapsulation dictates that frequently required services, used by a broad spectrum of web applications, including everything from e-Commerce to simple registration forms, will be available on an as-needed basis for those web applications. This faciliates more efficient and timely delivery of code which meets business requirements. Let's take a common example. If you are developing a site that requires user registration, the odds are fairly good that you'll require that person's physical address. If that person lives in the United States, you will probably provide that person with a drop-down of all fifty states (and the District of Columbia) in an abbreviated fashion. How will you accomplish this? Most likely, you will code it yourself. And you will manually enter the 2-digit codes for all 50 states. In response to that, one simple question need be asked: Why? Since so many web applications require a 50-state drop-down list, why would you need to code it? Shouldn't that code be available somewhere for all developers to simply reference, as opposed to recoding it themselves? With the advent of technologies such as AJAX and REST, it shouldn't even be a debate. Somewhere, there should be a REST service available which returns a list of all 50 states, including their 2-letter abbreviations, in XML or JSON format. This could then be parsed and placed in a drop-down list. Needless to say, the advantage here is not only to the efficiency of the development effort, but it minimizes code maintenance at a later date. Suppose, for example, a 51st state is added. If universal encapsulation is strictly followed, the update needs to occur only where the REST service is hosted, and not within the hundreds of thousands of applications using that service. Now, it may be true that somewhere out there, unbeknownst to this author, there is such a service which returns a formatted representation of the 50 United States. However, the concept of universal encapsulation takes things a step further. Not only should this service be universally available, but all services which are widely used. For example, zip code lookup. This seems to me to be a fantastic concept, the breadth of which has yet to be explored. Companies like Microsoft, IBM, and even Amazon should consider making these services available to the web development community at large. The effort would yield very good PR for organizations with the infrastructure capable of hosting such an effort, and may also be monetized at a later date outright. As of this writing, I cannot even find a simple REST directory. In fact, I Googled "REST directory" and got nothing of significance in return. The point here is that even if reusable services are not centrally located within one organization, they can still be centrally referenced in a web directory. Maybe one web site could provide a formatted 50-state return service in REST, while another could provide a zip code lookup. But they would both be referenced in the same directory. Developers need only consult the directory to find the service that is needed. With so much open source technology out there today, it's hard to believe that this concept hasn't even been discussed yet. In conclusion, I ask again: Where is universal encapsulation? 3/26/09