Presentation about Web services developed for my degree's web programming module. Includes TCP/IP, FTP and HTTP due to assignment requirements.

1. BSc(Hons) Computing & Internet
Technology
Web Development Research
NATHAN THOMAS
MARCH 2009

2. TCP &
The Transport
Layer
‘The transport layer has four main
functions:
1. It sets up and maintains a
session connection between
two devices
2. It can provide for the reliable
or unreliable delivery of data
across this connection
3. It can implement flow
control through ready/not
ready signals or windowing
to ensure one device doesn’t
overflow another device with
too much data on a
connection
4. It multiplexes connections,
allowing multiple
applications to
simultaneously send and
receive data. [Using Port
Numbers]’, (Meyers 2004).
TCP divides the data into segments, opens
a full-duplex connection using the network
layer, and passes the segments on to the
network layer.
It also ensures that all segments arrive at
the other end correctly.

3. 3 Way Handshake

4. Reliable and Unreliable Connections
 Transmission Control Protocol
Well Known/Reserved Port Numbers:
(TCP) and Sequenced Packet
Exchange (SPX) use the 3 way Application Port Number(s) Reliable/Unreliable
handshake, so are termed ‘reliable’ Connection
protocols at the transport layer. FTP 20 and 21 TCP Reliable
Connection
telnet 23 TCP Reliable
 Sometimes the full 3 way Connection
handshake is superfluous. SMTP (email) 25 TCP Reliable
Connection
 User Datagram Protocol (UDP) is
DNS 53 UDP Unreliable
Connection
an ‘unreliable’ protocol and can be Trivial FTP (FTP 69 UDP Unreliable
used in this case. without login) Connection
HTTP 80 TCP Reliable
Connection
 Segments sent using UDP have no POP mail 110
guarantee of reaching their
destination. UDP assumes this will SNMP 161 UDP Unreliable
be handled by the application. Connection
(Meyers 2004)

5. IP &
The Network
Layer
‘The network layer is responsible
for:
1. Defining logical
addresses used at the
network layer
2. Finding paths, based on
the network numbers of
logical addresses, to
reach destination
devices
3. Connecting different
media types together,
such as Ethernet, FDDI,
Serial and Token Ring’,
(Meyers 2004).
Network Layer Protocols:
Internet Protocol (IP)
•
Novell’s Internetwork Packet
•
Exchange (IPX)
AppleTalk.
•
TCP segment is encapsulated in an IP
packet. The source IP address and
destination IP address are defined in
this packet. The IP packet is passed to
the Data Link Layer.

6. HTTP, FTP and the Web
 File Transfer Protocol (FTP) existed when the web was first developed, but was
‘not optimal for the web, in that it was too slow and not sufficiently rich in
features’, (Berners-Lee 1996). So the Hyper-Text Transfer Protocol (HTTP)
was created.
 The Web is formed around three common standards: Hyper-Text Transfer
Protocol (HTTP), the Address Space (URLs) and Hyper-Text Mark-up
Language (HTML).
 In the same way that the TCP/IP model abstracts lower layers, the Web was
designed around the same principle. So, for instance, anybody designing
anything on top of HTTP did not have to know how HTTP worked.
‘A test of this ability was to replace [layers] with older specifications, and

demonstrate the ability to intermix those with the new. Thus, the old FTP
protocol could be intermixed with the new HTTP protocol in the address
space, and conventional text documents could be intermixed with the new
hypertext documents’, (Berners-Lee 1996).

7. How a Web Browser Works
 The browser determines the URL (by seeing what was selected).
 The browser asks DNS for the IP address of www.itu.org
 DNS replies with 156.106.192.32.
 The browser makes a TCP connection to port 80 on 156.106.192.32.
 It then sends over a request asking for file /home/index.html.
 The www.itu.org server sends the file /home/index.html.
 The TCP connection is released.
 The browser displays all the text in /home/index.html.
 The browser fetches and displays all images in this file.’
(Tanenbaum 2002)

8. Uniform Resource Locators (URLs)
 URLs can be broken into three parts: the protocol (or scheme), the
server location and the page location.
 Some common URLs:
Name Used For Example
http Hypertext (HTML) http://www.w3c.org/
ftp FTP ftp://ftp.cs.vu.nl/pub/minix/
README
file Local file file://c:/readme.txt
news Newsgroup news:comp.os.minix
gopher Gopher gopher://gopher.tc.umn.edu
/11/Libraries
mailto Sending Email mailto:user@domain.net
telnet Remote Login telnet://www.w3.org:80

9. HTTP Methods
Method Description
GET Request to read a Web page
HEAD Request to read a Web page’s header
PUT Request to store a Web page
POST Append to a named resource (e.g. a Web page)
DELETE Remove the Web page
TRACE Echo the incoming request
CONNECT Reserved for future use
OPTIONS Query certain options
(Tanenbaum 2002)

