ClientServer Architectures COMM1T Web Engineering Dr' Giles Oatley

1
Client/Server ArchitecturesCOMM1T Web
EngineeringDr. Giles Oatley
2
Client-Servers n-tier Systems History C/S and
Object Orientation Java RMI CORBA OLE/DCOM
3
Client-Servers
4
What is a Client/Server Architecture?

• Put simply client/server (C/S) involvesClients
  are system components that make requests on other
  system components to provide specific
  servicesServers are system components that
  provide specific services when requested to do so
  by other system components

5
Examples of Client/Server Architectures

• HTTP servers providing HTML web pages, Java
  applets, CGI scripts services etc. to web browser
  clients
• FTP servers providing data files to FTP clients
• Email servers providing email services to email
  clients
• Database servers providing SQL-based services to
  client applications

6
Local Machine verses Networked C/S

• All the previous examples had one aspect in
  common, they operate over a network of computers.
  
• It is also possible to introduce a C/S
  architecture into applications that run on local
  machines
• However, the potential of C/S is best realised
  over some form of computer network

7
n-tier Systems
8
1-tier System desktop PC and local database
DATASTORE
9
2-tier System Any number of machines (clients)
connecting to a central repository (server)
DATASTORE
Client System
Client System
10

• Two-tier describes the way application processing
  can be divided in a client/server application.
• A two-tier application ideally provides multiple
  workstations with a uniform presentation layer
  that communicates with a centralised data storage
  layer.
• The presentation layer is generally the client,
  and the data storage layer is the server.
• Most internet applications e-mail, telnet, ftp,
  gopher, and even the Web are simple two-tier
  applications.
• Without providing a lot of data interpretation or
  processing, these applications provide a simple
  interface to access information across the
  Internet.
• No problems because
• NO choices between different tasks
• NO redirecting of tasks to subordinate methods
• NO searches through distributed databases
• etc.

11
Displaying webpages Web browser on the client
side retrieves data stored at a Web server. The
display of static HTML pages requires very little
data manipulation, and thus there is very little
to fight over.
Form data
HTML documents
Web Browser
Web Server
12
Form data
HTML documents
Web Browser
Web Server
Form data validated, maybe rejected
Can maybe do this processing client-side
FAT CLIENT problem!!
13
Applet
Applet in direct communication with
database. Change our database slightly etc, will
require Complete of our application. Applet
Functionality tied directly into Business Logic.
14
Source code reuse .. And ACTUAL OBJECTS
REUSE.. SCENARIO if you are looking at building
a system for viewing bank accounts from the Web
and from an ATM machine, you really want the
users Web browser and the ATM machine to be
looking at the exact same data, especially if
they are looking at that data at the same
instant. Doing this with a two-tier system is
nearly impossible since each client ends up with
its own copy of the data. When one client
changes some data, other clients end up with old
data, resulting in a problem called dirty writes.
A dirty write is a situation in which someone
tries to modify data based on an old, out-of-date
copy of the database. If my spouse at an ATM
makes a withdrawal while I am paying bills at
home, I want to see that change happen. If we are
looking at copies of the original data, however,
I will end up paying a bill with money that my
spouse just withdrew! If a client, on the other
hand, is simply observing objects located in some
centralized location, it is always dealing with
the most recent information. When my spouse
withdraws that last 100, my Web browser is
immediately notified so that I do not act on
stale information. (Java makes things easier for
us by providing observer and observable classes).
15
if yes then two-tier

• Does your application use a single database?
• Is your database engine located on a single CPU?
• Is your database likely to stay approximately
  the same size over time?
• Is your user base likely to stay approximately
  the same size over time?
• Are your requirements fixed with little or no
  possibility of change?
• Do you expect minimal maintenance after you
  deliver the application?

else three-tier..
16
3-tier System Any number of machines (clients)
connecting to a central repository (server)
through an application server
DATASTORE
Client System
Application System
Client System
17

• A three-tier architecture adds to the two-tier
  model a new layer that isolates data processing
  in a central location and maximises object reuse.
  
