Web Services solve a basic, but pervasive problem experienced by many of us with today's Internet. Although literally billions of pages of useful data and information are served up by the Web, it is typically difficult to extract, examine, and use that data programmatically.
Much of this difficulty arises from the fact that the Web (at least as it exists today) is designed for human consumption. Consequently, data is presented in a form that's easy for a human to read but relatively difficult and error prone for applications to read and process reliably.
Web services are all about delivering distributed applications via programmable components that are accessible over the Web. As an example, many e-commerce sites need to calculate shipping charges based on a variety of shipping options. Typically, such a site might maintain a set of database tables that describe the shipping options and charges for each shipping company.
Obviously, this can become a time-consuming process, because the data is likely to change often, and someone must repeatedly update the tables.
A more automated approach might incorporate a process called "screen scraping." Suppose that one of the shipping companies maintains a Web site that conveniently lists the various shipping options and associated charges. By utilizing screen scraping (essentially a process of analyzing the data in a page for certain patterns in order to extract the data you are interested in processing), a program can examine the Web page and extract the shipping information from that page.
Suddenly and unexpectedly, your screen scraper may no longer be able to locate the data you need. Now, imagine this same e-commerce site programmatically calling a Web service provided by the shipping company on its Web site that automatically calculates shipping costs based on the shipping method and package weight that you specify in your request and returns the resulting charge to you in real time.
Potentially valuable applications of Web services ARE
Services that are either too difficult or too expensive to implement yourself.
For example, credit card validation, financial account management, stock quotes, and so on.
Services that provide commonly needed functionality for other services. For example, user authentication, usage billing, usage auditing, and so on.
Services that aggregate distributed, discrete services into an orchestrated whole. A good example of this type of service would be travel booking.
Services that integrate your business systems with your partners (or other business systems within your own organization).
No wonder so much excitement surrounds the promise that Web services offer to programmers, systems integrators, and IT professionals.
What is a Web service?
A Web service is a programmable URL. Stated another way, a Web service is an application component that is remotely callable using standard Internet protocols such as HTTP and XML. Thus, any system that supports these basic, standard protocols is capable of supporting Web services.
The ability to package application code into reusable components that is callable across process and machine boundaries is not a new concept. Today, technologies are available such as the Component Object Model (COM), the Common Object Request Broker Architecture (CORBA), Internet Inter-ORB Protocol (IIOP), and Remote Method Invocation (RMI), to name a few. A key limitation of these technologies is that they are not easily interoperable amongst the tremendous number of heterogeneous systems that comprise the Internet.
This is due, in part, to dependencies on particular operating systems, programming languages, or object-model-specific protocols. Consequently, this limits their effectiveness as a standard method for programming the Web. Clearly, what is needed for Web services to succeed on the Internet is a platform that does not depend on a specific operating system, object model, or programming language.
What sets Web services apart from these prior-generation component and middleware technologies is the fact that they are built upon widely accepted Internet standards that can interoperate seamlessly in the diversity of the Web. Web services use a text-based messaging model to communicate, allowing them to operate effectively on these many different platforms.
If you are familiar with creating and consuming COM components for distributed applications, you will find creating and consuming Web services a natural evolution of what you already know.
Foundational elements of Web services
Now that you have an idea of what Web services are and how they can be used, let's examine the key technologies that you will encounter when working with Web services.
Microsoft provides an excellent platform for building and consuming Web services with the .NET Framework, which virtually eliminates the need to learn about the "plumbing" that is a part of building and consuming Web services. If things worked right all of the time and never had the opportunity to fail, there would be no need to even discuss this plumbing. But, of course, things don't always work right and, when they don't, it is both useful and practical to have a basic understanding of the working principals of the foundation upon which Web services are built.
The goal is to empower you with enough knowledge that you can effectively troubleshoot any problems you might encounter when working with Web services.The key to the broad-reach capabilities of Web services on the Internet is a foundation built on Internet standards that does not rely on any platform-specific technology.
This foundation supplies standards-based services that provide the following capabilities to Web services:
Representing Data
Web services enable consumers to programmatically request and obtain structured data.
To promote the ability of Web services to communicate their data unambiguously, efficiently, and effectively, a common, portable, and standard method for describing data must be used.The simple (and logical) answer is XML.
What is XML?
XML provides a standards-based method for describing data (also known as metadata).
XML has the ability to describe data using a simple grammar that is highly interoperable among the many heterogeneous systems that are connected to the Internet. Using the basic elements of the XML language, you can describe simple as well as complex data types and relationships.
XML has several key strengths that have helped it to become the de facto method for describing data (especially over HTML and other binary formats):
XML is a text-based language, which makes it easily readable and more portable than binary data formats.
XML gives you the ability to define your own tags to describe data and its relationships to other data (hence, the word extensible in its name).
XML strictly enforces its language syntax, unlike HTML.
Parsers are widely available to accurately parse and validate XML structures that you define, which means you don't have to do it yourself!
Of course, XML is not without it's weaknesses. Among these is the fact that XML can be more "wordy" than an equivalent binary format. In addition, data interoperability can be difficult to achieve due to differences in naming conventions from one application to another.
XML syntax
XML is a markup language that, at first glance, looks very much like HTML. In fact, XML and HTML are both derived from the Standard Generalized Markup Language (SGML).
XML (like HTML) uses a set of human-readable tags and declarations to create a document. The major difference is in the meaning implied by these tags and declarations. Whereas HTML is concerned with describing how to format information on a page, XML is concerned with describing data and its relationship to other data.
XML uses tags enclosed in <> angle brackets to define elements that form element structures and hierarchies within an XML document.
XML document structure
An XML document consists of a prolog, document elements, and optional attributes that model a logically related set of data. An invoice is one example of such an information model. The prolog contains information that applies to the document as a whole and appears at the top of the document before the first document tag. The prolog usually contains information about the character encoding and document structure as well as other possible information. XML parsers use the prolog to correctly interpret the contents of an XML document.
XML namespaces
When developing XML documents, it is common to refer to element and attribute names that share a common context as a vocabulary. Thus, we might say that our previous sample XML document belongs to a weather vocabulary. Given that an XML document consists of a vocabulary that you define, the possibility arises that an element or attribute in that vocabulary may have a name that is identical to an element or attribute used by someone else in a different vocabulary.
XML namespaces solve this ambiguity problem by associating an explicit namespace (or vocabulary) with elements and attributes in an XML document. Thus, a namespace is essentially a set of names in which all the element and attribute names can be guaranteed to be unique.
Default namespace declaration
Default declaration defines a namespace whose scope includes all elements contained within the element where the declaration was specified. Default declaration is typically used when a document contains elements from a single namespace. Our weather Example used a default namespace declaration because all the elements shared the same context or vocabulary (in other words, none of the elements refers to elements from other namespaces).
XML schemas
In our coverage of XML thus far, it was mentioned that the XML parser uses strict rules to ensure that the XML document is well formed. Recall that a well-formed XML document is one that follows the rules for properly closing tags, nesting tags, enclosing attributes in quotes, and using a unique first element.
However, this does not address the issue of validating that an XML document contains the proper assortment of elements and in valid combinations. What is needed is a language that will allow a generic XML parser to determine that the document conforms to these additional, user-defined rules.
The XSD language defines rules for describing the valid combinations and relationships of elements, attributes, and data types that can appear in an XML document.
RELATED POST
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
Much of this difficulty arises from the fact that the Web (at least as it exists today) is designed for human consumption. Consequently, data is presented in a form that's easy for a human to read but relatively difficult and error prone for applications to read and process reliably.
Web services are all about delivering distributed applications via programmable components that are accessible over the Web. As an example, many e-commerce sites need to calculate shipping charges based on a variety of shipping options. Typically, such a site might maintain a set of database tables that describe the shipping options and charges for each shipping company.
Obviously, this can become a time-consuming process, because the data is likely to change often, and someone must repeatedly update the tables.
A more automated approach might incorporate a process called "screen scraping." Suppose that one of the shipping companies maintains a Web site that conveniently lists the various shipping options and associated charges. By utilizing screen scraping (essentially a process of analyzing the data in a page for certain patterns in order to extract the data you are interested in processing), a program can examine the Web page and extract the shipping information from that page.
Suddenly and unexpectedly, your screen scraper may no longer be able to locate the data you need. Now, imagine this same e-commerce site programmatically calling a Web service provided by the shipping company on its Web site that automatically calculates shipping costs based on the shipping method and package weight that you specify in your request and returns the resulting charge to you in real time.
Potentially valuable applications of Web services ARE
Services that are either too difficult or too expensive to implement yourself.
For example, credit card validation, financial account management, stock quotes, and so on.
Services that provide commonly needed functionality for other services. For example, user authentication, usage billing, usage auditing, and so on.
Services that aggregate distributed, discrete services into an orchestrated whole. A good example of this type of service would be travel booking.
Services that integrate your business systems with your partners (or other business systems within your own organization).
No wonder so much excitement surrounds the promise that Web services offer to programmers, systems integrators, and IT professionals.
What is a Web service?
A Web service is a programmable URL. Stated another way, a Web service is an application component that is remotely callable using standard Internet protocols such as HTTP and XML. Thus, any system that supports these basic, standard protocols is capable of supporting Web services.
The ability to package application code into reusable components that is callable across process and machine boundaries is not a new concept. Today, technologies are available such as the Component Object Model (COM), the Common Object Request Broker Architecture (CORBA), Internet Inter-ORB Protocol (IIOP), and Remote Method Invocation (RMI), to name a few. A key limitation of these technologies is that they are not easily interoperable amongst the tremendous number of heterogeneous systems that comprise the Internet.
This is due, in part, to dependencies on particular operating systems, programming languages, or object-model-specific protocols. Consequently, this limits their effectiveness as a standard method for programming the Web. Clearly, what is needed for Web services to succeed on the Internet is a platform that does not depend on a specific operating system, object model, or programming language.
What sets Web services apart from these prior-generation component and middleware technologies is the fact that they are built upon widely accepted Internet standards that can interoperate seamlessly in the diversity of the Web. Web services use a text-based messaging model to communicate, allowing them to operate effectively on these many different platforms.
If you are familiar with creating and consuming COM components for distributed applications, you will find creating and consuming Web services a natural evolution of what you already know.
Foundational elements of Web services
Now that you have an idea of what Web services are and how they can be used, let's examine the key technologies that you will encounter when working with Web services.
Microsoft provides an excellent platform for building and consuming Web services with the .NET Framework, which virtually eliminates the need to learn about the "plumbing" that is a part of building and consuming Web services. If things worked right all of the time and never had the opportunity to fail, there would be no need to even discuss this plumbing. But, of course, things don't always work right and, when they don't, it is both useful and practical to have a basic understanding of the working principals of the foundation upon which Web services are built.
The goal is to empower you with enough knowledge that you can effectively troubleshoot any problems you might encounter when working with Web services.The key to the broad-reach capabilities of Web services on the Internet is a foundation built on Internet standards that does not rely on any platform-specific technology.
This foundation supplies standards-based services that provide the following capabilities to Web services:
- A standard, portable method for describing data
- A standard, extensible message format for communicating requests and responses
- A standard, extensible method for describing the capabilities of Web services
- A method to discover what Web services are available at any particular site
- A method to discover what sites provide Web services
Representing Data
Web services enable consumers to programmatically request and obtain structured data.
To promote the ability of Web services to communicate their data unambiguously, efficiently, and effectively, a common, portable, and standard method for describing data must be used.The simple (and logical) answer is XML.
What is XML?
XML provides a standards-based method for describing data (also known as metadata).
XML has the ability to describe data using a simple grammar that is highly interoperable among the many heterogeneous systems that are connected to the Internet. Using the basic elements of the XML language, you can describe simple as well as complex data types and relationships.
XML has several key strengths that have helped it to become the de facto method for describing data (especially over HTML and other binary formats):
XML is a text-based language, which makes it easily readable and more portable than binary data formats.
XML gives you the ability to define your own tags to describe data and its relationships to other data (hence, the word extensible in its name).
XML strictly enforces its language syntax, unlike HTML.
Parsers are widely available to accurately parse and validate XML structures that you define, which means you don't have to do it yourself!
Of course, XML is not without it's weaknesses. Among these is the fact that XML can be more "wordy" than an equivalent binary format. In addition, data interoperability can be difficult to achieve due to differences in naming conventions from one application to another.
XML syntax
XML is a markup language that, at first glance, looks very much like HTML. In fact, XML and HTML are both derived from the Standard Generalized Markup Language (SGML).
XML (like HTML) uses a set of human-readable tags and declarations to create a document. The major difference is in the meaning implied by these tags and declarations. Whereas HTML is concerned with describing how to format information on a page, XML is concerned with describing data and its relationship to other data.
XML uses tags enclosed in <> angle brackets to define elements that form element structures and hierarchies within an XML document.
XML document structure
An XML document consists of a prolog, document elements, and optional attributes that model a logically related set of data. An invoice is one example of such an information model. The prolog contains information that applies to the document as a whole and appears at the top of the document before the first document tag. The prolog usually contains information about the character encoding and document structure as well as other possible information. XML parsers use the prolog to correctly interpret the contents of an XML document.
XML namespaces
When developing XML documents, it is common to refer to element and attribute names that share a common context as a vocabulary. Thus, we might say that our previous sample XML document belongs to a weather vocabulary. Given that an XML document consists of a vocabulary that you define, the possibility arises that an element or attribute in that vocabulary may have a name that is identical to an element or attribute used by someone else in a different vocabulary.
XML namespaces solve this ambiguity problem by associating an explicit namespace (or vocabulary) with elements and attributes in an XML document. Thus, a namespace is essentially a set of names in which all the element and attribute names can be guaranteed to be unique.
Default namespace declaration
Default declaration defines a namespace whose scope includes all elements contained within the element where the declaration was specified. Default declaration is typically used when a document contains elements from a single namespace. Our weather Example used a default namespace declaration because all the elements shared the same context or vocabulary (in other words, none of the elements refers to elements from other namespaces).
XML schemas
In our coverage of XML thus far, it was mentioned that the XML parser uses strict rules to ensure that the XML document is well formed. Recall that a well-formed XML document is one that follows the rules for properly closing tags, nesting tags, enclosing attributes in quotes, and using a unique first element.
However, this does not address the issue of validating that an XML document contains the proper assortment of elements and in valid combinations. What is needed is a language that will allow a generic XML parser to determine that the document conforms to these additional, user-defined rules.
The XSD language defines rules for describing the valid combinations and relationships of elements, attributes, and data types that can appear in an XML document.
RELATED POST
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