10. FTP Methods
Method Description
RETRIEVE (RETR) Causes the server to transfer a copy of the file, specified in the pathname,
to the server or user at the other end of the data connection.
STORE (STOR) Causes the server to accept the data transferred via the data connection
and to store the data as a file at the server site.
APPEND (with create) (APPE) Causes the server to accept the data transferred via the data connection
and to store the data in a file at the server site. If the file specified in the
pathname exists at the server site, then the data shall be appended to that
file; otherwise the file specified in the pathname shall be created at the
server site.
RESTART (REST) The argument field represents the server marker at which file transfer is
to be restarted. This command does not cause file transfer but skips over
the file to the specified data checkpoint.
RENAME FROM (RNFR)RENAME TO (RNTO) Renaming file
ABORT (ABOR) Aborts the previous command.
DELETE (DELE) Causes the file specified in the pathname to be deleted at the server site.

11. Status Responses
 Both HTTP and FTP will respond to requests with a status code. Some
example HTTP status responses are:
Code Meaning Examples
1xx Information 100 = server agrees to handle
client’s request
2xx Success 200 = request succeeded; 204 =
no content present
3xx Redirection 301 = page moved; 304 = cached
page still valid
4xx Client error 403 = forbidden page; 404 =
page not found
5xx Server error 500 = internal server error; 503 =
try again later

12. Web Services
 ‘Web services are server-side programs that listen for messages from
client applications and return specific information’, (Watson et al
2005).
 ‘Web services are meant to address the problems of connecting
disparate systems, creating single repositories, and working towards
the holy grail of programming – code reuse’, (Evjen et al 2007).
 Web service returns the information in XML format.
 XML can be used by any type of application, (Traditional or Web), on
any platform.
 Therefore Web services enable us to transfer data between disparate
systems.
 Enable us to maintain a central information store which is compatible
with all clients.

13. Before Web Services
Remote Procedure Call (RPC)

 Allows you to call (or ‘invoke’) a procedure (program method) at a remote location.
 Many different RPC protocols – mostly incompatible
 CORBA (Common Object Requesting Broker Architecture)
 Developed in 1991 by the Object Management Group, added object-orientation to RPC, (RPC
was procedural).
 ‘Because OMG didn’t define a reference implementation... the servers of these vendors
didn’t really interoperate... HP server needed an HP client... IBM server an IBM client, and
so on’, (Watson et al 2005).
 DCOM (Distributed Component Object Model)
 ‘In the past, it was possible to work with DCOM to port data from one point to another to
solve almost the same problem that Web services are now addressing. However, with
DCOM, requests and responses were required to ride on top of a proprietary communication
protocol’, (Evjen et al 2007).
 Distributed COM - Microsoft extended DCE-RPC protocol with object-oriented features.
 Not picked up by users of non-Microsoft platforms.
 RMI (Remote Method Invocation)
 Sun’s RMI added to CORBA and COM, but was aimed at Java platform and required a JVM.

14. Web Services Architecture:
UDDI – find a web service
Universal Description, Discovery and Integration (UDDI)
Web Services may be registered in a registration directory service, although not a requirement.
UDDI provides details about:
The owner

The Web service’s name and type

The Web service’s location

What the web service requires and what it returns (WSDL)

Primary UDDI sites are:
http://uddi.xml.org/

www.xmethods.net

These directories can be searched by the owner, type of web service, name etc.

There are sites that exist that focus on Web services with the same subject matter – these are

called Portals.

15. Web Services Architecture:
WSDL –what methods can be called?
Web Services Description Language (WDSL)

‘When you find a Web service that you want to include in your application, you must first figure

out how to supply the Web service with the parameters it needs in order for it to work. That
need also extends a bit further. Even if you know the parameters and types that are required for
instantiation, you also need to understand the types that are passed to your application in
return’, (Evjen et al 2007).
‘A WSDL document has the information about the methods a Web service supports and how

they can be called, parameter types passed to the service, and parameter types returned from
the service’, (Watson et al 2005).
WSDL enables client application to create a proxy for communicating with the web service,

using SOAP calls.

16. Web Services Architecture:
SOAP – calling a method
Simple Object Access Protocol (SOAP)

Maintained by W3C.

SOAP is just XML, works like XML and provides the same inter-operability as XML.

‘A SOAP message is the basic unit of communication between a client and a server’, (Watson et

al 2005).
‘The SOAP specification itself is made up of the following parts:

 A description of the SOAP envelope and how to package a SOAP message so that it can be
sent via a transmission protocol such as HTTP.
 The serialization rules for SOAP messages.
 A definition of the protocol binding between SOAP and HTTP.
 The capability to use SOAP for RPC-like binding’, (Evjen et al 2007).