• We should isolate our database connection so
  that our presentation does not care anything
  about the way we store our data
• Clients talk only to objects on the server
• Database connectivity becomes an issue hidden
  within each server object. The presentation layer
  stops caring about where the database is, as well
  as if we are using a database at all
• The client sees only middle-tier objects
• Middle-tier (application server) handles data
  processing issues out of place in either of the
  other tiers
• Populated by problem-specific objects commonly
  called business objects
• Banking application the business objects are
  things like accounts, customers, and transactions
  that exist independently of how a user might see
  them (by ATM or Web browser).
• (JDBC frees us from concerns related to
  portability among proprietary database APIs)

18
GUI learns everything about an account from an
account business object instead of from the
database. This object will have a data store
interface, for accessing the database.
GUI
DATASTORE
ACCOUNT BUSINESS OBJECT
Client System
Application System
19
Two-tier Client
DATA STORE
DataWindow
maps to
Three-tier Client
Business Object
observes
Object Observer
restores from
DATA STORE
20
observes
Observer
Observable
sends updates to
The observer relationship as implemented in the
Java API
21
Persistence Pattern I will survive.. Life
after death (well, after Ive logged off)..
22
History
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
C/S and Object Orientation
29
C/S and Object-Orientation

• The idea of client and server falls naturally
  into the Object-Oriented paradigm
• In O-O, objects interact through messages and we
  can regard the sender of the message as the
  client object, while the receiver of the message
  can be regarded as the server object
• In turn the server object could itself become the
  client of another object interaction and vice
  versa

30
An Example

• A Library object requires the details of a
  specific Book object held within a Stock object
  of available books.The Library object is acting
  as a client, requesting a service from the Stock
  object which is acting as a server to the
  Library. In turn, the Book object servers its
  details first to the Stock object (now acting as
  a client), with the Stock object returning the
  Book details to complete its server
  responsibilities.

31
Generic C/S Interaction

• Client Side Tasks1. Client contacts the
  server2. Client awaits a response from the
  server3. Client requests a service from the
  server4. Client awaits the results of this
  service from server5. Client disconnects from
  the server

• Server Side Tasks1. Server awaits a contact
  from a valid client2. On contact, the server
  connects to the client3. Server awaits request
  from connected client4. Server provides
  service5. Server disconnects from the client6.
  Back to task 1

32
Generic C/S Interaction

• Client contacts the server
• Need to uniquely address the server
• On a local machine you can use the namespace of
  the system (ie. an object reference)
• On a network there is a need for a uniform,
  consistent and understandable addressing. For
  example, Internet IP addresses and URLs,
  (www.cet.sund.ac.uk)

33
Generic C/S Interaction

• Client awaits a response from server,Client
  disconnects from the server
• Need a mechanism for providing a connection
  dialog (protocol) between client and server (eg.
  for handshaking)

34
Generic C/S Interaction

• Client requests a service from the server,Client
  awaits the results of this service from server
• Need a mechanism for transporting data across the
  connection
• If client and server are on a local machine this
  is relatively straightforward (via object
  reference)
• If the client and server are located on
  heterogeneous computer architectures there exists
  the potential for having to provide data
  translation mechanisms between these
  architectures. For example RMI or CORBA (see
  later)

35
Generic C/S Interaction

• Server awaits a contact from valid client
• Need a mechanism for both the client and the
  server to link with the underlying network. For
  example TCP/IP transport layer,
  connection-oriented verses connectionless links,
  sockets etc
• Need a mechanism to provide security against
  invalid clients

36
Generic C/S Interaction

• On contact, the server connects to the client,
  Server disconnects from the client, Server
  awaits request from connected client
• Server must operate with or at least understand
  the same dialog protocol as the client
• Server must understand the data sent from/to the
  client

37
Generic C/S Interaction

• Server provides service
• Single-tier C/S involves the server directly
  providing the requested service
• n-tier (multi-tier) C/S involves the server
  indirectly providing the requested service via
  interaction with further servers. For example,
  RMI and CORBA architectures (see later)
