Remote Server Interaction

1
Remote Server Interaction

• 2533CIT - Week 12

Coridyn Fitzgerald-Hood
2
Remote Server Interaction

• Whats the deal?
• At the basic level we are looking at how we can
  send a message, and perhaps some data, to a
  server, have it perform some processing and
  return a response.
• In specific terms we are talking about using
  Flash to make Remote Procedure Calls to a PHP
  webserver via HTTP.

3
Client/Server Model

• The interaction model we are using through the
  AMFPHP and HTTP technologies is called the
  Client/Server Model.
• The client makes a request to a server for
  information and waits for a response from the
  server.
• The server receives a request, performs some
  processing and returns a response.

4
Client/Server Model

• The Client/Server Model is used extensively on
  the internet for transferring web-pages via HTTP.
• A request is made to a server located at a URL.

5
HTTP Scenario

• A typical HTTP transfer
• A client makes a request for a page.
• E.g. http//www.google.com.au
• The server receives the request for the page,
  reads the html page from disk and sends it to the
  client as a response.
• The client receives the web-page and renders it
  for the user.

6
HTTP Request

• Request for the website
• www.google.com.au

7
HTTP Response

• Response (body removed)

8
Web-Page

• Rendered response

9
Requests

• There are a number of possible requests that a
  client can make to a server.
• The valid requests are defined in the HTTP
  standard.
• We shall be focussing on two
• GET
• POST

10
Client Requests

• Despite the name, we are not limited to just
  receiving information when we perform an HTTP
  request.
• Both GET and POST support sending information
  from the client to the server.
• The name refers only to the client sending
  information and expecting a response.
• The form the response takes may depend on the
  information sent and the URI that was requested.

11
Requests HTTP GET

• The GET request is officially used to make a
  request for some resource.
• Extra information may be sent as an encoded URL.
• URL variables are listed after the question mark
  in a URL.
• Values are sent as key/value pairs delimited by
  the equals sign and ampersand.
• Special characters are encoded with the percent
  sign and a numeric identifier.

12
Requests - HTTP GET

• URL with GET variables

13
Requests HTTP GET

• GET is used for requests that do not make lasting
  changes to the server.
• Duplicate GET requests should receive the same
  response Idempotent.
• GET is not a good method for sending sensitive
  information.
• Visible and easily editable by the user
• E.g. www.site.com/page.html?adminfalse

14
Requests HTTP POST

• POST is often used for sending larger amounts of
  information than GET.
• The values are sent as key/value pairs in the
  request message body.
• The information is largely hidden from the user.
• But it is still quite easy to spoof information
  being sent to the server.
• Avoid putting sensitive information in either GET
  or POST requests (or any insecure communication
  channel) use HTTPS.

15
Requests HTTP POST

• POST requests are allowed to make changes to the
  server state.
• It is also possible to make idempotent requests
  to the server with the POST method.
• The HTTP standard also allows the action to a
  POST request to result in a resource that cannot
  be identified by a URI.
• This can be a major problem with websites that
  make extensive use of POST not possible to
  bookmark a particular state of the site.

16
Servers and Requests

• A server located at a particular URI and
  listening on a given port is responsible for
  handling requests to that server.
• This goes for almost any server, not just
  webservers.
• Web-servers listen on port 80 by default.
• The web-server is responsible for listening to
  requests made by a client, acting on the received
  information and formulating a response.

17
Servers and Requests

• The response sent to any given request depends on
  a number of factors
• Requested URI,
• Client information,
• State of the server,
• Services provided by the server.
• HTTP is a stateless protocol. This means that
  the state of a web-application or service must be
  managed by the web-developers. Databases are
  often used to manage this.

18
PHP and Requests

• PHP is a server-side scripting language.
• This is in contrast to Javascript and
  Actionscript which are both client-side
  technologies. JS and AS applications are executed
  on the client machine.
• PHP was originally written to perform simple
  processing on HTML pages.
• Simple find/replace for special tags, inserting
  information when pages were requested.

19
PHP and Requests

• PHP runs in a web-server environment.
• It is not the web-server itself.
• The web-server handles the low-level client
  requests for resources.
• When a PHP resource is requested the PHP
  libraries are loaded to process the file and
  generate the response to be sent back to the
  waiting client.

20
PHP and Requests

• When PHP processes a requested PHP resource it
  has access to the information sent to the
  web-server by the client.
• The response to the request depends on the
• Resource requested by the client,
• Information sent by the client, and
• The state of the server.

21
PHP Resource

• The requested PHP resource is the PHP file that
  corresponds to a web-servers URI.
• We create different PHP files to perform
  different tasks and to represent different pages
  on our website.
