Web Services
What are web services? Why are they popular? Why do you care?
A web service is some kind of software product that receives messages and responds to those messages.
- The messages are typically sent through the web using HTTP.
- The messages are typically formatted as XML.
- The messages typically follow the SOAP standard.
- These messages can represent remote procedure calls (RPC), or one way (event based) messages.
(Both supported by SOAP).
- The messages can be processed synchronously or asynchronously.
- The messages are typically described using a WSDL (pronounced wiz-dull) document.
Web Service popularity is on the rise for many reasons, three appear below.
XML is agnostic. XML messages can be created and consumed by any language on any platform. This allows
a team to implement a web service, or web service client, using any comfortable platform (J2EE, .Net, Cobol).
SOAP and related specs are not-proprietary. SOAP and related specifications have created a non-proprietary
way to format XML messages. Standardization allows you to integrate to different platforms like J2EE, .Net
and Mainframe. Web Services become a standard approach to integration between existing systems.
Web Services can be more loosely coupled than traditional component based architectures. Creating a web
service instead of publishing a component allows you to more loosely couple disparate systems. The loose
coupling of systems results in a more flexible implementation. The implementation can change if the interface
remains the same. A client could change which service provider is being used.
When describing a web service it is typically better to bring in a simple example web service. An example, no
matter how simple, provides a concrete view of what a web service is and what it does. The example we will
investigate is a simple Stock Price Quote Service.
Web Service Learner Example
To better understand Web services and the technologies that make it up, it is typically better to bring in a
simple example Web service. An example, no matter how simple, provides a concrete view of what a Web
service is and what it does. In this example, you investigate a simple Stock Price Quote Service.
In this scenario you are a developer working for a company that provides stock quotes to customers. The
service has been available through a browser for a long time, but using a browser requires some human
interaction. Users of this system have been creating HTML scraping applications to read the same
information, but the system is unreliable.
<html>
...
<td>Price:</td><td>45.55</td>
...
They use Regular Expressions to find the correct HTML tags. However, Web sites and there HTML pages
are changing all the time.
For example, open a browser and enter the following URL:
http://finance.yahoo.com/q?s=WFC or
http://finance.yahoo.com/q?s=MMM
Examine the source code of the HTM page that is displayed. In the browser, click on the View menu and
select Source. Attempt to locate the stock price in the HTML page provided to you. It could be done, but
what would your code look like? What would happen if Yahoo changed their site?
The customers of this service would like a simpler, more machine-friendly, way to call for this information.
They would like it to be as easy as a method call, like that below.
double quote = StockQuoteService.getQuote(“WFC”);
To facilitate the request, you decide to pass more structured XML out of your Web server instead of HTML.
The Web server is already in place. The price producing application is already in place. All you need to do is
add the XML reading/producing functionality. The XML is much easier for a client’s machine to parse, so
they can use the information you feed out more easily.
Web services allow you to reuse your infrastructure and applications while facilitating standard machine-to-
machine communications. There is no need to set up special servers or other communications infrastructure.
You can just use the existing Web infrastructure. Using a Web service in this situation would be as easy as
adding some functionality to your existing Web server. Your service still allows the client and your systems
to communicate securely without any special needs to tunnel through the firewall. You already have the
business logic in place to feed a stock quote given a stock symbol in HTML. Now you just need to format it
as XML. You are reusing expensive business logic. No need to spend months negotiating how the client
should communicate with your server. Web service standards are already in place. Using standard Web
services gives you and your clients an easy way to format the XML and describe what it takes to call the
“service.” In short, you won’t need to invent your own way to pass messages back and forth.
While Web services are typically sent through HTTP, the architecture makes no assumptions about the
channel. The XML data could be communicated via other protocols later. Web services could use other
Internet protocols like SMTP and FTP. Additionally, you can add other functionality like security in a
standard way.
Following standards you create a Web component that, when called, reads an XML message in what is called
SOAP format. The example XML SOAP message to invoke this service is below.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:getLastTradePrice xmlns:m="myURI">
<symbol>WFC</symbol>
</m:getLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
When this message is received the XML is parsed and the information on what is being called is found. The
service getLastTradePrice is being called and a symbol of WFC is being passed in.
After reading the SOAP message the existing business logic may be invoked to find the price for that symbol.
The response back to the user is also via SOAP so the price needs to be wrapped in some XML. Writing
XML documents can be done with any output stream. XML is really just characters. The creation of this
XML would not usually be done by hand, but let’s leave implementation for later. The response generated
would look something like the XML below.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:getLastTradePriceResponse xmlns:m="myURI">
<price>0.08</price>
</m:getLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
For a real world example of the same service, open a browser and go to the following URL (all on one line):
http://www.mindreef.net/tide/scopeit/start.do?referer=xmethods&url=
http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl
Enter a stock symbol (MMM or WFC) into the getSymbol text field. Hit the Send button.
The choice of using a Web service for this overly simple example provided three advantages. Because you are
defining only the messages being sent to and from the server, no particular language or platform is required for
either the client or the server implementations. Because you are using Web service standards like SOAP, the
creation of these XML processing components is simple. Most of the work is in creating the business logic.
Because you are using HTTP as a transport for the message, the client can access this information through the
Internet. And, they can do this without special tunneling through the firewall.
Other advantages also emerge when examining the protocols that are used for creating Web services. If you
provide WSDL to your clients, they are able to quickly and easily generate code to call this service. If you
register the service in UDDI it can be discovered by interested parties. If you need to secure the
communication you can use WS Security.
Web Services Standards
Web Services is widely accepted by large and small companies, but it is still a young technology. There are
few key standards producing organizations involved, and some standards are still being questioned and
challenged. Many companies (from tiny to gigantic) have made web service creation a standard for their
organization. This technology has tremendous momentum. You may occasionally encounter technology
forecasters that warn you away from Web Services due to an uncertainty. Remember this is a technology
with tremendous momentum and great support.
To understand some of the accepted emerging standards we will investigate a few of the key standards.
- XML
- SOAP
- WSDL
- XML Schema
- UDDI
As mentioned, XML is a fundamental technology in Web services. It is used for the content of messages (the
payload). It is also used for describing a service. When looking to add security or addressing you add new
XML tags to messages. When attempting to locate or publish service information you use XML to transfer
that information.
XML Schema is a language for describing the structure and constraining the contents of XML documents.
Schema defines the legal building blocks of an XML document.
- Defining the elements and attributes can appear in a document
- Defining the relationship, order and number of the various XML elements.
- Defining data types for elements and attributes.
In short, XML Schema defines the data that is in the XML messages.
SOAP is a standard that defines how to send messages using XML.
- Messages can be just informational messaging.
- Messages can also represent requests for some service.
- Messages can represent a direct method call with a required response.
WSDL (pronounced Wiz-dull) provides a template to define how your Web services communicate.
- WSDL provides a description of a Web service.
- WSDL provides the glue between two systems that wish to communicate by describing how to
create a client to a Web service.
- WSDL, like SOAP, is an XML based specification.
The registry and lookup of services is also standardized in Web services.
- UDDI (Universal Description Discovery and Integration) is a standard aimed at producing a way
to find Web services.
- UDDI uses (unsurprisingly) XML and SOAP to describe the services available.
- UDDI defines a registry service for publishing business entity information and the services they
offer.
What are web services? Why are they popular? Why do you care?
A web service is some kind of software product that receives messages and responds to those messages.
- The messages are typically sent through the web using HTTP.
- The messages are typically formatted as XML.
- The messages typically follow the SOAP standard.
- These messages can represent remote procedure calls (RPC), or one way (event based) messages.
(Both supported by SOAP).
- The messages can be processed synchronously or asynchronously.
- The messages are typically described using a WSDL (pronounced wiz-dull) document.
Web Service popularity is on the rise for many reasons, three appear below.
XML is agnostic. XML messages can be created and consumed by any language on any platform. This allows
a team to implement a web service, or web service client, using any comfortable platform (J2EE, .Net, Cobol).
SOAP and related specs are not-proprietary. SOAP and related specifications have created a non-proprietary
way to format XML messages. Standardization allows you to integrate to different platforms like J2EE, .Net
and Mainframe. Web Services become a standard approach to integration between existing systems.
Web Services can be more loosely coupled than traditional component based architectures. Creating a web
service instead of publishing a component allows you to more loosely couple disparate systems. The loose
coupling of systems results in a more flexible implementation. The implementation can change if the interface
remains the same. A client could change which service provider is being used.
When describing a web service it is typically better to bring in a simple example web service. An example, no
matter how simple, provides a concrete view of what a web service is and what it does. The example we will
investigate is a simple Stock Price Quote Service.
Web Service Learner Example
To better understand Web services and the technologies that make it up, it is typically better to bring in a
simple example Web service. An example, no matter how simple, provides a concrete view of what a Web
service is and what it does. In this example, you investigate a simple Stock Price Quote Service.
In this scenario you are a developer working for a company that provides stock quotes to customers. The
service has been available through a browser for a long time, but using a browser requires some human
interaction. Users of this system have been creating HTML scraping applications to read the same
information, but the system is unreliable.
<html>
...
<td>Price:</td><td>45.55</td>
...
They use Regular Expressions to find the correct HTML tags. However, Web sites and there HTML pages
are changing all the time.
For example, open a browser and enter the following URL:
http://finance.yahoo.com/q?s=WFC or
http://finance.yahoo.com/q?s=MMM
Examine the source code of the HTM page that is displayed. In the browser, click on the View menu and
select Source. Attempt to locate the stock price in the HTML page provided to you. It could be done, but
what would your code look like? What would happen if Yahoo changed their site?
The customers of this service would like a simpler, more machine-friendly, way to call for this information.
They would like it to be as easy as a method call, like that below.
double quote = StockQuoteService.getQuote(“WFC”);
To facilitate the request, you decide to pass more structured XML out of your Web server instead of HTML.
The Web server is already in place. The price producing application is already in place. All you need to do is
add the XML reading/producing functionality. The XML is much easier for a client’s machine to parse, so
they can use the information you feed out more easily.
Web services allow you to reuse your infrastructure and applications while facilitating standard machine-to-
machine communications. There is no need to set up special servers or other communications infrastructure.
You can just use the existing Web infrastructure. Using a Web service in this situation would be as easy as
adding some functionality to your existing Web server. Your service still allows the client and your systems
to communicate securely without any special needs to tunnel through the firewall. You already have the
business logic in place to feed a stock quote given a stock symbol in HTML. Now you just need to format it
as XML. You are reusing expensive business logic. No need to spend months negotiating how the client
should communicate with your server. Web service standards are already in place. Using standard Web
services gives you and your clients an easy way to format the XML and describe what it takes to call the
“service.” In short, you won’t need to invent your own way to pass messages back and forth.
While Web services are typically sent through HTTP, the architecture makes no assumptions about the
channel. The XML data could be communicated via other protocols later. Web services could use other
Internet protocols like SMTP and FTP. Additionally, you can add other functionality like security in a
standard way.
Following standards you create a Web component that, when called, reads an XML message in what is called
SOAP format. The example XML SOAP message to invoke this service is below.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:getLastTradePrice xmlns:m="myURI">
<symbol>WFC</symbol>
</m:getLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
When this message is received the XML is parsed and the information on what is being called is found. The
service getLastTradePrice is being called and a symbol of WFC is being passed in.
After reading the SOAP message the existing business logic may be invoked to find the price for that symbol.
The response back to the user is also via SOAP so the price needs to be wrapped in some XML. Writing
XML documents can be done with any output stream. XML is really just characters. The creation of this
XML would not usually be done by hand, but let’s leave implementation for later. The response generated
would look something like the XML below.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:getLastTradePriceResponse xmlns:m="myURI">
<price>0.08</price>
</m:getLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
For a real world example of the same service, open a browser and go to the following URL (all on one line):
http://www.mindreef.net/tide/scopeit/start.do?referer=xmethods&url=
http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl
Enter a stock symbol (MMM or WFC) into the getSymbol text field. Hit the Send button.
The choice of using a Web service for this overly simple example provided three advantages. Because you are
defining only the messages being sent to and from the server, no particular language or platform is required for
either the client or the server implementations. Because you are using Web service standards like SOAP, the
creation of these XML processing components is simple. Most of the work is in creating the business logic.
Because you are using HTTP as a transport for the message, the client can access this information through the
Internet. And, they can do this without special tunneling through the firewall.
Other advantages also emerge when examining the protocols that are used for creating Web services. If you
provide WSDL to your clients, they are able to quickly and easily generate code to call this service. If you
register the service in UDDI it can be discovered by interested parties. If you need to secure the
communication you can use WS Security.
Web Services Standards
Web Services is widely accepted by large and small companies, but it is still a young technology. There are
few key standards producing organizations involved, and some standards are still being questioned and
challenged. Many companies (from tiny to gigantic) have made web service creation a standard for their
organization. This technology has tremendous momentum. You may occasionally encounter technology
forecasters that warn you away from Web Services due to an uncertainty. Remember this is a technology
with tremendous momentum and great support.
To understand some of the accepted emerging standards we will investigate a few of the key standards.
- XML
- SOAP
- WSDL
- XML Schema
- UDDI
As mentioned, XML is a fundamental technology in Web services. It is used for the content of messages (the
payload). It is also used for describing a service. When looking to add security or addressing you add new
XML tags to messages. When attempting to locate or publish service information you use XML to transfer
that information.
XML Schema is a language for describing the structure and constraining the contents of XML documents.
Schema defines the legal building blocks of an XML document.
- Defining the elements and attributes can appear in a document
- Defining the relationship, order and number of the various XML elements.
- Defining data types for elements and attributes.
In short, XML Schema defines the data that is in the XML messages.
SOAP is a standard that defines how to send messages using XML.
- Messages can be just informational messaging.
- Messages can also represent requests for some service.
- Messages can represent a direct method call with a required response.
WSDL (pronounced Wiz-dull) provides a template to define how your Web services communicate.
- WSDL provides a description of a Web service.
- WSDL provides the glue between two systems that wish to communicate by describing how to
create a client to a Web service.
- WSDL, like SOAP, is an XML based specification.
The registry and lookup of services is also standardized in Web services.
- UDDI (Universal Description Discovery and Integration) is a standard aimed at producing a way
to find Web services.
- UDDI uses (unsurprisingly) XML and SOAP to describe the services available.
- UDDI defines a registry service for publishing business entity information and the services they
offer.
Web Services
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services
