Introducing XML web services. (Teach-In).

Back in 1994 and 1995, the world was taken over by a new wave of computing. The browser was introduced to the mass public, and people could sit in the comfort of their own homes and, over slow connections, these end users could connect to remote computers. At that moment, many of us felt that an earth-shattering change had occurred.

I, as an end user, could sit in front of a lightweight application (the browser), type in some unique address, and away my browser went on some journey to the other side of the world. It went off for me like a car on a road trip through the pipes of the Internet. Sometimes my little car had to stop and ask for directions, and other times it may have been lost somewhere "out there" never to be found again, but in most instances it brought back a whole carload of information that it displayed in the container of my browser. I was truly awed.

It was a new dawn of computing. No longer did we need to locally house information on our machines at home or in the office. Instead, we were able to venture out onto the Internet and get the information that we needed.

It wasn't long before people realised that this medium would he great to not only deliver information, but it would also be an outstanding way to provide applications to people around the world regardless of their locale. Before the Internet, if your application needed an update or a quick change, it would be a while before the end user saw the change. The Internet application answered this problem mainly because there was really only one instance of the application that was housed somewhere on a server and this single instance of the application simply dished out responses to all the requests that came its way regardless of where the end user is in the world. If there was a change to make to the application, changes were then made to this single instance and because of this, the end user was always seeing the latest and greatest version of the application. At this point in Internet history, many people thought they were in some sort of utopia and things just simply couldn't be any better than this.

Browser-based applications became more advanced as time went on. Over time, many businesses had information about customers in thick-client applications, databases, content management servers, XML files, and tab-delimited text files, in addition to the information and functionality that was provided by the company's Web applications. Everything was scattered, and these information islands cropped up everywhere in the enterprise.

What was needed was a way for these systems, which were in many cases quite disparate, to communicate with one another so that this information could be shared. Sharing data and application logic works toward the Holy Grail of computing--code reuse. Instead of housing the customer's order information in three separate parts of the enterprise, the three separate applications that needed this information could share it instead from a single source ensuring that the data was always correct and up to date. However, many of these information islands were miles apart in languages and platforms and getting them to work together sometimes was difficult at best.

What is This Internet Thing

As the Internet started to infiltrate the enterprise, this newly spread pipeline was connecting all these data islands together. It didn't take long for various vendors (for example, Microsoft, IBM, Sun Microsystems, and others) to see that their applications and servers in the enterprise could use this pipeline for communication.

What faced each of the vendors is that they could work out ways for one entity on the Internet to communicate with another, but the problem was that there was no common-language or industry-wide standard that disparate systems could use in their desire to communicate with each other as a whole. What was needed was a common language that used a common protocol.

Instead vendors implemented proprietary solutions on their own. For example, Microsoft released DCOM as their solution, but like other solutions from other vendors, it didn't answer all the problems that the enterprises faced in getting these disparate and distant systems to talk to one another.

These solutions were in many cases using proprietary forms of communication. In some cases, such as is the case with DCOM, these solutions were dependent on specific ports to be open for application-to-application communication to occur. This was generally a problem in the enterprise space because it is not typically the developers that are controlling the opening and closing of ports within their company, but it is usually operations whose general philosophy is to lock down everything but port 80 (for surfing the Internet) for security reasons.

In the end, some of these new technologies helped, but in most cases, the basic problems still existed. There had to be an easy way for completely disparate systems (for example, a Microsoft system and an Apache system) to communicate data and business logic across the wall that stood between them. It soon became evident that no single company or proprietary system could answer these problems; instead, it would take a concerted effort on the, part of the entire IT industry to find a solution. What the industry needed to do was to find a common language that everyone agreed upon and that no single company controlled.

Understanding the Beauty of XML

It came to light to all the major vendors within the IT industry that XML (Extensible Markup Language) was the answer for complete integration of the enterprise, regardless of the platform, language, or fashion in which data is stored. More importantly, this new XML communication would occur over HTTP.

Probably the most vital decision to come from all of this was that all the vendors understood the logic of working together in a set of common standards and protocols so that cross-platform communication could occur. The core pieces that everyone agreed upon for this new form of application communication, called simply Web services, involved the following three technologies:

* XML

* SOAP

* HTTP

