Web Technologies

Plattner Melanie
Leschinger Bernhard
What is this lecture about?

 Introduction to the basic Web technologies

that are used to implement the „Web“
portion of Web Services:
Some historical details
Core Web Technologies
Wide area integration
Tunneling, Firewalls, EDIFACT
Some historical details

 Start of standard groups

 TCP
• handles conversion between messages and streams packets
 IP
• handles addressing of packets across networks

 TCP/IP
• enables packets to be sent across multiple networks using multiple
standards

 Telnet
• One of the earliest standards for exchanging transmission, directly
connect accounts on different systems.
 SMTP
• specifies another way of direct connection
Some historical details
 MIME
• Extension to the SMTP Protocol which supports the
exchange of richer data files such as audio-, video-, and
images data.
 FTP
• (1973) supports file transfer between Internet sites
and allows a system to publish a set of files by hosting
an FTP sever
innovation  permits anonymous users to transfer files
 Archie
• Late 1980‘s distributed file system based on FTP
 Gopher
• First simple system, providing GUI
Core Web Technologies

 HTTP(HyperText Transfer Protocol)

 generic, stateless protocol
 governs the transfer of files across a network
 developed at CERN (Central European Research
Network), they also came up with the name WWW,
later W3C
 supports access to SMTP,FTP and other protocols
 was designed to support hypertext
Core Web Technologies
 Exchanged information, can be static or dynamic
 Every resource, accessible over the Web has a
URL(Uniform resource locator)
 HTTP mechanism is based on client/server model
typically using TCP/IP sockets
Core Web Technologies
 since Version 1.1 HTTP requires servers to support
persistent connections, to minimize overhead associated
with opening and closing connections.
 Typical methods on the server side are:
• OPTIONS
 send information about the communication options
• GET
 retrieve document or document produced by a program
• POST
 Append or attach information
• PUT
 Store information
• DELETE
 Delete the resource indicated in the request
Core Web Technologies
 Another limitation HTTP is stateless
• Does not provide storing of information between
requests
• No indication of any relationship between two different
requests
 cookies, small data structures that a web server
requests the HTTP client to store on the local machine,
are used to maintain state information
e.g. cookies store recently view items on a web shop
REST(Representational State Transfer)

 architectural style, defining the principles

of distributed network systems.
 is the underlying architectural model,
guiding the design and development of the
current and next generation web
architectures
REST

 Provides a set of architectural constraints,

that emphasizes
Scalability of component interaction
Generality of interfaces
Independent deployment of components
Enforce Security
Etc.
REST vs. Web Services
 Rest promotes and recommends generic
operations on resources
 HTTP methods: PUT GET POST DELETE
 SQL: select create drop ect.
 Utilizes the caching mechanism
 WS does not promote generic operations
 First generation only utilizes HTTP POST
 Each service defines its own application specific
operations
 Requires additional means of discrption,discovery
mechanisms on top of the web
 No caching capabilities
Rest Principles
 Web consists of addressable resources

 a user, utilizing an application selects a specific

address(URL)
a specific representation of that resource is returned over
the web
 places the client application into a specific state.
On accessing another URL, the client application gets
another representation of the resource and in turn,
transferring from the current to the new state.
Core Web Technologies

 HTML(HyperText Markup Language)

 Defines a standard set of special textual
indicators(markups) specifying how a Web pages
words and images should be displayed by the web
browser
Technologies for Supporting Remote
Clients
 Original intent of core Web Technologies
 enable linking and sharing documents
 It was quickly realized, that by wrapping local
information systems to expose their presentation
layer by using HTML documents, one could leverage
the core Web technologies to have clients that are
distributed across the internet.
B2C (Business to consumer)

 Conventional 3-tier architectures are

designed to operate within a single
company  data exchanges occur within
the safe boundaries of the company
 in principle there are no reasons why the system
