Living Stones Updates

 
 
 
  • About

    Updates to the software and services provided by Living Stones Ministry
  • Living Stones Ministry

    The mission of Living Stones Ministry is to be used by God to build up His body, the Church, by providing software tools and building blocks

Enter your email address:

Delivered by FeedBurner

 
AJAX September 23rd, 2005

Asynchronous JavaScript and XML (aka AJAX) is likely to have a huge impact on the software industry over the coming years.

In the early 1990s when the Web was first introduced, the initial excitement was all about linking together information to make it much easier for folks to move around and find documents referenced by the author of the document they were currently reading. When Netscape emerged in the mid 1990s, the company promoted a new vision for software that would make desktop software from companies like Microsoft obsolete.

Netscape obviously didn’t survive long enough to see that happen. A big part of the problem was that Microsoft didn’t exactly like the idea of their products being made obsolete. And Microsoft had the resources and position to undermine Netscape’s value proposition and revenue stream/business model. Whether legally or illegally, Microsoft took actions that led to Netscape’s demise.

However, another big part of the problem with Netscape’s vision was that it just didn’t work. The web was originally designed as a document model. Your web browser asked for a document from a server, and then displayed it for you. Smart people added lots of functionality over the years including the ability to run programs that run “through” the web browser, but the model remained that each time the user wanted something to change, they had to request a new document, or at least an updated version of the current document. That’s not how good desktop software works.

AJAX changes all of that. The name of the technology explains the ways in which this happens, so let’s take it apart.

The first A in AJAX stands for Asynchronous. That means that the web browser and the web server no longer have to wait on each other to take action. Specifically, the web browser can send a request to the server and then immediately go back to doing whatever the user wants and not sit “spinning” waiting for the server to respond. When the server does respond, the browser can decide what to do with the response.

The J in AJAX stands for JavaScript. JavaScript was basically invented by Netscape based loosely on ideas and syntax in the Java programming language invented by Sun Microsystems to specifically run programs within a web browser. JavaScript is a relatively light-weight programming language that only does stuff on the browser side. It can’t (at least not very easily) take any action with the server. It’s great for making a web page appear very dynamic to the user, for example, changing the background color of an object when the user moves his mouse over it, or checking that data entered by the user is valid before it gets sent to the server. JavaScript has been a huge addition to the web and has made the web a much more interesting and much more user-friendly place, but again, it really only works on the browser side, so it can’t, by itself update data on the server or get new information from the server.

The second A in AJAX is important. It stands for And, because it’s the combination of JavaScript AND XML (the X in AJAX) that could finally bring about Netscape’s original vision and could cause big problems for companies like Microsoft.

XML stands for eXtensible Markup Language. The web was originally written to run using HTML or HyperText Markup Language. Tags within an HTML document tell the browser how to display a document – what to bold, what colors to display, where to place a picture, etc. The tags are well defined so that any web browser can display any web document, as long as they both use the HTML tags to mean the same things.

XML allows anyone to define any tag to basically mean anything (I’m sure this is a gross overstatement, but you get the picture). A standard web browser generally won’t know what to do with XML tags because they are no longer a standard set that everyone follows. Instead XML allows a server to send XML “documents” (it may be easier to think of them as messages) to a program that has been written to understand the specific XML tags that the server is using. There are generic ways to do this, but it’s much more interesting when a program has been written for a specific purpose to understand specific data with specific tags from a specific type of server. In a simple way, this is exactly what HTML is – web browsers are programs written for a specific purpose (to display web documents) by understanding the specific HTML tags used by web servers when sending web documents.

XML has become most interesting, because most XML is NOT being used to format documents for humans to read, but rather for computers to communicate with each other and make sense of the data that is being sent back and forth.

So, what does this have to do with JavaScript and AJAX? Well, in AJAX, the user does something (like click on a button) which kicks off a JavaScript function. That function generates an XML request to an XML server, asynchronously (in other words, it sends the request, and then gets back to work responding to the user’s actions). The XML server responds to the request by providing the requested data. When it arrives at the user’s computer, JavaScript kicks in again, takes the supplied data, and does something – such as updating the information being displayed to the user – but without having to totally redraw the entire page. To the user, this seems to work just like any other desktop program.

As with many technologies, this is easier to show than to explain. Here’s a demonstration of an AJAX application.

As with many Internet-based technologies, Google is probably the most aggressive user of AJAX in providing new applications for users. Gmail, Google Maps, and Google’s customized homepage are all real-world examples of AJAX in action.

Web Services September 21st, 2005

One of the most powerful and exciting trends in technology is the emergence of “web services.” This technology trend allows computers to talk to each other to accomplish tasks in ways that are transparent to us end users. The way this works is that one computer acts as the server and other computers request help from the server, which responds to their requests. That way the functionality can be implemented on one computer and made available to many other computers without burdening those other computers with the resource constraints required to perform the function.

The most famous example of web services is Google’s API. It has taken years of software development and crawling the web to build a massive index of the entire Internet. None of us could afford to duplicate that functionality nor the terabytes of disk storage required to hold that index data. However, Google now allows virtually any website (under specific license restrictions) to search their index and present the search results within the independent website.

We will look for similar opportunities to enable many websites to add functionality without burdening themselves with the resources required for that functionality. Our first such capability is Bible searching and passage lookup. It takes several megabytes of disk space to store the text of any one translation of the Bible. Since most web hosting services charge based on the amount of disk space you use, this alone can prevent you from adding Bible tools to your website. We also know from experience that although Open Source tools are available for your website, these can be a challenge to implement and to customize to your website’s look and feel.

Therefore, we have implemented a web service for any website to be able to search any of three Bible translations that are in the public domain (KJV, AKJV, ASV) and to lookup passages from those translations. While most web services use a standard called XML (eXtensible Markup Language) over SOAP (Service Oriented Architecture Protocol) to communicate between servers, we have chosen to use a more lightweight markup language and a technique called REST (REpresentational State Transfer). What this means is that your web server merely sends a message to our web server that looks just like an HTTP GET request and our server sends your server back a message that can easily be parsed to pull out the information you need to present the results.

This is a whole lot easier to demonstrate than explain. Try it out here.

Welcome to Living Stones September 21st, 2005

The name Living Stones has two meanings.

The main focus of the ministry is to create software building blocks used by web developers to strengthen their church and ministry websites. These building blocks are active and dynamic, thus the term “living stones” is appropriate.

The second meaning of the name Living Stones is relative to 1 Peter 2:5 which refers to God’s people as living stones, being built up as a spiritual house to be a holy priesthood. It is our hope that every product of our ministry will be used to build up God’s people in this way.

This blog will be a place where I can share lengthier discussions of features of Living Stones products without burdening the ministry’s web pages with verbosity.

Look for specific articles under the Categories listed to the left.