17. Example SOAP Request
‘Hello World!’ string passed as argument to Web service method: ReverseString()

Before the start of the XML SOAP message, is the HTTP header, because the SOAP message is

sent with a HTTP POST request...
POST /WebServiceSample/Service1.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 508
SOAPAction: “http://www.wrox.com/webservices/ReverseString”
<?xml version=”1.0” encoding=”utf-8” ?>
<soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<ReverseString xmlns=”http://www.wrox.com/webservices”>
<message>Hello World!</message>
</ReverseString>
</soap:Body>
</soap:Envelope>
The server answers with a similar SOAP message with the ‘ReversStringResult’ attribute set to

‘!dlroW olleH’.

18. Alternative Protocols
‘XML-RPC, ebXML and REST can be used in a similar manner to SOAP. They all provide

structure to any remote-procedural call you need’, (Evjen et al 2007).
Alternatively, ‘just do a simple HTTP GET or HTTP POST request without the overhead of a

SOAP call:
HTTP POST request:

POST /WebServiceSample/Service1.asmx/ReverseString HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: length
message=string
THE HTTP GET request is even shorter. The disadvantage of the Get request is that the size of

the parameters sent is limited. If the size goes beyond 1K, you should consider using POST:
GET /WebServiceSample/Service1.asmx/ReverseString?message=string HTTP/1.1
Host: localhost
‘The disadvantage here is that there is no support from Web services on other platforms and no

support for sending anything other than simple data.’, (Watson et al 2005)

19. Representational State Transfer (REST)
‘In a pure REST system, resources are the entities exposed by the service: the products you sell, the customer

records you view, the pages you interact with. Each resource should have a unique URL that defines it, such as
http://www.mysystem.com/products/5323. Accessing that URL using an HTTP GET request should return a
representation of that resource, in this case a block of XML. In a pure REST system, GET requests cannot
change the resource. Changes are performed by other HTTP verbs:
GET

 Request for a resource. No change is made to the resource. Returns an XML representation of that
resource.
POST

 Creates a new resource. Returns an XML representation of that resource.
PUT

 Updates an existing resource. Returns an XML representation of that resource.
DELETE

 Deletes a resource from the system’, (Evjen et al 2007).
‘In a just-enough REST system, only GET and POST (or even just GET) URLs are used. In this model, all the

operations of the service can be accessed via a query string in the browser. Part of the rationale for this is that
many clients do not support the PUT and DELETE verbs, leaving GET and POST to perform multiple duties’,
(Evjen et al 2007).

20. Other Internet Architectures
 W3Cs Semantic Web Initiatives:
 Resource Description Framework (RDF)
 Web Ontology Language (OWL)
 SPARQL Queries
 HTML5/XHTML2/XForms

21. Service Oriented Architecture (SOA)
 SOA is about making the different layers of an information system
independent.
 The services provided at each layer are networked and can be combined in
any way desired to provide the required service to a user.
 For example, a web service could be used as a Data Access Layer for a
database.
 Web services, interacting with a variety of databases, can be mixed and
matched as required in a Business Logic Layer, which may do something
else. This Business Logic Layer should provide its own API, again perhaps
as a Web Service, that can then be used by any application.
 SOA is about the same old programming concepts of modularity,
abstraction and information-hiding.

22. References
Berners-Lee, T., 1996. The World Wide Web: Past, Present and Future. Available
1.
at: http://www.w3.org/People/Berners-Lee/1996/ppf.html [Accessed February
25, 2009].
Evjen, B., Sharkey, K., Thangarathinam, T., Kay, M., Vernet, A. & Ferguson, S.,
2.
2007. Professional XML. John Wiley & Sons.
Fielding, R., Irvine, U.C, Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P,
3.
Berners-Lee, T., Compaq, W3C, MIT, Xerox and Microsoft, 1999. RFC 2616 -
Hypertext Transfer Protocol -- HTTP/1.1. Internet Engineering Task Force
(IETF) Available from: http://www.ietf.org/rfc/rfc2616.txt [Accessed March 17,
2009].
Meyers, M., 2004. Network+ Certification All-in-One Exam Guide, Third Edition
4.
3rd ed., McGraw-Hill Osborne.
Postel, J., Reynolds, J. & ISI, 1985. RFC 959 - File Transfer Protocol. Internet
5.
Engineering Task Force (IETF). Available from: http://tools.ietf.org/html/rfc959
[Accessed March 17, 2009].
Tanenbaum, A.S., 2002. Computer Networks. 4th ed., Pearson Education.
6.
Watson, K. , Nagel, C., Hammer Pedersen, J., Reid, J.D., Skinner, M. And White,
7.
E., 2005. Beginning Visual C# 2005 2005th ed., John Wiley & Sons.