Home > Articles

The Road to Web Services

Kenn Scribner and Mark Stiver provide a brief conceptual and historical overview of the issues driving the emergence of Web Services.
This article is excerpted from Chapter 1, "Web Service Fundamentals," of Applied SOAP: Implementing .NET Web Services by Kenn Scribner and Mark Stiver (ISBN 0672321114).
Like this article? We recommend

Most things in software engineering happen for a very good reason—or, at least, we hope so. This is how concepts such as abstraction and encapsulation have become mainstream. As with any technology, we learn from past mistakes and capitalize upon our successes.

Web Services are no different. They have materialized from a variety of Web technologies that have been proven to work in the widely distributed environment of the Internet. The Internet itself has evolved over the years, spawning many new ideas and concepts that have contributed to the Web Service approach.

Waves of the Internet

Since the beginning of the Internet, many changes have come about in networking technology, security, system scalability, and many other areas of distributed computing. Overall, we believe that the Internet has succumbed to four major waves of development.

The first wave of the Internet started around the 1970s with some very important government research, specifically the Defense Advanced Research Projects Agency (DARPA). This is where Transmission Control Protocol/Internet Protocol (TCP/IP) was born. Its goal was to interconnect computer systems through a complex architecture of networks and subnetworks. Over the years, a variety of physical networks (such as Ethernet) and routing technologies evolved to the point that, in 1990, more than 200,000 computers were interconnected on the Internet.

Although Internet connectivity was one of the most significant achievements in computing, it meant very little without applications to drive it. This is where the second wave of the Internet began (roughly in the 1980s). Tools such as FTP and Telnet gained in popularity by allowing system users to remotely access other computers. Although the tools were crude, compared to today's standards, the underlying protocols that they used where quite elegant.

In the early 1990s, the Internet began to seep into more sophisticated applications and led to the dawn of the Web, which marks the third wave. Browsers—and eventually Java applets—allowed the general consumer to experience interconnected communities of users. Of course, where there are consumers, there are vendors. This spawned more electronic business opportunities, as evidenced by the plethora of electronic storefronts and shopping carts.

All this, of course, has brought about the fourth wave of the Internet, which is the focus of this book—Web Services. Here, the goal is for multiple diverse applications to communicate so that they can execute some task. Not only does this improve the user's experience, but it also offers the ability for you to integrate functionality at a much lower cost than developing it all yourself. From the user's standpoint, all of this is orchestrated from a single application. But behind the scenes, one or more additional applications will likely participate. The key is that the applications work while remaining oblivious to vendor-specific technologies being used by the participating services.

Looking back, each wave introduced new Internet standards that facilitated the next wave of development.

Internet Standards

In April of 1969, the first Request for Comments (RFC) was published at UCLA (RFC1), and thus began the process of sharing ideas in computing for a much greater cause. Then, in 1986, the Internet Engineering Task Force (IETF) was officially created. Its charter was (and still is) to evolve the architecture of the Internet using open contributions from the research and development community.

After inventing the Web, Tim Berners-Lee decided to create the World Wide Web Consortium (W3C) in October of 1994. The W3C's purpose is to promote interoperability and open forum discussions about the Web and its protocols.

These organizations have led the way to standardization, a process that has resulted in a strong foundation for the Web Service infrastructure.

Several standards are prevalent in current Internet development. Some have existed for years, and others are relatively new, and not necessarily standards. This section summarizes these technologies and shows how they apply to Web Services.

HTTP and SMTP

As stated before, TCP/IP is the foundation of Internet communication protocols. However, TCP/IP without an application is a little like a car without a driver. How an application uses TCP/IP also determines the semantics of that application's protocol.

Application protocols such as HTTP and Simple Mail Transfer Protocol (SMTP) already have predefined semantics and behavior that determine how they should be used. For HTTP, the semantic implies a request/response model designed to serve Web resources such as HTML or JPG files. SMTP, on the other hand, implies a one-way request/acknowledge semantic designed to transmit text-based email messages in a fire-and-forget manner.

NOTE

Fire-and-forget is a military warfare term that has been overloaded for networking purposes. We use it to describe the process of sending a message, where the sender does not require any acknowledgement that the recipient actually received the message.

In the context of Web Services, these application protocols are used to carry additional semantics, such as those specified by SOAP. SOAP in turn, provides a way for you to define your application semantics that are also carried over these application protocols. This layering of semantics just re-emphasizes the flexibility of Web Service protocols.

Because HTTP is the dominant protocol being used for Web Services, let's take a quick look at the two most common aspects of HTTP being exploited, the GET and POST verbs.

The following is a sample HTTP GET request:

