Scribd
Upload
167 views20 pages

Web Services Notes

This document provides an overview of XML, URIs, URLs, URNs, and web services. It defines key terms like URI, URL, URN and explains the differences between them. URIs identify objects on the network, URLs specify locations, and URNs define names or identities. The document also summarizes the roles of XML, SOAP and WSDL in web services. XML is used to transport data, SOAP defines message formats and WSDL describes available web service operations.

Uploaded by

selcukcankurt
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
167 views20 pages

Web Services Notes

This document provides an overview of XML, URIs, URLs, URNs, and web services. It defines key terms like URI, URL, URN and explains the differences between them. URIs identify objects on the network, URLs specify locations, and URNs define names or identities. The document also summarizes the roles of XML, SOAP and WSDL in web services. XML is used to transport data, SOAP defines message formats and WSDL describes available web service operations.

Uploaded by

selcukcankurt
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 20

http://www.w3schools.com/default.

asp

URI, URL, URN

URI = Uniform Resource Identifier : Names and Addresses of Objects on the Network as used in
the World-Wide Web

URI is merely the possibly overlapping that are a URL or a URN.

There are two types of URIs: URLs and URNs

URL

URL = Uniform Resource Locator

<protocol>:// <host> [:<port>] [<path> [? <query>]]

URN

URN = Uniform Resource Name.


URNs define XML schemas.
urn:<namespace>:<string>

One can classify URIs as locators (URLs), or as names (URNs), or as both. A Uniform
Resource Name (URN) functions like a person's name, while a Uniform Resource Locator
(URL) resembles that person's street address. In other words: the URN defines an item's
identity, while the URL provides a method for finding it.

The ISBN system for uniquely identifying books provides a typical example of the use of
URNs. ISBN 0486275574 (urn:isbn:0-486-27557-4) cites unambiguously a specific edition of
Shakespeare's play Romeo and Juliet. To gain access to this object and read the book, one
needs its location: a URL address. A typical URL for this book on a Unix-like operating
system would be a file path such as file:///home/username/RomeoAndJuliet.pdf,
identifying the electronic book saved in a file on a local hard disk. So URNs and URLs have
complementary purposes.
Examples for web services
 A "Weather Web Service" is probably one of the most typical examples of a simple web
service.

WEB server & Web Services

 The terms Web service and web server should not be confused.
 Web service is an addition to the web servers.

XML
 External data representation and marshalling of messages exchanged between clients and
web services is done in XML.
 A web service is identified by a URI and can be accessed by clients using messages formatted
in XML.

XML was designed to transport and store data.

HTML was designed to display data.

What You Should Already Know

Before you continue you should have a basic understanding of the following:

 HTML
 JavaScript

If you want to study these subjects first, find the tutorials on our Home page.

What is XML?

 XML stands for EXtensible Markup Language


 XML is a markup language much like HTML
 XML was designed to carry data, not to display data
 XML tags are not predefined. You must define your own tags
 XML is designed to be self-descriptive
 XML is a W3C Recommendation
The Difference Between XML and HTML

XML is not a replacement for HTML.

XML and HTML were designed with different goals:

 XML was designed to transport and store data, with focus on what data is
 HTML was designed to display data, with focus on how data looks

HTML is about displaying information, while XML is about carrying information.

XML Does Not DO Anything

Maybe it is a little hard to understand, but XML does not DO anything. XML was created to
structure, store, and transport information.

The following example is a note to Tove, from Jani, stored as XML:

<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

The note above is quite self descriptive. It has sender and receiver information, it also has a
heading and a message body.

But still, this XML document does not DO anything. It is just information wrapped in tags.
Someone must write a piece of software to send, receive or display it.

With XML You Invent Your Own Tags

The tags in the example above (like <to> and <from>) are not defined in any XML standard.
These tags are "invented" by the author of the XML document.

That is because the XML language has no predefined tags.

The tags used in HTML are predefined. HTML documents can only use tags defined in the
HTML standard (like <p>, <h1>, etc.).

XML allows the author to define his/her own tags and his/her own document structure.
XML is Not a Replacement for HTML

XML is a complement to HTML.

It is important to understand that XML is not a replacement for HTML. In most web
applications, XML is used to transport data, while HTML is used to format and display the
data.

My best description of XML is this:

XML is a software- and hardware-independent tool for carrying information.