• n-tier C/S will involve a much increased degree
  of complexity within the interaction, but will
  typically enable a greatly increased level of
  service

38
Generic C/S Interaction

• Back to Task 1
• Once the service is completed, the server returns
  to awaiting a contact from another client
• However this one-to-one approach is very
  inefficient and negates a major advantage of the
  C/S architecture, that of one server, multiple
  clients

39
One Server, One Client

• Obviously, if a server could only service a
  single client at anyone time then we negate the
  benefit of allowing multiple clients to request
  services from the same server
• To overcome this we allow a single server to
  provide services to multiple clients at the same
  time

40
One Server, Multiple Clients

• One server continually awaits contacts from
  multiple clients.
• As a server accepts a client connection, it
  spawns an object to deal with the service
  requested by the client and returns to awaiting
  contact immediately
• The spawned object then deals directly with the
  client involved, hence we see a delegation from
  the original server to the spawned object
• This we can refer to as a multi-threaded server
  as each service request is effected by using a
  separate thread

41
Fat and Thin C/S Models

• A fat server, thin client model has the majority
  of the application data processing occurring at
  the server-side of the link (eg. when using CGI
  server scripts)
• A fat client, thin server model has the majority
  of the application data processing occurring at
  the client-side of the link(eg. when running Java
  applets on the local machine)
• Which is better depends upon specific
  circumstances, however, if you overload the
  server then the level of client servicing can be
  reduced. Typically, it is sensible to only
  perform on the server the minimum of necessary
  work and expect the client to allow for this

42
Java
43
Java JDBC Java Database Connectivity RMI
Remote Method Invocation Servlets, Sockets CORBA
44
Java and Client/Server

• Java provides an extensive set of objects to deal
  with client/server approaches to application
  operation
• These reside in the packagesjava.net. (for
  basic network support)java.rmi. (for RMI
  support)java.servlet. (for producing
  extensible servers)org.omg.CORBA. (for
  providing CORBA support)org.omg.CosNaming. (for
  providing an IDL naming service)java.io. (for
  providing stream support for C/S sockets)

45
Java C/S Mechanism

• Java implements C/S using the TCP/IP protocol
  more commonly referred to as the Internet
  protocol (it is more complicated than this but a
  full treatment of Internet protocols are beyond
  the scope of our module)
• To achieve network connections between clients
  and servers, Java uses the concept of a Socket (a
  software device for encapsulating the intricacies
  of the underlying TCP/IP network protocol)

46
Java C/S Mechanism

• Through TCP/IP, Java can locate server and client
  objects across the network using IP addresses
  and/or URLs(Please refer to the Java
  documentation for a description of the
  java.net.InetAddress and java.net.URL classes)
• Sockets are a connection-oriented approach to
  linking servers and clients (you may wish to
  consult the Java documentation to look at the
  alternative to this, connectionless linking)

47
Sockets

• A Socket is a high level abstraction of the
  connection mechanism utilised by TCP/IP (which is
  quite complicated)
• Any host that is involved in the TCP/IP network
  must provide a number of socket ports (identified
  by a unique number in the range 0 - 65534).
  Sockets we create are then bound to one of these
  port numbers
• Other hosts can then connect to a specific hosts
  bound sockets using this unique port number.
  Typically, the port numbers 1 - 1023 are reserved
  for common services, eg. port 21 for FTP
  services, 80 for HTTP services etc
• The full URL for a socket port can be constructed
  using the form ltinternet addressport numbergt,
  eg. The FTP service on the Universitys ISIS
  server is at URL isis.sund.ac.uk21

48
Local Machine TCP/IP Addressing

• The local machine is typically set to be
  addressed using the name localhost. This is
  typically bound to the IP address 127.0.0.1
• This will work on any machine that has been set
  up for a loopback network (ie. not a real network
  but a way of faking such)
• If the idea of the localhost is not operating on
  the local machine, you must use the individual
  machine names allocated for each workstation when
  addressing (For instance, in the cell you are
  using for tutorials, the name can be found on the
  desk edge underneath each monitor)
