This is the html version of the file http://www.

sti-
innsbruck.at/fileadmin/documents/teaching_archive/ws0405/group4.ppt.
Google automatically generates html versions of documents as we crawl the
web.

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

o Scalability of component interaction
o Generality of interfaces
o Independent deployment of components
o Enforce Security
o Etc.

REST vs. Web Services

• Rest promotes and recommends generic operations on resources

o HTTP methods: PUT GET POST DELETE
o SQL: select create drop ect.
o Utilizes the caching mechanism
• WS does not promote generic operations
o First generation only utilizes HTTP POST
o Each service defines its own application specific operations
o Requires additional means of discrption,discovery mechanisms on
top of the web
o 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
o Nowadays such architectures are implemented by letting the
remote computer use a Web Browser as a client
o 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

o 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

o 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

o it assigns programs to URLs, so that when the URL is invoked, the
program is executed

o 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
 o 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?

o 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

 o 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

o Suns J2EE
o 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
o 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
o 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
o Session beans
o Entity beans
o 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
o 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
o Caching frequently needed objects
o Checking that an application is running and restarting
o 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
o implement mechanisms which make the transaction between
documents and arguments more efficient, flexible and manageable
o 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

o Web Browsers(most common types of clients)
o Applications
 Such as those encountered in conventional middleware
o Devices
 Such as mobile phones and PDAs
o E-mail programs
o Web service clients
Wide area integration

• A number of strategies
• 3 layers
o Client
o Middleware
o 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
o Acts as a barrier against unwanted network traffic
o Blocks many communication channels
o 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?

o 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

o 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.
o Provides standard templates for messages and for the contents of
the message

EDIFACT
 • A EDIFACT message typically contain the following fields
o Interchange Header
 Version of EDIFACT,IDs of sender end recipient,
passwords,date,time
o Message Header
 Type of message
o User Data segments
 payload
o Message Trailer
 Check message completeness
o 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