• The information sent by the client is very
  important in determining application behaviour.
• e.g. Passing correct data to a login page will
  perform a different action to passing incorrect
  data.

22
PHP Application State

• The state of the application also determines the
  result returned by a request to the PHP resource.
• Attempting to access a page that requires
  authentication will take you to a login page.
• Again, the state of the application must be
  managed by the web-developers.
• Login status is usually managed by a GUID stored
  in a cookie on the client machine.
• The client sends this value (and a username) in
  the request to the server the server compares
  this value against a session ID in a database.

23
Webservices
24
Webservices

• HTTP is not just limited to web-browsers and
  web-servers.
• Potentially any application can talk to any
  server over HTTP.
• As long as they both agree on what they are
  talking about.

25
Webservices

• A webservice is, quite literally, a service that
  can be accessed and invoked on a remote system
  (or host).
• A remote service is made up of a number of
  complimentary elements
• Service Interface,
• Runtime Environments,
• Client,
• Server.

26
Webservices

• Interface The interface is defined on both the
  client and the server to describe the information
  exchange between the two systems.
• Runtime Environment The runtime environment is
  the set of technologies used to process, send and
  receive information between the client and the
  server.
• It is possible (or indeed, highly likely) that
  the client and server are utilising different
  tools to implement this elment.

27
Webservices

• Client The entity that is making a request to
  the server.
• Server (or Service Provider) The entity that
  receives the clients request and performs some
  action.
• The interaction of these two entities is managed
  through the runtime environment and described by
  the service interface.

28
Webservice - Diagram
29
Remote-Procedure Calls
30
Remote Procedure Calls

• Remote Procedure Calls (RPC) are a special way of
  invoking a remote service.
• RPCs allow us to treat the remote calls as if
  they were a local function on a local object.
• Despite being located on a remote server.
• RPC frameworks abstract away the implementation
  and technology behind the service.

31
Client-Server Architecture

• The idea of the Client-Server architecture
  separates the users Client from the remote
  Server.
• This is often done to promote
• Maintainability separate the user interface
  from the remote implementation,
• Security avoid retaining sensitive data on the
  client,
• Performance Perform intensive or complex
  processing on a dedicated server,
• Functionality Provide services that are
  unavailable on the clients machine.
• However, none of these come free there are
  issues with them all.

32
Client-Server Architecture

• Maintainability
• The applications must be designed to work in a
  client-server relationship. It can be difficult
  to retroactively add remote capabilities.
• It can be difficult to debug and verify remote
  applications.
• Security
• Security must be considered when the application
  is being designed.
• Multiple aspects to security storage of data,
  access to remote interfaces, encryption of data,
  insecure server connections.

33
Client-Server Architecture

• Performance
• The server-side implementation should be
  appropriate for its task
• e.g. using an interpreted language for a
  processor-intensive application would probably be
  inappropriate.
• Latency should also be considered between the
  client and server how responsive does the
  application have to be?
• Functionality
• Our added functionality comes at the price of
  greater complexity and possibility of error.

34
Reasons for Remoting

• The major reasons for implementing remote
  services are Performance and Functionality.
• Either Flash is not fast enough to perform some
  task or, due to some limitation, it is unable to
  perform it at all.
• Example
• Accessing the local filesystem For security
  reasons Flash does not provide write access to
  the local file system.

35
Reasons for Remoting

• The idea behind remote services is to delegate
  some functionality to the remote server
• That is, it provides a service to your client.
• This allows us to implement functionality that
  would be otherwise impossible to provide in
  straight Flash/Actionscript.
• Examples
• Drawing program that lets the user download a
  JPEG or PNG of their drawing.
• Create a downloadable .swf of the users content.
• Access a database save/retrieve data.

36
AMFPHP
37
AMFPHP

• AMFPHP is an RPC framework for communicating
  between Flash and a PHP server.
• AMF is Adobe/Macromedias binary format for
  exchanging object representations between remote
  entities.

38
AMFPHP

• There are three important parts to remote
  services
• The Client.
• The Server.
• The Remote Interfaces.
• Our client will be our Flash movie.
• We will be using a PHP server.
• Our interfaces will be written in PHP and exposed
  through the AMFPHP Libraries.

39
AMFPHP Function Calls

• The remote nature of RPC calls presents a
  problem
• How do we know when we have received the result
  from the server?
• This is a classic software architecture problem.
  We have two well-explored solutions (amongst many
  others) available to us
• Block the calling thread until we have received
  the result.
• Create a new thread to process the remote call
  whilst we continue processing.

40
AMFPHP Function Calls

• You might have encountered the first solution
  when using the XML.load() function.
• Sometimes this causes the Flash player to pause
  for a short while until the file has been loaded.
