1 / 53

Topic 11 – Deployment Strategies

Topic 11 – Deployment Strategies. CISC370/Object Oriented Programming with Java. “Through this be madness, yet there is method in ‘t.”. Use and Distribution Notice. Possession of any of these files implies understanding and agreement to this policy.

munin
Télécharger la présentation

Topic 11 – Deployment Strategies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Topic 11 – Deployment Strategies CISC370/Object Oriented Programming with Java “Through this be madness, yet there is method in ‘t.”

  2. Use and Distribution Notice • Possession of any of these files implies understanding and agreement to this policy. • The slides are provided for the use of students enrolled in Jeff Six's Object Oriented Programming with Java class (CISC 370) at the University of Delaware. They are the creation of Mr. Six and he reserves all rights as to the slides. These slides are not to be modified or redistributed in any way. All of these slides may only be used by students for the purpose of reviewing the material covered in lecture. Any other use, including but not limited to, the modification of any slides or the sale of any slides or material, in whole or in part, is expressly prohibited. • Most of the material in these slides, including the examples, is derived from multiple textbooks. Credit is hereby given to the authors of these textbook for much of the content. This content is used here for the purpose of presenting this material in CISC 370, which uses, or has used, these textbooks.

  3. What is an Applet? • An applet is a Java program that can be downloaded and run in a browser. • As applets are written in a full programming language, they are potentially more powerful than any combination of HTML, XML, JavaScript (which has no relation to Java, save the name), ASP, etc… • An applet is included in a web page; it is not a web page itself. You include an applet in much the same way as anything else, using HTML tags.

  4. Deployment Strategies • Java 1.0 introduced applets – Java programs than ran inside of web browsers. • This allowed users to download applets over the web and run them on the local system inside a very restrictive sandbox to prevent malicious applets from inflicting damage. • Java Web Start is a less restrictive and more powerful deployment technology where applications can be downloaded to clients over the web and run in a less restrictive environment. • Let’s look at these two technologies in detail.

  5. Writing a Simple Applet • Looking at the Java code for a simple, Hello World, applet… import java.awt.*; import javax.swing.*; public class HelloWorldApplet extends JApplet { public void init() { Container contentPane = getContentPane(); JLabel label = new JLabel(“Hello World as an applet”, SwingConstants.CENTER); contentPane.add(label); } }

  6. The Simple Applet • Note that this is very similar to other graphics programming we have seen. • The applet itself has a content pane, to which we can add components. • Notice we do not need a method of exiting the applet as it lives inside a web page. • Also notice that the applet has no main() method, but it has an init() method. More about that shortly…

  7. Converting Applications to Applets • It is easy to convert a graphical application to an applet. Almost all of the user-interface code can stay the same… • Make a HTML page with the appropriate tag for the applet (and convert using the HTMLConverter) – more about this in a bit. • Make a class derived from JApplet. This class must be public.

  8. Converting Applicationsto Applets • Remove the main() method of the application. Do not make a frame..the applet will be displayed in the browser. • Move any initialization code out of the frame’s constructor and into the init() method of the applet. You do not need a constructor for the applet class. • Remove the call to setSize(), this is done using the WIDTH & HEIGHT in the HTML.

  9. Converting Applicationsto Applets • Remove any application exit code – you cannot call System.exit() or anything like it from an applet. • If the application calls setTitle(), remove that call as applets cannot have titles. • Do not call show() - the applet is displayed automatically in the browser.

  10. Applet Example • Suppose we have a panel, CalculatorPanel, which implements a simple push-button calculator. • To display this inside an applet… import java.awt.*; import javax.swing.*; public class CalculatorApplet extends JApplet { public void init() { Container contentPane = getContentPane(); CalculatorPanel calc = new CalculatorPanel(); contentPane.add(calc); } }

  11. An Applet’s Life Cycle • There are four methods that define an applet’s behavior. Let’s look at them one at a time…

  12. init() • The init() method performs whatever initialization is required for your applet. It is a lot like a constructor. • It is called automatically whenever the applet is first launched by Java. • Common actions in init() include parsing PARAM values (more about that later) and creating UI components. • Applets can have a default constructor; however it is customary to perform all initialization in the init() method.

  13. start() • This method is called automatically after the call to init(). • It is then called again whenever the user revisits the page containing the applet, after viewing other pages. • Thus, start() gets called multiple times, while init() only gets called once (the first time). • If your applet does nothing that needs to be suspended if the user leaves the page, you don’t need to worry about start() & stop().

  14. stop() • This method is called automatically when a user leaves the applet page. • This method exists so you can stop a time-consuming activity from slowing down the system when the user is no longer paying attention to the applet. • If your applet does not perform animation, play audio, or perform threaded calculations, you don’t need to worry about this.

  15. destroy() • Java calls this method when the browser is shut down normally. • If the applet is still active when the browser is shut down, Java will call stop() and then destroy(). • This method should contain code for reclaiming any non-memory-dependant resources your applet may be using.

  16. Executing the Applet • So, how do we execute an applet? • First, compile the source code files into class files. • Then, create a HTML file that tells the browser where to position and size the applet and which class file to load first. • So, inside HelloWorldApplet.html: <APPLET CODE=“HelloWorldApplet.class” WIDTH=300 HEIGHT=300> </APPLET>

  17. The Applet Viewer • Once the HTML file is written, we can use AppletViewer, included with the Java 2 SDK to see how our applet will look. • Simply start the applet viewer with the name of the HTML file that describes how to load the applet… appletviewer HelloWorldApplet.html

  18. The Applet Viewer • This will start the applet viewer, which will read your HTML file, find the applet class file, and display it with the sizes specified in the HTML file. • This is very convenient for initial testing of your applets, but at some point you really should run them in a browser to see how they look, from a user point-of-view. • The applet viewer only displays the applet; not the surrounding HTML text (or anything else). If you have more than one applet in a HTML file, AppletViewer will display them in separate windows.

  19. Applet Example • The HTML for our Calculator applet… <HTML> <TITLE>A Simple Calculator Applet</TITLE> <BODY> Here is a silly little calculator. <APPLET CODE=“CalculatorApplet.class” WIDTH=180 HEIGHT=180> </APPLET> </BODY> </HTML>

  20. Applet Attributes • There any many attributes that can be included with the <APPLET> HTML tag. • WIDTH & HEIGHT – These attributes give the width and height of the applet, in pixels. In a browser, you cannot resize the applet. • ALIGN – This attributes specifies the alignment of the applet. It follows the same form as when displaying an image in HTML using the <IMG> tag. Table 10-1 in the Core Java 2 textbook outlines all of the available alignments.

  21. Applet Attributes • CODE – This attribute specifies the class file that contains the applet. It is relative to the codebase attribute (see below) or relative to the current web page (if no codebase). This specifies the name of the class for the applet itself. • CODEBASE – This optional attribute specifies the location of other class files used by the applet. For example, if the applet called CalculatorApplet is located in the directory MyApplets (down one level from the directory containing the HTML), the tag would look like: <APPLET CODE=“CalculatorApplet.class” CODEBASE=“MyApplets” WIDTH=100 HEIGHT=150>

  22. Applet Attributes • ARCHIVE – This optional attribute specifies the Java archive (JAR) file that contains classes or other resources used by the applet. This archive is downloaded from the server before the applet is run. This speeds up the loading process. For example, if our CalculatorApplet uses classes contained in two JAR files… <APPLET CODE=“CalculatorApplet.class” ARCHIVE= “CalculatorClasses.jar,cisc370/JeffsClasses.jar” WIDTH = 100 HEIGHT = 150>

  23. JAR Files and Applets • If an applet uses a number of classes, the browser will issue one HTTP request for each class file, as it needs them. • Java supports an improved method for loading class files (and other resources) by combining all the needed files into a single file. • This (compressed) file can then be downloaded via one HTTP request, which will reduce download time.

  24. JAR Files and Applets • The jar command works much like the Unix tar command. • To combine files into a JAR archive. . . jar -cvf <JARFilename> <file1> <file2> . . . • For example… jar -cvf CalculatorClasses.jar *.class icon.gif • The various options (in this case, -cvf) are shown in the online documentation.

  25. JAR Files and Applets • Now that all the classes needed for our Calculator applet are in a single JAR file, specify it as archive in the <APPLET> tag… <APPLET CODE=“CalculatorApplet.class” ARCHIVE=“CalculatorClasses.jar” WIDTH=100 HEIGHT=150> • Now when a class or image or sound file is needed by the applet, it will be searched for in the JAR file. Only if it’s not found will the applet fetch it from the web server.

  26. JAR Files and Applets • Note that the CODE attribute is still necessary to tell the browser which applet to load and execute. • The ARCHIVE attribute is simply a source where the applet class and other files may be located.

  27. Passing Parameters to Applets • Just like applications can be passed command-line information, applets can be passed parameters from their enclosing HTML code. • This is done with the <PARAM> HTML tag… <APPLET CODE=“MyNiftyApplet.class” WIDTH=200 HEIGHT=100> <PARAM NAME=“font” VALUE=“Helvetica”> </APPLET>

  28. Passing Parameters to Applets • This passes a parameter with the key “font” and the value “Helvetica” to the applet. The applet can then retrieve its parameters through the getParameter() method… public class MyNiftyApplet extends JApplet { public void init() { String fontName = getParameter(“font”); . . . } . . . }

  29. Passing Parameters to Applets • Parameters are always passed as Strings. • Notice you need to know the name(key) of a parameter in order to get its value. • You can test to see if a parameter has been passed in… int fontsize; String sizeString = getParameter(“size”); if (sizeString == null) fontsize = 12; // size param not passed in else fontsize = Integer.parseInt(sizeString);

  30. Applets and Pop-Up Windows • When an applet is embedded in a web page, it exists inside a frame sized by the WIDTH and HEIGHT parameters passed to it in the HTML code. • It is also possible to create a pop-up frame(window). • So, let’s modify our calculator frame applet to now contain one button. When we click that button, the calculator frame will pop-up.

  31. Calculator as a Pop-Up Window public class PopupCalculatorApplet extends JApplet { public void init() { frame = new JFrame(); frame.setSize(200,200); frame.getContentPane().add(new CalculatorPanel()); JButton calcButton = new JButton(“Calculator”); getContentPane().add(calcButton); calcButton.addActionListener( new ActionListener() { public void actionPerformed(ActionEvent e) { if (frame.isVisible()) frame.setVisible(false); else frame.show(); } } } private JFrame frame; }

  32. Applet Security • Applets are designed to be loaded from remote sites and then executed. • As such, a nasty applet could cause some pretty serious damage to your system is you downloaded and executed it. • For this reason, applets are restricted in what they are allowed to do.

  33. The Applet Sandbox • For these security reasons, applets run in a sandbox. This is a restricted execution environment that does not allow applets to alter a system or spy on it. • There are a number of security rules that apply when an applet is running inside of the sandbox.

  34. Sandbox Rules • An applet can never run any local executable programs. • Applets cannot communicate with any host other than the server from which they were downloaded (the originating host). • Applets cannot read/write to the local computer’s file system. • All windows that an applet opens carry a warning message, alerting the user that it is a applet running and should not be trusted.

  35. Sandbox Rules • Applets cannot find out any information about the local computer except for the JVM version, the name and version of the operating system, and the characters used to separate files, paths, and lines. • This sandboxing is possible because Java is interpreted; it runs on the JVM and not directly on the local computer’s CPU. Thus, the JVM can impose these restrictions and limit the applet’s abilities to cause damage.

  36. Applet Browser Compatibility • When applets were first developed, back in Java 1.0, the only browser which supported them was Sun’s HotJava browser. • Netscape followed suit and included support for applets and a JVM inside of their browser, followed shortly thereafter by Microsoft doing the same in Internet Explorer. • Currently, IE supports all Java 1.0 features, and most of Java 1.1, but not the Java 2 platform. Mozilla-based browsers now use a plug-in architecture, as we will see in a second (and IE can too!).

  37. The Java Plug-In • Sun has released a tool known as the Java Plug-In. It is a browser plug-in, available for both IE and Mozilla-based browsers; it integrates into the browser and allows the browser to execute applets by using an external version of the JVM. • You can then download a new external version of the JVM that implements the current version of Java from Sun. • Assuming Sun keeps its JVMs up-to-date (which is a pretty safe assumption), you can always take advantage of the current features of Java).

  38. Viewing Applets in a Browser • The Java Plug-In comes with the Java 2 SDK and with most of the JREs (Java Runtime Environment – the JVM and all the system classes but no compiler or other development tools). Basically, if you have Java installed on your system, you probably have the plug-in. • Unfortunately, if you use the plug-in, the HTML you need for the applet is significantly more complex than a simple <APPLET> tag. • This is because the browser should not use its internal JVM to display the applet…it needs to use the plug-in.

  39. HTMLConverter • To make things easier, Sun provides a tool, HTMLConverter, which takes a standard HTML file and converts <APPLET> tags to the appropriate code for the Java Plug-In. • The converter is part of the Java 2 SDK. Documentation is here: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/html_converter_more.html

  40. Using the HTML Converter • The converter itself is written to Java. • Instructions for running it come with the download package and are also available from multiple sites online. • When the program starts, a friendly GUI comes up and will convert HTML with APPLET tags to HTML with more complex, Java Plug-In capable tags.

  41. Converted. Now What? • Now that the HTML file for your applet is complete and ready for the plug-in, you need to load the file into a browser. • If you have installed the plug-in in your browser correctly, the applet will be displayed. If not, the browser should lead you through steps which will fetch and install the plug-in.

  42. Enter Java Web Start • Java Web Start (JWS) is a new technology with the goal of improving the user experience of Java programs downloaded over the Internet. • JWS is something of a follow-on technology to applets and aims to solve a lot of the programs that applet have. • A program deployed with JWS differs from one deployed as an applet – it is worth comparing the two technologies and see how they differ.

  43. JWS versus Applets • JWS delivers normal Java programs (starting with a main method), not applets. • A JWS applications can be launched from within a browser but it does not run there. The browser simply launches an external application (similar to what happens with Adobe Acrobat, for example). • Once a JWS app has been downloaded, it can be started from outside the browser. • JWS has enhanced support for caching and automatically updating from the program’s source than the applet plug-in does (although JWS and the plug-in will eventually become one product).

  44. The JWS Sandbox • JWS applications run in a relaxed sandbox – it allows normal, unsigned, apps some access to local resources (more about signed/unsigned in a bit). • The Java Network Launch Protocol (JNLP) is what makes JWS work. With minimal security permissions, the JNLP API allows the JWS-deployed application some access to local resources.

  45. The JWS Sandbox • For example, there are services for JWS apps to load and save files but they are restrictive. The JWS app cannot look at the file system and it cannot specify file names. • Instead, a file dialog pops up and the user selects the file. Before this happens, a dialog asks the user if they want to allow the JWS app to open a file dialog box. • Even more, the program does not get access to a File object and the app cannot find the file location the user selected – in all JNLP API calls, as much information as possible is hidden from these untrusted applications.

  46. JNLP API Services • The JNLP API provides these services to a Java Web Start application… • Loading and Saving Files • Accessing the System Clipboard • Downloading a File over the Network • Printing to a Local Printer • Storing and Retrieving Configuration Information • Displaying a HTML document in the Default HTML Web Browser • A JWS applications uses these services by asking the JNLP ServiceManager for a Service object.

  47. JNLP Example –Reading a Local File • To allow a JWS application to read data from a file, the app needs a FileOpenService… • The openFileDialog() method receives suggestions for the initial path and extensions for the file dialog box and returns a FileContents object (a restrictive File-like object) or NULL. • After that call completes, you can call getInputStream() on the FileContents object. FileOpenService srv=(FileOpenService)ServiceManager. lookup(“javax.jnlp.FileOpenService”); FileContents con=srv.openFileDialog(“.”, new String [] { “txt” }); if (contents != null) {InputStream in=con.getInputStream();}

  48. The FileOpenService and JWS/Applet Sandbox Comparison • Notice that the JNLP FileOpenService is much more restrictive than what a normal application is allowed to do with a File object. • However, remember that an applet is not allowed to touch the local file system at all. The JWS sandbox is less restrictive than the applet sandbox. • Safety is still preserved – the JWS application cannot specify a filename or path nor can it learn which path the user specified – this is an interesting balance between security and functionality.

  49. Other JNLP Services • The other services that JNLP provides are designed in a similar way – the application can access more local system resources than an applet can – but the user typically decides what and where and the JWS application cannot find out any important information. • This is a key advantage to JWS applications over applets – they are more powerful and can do more things, yet they are still quite restrictive and cannot look at or manipulate anything on the local system unless that resource is specified by the user (and even then, the app doesn’t know what it can look at or change!).

  50. JWS Deployment • So how is a JWS application deployed? • Compile your application and package the entire app in a JAR file (all classes and resources). • Create a descriptor file in JNLP format. • Place these two files on a web server and make sure the server is configured to return “application/s-java-jnlp-file” as the MIME type for files with a JNLP extension. • Notice that the last step will be web server dependent. Each server requires these configuration steps be performed in a different manner – check the documentation!

More Related