GET /default.htm HTTP/1.1
Accept: text/*
Host: http://www.mcp.com
{CR}{LF}

In this case, the client is requesting that the http://www.mcp.com server return the default.htm resource. The client would like to use version 1.1 of the HTTP protocol in this transaction and is willing to accept the resource as some form of text. Notice that the message is terminated by the carriage return/line feed pair following the message.

Many times you need to provide application-specific information to the server that is not represented in the semantics of the HTTP protocol. For instance, you can pass parameters on the URL, as shown:

GET /GetStockQuote.asp?symbol=MSFT HTTP/1.1
Accept: text/*
Host: http://www.mcp.com
{CR}{LF}

Given this sample request for obtaining stock quote information, the symbol parameter and its value are passed on the query string, and you can expect the server to respond with some form of HTML, such as the following:

HTTP/1.1 200 OK
Content-type: text/html

<html><head><title>Microsoft Stock Price</title></head>
<body>
  <b>Microsoft: 80.75</b>
</body>
</html>

The server's response contains the HTTP version, a status code and message, and the content type that is associated with the related payload following the carriage return/line feed pair.

However, using the GET request is less than optimal when dealing with large and complex parameters. Certain HTTP implementations and older firewalls have been known to truncate URLs based on poorly chosen size limits. URLs also undergo encoding for a large number of characters, which complicates processing procedures.

Instead, we can use the HTTP POST verb, which places information within the Body of the request message:

POST /GetStockQuote.asp HTTP/1.1
Accept: text/*
Host: http://www.mcp.com
Content-type: text/xml
Content-length: nnnn


<Symbol>MSFT</Symbol>

Similar to the GET verb, the POST verb also identifies a resource, the version of HTTP, and the content that it expects to receive. However, two additional HTTP fields are provided—Content-type and Content-length. The two new fields refer to the remainder of the message, which, in this case, happens to carry an XML message.

Here you can see that we are no longer bound by limitations of the URL there is less character encoding taking place, and we are able to transmit more complicated payloads—this is by far the most helpful aspect of HTTP when used in the Web Service model.

NOTE

Although we generally recommend that you use the POST method, in some situations using GET might make sense. GET is best used for simple semantics that require only minimal message structure and in situations when client applications don't have control over the POST payload.

An example of this is with the Visual Studio.NET test pages that are generated with your Web Services. Because the browser's POST feature does not allow you to place customized information in the message Body, the GET verb comes in very handy.

Also note that your test pages won't support complicated parameter types (neither with the WSDL for HTTP GET or POST), so you'll be required to manually build a client that can exercise your service in this case.

eXtensible Markup Language (XML)

Although XML has such a wide variety of uses, it makes a great foundation for Web Services for many reasons:

  • In a world where global business arrangements are becoming the norm, XML natively supports different character sets through Unicode (UTF-8, UTF-16, and so on).

  • XML promotes interoperability in a platform-agnostic way by promoting the convergence of information to a common, vendor-neutral state.

  • Probably most importantly, XML is simple.

As we briefly mentioned before, XML is really just syntax for application semantics that you must define. To define semantics and the associated XML syntax for your semantics, you need to establish the appropriate structure and restrictions of your markup—you do this through a schema.

XML Schemas

When you want to describe (and possibly validate) an XML document, you might use a Document Type Definition (DTD), such as this one:

<!-- House DTD -->
<!ELEMENT house (address)>
<!ATTLIST house bedrooms CDATA #REQUIRED
        bathrooms CDATA #REQUIRED>
<!ELEMENT address (street, city, state, zip)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT zip (#PCDATA)>

As you can see, though, DTDs are limited by their somewhat cryptic syntax and lack of type checking.

In February 2001, the XML Schema specification was promoted to Recommendation status by the W3C. XML schemas not only encapsulate the same feature-function as DTDs, but they also offer complex type checking, all wrapped up in an XML language. This makes XML schemas the preferred method of describing all forms of XML documents, including XML messages. The same example is shown in XML Schema format, as follows:

<!-- House XML Schema -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:complexType name="AddressType">
  <xsd:sequence>
   <xsd:element name="street" type="xsd:string" />
   <xsd:element name="city" type="xsd:string" />
   <xsd:element name="state" type="xsd:string" />
   <xsd:element name="zip" type="xsd:decimal" />
  </xsd:sequence>
  <xsd:attribute name="bedrooms" type="xsd:positiveInteger" use="required" />
  <xsd:attribute name="bathrooms" type="xsd:positiveInteger" use="required"/>
 </xsd:complexType>

 <xsd:element name="house" type="AddressType" />
</xsd:schema>

SOAP

Although SOAP isn't officially an Internet standard, it has been widely adopted by the Internet community, including the Electronic Business XML (ebXML) organization, for its transport and routing layer.

To summarize SOAP in a single word, packaging is the most appropriate description. Many developers have created ad-hoc approaches for sending XML messages between their applications. The creators of XML-RPC took the concept to the next level, by exposing a publicly available specification for XML messaging. Taking XML-RPC a step further, SOAP basically defines a standard yet extensible way to wrap information in XML so that both ends of the connection (and potentially everything in between) can understand how to open this package. Let's take a quick look at a SOAP request message:

<SOAP-ENV:Envelope 
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Header>
   <t:transId xmlns:t="http://www.mcp.com/trans">
     87654
   </t:transId>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
   <m:GetStockQuote xmlns:m="http://www.mcp.com/stock">
     <Symbol>MSFT</Symbol>
   </m:GetStockQuote>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

This simple message shows the general packaging of a SOAP message. The Envelope contains an optional Header and a mandatory Body. The Header is used for out-of-band information that doesn't necessarily apply to the semantics of the message Body. The Body is used to carry the application-specific message content. This is definitely not all that SOAP represents, but it captures the spirit of what SOAP set out to accomplish. We'll leave it to Chapter 4, ".NET Web Services and SOAP," to provide the gory details about the remainder of the SOAP protocol.

WSDL and UDDI

WSDL is the description language that is used to describe how software must interact with a particular Web Service. Clients use WSDL documents to understand the logical structure and the syntax of a Web Service. WSDL also provides message exchange patterns, service bindings, and references to the location of a service.

Growing in popularity, Universal Description, Discovery, and Integration (UDDI) is one way for the publish, find, and bind process to be accomplished. UDDI servers allow WSDL to be published and propagated across the Internet so that clients can ultimately consume a given service.

Although neither WSDL nor UDDI has been standardized, the industry is giving both the most attention of any similar mechanisms. A great deal more about WSDL and UDDI will be explained in Chapter 5, "Web Services and Description and Discovery."

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020