• localhost should work on the SCET Sun and NT
  network and should also work on your home Windows
  95/98 set-ups (unless you use a network, then you
  will again need the name of your workstation). If
  in doubt, first try localhost and/or IP address
  127.0.0.1

49
Creating a Java Server

• Java.net contains a class ServerSocket that
  handles requests from clients to connect upon a
  TCP/IP port number supplied as a parameter to
  the constructor of the ServerSocket
• Calling the ServerSocket.accept( ) method results
  in the run state of the thread within which this
  method is called to suspend until a valid client
  attempts to connect

50
Creating a Java Server

• Once a valid client contacts the ServerSocket,
  the ServerSocket.accept( ) method returns with a
  reference to a java.net.Socket class
• This Socket object can then provide both a
  java.io.InputStream object (by calling
  Socket.getInputStream( ) ) and a
  java.io.OutputStream object (by calling
  Socket.getOutputStream( ) ). These stream objects
  can then be used to pass data directly between
  the client and the server (as per any normal
  stream operation in Java)
• Once you have finished with a connection between
  the client and the server you must call the
  close( ) method for any streams you have been
  using and the close( ) method of the Socket
  object. When the ServerSocket is no longer
  needed, you must also call its close( ). Failing
  to do any of this could result in you using up
  valuable system resources unnecessarily.

51
Creating a Java Server

• For example, a code snippet may includeimport
  java.net. // Java network packageimport
  java.io. // Java I/O packageServerSocket
  theSS // Server socket objectSocket aSocket //
  Socket objectInputStream anIStream // Input
  stream (ie. to read data from client)OutputStream
  anOStream // Output stream (ie. to send data to
  client)// Continued on next slide

52
Creating a Java Server

• while(!completed) try theSSocket new
  ServerScoket(3790) // Bind to port number
  3790 aSocket theSSocket.accept( ) // Wait for
  client, ie. keep listening anIStream
  aSocket.getInputStream( ) anOStream
  aSocket.getOutputStream( ) // Do stuff with the
  streams to service the client anIStream.close(
  ) anOStream.close( ) aSocket.close( ) // All
  finished catch(IOException ioe) // thrown
  by ServerSocket.accept( ) // ... thrown by
  getInput/OuputStream( ) // thrown by close( )
  methods
• // Server completed
• try theSSocket.close( )
• catch(IOException ioe) // thrown by
  ServerSocket.close( )

53
Creating a Java Client

• Using a Socket object, the client can request a
  connection to the server provided as a parameter
  to the constructor of this Socket
  object Socket(ltInternet addressgt, ltport
  numbergt)(Note, the Socket constructor throws an
  IOException which must be caught)For example,
  to connect to a server running on ISIS and bound
  to the port number 3790aSocket new
  Socket(InetAddress.getByName(isis.sund.ac.uk),
  3790)
• The creation of the new Socket object assumes
  that there is a valid server listening at the
  provided URL and port number. If not, then an
  IOException is thrown

54
Creating a Java Client

• Once a connection has been established using the
  newly created Socket object, the client can use
  the getInput/OutputStream( ) method to provide
  streams over which communication can occur
• Again, ensure you close down any streams and
  sockets used when the client no longer needs to
  communicate with the server

55
Multi-Threaded Server

• To effect a multi-threaded server, you should
  fork a new thread upon which a new Socket object
  created from ServerSocket.accept( ) will operate.
  A good approach is to provide an additional
  object that wraps the Socket object and can run
  on a separate thread from the ServerSocket
• Typically this is not an issue at the client-side
  of the link as a client only requests one service
  (but it could be possible to have a
  multi-threaded client as well)

56
Further Resources for Java C/S

• Refer to the relevant sections of the Java
  Tutorial for more examples of developing C/S Java
  systems
• Refer to the relevant Java API documents that
  cover the packages involved in C/S (see previous
  slide)
• A very good text on the subject of Java network
  programming isJava Network Programming,
  Elliotte Rusty Harold, OReilly, 1997

57
Remote Method Invocation
58
What is Remote Method Invocation?