SOAP
SOAP is used to encapsulate messages and transmit them over HTTP or another protocol, for
example, TCP or SMTP.

In the middleware, a naming or a directory service allow clients to find out services.

SOAP is a simple XML-based protocol to let applications exchange information over HTTP.

Or more simply: SOAP is a protocol for accessing a Web Service.

What is SOAP?

 SOAP stands for Simple Object Access Protocol


 SOAP is a communication protocol
 SOAP is for communication between applications
 SOAP is a format for sending messages
 SOAP communicates via Internet
 SOAP is platform independent
 SOAP is language independent
 SOAP is based on XML
 SOAP is simple and extensible
 SOAP allows you to get around firewalls
 SOAP is a W3C recommendation

Why SOAP?

It is important for application development to allow Internet communication between


programs.

Today's applications communicate using Remote Procedure Calls (RPC) between objects like
DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility
and security problem; firewalls and proxy servers will normally block this kind of traffic.
A better way to communicate between applications is over HTTP, because HTTP is supported
by all Internet browsers and servers. SOAP was created to accomplish this.

SOAP provides a way to communicate between applications running on different operating


systems, with different technologies and programming languages.

SOAP
Envelope

Header

Body

http://www.tutorialspoint.com/soap/what_is_soap.htm

Web service: First and foremost, we have our Web service. As we have seen, this is basically a piece
of software that exposes a set of operations. For example, if we are implementing our Web service in
Java, our service will be a Java class (and the operations will be implemented as Java methods).
Obviously, we want a set of clients to be able to invoke those operations. However, our Web service
implementation knows nothing about how to interpret SOAP requests and how to create SOAP
responses.

WEB (HTTP) Server: This is more commonly called a 'Web server'. It is a piece of software that knows
how to handle HTTP messages. A good example is the Apache HTTP Server, one of the most popular
web servers in the Internet.
SOAP engine: This is a piece of software that knows how to handle SOAP requests and responses. In
practice, it is more common to use a generic SOAP engine than to actually generate server stubs for
each individual Web service (note, however, that we still need client stubs for the client). One good
example of a SOAP engine is Apache Axis (this is, in fact, the SOAP engine used by the Globus
Toolkit). However, the functionality of the SOAP engine is usually limited to manipulating SOAP.

Application server: This is a piece of software that provides a 'living space' for applications
that must be accessed by different clients. The SOAP engine runs as an application inside the
application server. A good example is the Jakarta Tomcat server, a Java Servlet and Java
ServerPages container that is frequently used with Apache Axis and the Globus Toolkit.

Many application servers already include some HTTP functionality, so we can have Web
services up and running by installing a SOAP engine and an application server. However,
when an application server lacks HTTP functionality, we also need a Web server.

Web Services Architecture

So, what exactly are SOAP and WSDL? They're essential parts of the Web Services
Architecture:

Figure 1.6. The Web Services architecture

 Service Processes: This part of the architecture generally involves more than one Web
service. For example, discovery belongs in this part of the architecture, since it allows
us to locate one particular service from among a collection of Web services.
 Service Description: One of the most interesting features of Web Services is that they
are self-describing. This means that, once you've located a Web Service, you can ask it
to 'describe itself' and tell you what operations it supports and how to invoke it. This is
handled by the Web Services Description Language (WSDL).
 Service Invocation: Invoking a Web Service (and, in general, any kind of distributed
service such as a CORBA object or an Enterprise Java Bean) involves passing
messages between the client and the server. SOAP (Simple Object Access Protocol)
specifies how we should format requests to the server, and how the server should
format its responses. In theory, we could use other service invocation languages (such
as XML-RPC, or even some ad hoc XML language). However, SOAP is by far the
most popular choice for Web Services.
 Transport: Finally, all these messages must be transmitted somehow between the
server and the client. The protocol of choice for this part of the architecture is HTTP
(HyperText Transfer Protocol), the same protocol used to access conventional web
pages on the Internet. Again, in theory we could be able to use other protocols, but
HTTP is currently the most used one.

How does this work in practice?

OK, now that you have an idea of what Web Services are, you are probably anxious to start
programming Web Services right away. Before you do that, you might want to know how
Web Services-based applications are structured. If you've ever used CORBA or RMI, this
structure will look pretty familiar.