• This isnt really acceptable to us we want to
  keep the Flash app responsive.
• Luckily, the second possible solution is handled
  for us when using AMFPHP and the remoting classes.

41
AMFPHP Function Calls

• This solution doesnt fix the problem entirely.
• The thread that invokes the remote call blocks
  execution until the response is received but
  our main application still doesnt know when the
  response has been received.
• The solution is a callback handler.
• A listener function given to the remote proxy
  object.
• This function will be called (and passed the
  result of the call) when the response is received
  from the server.

42
Half-Time Show

• http//www.xkcd.com/198/

43

• http//www.xkcd.com/327/

44
Installing AMFPHP
45
Server-Side Installation

• Install a HTTP server
• Apache Apache Software Foundation(current
  version 2.2.6) (http//httpd.apache.org/)
• IIS - Microsoft (http//www.microsoft.com/resource
  s/documentation/windows/xp/all/proddocs/en-us/iiii
  sin2.mspx?mfrtrue)
• Install PHP
• (www.php.net)
• I am currently using Version 5.2.0RC4-dev
• Ensure the version you download has support for
  the Apache 2.2.x HTTP server if required.

46
Installing AMFPHP

• Install AMFPHP
• (www.amfphp.org)
• http//www.amfphp.org/docs/installingamfphp.html
• Place AMFPHP files in appropriate HTTP folder.
• htdocs folder in a default apache installation.
• C\Inetpub\wwwroot in a default IIS web-site.
• Test installation.
• Navigate to the directoryhttp//localhost/amfphp
  /gateway.php

47
Client-Side Development

• AMFPHP Documentation on installing Macromedia
  Remoting Components
• http//www.amfphp.org/docs/installingremoting.html
  
• Install Macromedia Flash Remoting Components
• (http//www.adobe.com/products/flashremoting/downl
  oads/components/)

48
Using AMFPHP
49
AMFPHP

• We can use AMFPHP to define the services
  available to our Flash application.
• AMFPHP provides the framework that lets us
  communicate between the client and server.
• The actual remote services are written in PHP.
• Although we could then make calls from PHP to
  other server-side scripts or applications.

50
Creating a Service

• AMFPHP remote services are defined in a PHP
  class.
• The class must specify a methodTable array
  variable that specify which functions are
  available to be called from the Flash client.
• For security you can specify which functions may
  be accessed by the remote client.

51
HelloWorld.php

• Define a PHP class
• Very similar syntax to Actionscript.

52

• Define the constructor and our simple function

53

• Create our methodTable

54
Creating a Service

• Define our server-side function
• This describes our remote services to the AMFPHP
  framework.

55
Completed Remote Service
56
AMFPHP Client-Side Implementation
57
Client-Side Usage

• Import the Flash Remoting class definitions
• Define our class this is usually similar to the
  name we gave our remote PHP class

58

• Define our local variables and class constructor
• Initialise our NetDebugger and connect to the
  service

59

• Define the client-side call to the remote
  function
• say(msg) is the local function we will call to
  communicate with the server.
• The selected text is the name of the remote
  function we will be calling.
• The RelayResponder object will handle the event
  which is dispatched when the remote function
  returns a value.
• handleSay is the local function that will be
  called when the remote function has completed
  execution.
• handleRemotingError will be called if there was
  an error on the server-side.

60

• Create our handleSay function to handle the
  result from the server
• Create our function to manage errors that
  occurred on the server

61

• Finally, ensure you have included instances of
  the RemotingClasses and DebugRemotingClasses
  in your Flash .fla movie.
• These are accessible via the Windows Common
  Libraries Remoting menu.
• Drag an instance of each to the screen.

62
AMFPHP Example

• Test your application )
• See the files in the HelloWorld Service folder.

63
AMFPHP Coding Shortcuts

• The AMFPHP installation also includes a service
  browser that lets you view and test the
  server-side PHP classes.
• The service browser will also generate the PHP
  methodTable and basic client-side Actionscript
  code for you (saves a lot of typing).
• Browse to the browser directory of the AMFPHP
  installation
• On the Hobbit server the address is
  http//www.cit.gu.edu.au/s2102116/amfphp/browser/
  

64
AMFPHP Assignment Services
65

• The server-side code for the Assignment will be
  located at
• http//hobbit.cit.gu.edu.au/s2102116/public_html/a
  mfphp/services/pertservice/
• You can use the AMFPHP Service Browser to view
  the remotely accessible functions.

66
PHP Apache httpd.conf

• For PHP 5 do something like this
• LoadModule php5_module "c/php/php5apache2_2.dll"
• AddType application/x-httpd-php .php
• configure the path to php.ini
• PHPIniDir "C/php"