• In simple terms, Remote Method Invocation (RMI)
  allows a local object to directly call the
  methods of an remote object located on a remote
  host as if that remote object existed in the
  namespace of the local object
• This is typically achieved by contacting the
  remote object through some form of computer
  network architecture (eg. over the Internet using
  TCP/IP)

59
RMI Schematic
Remote Services
Network
Local Object
Remote Object
Local object calls remote methods
Exposed Methods - public void m1( ) - public
int m2( ) etc.
Local object calls remote methods
Local Object
RMI mechanism
An n-tier architecture
60
RMI is an n-tier C/S Architecture

• Since there is now no direct client to server
  interaction, we are now considering an n-tier
  architecture (multi-tier architecture)
• This will increase the underlying complexity of
  the architecture, but will help to alleviate some
  of the possible disadvantages of the single-tier
  architecture (for example, an n-tier approach can
  help to hide implementation issues of services
  provided by a server such as database access)

61
RMI Mechanism
A layered approach
Remote Object
Client
Stub
Skeleton
Object Reference
Registry
Network
62
Remote Object Stub

• A stub represents a proxy for the remote object
  on the client machine
• Each stub provides the interface description for
  methods made visible to the RMI mechanism by the
  remote object
• Therefore a stub can be seen as a blueprint for
  visible sections of the remote object

63
Remote Object Skeleton

• A skeleton represents the remote object blueprint
  that resides on the remote host
• It provides the direct mechanism for accepting
  client requests, forwarding them to the actual
  remote object and sending any results back to the
  client
• Both the skeleton and the stub must be loaded
  dynamically at run-time

64
Stub and Skeleton Creation

• Typically, an RMI mechanism will provide a tool
  for creating stubs and skeletons automatically
  from a description of the remote object
• In Java this tool is called rmic and is
  distributed as part of the Java API (found inside
  the ../jdk/bin directory)
• The rmic tool is run using the Java class file of
  the remote object as a parameter, and produces
  two further class filesltremote_objectgt_stub.cla
  ssltremote_objectgt_skel.class

65
RMI Registry

• The RMI mechanism requires the inclusion of a
  registry that will hold a mapping from the remote
  object reference on the remote machine and a
  unique name that clients can use when connecting
  across the network
• In Java, this registry is created by a tool
  called rmiregistry. The tool is run as a
  background process and waits for remote objects
  to bind with it so they can be made available to
  clients
• The rmiregistry tool is part of the Java API and
  ca n be found in the ../jdk/bin directory

66
Object Reference on Client Machine

• The result of a connection between the client and
  remote object when using the RMI mechanism is a
  local reference to an object within the namespace
  of the connecting client that effectively proxies
  the remote object
• This proxy reference allows direct access to the
  methods made visible by the remote object
• Any call to these methods by the client will
  result in an indirect call to the equivalent
  method held in the actual remote object, hence a
  remote method invocation

67
Data Transfer within RMI Mechanism

• As a consequence of the RMI mechanism, data can
  be passed between the client and the remote
  object as simple method parameter passing and any
  method data return statements
• Hence, with RMI we can overcome the difficulties
  shown by single-tier C/S with respects to data
  transfer between client and server
• In Java, this mechanism is achieved by
  serialising objects passed as parameters to and
  data returned from methods (thus objects involved
  in this form of transfer require implementation
  of the serializable interface)

68
Java RMI Remote Objects

• Require an interface that provides each of the
  methods the remote object will make
  visibleeg.import java.rmi. // To use the
  Java RMI packagepublic interface LibraryRO
  extends Remote public int addUser(int id,
  Member aMember) throws RemoteException // All
  remote methods must throw a RemoteException//T
  his remote interface will allow a remote object
  to provide visibility to an addUser( ) //method

69
Java RMI Remote Objects

• Each remote object must implement its visible
  interface and extend the UnicastRemoteObject
  class from the java.rmi packageeg.import
  java.rmi.import java.rmi.server.UnicastRemoteOb
  ject // Needed by RMI remote objectspublic
  class LibraryROImpl extends UnicastRemoteObject
  implements LibraryRO public LibraryROImpl
  throws RemoteException super( ) // MUST
  provide at least a default constructor for RMI to
  work // Implement the addUser( )
  method // Install an appropriate security
  manager for the running VM // Bind with the
  RMI registry