First of all, you should know that despite having a lot of protocols and languages floating
around, Web Services programmers usually only have to concentrate on writing code in their
favorite programming language and, in some cases, in writing WSDL. SOAP code, on the
other hand, is always generated and interpreted automatically for us. Once we've reached a
point where our client application needs to invoke a Web Service, we delegate that task on a
piece of software called a stub. The good news is that there are plenty of tools available that
will generate stubs automatically for us, usually based on the WSDL description of the Web
Service.

Figure 1.7. Client and server stubs are generated from the WSDL file

Using stubs simplifies our applications considerably. We don't have to write a complex client
program that dynamically generates SOAP requests and interprets SOAP responses (and
similarly for the server side of our application). We can simply concentrate on writing the
client and/or server code, and leave all the dirty work to the stubs (which, again, we don't
even have to write ourselves... they can be generated automatically from the WSDL
description of a web service).

The stubs are generally generated only once. In other words, you shouldn't interpret the
"Typical Web Service Invocation" figure (above) as saying that we go through the discovery
process every single time we want to invoke a Web service, and generate the client stubs
every time we want to invoke the service. In general, we only go through the discovery step
once, then generate the stubs once (based on the WSDL of the service we've discovered) and
then reuse the stubs as many times as we want (unless the maintainers of the Web service
decide to change the service's interface and, thus, its WSDL description). Of course, there are
more complex invocation scenarios, but for now the one we've described is more than enough
to understand how Web services work.

A Typical Web Service Invocation (redux)

So, let's suppose that we've already located the Web Service we want to use (either because
we consulted a discovery service, or because the Web service URI was given to us), and
we've generated the client stubs from the WSDL description. What exactly happens when we
want to invoke a Web service operation from a program?

Figure 1.8. A typical Web Service invocation (more detailed)

1. Whenever the client application needs to invoke the Web Service, it will really call the
client stub. The client stub will turn this 'local invocation' into a proper SOAP request.
This is often called the marshaling or serializing process.

2. The SOAP request is sent over a network using the HTTP protocol. The server
receives the SOAP requests and hands it to the server stub. The server stub will
convert the SOAP request into something the service implementation can understand
(this is usually called unmarshaling or deserializing)

3. Once the SOAP request has been deserialized, the server stub invokes the service
implementation, which then carries out the work it has been asked to do.

4. The result of the requested operation is handed to the server stub, which will turn it
into a SOAP response.

5. The SOAP response is sent over a network using the HTTP protocol. The client stub
receives the SOAP response and turns it into something the client application can
understand.

6. Finally the application receives the result of the Web Service invocation and uses it.

There are different method for providing web services but the most common are

 SOAP,
 XML-RPC and

 REST .

Google is consistent in implementing their web services using SOAP, with the exception of Blogger,
which uses XML-RPC.

All of the major webservices on the Internet now use REST: Twitter, Yahoo’s web services use REST,
others include Flickr, del.icio.us, pubsub, bloglines, technorati, and several others. Both eBay and
Amazon have web services for both REST and SOAP.

What is web services?

In a typical web surfing scenario, a visitor visits a website and use the functionality provided
by that particular website.HTTP request is send to server from web browsers and server
responses are translated by browser to display the desired result of the visitor. But, this
scenario has been changed in the recent days. You don’t need to visit the particular website to
use their service and functionality if they are providing web services. Web services are set of
platform independent exposed APIs(functions) which can be used used from remote server
over the Internet. There are basically two parties involved in this, one which provides a set of
exposed APIs and the another one ,commonly know as web services consumers,is the party
which uses the functionality and services provided by web services providing party.

There are different method for providing web services but the most common are SOAP,
XML-RPC and REST .

SOAP

SOAP was the acronym of Simple Object Access Protocal but this acronym was dropped in
the version of 1.2 of SOAP. It is method for exchanging XML based message over the
Internet for providing and consuming web services. SOAP message are transferred forming
the SOAP-Envelope.You can view the typical SOAP Message articture from here. SOAP is
widely criticized for it’s design complexity.

In PHP 5, there is built-in extension for the providing and consuming web services. But, I
personally prefer Nusoap toolkit of PHP for providing and consuming web services using
SOAP in PHP.

XML-RPC

XML-RPC (remote procedure call) another way of providing and consuming web services. It
uses XML to encode and decode the remote procedure call along with it’s parameter.
Compared to the articture of SOAP, it has simpler architecture. You can even define data type
of parameters of procedure in XML-RPC. You can visit the official website www.xmlrpc.com
to know more about XML-RPC.

In PHP, there is extension which contain various functions for facilating XML-RPC request
and response. But the functions xmlrpc_encode_request() and xmlrpc_decode_request()
available in PHP is very useful for when it comes to encode and decode XML-RPC request
and response.

I’ve built  Nepali Currency Converter using XML-RPC web services provided by foxrate.org.

REST

Representational State Trasfer(REST) is comparatively simpler method for providing and


consuming web services. Nowadays, this method is becoming popular in the arena of web
services. Unlike above two method, it is not necessary to use XML as a data interchange
format in REST. REST architecture is basically focused on two things : Resources and
Interface.RESTful  is another term to define REST web services .

Resources are application’s state and functionality which is represented by a unique URL.
The resources share a uniform interface to transfer the state between the client and server.

For example the URL, http://example.com/product/11 can be a resource.Suppose, GET


method is used to retrieve product detail from that URL, POST method is used to modify the
production information and DELETE method can be used to delete the product from the same
URL. Here, the HTTP methods works as a interface to access the resources.

Talking about PHP, the format of information(representation) returned can be in XML, JSON
or even in HTML format. DOM functions, SimpleXML functions and JSON functions comes
handy when you are handling RESTful interfaces in PHP.
Travel Agent:
Consider people currently use their browsers to book flights, hotels and care hire with a selection of
different web sites. If each of these web sites were to provide a standard web service interface, then
Travel Agent Service could use their operations in order to provide a traveller with a combination of
these services.
WSDL
WSDL (Web Services Description Language) is an XML-based language for describing Web services
and how to access them.

What You Should Already Know

Before you continue you should have a basic understanding of the following:

 XML
 XML Namespaces
 XML Schema

If you want to study these subjects first, find the tutorials on our Home page.

What is WSDL?

 WSDL stands for Web Services Description Language


 WSDL is written in XML
 WSDL is an XML document
 WSDL is used to describe Web services
 WSDL is also used to locate Web services
 WSDL is a W3C recommendation

WSDL Describes Web Services

WSDL stands for Web Services Description Language.

WSDL is a document written in XML. The document describes a Web service. It specifies the
location of the service and the operations (or methods) the service exposes.

A WSDL document is just a simple XML document.

It contains set of definitions to describe a web service.

The WSDL Document Structure

A WSDL document describes a web service using these major elements:

Element Defines

<types> The data types used by the web service


<message> The messages used by the web service

<portType> The operations performed by the web service

<binding> The communication protocols used by the web service

The main structure of a WSDL document looks like this:

<definitions>

<types>
  definition of types........
</types>

<message>
  definition of a message....
</message>

<portType>
  definition of a port.......
</portType>

<binding>
  definition of a binding....
</binding>

</definitions>

A WSDL document can also contain other elements, like extension elements, and a service
element that makes it possible to group together the definitions of several web services in one
single WSDL document.

WSDL Ports

The <portType> element is the most important WSDL element.

It describes a web service, the operations that can be performed, and the messages that are
involved.

The <portType> element can be compared to a function library (or a module, or a class) in a
traditional programming language.
WSDL Messages

The <message> element defines the data elements of an operation.

Each message can consist of one or more parts. The parts can be compared to the parameters
of a function call in a traditional programming language.

WSDL Types

The <types> element defines the data types that are used by the web service.

For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.

WSDL Bindings

The <binding> element defines the message format and protocol details for each port.

WSDL Example

This is a simplified fraction of a WSDL document:

<message name="getTermRequest">
  <part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
  <part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
  <operation name="getTerm">
    <input message="getTermRequest"/>
    <output message="getTermResponse"/>
  </operation>
</portType>

In this example the <portType> element defines "glossaryTerms" as the name of a port, and
"getTerm" as the name of an operation.

The "getTerm" operation has an input message called "getTermRequest" and an output
message called "getTermResponse".
The <message> elements define the parts of each message and the associated data types.

Compared to traditional programming, glossaryTerms is a function library, "getTerm" is a


function with "getTermRequest" as the input parameter, and getTermResponse as the return
parameter.

A WSDL port describes the interfaces (legal operations) exposed by a web service.

WSDL Ports

The <portType> element is the most important WSDL element.

It defines a web service, the operations that can be performed, and the messages that are
involved.

The port defines the connection point to a web service. It can be compared to a function
library (or a module, or a class) in a traditional programming language. Each operation can be
compared to a function in a traditional programming language.

Operation Types

The request-response type is the most common operation type, but WSDL defines four types:

Type Definition

One-way The operation can receive a message but will not return a response

Request-response The operation can receive a request and will return a response

Solicit-response The operation can send a request and will wait for a response

Notification The operation can send a message but will not wait for a response

One-Way Operation

A one-way operation example:

<message name="newTermValues">
  <part name="term" type="xs:string"/>
  <part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
  <operation name="setTerm">
    <input name="newTerm" message="newTermValues"/>
  </operation>
</portType >

In the example above, the port "glossaryTerms" defines a one-way operation called
"setTerm".

The "setTerm" operation allows input of new glossary terms messages using a
"newTermValues" message with the input parameters "term" and "value". However, no output
is defined for the operation.

Request-Response Operation

A request-response operation example:

<message name="getTermRequest">
  <part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
  <part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
  <operation name="getTerm">
    <input message="getTermRequest"/>
    <output message="getTermResponse"/>
  </operation>
</portType>

In the example above, the port "glossaryTerms" defines a request-response operation called
"getTerm".

The "getTerm" operation requires an input message called "getTermRequest" with a


parameter called "term", and will return an output message called "getTermResponse" with a
parameter called "value".

WSDL bindings defines the message format and protocol details for a web service.
Binding to SOAP

A request-response operation example:

<message name="getTermRequest">
  <part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
  <part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
  <operation name="getTerm">
    <input message="getTermRequest"/>
    <output message="getTermResponse"/>
  </operation>
</portType>

<binding type="glossaryTerms" name="b1">


   <soap:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http" />
   <operation>
     <soap:operation soapAction="http://example.com/getTerm"/>
     <input><soap:body use="literal"/></input>
     <output><soap:body use="literal"/></output>
  </operation>
</binding>

The binding element has two attributes - name and type.

The name attribute (you can use any name you want) defines the name of the binding, and the
type attribute points to the port for the binding, in this case the "glossaryTerms" port.

The soap:binding element has two attributes - style and transport.

The style attribute can be "rpc" or "document". In this case we use document. The transport
attribute defines the SOAP protocol to use. In this case we use HTTP.

The operation element defines each operation that the port exposes.

For each operation the corresponding SOAP action has to be defined. You must also specify
how the input and output are encoded. In this case we use "literal".
WSDL and UDDI

Universal Description, Discovery and Integration (UDDI) is a directory service where


businesses can register and search for Web services.

What is UDDI

UDDI is a platform-independent framework for describing services, discovering businesses,


and integrating business services by using the Internet.

 UDDI stands for Universal Description, Discovery and Integration


 UDDI is a directory for storing information about web services
 UDDI is a directory of web service interfaces described by WSDL
 UDDI communicates via SOAP
 UDDI is built into the Microsoft .NET platform

What is UDDI Based On?

UDDI uses World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF)
Internet standards such as XML, HTTP, and DNS protocols.

UDDI uses WSDL to describe interfaces to web services

Additionally, cross platform programming features are addressed by adopting SOAP, known
as XML Protocol messaging specifications found at the W3C Web site.

UDDI Benefits

Any industry or businesses of all sizes can benefit from UDDI.

Before UDDI, there was no Internet standard for businesses to reach their customers and
partners with information about their products and services. Nor was there a method of how to
integrate into each other's systems and processes.

Problems the UDDI specification can help to solve:

 Making it possible to discover the right business from the millions currently online
 Defining how to enable commerce once the preferred business is discovered
 Reaching new customers and increasing access to current customers
 Expanding offerings and extending market reach
 Solving customer-driven need to remove barriers to allow for rapid participation in the global
Internet economy
 Describing services and business processes programmatically in a single, open, and secure
environment
How can UDDI be Used

If the industry published an UDDI standard for flight rate checking and reservation, airlines
could register their services into an UDDI directory. Travel agencies could then search the
UDDI directory to find the airline's reservation interface. When the interface is found, the
travel agency can communicate with the service immediately because it uses a well-defined
reservation interface.

Who is Supporting UDDI?

UDDI is a cross-industry effort driven by all major platform and software providers like Dell,
Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, and Sun, as well as a large
community of marketplace operators, and e-business leaders.

Over 220 companies are members of the UDDI community.


http://gdp.globus.org/gt4-tutorial/multiplehtml/ch01s02.html

You might also like