Historical Influences

for RuBoard

Let's take a look back at the genesis of the Web. How did it start? It was the combination of a document format, HTML, and a protocol, HTTP, that enabled scientists to share documents in a standard fashion and to link those documents together. This was nothing new. We had a myriad of document formats: WordPerfect, Word, or even LATEX. The problem was that none of these document formats was interoperable. The guy who used WordPerfect couldn't read the LATEX documents, and vice versa. An interoperable document format alone, however, wouldn't solve the problem. A way also had to exist for scientists to discover papers published by other colleagues. This was done initially by placing hyperlinks into the document to enable navigation to other documents. Theoretically, given a starting point, a scientist could read a document and (by utilizing the hyperlinks) navigate to information related to the subject at hand. This navigation scheme assumed that there was a known starting point. This problem gave rise to the directory, such as Yahoo!, as a starting point. It was up to the directory to catalog the Web and indicate the appropriate starting point.

This clearly was a successful paradigm for finding, navigating to, and reading information. As the Internet grew, it became clear that a need existed for businesses to exchange information and transact business online. Although the Web was successful for humans to exchange information, it had far too little organization to make it an effective way for very literal-minded computers to take advantage of it.

What was appropriate (if not ideal) for a human being was far from ideal for a computer. First, computers need a fairly rigid structure to be applied to the information that they are exchanging. This structure must go beyond the document format to also encompass the structure and organization of the actual information itself. Second, if computers are going to trade information, there needs to be a way to agree on the format of information that is being exchanged. Finally, a need still exists to find partners to trade with. Given a partner, a business can negotiate with them to determine what services they may expose, but how does it find new partners? It still has a need for a directory service, but in this case it's one that the computer can query to find appropriate partners .

One answer to this problem is the concept of a Web service. This is in contrast to the ubiquitous Web page that we all know and love. A Web service is just what it sounds like: a facility that provides a way to do work. That being said, a Web service is not a Web page. It is not intended to be consumed by human eyes; it is intended to be consumed by a computer and is optimized for this type of access. If you want to make an analogy to the existing computer world, you could think of a Web service as a new form of Remote Procedure Call (RPC). Historically, the problem with RPC has been the lack of an open and widely accepted standard that defines how to represent data on the network, how to identify endpoint locations, and how to advertise the endpoints. Wait! This sounds very much like the problems just mentioned that the Web was created to solve! So let's take each of those three problems and think about how to translate the lessons of the Web to services.

for RuBoard


C# Developer[ap]s Guide to ASP. NET, XML, and ADO. NET
C# Developer[ap]s Guide to ASP. NET, XML, and ADO. NET
ISBN: 672321556
EAN: N/A
Year: 2005
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net