could not be opened to other users if the need arises
• ATM(automatic teller machines are an excellent example
of the advantages if doing so
B2C
 ATM(automatic teller machines are an excellent
example of the advantages if doing so
• client/server system
• a PC with a network connection to the information
services of the bank
• gives customers easier access to their accounts without
the bank incurring
• a significant part of manual work disappears
• more efficient interactions with the customer
 great service, but there are limitations
B2C
• Limitations
 Customers must travel to the nearest ATM,
would not be necessary,
access to their bank accounts any time,
helps extend its functionality.

This architecture is called B2C, indicating that the

business allows consumers to access their
information services directly
Problem

 Users wanting to take advantage of this

opportunity would need to have
specialized clients for every company they
want to interact with
 Complexity would grow enormous ->
administration
Solution

 One of the biggest contributions of the

Web  providing a universal client for
such extensions
Nowadays such architectures are implemented
by letting the remote computer use a Web
Browser as a client
since Web Browsers are standard tools, no
application specific client has to be installed
Web Browsers

 One of the first problems  web Browsers

were originally intended only to display
static documents, returned by HTTP calls
 Difficult to build sophisticated application specific
clients for web browsers
Applets

 One answer to this problem  Applets

Java programs, can be embedded in an
HTML document
When the document is downloaded, the program
is executed by the JVM, presented in the
browser, turning the browser into a client by
sending the client code as an applet
• Limitations  download the code
• Advantage  complexity
CGI(Common Gateway Interface)

 Web servers must be able to server up

content from dynamic sources
How can a Web server respond to a request by
invoking an application that will automatically
generate a document to be returned
 One of the first approaches to solve this problem,
was CGI, a standard mechanism that enables HTTP
servers, to interface with external applications, which
can serve as „gateways“ to the local information
system
CGI
 How does CGI work
 it assigns programs to URLs, so that when the URL is
invoked, the program is executed

 CGI programs often serve as an interface between a

database and a Web server, allowing users to submit
complex queries over the DB through predefined URLs

 When the Web server receives request for the URL, it will run
a program, that will act as a client of the database and submit
the query  executing and packs the result into a HTML
document  returned to remote browser
Servlets

 Performance  CGI programs involve a

certain overhead
 Separate process for each instance  takes time,
requires a context switch in the operating system
 Multiple request results – multiple process
 To avoid this overhead, Jave servlets can
be used instead
 The idea is exactly the same as in CGI programs, but
the implementation differs.
Servlets

 How do they work?

Execution and result is the same, but servlets
are invoked directly by embedding servlet-
specific information within an HTTP request
 run as threads of the Java server process,
moreover they run as a part of the Web server
 eliminates overhead
Application Servers – short overview

 Equivalent to middleware platforms

Main difference  intercorporation of the Web
as a key access channel to the services
implemented using the middleware  several
important implications
 The presentation layer acquires a much more
relevant role
• Direct consequence of how HTTP and the Web work
Application servers – short overview
• Realized by merging the presentation layer related to the
Web with the application layer of the middleware
platform
Reason  to allow the efficient delivery of content trough
the Web as well as to simplify the management of Web
applications
J2EE

 There are two competing frameworks for

Web-based middleware
Suns J2EE
Microsoft's .NET
 very similar
J2EE

 A significant aspect of application servers

is the bundling of more and more
functionality within the middleware
platform
 Providing integrated support for many
different middleware abstractions
 Therefore blurring the borders between
application servers and other middleware
Application server - Application Layer

 At the application layer, application servers

conceptually resemble conventional
middleware, provided functionality similar
to CORBA, TP monitors and message
brokers
 Goal of application server vendors
providing a unique environment for hosting
all kinds of application logic, whether Web-
based or otherwise,
J2EE - EJB

 EJB (Enterprise JavaBeans) specification

is at the heart of J2EE  there the bulk of
the application logic resides
An EJB is a server-side component, that
delivers application-specific
funktionality(responding to a request for a
quote…)
J2EE - EJB
 The EJB specification defines 3 different types of
beans, based on how they interact with other
components and how they manage state and
persistence
 Session beans
 Entity beans
 Message-driven beans
J2EE –EJB container

 Provides the environment in which the

beans run  all interactions go through
the container
 Provides a number of services
Supports transactions  freeing a developer
from having to define transaction boundaries
and implement the related code
J2EE - JNDI

 Defines an interface for directory services,

without mandating any implementation
 Clients can bind to servers based on the
object name (EJB  binding to a server
involves binding to an object that provides
the interface for interacting with a server)
J2EE - JDBC

 is an API that enables developers to

access almost any tabular data source by
executing SQL commands from a java
program
 methods can be called from an EJB or
directly from a servlet
Application Server

 Offer services that simplify administration

and management of the application
Caching frequently needed objects
Checking that an application is running and
restarting
Object administration and security, defining
user has access to which application and
enforcing access restrictions
Application Server

 Cannot match the performance of TP

monitors but they try to make systems
easier to develop and easier to evolve.
Application Server - Presentation Layer

 the support for the presentation layer and for the

document as the basic unit of transfer is what
differentiates application servers from
conventional middleware
 Application servers
 implement mechanisms which make the transaction
between documents and arguments more efficient,
flexible and manageable
 provide a variety of presentation features to support the
delivery of dynamically generated, personalized content
to different types of clients
Application Server - Presentation Layer

 A modern application server supports the

following types of clients
Web Browsers(most common types of clients)
Applications
 Such as those encountered in conventional
middleware
Devices
 Such as mobile phones and PDAs
E-mail programs
Web service clients
Wide area integration
 A number of strategies
 3 layers
 Client
 Middleware
 Server(resource manager)

The available strategies are given

by all possible combinations of
these three layers
Wide area integration - strategies
 integrating systems at the client level
 at the middleware level
 by connecting clients directly to the remote
middleware platform,
 by connecting resource managers to the remote
middleware platform.

Which of these strategies is the most appropriate,

depends on a number of factors
Middleware Extensions
 The internet requires additional
middleware layers between clients and
servers or between servers.

 existing platforms were simply

extended to allow them to interact through
the internet, most middleware platforms
were designed to work on a single
LAN(Local area network)
B2B Business to Business
 The number of LANs started to grow
different branches of the same company
implemented their own middleware-based
systems
 the need for different middleware platforms to
communicate with each other, arose.

such interactions are called B2B

 fully automate the interactions
Firewalls and Tunneling

 Firewalls
Acts as a barrier against unwanted network
traffic
Blocks many communication channels
Can change the design space in two ways
 No direct communication between the system to be
integrated
 Parties outside the firewall are not trusted
Firewalls and Tunneling

 How to get through a firewall and why?

Tunneling
 Tricking the firewall into believing that traffic, which
otherwise should be blocked, is actually allowed
Protocols which would be blocked are hidden under
protocols that are accepted by the firewall
Why  not having a direct communication channel is
compounded by a necessary lack of trust on all traffic
generated outside the firewall
EDIFACT
 Another important challenge
 Identifying a common syntax and semantics for the data
exchanged between applications

In conventional middleware platforms, this problem is

hidden behind IDLs  fulfill two roles
 used to define interfaces
uses an intermediate data representation that
specifies how each data type used in IDL is
represented in a machine-independent manner
EDIFACT

 In message-based systems, format and

semantics of the messages or files
exchanged are typically determined by the
EDIFACT standard.
Provides standard templates for messages and
for the contents of the message
EDIFACT
 A EDIFACT message typically contain the
following fields
 Interchange Header
 Version of EDIFACT,IDs of sender end recipient,
passwords,date,time
 Message Header
 Type of message
 User Data segments
 payload
 Message Trailer
 Check message completeness
 Interchange Trailer
 Check interchange completeness
EDIFACT Pros & Cons
 + standard structure with 3 letter codes
 + universal standard defined by EDIFACT
 + parsers can be constructed easily

 - very complex standard, often unnecessarily

complicated
 - often only a fraction of the possible information
is used
 - hast to be standardized by EDIFACT before
use
 -requires adhoc development on the systems