XML is an ASCII based way to describe data. It is extremely flexible and that is the power of this technology as it is easy to describe a wide variety of data quite easily using XML. The other advantage of XML for data description is that most applications and platforms can read and understand XML, making it quite versatile.

SOAP, or Simple Object Access Protocol, is an XML-based way of describing an XML encapsulated message that is being sent across the wire. The power of SOAP is that it is based upon XML, making it easily understood by the same applications and platforms that can read and use XML. Secondly, as its name suggests, it is simple and quite extensible.

HTTP is the wire in which these SOAP messages are sent from one point to another HTTP is the Internet, and the medium that we are going to be using for our SOAP requests and responses. The great thing about SOAP using HTTP is that not only do most applications and platforms use HTTP in one manner or another, but SOAP simply flows through firewalls as regular Internet traffic over HTTP.

Microsoft's XML Web services

Based on these industry agreements, Microsoft introduced XML Web services as a core component of its new .NET platform. XML Web services in ASP.NET is a new model for exposing application logic. The entire .NET Framework has been built around this model and Microsoft provided a number of new tools and core functionality that make it quite simple to build and consume XML Web services in .NET.

One way to think of how an XML Web service works is to compare it to calling a standard function, by making the call over HTTP (Hypertext Transfer Protocol) specifying a URL. This model of Web services is quite different than previous models, although it is similar to older models as well.

For example, the classic Active Server Pages model was based on the client/server technologies. The client made a request over the Internet, or HTTP, and the response, if there was one, was sent back by the same means. On the receiving end of the request, application logic or registration was applied and in most cases, a response was sent back. When users opened their browsers and typed a URL, a request for the page was sent to a server. The server made note of the page being requested and a stream of information (usually HTML) was sent back over the wire to the client. In some cases, before the requested server sent anything back over the wire, it went to another location to check another server or database for some additional information. Figure 1-1 shows how this model looks. Working with XML Web services basically involves the same model, except that we are not using ASP or ASP.NET to build an interface that we would use to activate requests and receive responses over HTTP. There are many situations in which we would want to expose the logic or information that we are holding in a database somewhere, but we would not always want to build a visual interface to that logic or information.

[FIGURE 1-1 OMITTED]

For example, say that you are a large wholesaler of a wide variety of widgets and you have a number of customers who depend upon your current inventory status in order that their customers can place appropriate orders. The entire widget inventory is stored in a SQL Server database and you want to give access to this database to your customers. You could build a Web interface to this database in ASP.NET that would allow users to log on to your system and gather the information that they would need.

However, suppose your users want to put the information on their own Web site, or extract it for their own customers? This is where you can expose your database information to them by offering it as an XML Web service. Doing this will allow customers to access the information in whatever fashion they choose because only the data is returned. Now, within their own Web page, they can make a call to your XML Web service and get the information sent to them in an XML format, where they can use it as they see fit. Thus instead of building separate Web interfaces for different clients to access this data, you need only provide the application logic to the users, and let them handle it in their own way.

What is outstanding about this entire process is that it doesn't matter which system the end user is using to make this request. It is not a Microsoft proprietary message format being sent to the users, instead, everything is being sent over standard protocols. The message is being sent over HTTP using SOAP, a flavour of XML. Therefore any system that can consume XML over HTTP can use this model. Figure 1-2 shows an example.

[FIGURE 1-2 OMITTED]

Composition of XML Web services

Visual Studio NET and the Microsoft .NET platform make building and consuming XML Web services very easy. However, it is important that you understand the basic structure of XML Web services in order to make your ventures into this new application model successful. There are a few pillars of XML Web services development that will make this job a lot easier. Not all of these specifications or technologies that are used to build and consume XML Web services are required, but you should still review and understand them before you seriously start using XML Web services in any of your applications. Building XML Web services within the NET environment allows the following:

* An industry-standard way to represent data

* A way to transfer data in a common message format

* A way to describe an XML Web service to potential consumers

* A path to discovery of XML Web services on remote servers and local machines

* A way to find XML Web services

Now let's take a look at how each of these functions plays a role in XML Web services.

Introducing XML

Just as XML is tightly integrated throughout the .NET Framework, XML is the key technology used in Web services. Most of the Web services that are available today use XML for data representation as well as XML Schemas to describe data types. As you will see, using XML just makes sense. XML Schemas, or XSD documents, are an important part of working with XML. XSD documents support an XML document by specifying the structure of the XML document. As a replacement for Document Type Definition (DTD) documents, XSD documents are ideal as they are made up of XML themselves unlike the former DTD documents.