70
Java RMI Remote Objects

• At some stage prior to binding the remote object
  to the RMI registry, an appropriate security
  manager must be installed for the VM within which
  the remote object is running. This is usually
  created from the class RMISecurityManager
  usingSystem.setSecurityManager(new
  RMISecurityManager( ))

71
Java RMI Remote Objects

• Binding the remote object to the RMI registry
  involves the Java Naming classNaming.rebind(ltna
  me associated with remote objectgt, ltremote object
  referencegt)This will throw an Exception
  exception which must be caughteg. within the
  LibraryROImpl class example we usetry
  Naming.rebind(LibraryRO, this)catch(Except
  ion e)

72
Java RMI Clients

• The RMI client needs a reference to the proxy for
  the remote object, and must install an
  appropriate security manager into its VM as per
  the remote object VM (see earlier)
• This is achieved using the Java Naming class
  method lookup( ) which takes as a parameter that
  provides the location and name of the remote
  objects RMI registry using the URL form (as a
  string or a URL object)rmi//lthost
  addressgtltportgt/ltremote object namegt

73
Java RMI Clients

• The Naming.lookup( ) method returns an object
  reference of class java.lang.Object, thus to use
  the reference it must be cast to the class of the
  remote object interfaceeg.aLibraryRO
  (LibraryRO)Naming.lookup(rmi//localhost1099/Lib
  raryRO)// Remember, LibraryRO was the name
  given to our remote objects interfaceThis
  lookup( ) method also throws an Exception
  exception which must be caught

74
Java RMI Clients

• From the point that the reference to the remote
  object proxy is acquired, the client can simply
  access the visible methods of the proxy as per
  any normal Java objecteg.int addUserResult
  aLibraryRO.addUser( )

75
Additional Java RMI Tools

• After writing your remote objects and the clients
  that will use these objects you must provide the
  stubs and skeletons associated with the remote
  objects
• Java provides the tool rmic which produces
  these for you from the remote object classes
• Also, the rmiregistry tool must be run as a
  background process on the server to provide the
  remote object name mapping to remote object
  references. This tool must be run before creating
  the remote objects and before trying to connect
  clients

76
Java RMI Advantages

• Hides the complexity of the underlying TCP/IP
  network and its associated data transfer from the
  interacting objects as simple Java parameter
  passing and data return statements
• Provides direct security management as per the
  Java security model
• Allows the application of distributed computing
  within the scope of the Java language

77
Java RMI Disadvantages

• Requires the management of the various stubs and
  skeletons within the distributed application
  environment
• Only provides inter-operation between objects
  running within Java VMs and is therefore only
  appropriate for homogeneous distributed computing
  

78
Heterogeneous Distributed Computing

• In contrast to homogeneous distributed computing,
  an heterogeneous approach to distributed
  computing system involves components that are
  produced using dissimilar programming languages
  and dissimilar operating environments.
• Thus heterogeneous systems will pose particular
  difficulties during inter-operation of computer
  components (such as data transfer, component
  synchronisation etc.)

79
Heterogeneous Distributed Computing

• There are a number of well developed approaches
  to solving the problems of heterogeneous
  systemsSockets (As we have already seen)CGI
  Scripts (server-side scripting approaches)Connect
  ivity Drivers (eg. ODBC, JDBC)IDL (Interface
  definition langauges)ORBs and CORBA (Object
  Request Brokers and Common Object Request Broker
  Architectures)

