Most developers can understand the nature of an Internet page address such as example dot com , slash help (i.e. http://example.com/help). This 'path', 'URL' or the 'URI' of http://example.com/help when opened in a browser causes the web server to send you the contents of some file on disk.
Java servers — as with many other servers — begin this process by designating a specific directory on disk to be the base 'path', 'home', 'root' , or 'top-level' of the website (ie, http://example.com/).
Red5 uses a directory named 'webapps'. Each folder in this directory represents a different 'path', generally by the literal name. A folder named 'help' in the /webapps directory would resolve to this Internet address:
Defining and locating the files to be served from within the
/webapps/help directory is where Java is different from other servers.
Inside an application directory under /webapps - eg, /webapps/help - there is another folder named 'WEB-INF'. The WEB-INF directory contains a file named web.xml which specifies exactly how a Internet 'path' is linked to files.
http://example.com/help/account http://example.com/help/guidlines http://example.com/help/contact
These are examples of 'paths' which would be defined as a mapping from the browser's Internet request for a particular page, to the files containing Java code the server will execute.
Of course, Java will also serve static files from the application folder if they exist. Putting a stylesheet, js file, or image file right into the example 'help' directory for linking in web pages is easy:
http://example.com/help/account/login.jpg http://example.com/help/account/prefs.js http://example.com/help/account/login.css
The following describes the different type of ways to use Java to deliver content.
Java Server Page (JSP) files are 'just-in-time' compiled when a browser request is made for its path. They are accessed by the browser just like any other html document but use the .jsp extension (eg, http://example.com/help/faq.jsp) and allow the browser page to run dynamic content.
By extending the HTTPServlet class provided in the Java SDK, you can link Java code execution to an Internet path. Through configuration of web.xml, you define the path to associated with the servlet which will respond to HTTP requests.
All other Java code is compiled before deploying it on the server, and typically the web path linked to specific classes at server start up.
There are two ways to deploy compiled Java code to a Java server:
First thing to know: Java files turn into Class files.
operation.java ->(compiler creates new file)->operation.class
Java ARchive (JAR) are zip files full of compiled Java classes and any additional resource files. These can be found in two locations in relation to the current webapp application being accessed:
The Java server loads these resources into memory before it starts accepting Internet requests.
The second way to put Class files onto a Java server is to put them directly in a folder named 'classes' in the application's /WEB-INF directory. The web.xml file will declare Java classes as request handlers, and also declare the Internet paths that the request handlers are responsible for.
The Red5 Java server has one additional file, red5-web.xml, which defines how Internet requests map to Java files too. It differs from the web.xml file in that it defines the Internet paths that start with the 'RTMP' and 'RTSP' protocols instead of 'HTTP'.
The RTMP protocol is widely used for communication with a Flash-based client.
The Flash Player API provides a different communication context than that of requesting information over HTTP. Typically, an HTTP request uses 'slashes' to point to and endpoint to access information using a request (eg, http://example.com/help). In using RTMP for requests, the service path uses dot-notation:
service_name.service_method. Red5 uses red5-web.xml to map Java class objects with service names, and the public methods of that Java class object are the potential service methods the flash client can use.
Java based data objects are neatly passed to flash clients over RTMP, and then interpreted as Flash objects.
The RTSP prototocol is used by mobile (ie. iOS, Android) clients to connect to RED5.
Currently do not have a Red5 Pro Account? Register now to start enabling Live Streaming and Second Screen experiences for your iOS, Android and HTML5 applications.