In its short lifetime, XML has become the Internet standard in data representation. XML came to light when the W3C (World Wide Web Consortium) realized that it needed to develop a markup language to represent platform-independent data. In 1998, XML was developed and was quickly hailed as the solution for data transfer across varying systems. Not only could XML be transported over HTTP, but it could also go through firewalls, making this markup language quite fluid.

XML Web services, as its name suggests, is highly dependent on XML. Data makes the Internet go around and XML is an elementary way that data can be represented and packaged for transport to other systems.

In the past, one way to package data for transport was to place the data within a comma, tab, or pipe-delimited text file. Listing 1-1 shows an example of such a file.

Listing 1-1: An example of a pipe-delimited text file.

Bill|Evjen|Programmer|03/08/1998|Seattle, Washington|2

These kinds of data representations are in use today. The individual pieces of data are separated by pipes, commas, tabs, or any other characters you want to use. Looking at the collection of items in Listing 1-1, it is hard to tell what the data represents. You might be able to get a better idea based on the file name, but what do the date and the number 2 represent?

XML relates data in a self-describing manner so that any person, technical or otherwise, can decipher what the data means. Listing 1-2 shows how the same piece of data is represented using XML.

Listing 1-2: XML file example

<xml version="1.0" encoding="UTF-8" ?>
<Employee>
  <FirstName>Bill</FirstName>
  <LastName>Evjen</LastName>
  <JobTitle>Programmer</JobTitle>
  <StartDate>03/08/1998</StartDate>
  <WorkLocation>Seattle, Washington</WorkLocation>
  <NumDependents>2</NumDependents>
</Employee>

In Listing 1-2, you can tell by just looking at the data in the file what each of the data items means and how they relate to one another. This is laid out in such a simple format that it is possible for any non-technical person to be able to understand the data.

After looking at this XML file, you may have noticed how similar XML is to HTML. Both markup languages are related, but HTML is used to mark up text for presentation purposes such as for delivering Web pages in a browser, and XML is used to mark up text for data representation purposes.

Both XML and HMTL have their roots in the Standard Generalized Markup Language (SGML), which was created in 1986. SGML is a more complex markup language that was also used for data representation. With the explosion of the Internet, the W3C realized that it needed a universal way to represent data that would be easier to use than SGML, and that brought forth the birth of XML.

Advantages of XML in data representation

There are a number of ways to represent data, a few of which have already been addressed in this chapter. XML has a distinct advantage over other forms of data representation. The following list explains some of the reasons why XML has become as popular as it is today:

* XML is easy to read and understand.

* A large number of platforms support XML and can manage it through an even larger set of tools that are available for XML data reading, writing, and manipulation.

* XML can be used across open standards that are available today.

* XML allows developers to create their own data definitions and models of representation.

* XML is simpler to use than binary formats when sending complex data structures because there are a large number of XML tools available.

Communicating Data from XML WEb Services

XML Web services use XML for data representation in order that different systems and applications can quickly share and consume data. XML is based on standards and any application or system that can take hold of an XML file and use it in some fashion is a candidate for dealing with an XML Web service. To take advantage of this wide acceptance, you need to be able to transport the XML data from point A to point B. XML Web services use HTTP, and occasionally SMTP, to transport XML data from one point to another. Figure 1-3 shows how this works.

As shown in Figure 1-3, by using an XML Web service, you are making a request from some sort of client. This request then triggers a response from the server. The request message carries information about the function to be called and any parameters that are required by the function. Once the server that hosts the XML Web service receives the request message from the client, it initiates the function and returns a response message that contains information returned by the function. This response message can be just a simple message that some specific action was taken or it can contain a complete dataset. What you return is really up to you.

[FIGURE 1-3 OMITTED]

Editorial Note:

The above feature was taken from a new book 'Web Services Enhancements' Wiley Publishing Inc. ISBN:-7645-3736-9 as an illustration of how a technical subject can be clarified by simple clear presentation. In total there are some nine chapters. Readers must be prepared to download the latest versions of .NET and Visual Studio .Net and have a system capable of running the Microsoft Web Services Toolkit, the .Net Framework and Visual Studio .Net. This data is supplied in the book.