80
JDBC drivers Type 1 These drivers use a
bridging technology to access a database. The
JDBC-ODBC bridge that comes with the JDK 1.1 is a
good example of this kind of driver. It provides
a gateway to the ODBC API. Implementations of
that API in turn do the actual database access.
Bridge solutions generally require software to be
installed on client systems, meaning that they
are not good solutions that do not allow you to
install software on the client. Type 2 These
drivers are native API drivers. This means that
the driver contains Java code that calls native C
or C methods provided by the individual
database vendors that perform the database
access. Again, this solution requires software on
the client system.   Type 3 These drivers provide
a client with a generic network API that is then
translated into database specific access at the
server level. In other words, the JDBC driver on
the client uses sockets to call a middleware
application on the server that translates the
client requests into an API specific to the
desired driver. As it turns out, this kind of
driver is extremely flexible since it requires no
code installed on the client and a single driver
can actually provide access to multiple
databases.   Type 4 Using network protocols built
into the database engine, type 4 drivers talk
directly to the database using Java sockets. This
is the most direct pure Java solution. In nearly
every case, this type of driver will only come
from the database vendor.
81
CORBA
82
CORBA

• While it is beyond the scope of this module to
  investigate and apply the actual intricacies of
  CORBA systems, it is important that you gain an
  understanding of the operation of distributed
  systems implemented using CORBA
• Please refer to the OMG (Object Management Group,
  a group of companies which has become the major
  contributor to the CORBA standard) web-site for
  an introduction to the ideas relating to CORBA at
  www.omg.com
• In particular you are required to use this
  resource for appreciating CORBA at the
  introductory level, understand the reasons for
  wishing to adopt CORBA within heterogeneous
  distributed computing systems and gain an
  appreciation of the advantages and disadvantages
  of adopting CORBA.

83
DCOM
84
OLE Object Linking and Embedding
85
(No Transcript)
86
(No Transcript)
87
(No Transcript)
88
(No Transcript)
89
Acknowledgements All nice pictures from
Byte.com Code from Chris Knowles
(http//osiris.sunderland.ac.uk/cs0ckn) Nice
book Database Programming with JDBC and
Java George Reese, OReilly
90
TUTORIAL

• (v. briefly) find information about
• C/S, CORBA, OLE, ACTIVEX, RMI..
• Investigate
• ASP see presentation
• CGI www.cgi101.com
• PHP all over the web..
• Try Java code in JBuilder
• Continue with Javascript
• www.webmonkey.com
• More tutorial questions..

91

• CGI
• /home/webeng/public_html/scripts
• Full permissions on files in that  directory (ie
  create,delete copy, list) but not on the
  directory itself.To copy a script into that
  directory, for examplecp blah.sh
  /home/webeng/public_html/scriptsTo make
  avaiable ovr the webchmod 755
  /home/webeng/public_html/scripts/blah.sh

92

• ASP
• www.webmonkey.com
• More tutorial questions..
• Name your database webeng.mdb

93

• Interesting article
• Shows some issues of FAT/THIN CLIENTS
• Programming issues (JavaScript-PHP)
• http//www.phpbuilder.com/columns/luis20000724.php
  3
• PHP JavaScript World Domination Series Storing
  data in the client.
• One of the things that all programmers love is to
  write a program which writes another program. On
  the web we have two different programming
  environments the client (browser) and the
  server. Due to the HTTP protocol definition we
  can write a program on the server which writes
  another program to be executed on the client.
  Let's pick PHP (of course) for the server and
  JavaScript for the client. We'll show you in this
  article how you can use this scheme to store data
  in the client and then minimize the data
  transfered between the server and the browser for
  interactive applications like a chat room, a news
  system or whatever you want.
• We have been trying to develop an HTTP chat room
  in PHP for a while. HTTP is not a good protocol
  for chatting but it is firewall/proxy immune, can
  use the potential of PHP and there's no need for
  Java Applets. We have had two main problems with
  the chat room first since IE doesn't support the
  PUSH method, we needed to make it a "pull"
  application, (the client refreshes itself) which
  is unnatural for a chat application. We decided
  to make the client refresh time variable, the
  server will generate the refresh time as a
  function of the number of messages received in
  the server in the last x minutes. The second
  problem was deeper since the idea is to refresh
  the client we would need the server to send all
  the messages each time, we observed that this
  implied heavy transfers and our benchmarks in a
  simulated simplified chat room model showed that
  this was the main cause of delays in the chat.
  This article deals with that second and deeper
  problem.