Java component technology Visual Components and Systems Integration

1. Java component technologyVisual Components and Systems Integration • This lecture is all about the support for developing software components for the Java programmer. • We will look at some aspects of the Java language - most notably its support for distributing applications over the web, and the security implications of this. • We will then look at JavaBeans and what they are used for. • We will also look briefly at Microsoft’s competing technology - ActiveX and compare the two from a high level point of view. • We also briefly look at Java’s evolving support for distributed applications (EJB, RMI and CORBA).

2. JavaVisual Components and Systems Integration • Java is an object-oriented programming language developed by Sun Microsystems. • It shares many superficial similarities with C, and C++ but it is not based on any of those languages, nor have efforts been made to make it compatible with them. • Java was designed from the ground up to allow for secure execution of code across a network, even when the source of that code was untrusted and possibly malicious. • Java is compiled to an intermediate byte-code which is interpreted on the fly by a Java interpreter.

3. Java class filesVisual Components and Systems Integration • When you compile a Java program you create a class file - if you are creating an applet for example all you have to do is place the file on a Web server and place the applet tag in the appropriate HTML file. • Whenever someone downloads your HTML page, their browser, if it is Java-enabled, will read through your page download the .class file. • Once the file has been downloaded, the browser will run the applet using a Java Virtual Machine (JVM). • What the developers of Java did was invent a hypothetical microprocessor. Each of the instructions for this processor were intended to be one byte large - hence your compiled Java is called byte code.

4. Java packagesVisual Components and Systems Integration • Java is supplied as a collection of packages - these are simply class files which are grouped depending on what they do. • Take, for example, the supplied package java.awt. • The first part of that package name "java" represents the organisation that developed the package (Sun's Java group). • The second part of the package name "awt" stands for the contents of the package, in this case the Abstract Window Toolkit. • To use this package in a program you must import it at the beginning of your program.

5. Applets and applicationsVisual Components and Systems Integration • There are two major types of Java program - an application and an applet. • A Java application is made up of a main() method declared that accepts a string array argument, along with any other classes that main() calls. • It lives in the environment that the host OS provides. • A Java applet is made up of at least one public class that has to be subclassed from java.awt.Applet. • The applet is confined to living in a Web browser, and the browser's security rules, (or Sun's Appletviewer, which has fewer restrictions). • Typically an applet is a disposable program that is run once or twice and discarded.

6. Security of Java Applets Visual Components and Systems Integration • You can download Java applets from any system; thus security mechanisms exist within the Java virtual machine to protect against malicious applets. • Java applets are typically restricted in what operations they can perform, how they access memory, and how they use the Java virtual machine. • The restrictions are in place to prevent a Java applet from gaining access to underlying operating system or data on the system. An applet could potentially cause damage maliciously or by accident. • Java applets were originally constrained by the sandbox security model, so called because a Java applet could only play in its own sandbox.

7. Application from a local drive Applet loaded into an applet viewer froma local drive Applet loaded into a browser from a local drive Applet loaded into browser from a remote server Sandbox model of security Visual Components and Systems Integration • In Java 1.0 different default levels of security were assigned to Java programs depending on their type and origin : Increasing security restrictions

8. Signed Applets Visual Components and Systems Integration • In Java 1.1 the concept of the trusted or signed applet was introduced. Applets are packed into a Java ARchive File (JAR) and signed using a certificate. • The system that receives the applet then decides if it trusts that applet based on its signature. • If the user (or the system) judges that applet as trusted it is executed under the same conditions as local code and is able to access local resources without restrictions. • If an application required a more fine-grained security policy then the programmer had to manipulate the Security Manager and ClassLoader classes. • This requires fairly in-depth knowledge of computer security and the Java Virtual Machine.

9. JavabeansVisual Components and Systems Integration • JavaBeans is a portable, platform-independent component model written in Java. • It is developed by Javasoft, SunMicrosystems’s Java business group and was originally puttogether in collaboration with big industry leaders. • Software components are black boxes that encapsulate functionality and provide services based on a specification. • Software reusability has long been a holy grail of software engineering: software components are designed to be reusable, even interchangeable.

10. Classes or Beans?Visual Components and Systems Integration • Software components hide implementation, conform to interfaces, and encapsulate data, just like classes do in object-oriented languages. • So how do components differ from classes? Almost all software components are also classes. What makes them components is their conformance to a software component specification. • The JavaBeans Spec is the document that describes what a Java class must do to be considered a "Bean." • Programmers can depend on any class that advertises itself as a Bean to conform to the rules set out in the specification. If it doesn't conform, the contract has been broken and the Bean is defective.

11. Javabeans terminologyVisual Components and Systems Integration • Software components have properties, which are attributes of the object. Customization is the process of configuring a Bean for a particular task. • Beans may be dissected by IDEs or by other classes through a process called introspection. • Beans may be persisted (or serialized) into byte streams for transmission or storage. • Persisted Beans may be packaged into JAR files to ease downloading and access. • Finally, Beans have been designed to interoperate easily with legacy component technologies such as ActiveX, and participate in transactions with Object Request Broker systems such as CORBA.

12. OK - but what is Javabeans?Visual Components and Systems Integration • JavaBeans is • a core Java package (java.beans) that Beans may use to provided extended functionality, and • a document (the JavaBeans Specification) that describes how to use the classes and interfaces in the java.beans package • The package is part of the base release of Java, and no additional software must be installed in order to use it. • JavaBeans turns classes into software components by providing several new features. • Some of these features are specific to Beans. Others, like serialization, can apply to classes or Beans but are crucial to the understanding and use of Beans.

13. Making a Bean a Bean Visual Components and Systems Integration • To make a class into a component, the programmer must add functionality to the class that has little to do with what makes the class useful. • The only requirement to make a class into a Bean is that the class implement the interface java.io.Serializable. • Serializable classes know how to package themselves into streams of bytes to be transmitted through networks or saved to disk, awaiting later reincarnation. • Interfaces and classes defined in the package java.beans allow a Beans developer to control how the Beans user may set and get Beans' properties, hook Beans up to communicate with other components, and ask a Beans to describe themselves.

14. SerializationVisual Components and Systems Integration • It's often useful to "freeze-dry" an object by converting its state into a blob of data to be packed away for later use -- or transmitted through a network for processing elsewhere. • This process is called serialization. • One of the simplest uses for serialization is to save the state of a customised Bean, so that a newly-constructed Bean's properties can be correctly set at run time. • Where do you keep a group of freeze-dried Beans that have been "pickled" in this way? Why, in a JAR, of course! • JAR stands for Java ARchive is pretty obviously a play on the Unix tar file format.

15. JAR FilesVisual Components and Systems Integration • A JAR file is a ZIP compressed file containing multiple serialized objects, documentation, images, class files, etc. • A JAR file, containing many files, can be downloaded all in one piece and decompressed on the client end, making downloading more efficient. • A JAR file can contain an optional manifest file describing the JAR contents. This must file must be named META-INF/MANIFEST.MF. • JAR files containing beans should contain a META-INF/MANIFEST.MF manifest file giving the name of each bean class and specifying that it is a bean. • When a JAR file is signed, a signature file is generated and also placed in the JAR file's META-INF directory.

16. JavaBeans vs. appletsVisual Components and Systems Integration • Java Beans are cross-platform lumps of Java code that are ideally suited for building distributed networked applications - sounds like an applet? • Applets are generally, but not exclusively, designed to be small and disposable ­ that is, disposable from the user's perspective. Beans, by contrast, will typically be used to build larger, more-enduring programs, although again this need not necessarily be the case. • Applets are Java programs that are specifically designed to be acceptable from unqualified sources, such as an arbitrary Web page. Applets exploit the sandboxsecurity features provided in the JVM to reassure users that they are downloading harmless code.

17. JavaBeans vs. appletsVisual Components and Systems Integration • Beans will not necessarily execute within the confines of a sandbox. • They are intended for use in general-purpose applications, and so they can be given full or limited access to the resources of a host machine at the discretion of the developer. • Note that, like applets, Beans can make use of a variety of other security facilities provided by the JDK. They can be signed so that users can be sure of the origin of a Bean downloaded over a network. • Finally, Java Beans provide a way to carry out visual component-based development with Java, while applets provide no such structure.

18. The BDKVisual Components and Systems Integration • The BDK, or Beans Develop-ment Kit, is Sun’s own visual development application geared specifically for creating Beans. • The latest version (1.1) must be downloaded from Sun and is not part of the standard Java distribution. • You can use the BDK to visually wire Beans up together (using the Bean Box), edit their properties, serialization, introspection and so on. • You can also create Beans using Borland Jbuilder, Symantec's Visual Cafe,or by hand using the JDK.

19. Potential of JavaBeansVisual Components and Systems Integration • Javabeans can be used to create dynamic web based applications. My online banking service from Natwest is based almost completely around Javabeans which I have to download as JARs. • It is possible to interact with Javabeans objects via drag-and-drop actions and other forms of direct manipulation. This is a step on from applets. • Client Beans can interact with other client Beans in the a downloaded container as well as with server Beans. In addition, server Beans will be able invoke methods on client Beans, perhaps using CORBA events and callbacks. • We are now into the realm of server-side Beans - nowadays called Enterprise Javabeans.

20. Microsoft componentsVisual Components and Systems Integration • ActiveX is a reusable components object technology, developed by Microsoft for its Windows platform. • Developers can create ActiveX components that can be used in IDE products such as Visual C++, Visual Basic and Borland Delphi. • ActiveX really refers to a loosely defined set of Microsoft COM (Component Object Model) based technologies originally developed for compound-document technology, or Object Linking and Embedding (OLE). • While ActiveX is now being pushed as an open standard, it will be some time (if ever) before we see truly portable ActiveX controls. There are also has security concerns over the use of ActiveX components outside of Intranets.

21. Microsoft componentsVisual Components and Systems Integration • A straightforward way to think about COM, and ActiveX, is as a packaging technology, a group of conventions and supporting libraries that allows interaction between different pieces of software in a consistent,object-oriented way. • COM objects can be written in all sorts of languages, including C++, Java, Visual Basic, and more, and they can be implemented in DLLs or in their own executables, running as distinct processes. • A client using a COM object need not be aware of either what language the object is written in or whether it's running in a DLL or a separate process. To the client, it all looks the same.

22. Microsoft componentsVisual Components and Systems Integration • We are now beginning to see that ActiveX and COM are very similar to the Javabeans approach. • Code that's downloaded from a Web server to run inside a browser can appear as a COM object to the browser, providing a standard way to package downloadable code. • If the browser is ActiveX enabled (IE is by default, Netscape requires a plugin) then it will know exactly what to do with the downloaded component. • This is very similar to the way that a browser, if it is Java enables, deals with an applet or a Bean. • It would appear that Microsoft saw that browsers could be thought of as containers for component technology and forged ahead with this idea in competition with Java.

23. ActiveX controlsVisual Components and Systems Integration • COM-based components for the desktop are known as ActiveX controls - they have certain attributes that allow them to be used in larger applications. • In other words, An ActiveX control is just a COM object that follows certain standards in how it interacts with its client. • ActiveX controls are written as DLLs, and so they must be loaded into some kind of container. • The archetypal container for ActiveX controls was Visual Basic but today there are many more choices such as Visual C++, and Borland Delphi. • An especially important example of a control container today is Microsoft's Web browser, Internet Explorer.

24. JavaBeans vs. ActiveXVisual Components and Systems Integration • ActiveX competes directly against JavaBeans. • JavaBeans are highly portable, and can run on any platform that has a Java Virtual Machine. • ActiveX controls can execute on the Windows platform, and most use Win32 specific calls that would render them unsuitable for automatic porting to other platforms. • While ActiveX is now being pushed as an open standard, it will be some time (if ever) before we see truly portable ActiveX controls. • There are also has security concerns over the use of ActiveX components outside of Intranets - conversely Beans can run almost anywhere but are still restricted in what they can do because of Java’s security model.

25. Enterprise JavaBeans (EJB)Visual Components and Systems Integration • JavaBeans were originally designed for user-interface and client-side tasks. • To allow for server-side component-based development in Java, Sun has released the Enterprise JavaBeans (EJB) specification that adds server-side features such as transactions, persistence, and scalability. • In fact apart from the name, JavaBeans and EJB are quite different technologies. • In many ways the Enterprise JavaBeans architecture competes directly with Microsoft's Transaction Server (MTS). Both MTS and EJB provide similar functionality for COM-based ActiveX controls and Java-based components, respectively.

26. Java ServletsVisual Components and Systems Integration • Servlets are the server-side equivalent of applets. They differ from applets in that they have no user interface and do not use either the Abstract Window Toolkit (AWT) or swing. • They are intended as the Java replacements for the Common Gateway Interface (CGI) programs. The main advantage of Java servlets is their platform independence and the security that they provide, they should be seen as extensions of your web server. • Enterprise JavaBeans depend for security on the servlets that are provided with Enterprise Server for Java, their advantage lies with their persistence, component architecture, and reusability.

27. Java and CORBAVisual Components and Systems Integration • On the web, current HTTP/CGI paradigms are often seen as inadequate solutions to complex business applications - especially ones where legacy software is used. • The various CGI replacements -- such as cookies, scripting, PHP, and Active Server pages -- are often viewed as patched up, short-term, solutions. • One approach to creating an adequate solution might be with Common Object Request Broker Architecture (CORBA) and Java. • As it turns out, CORBA and Java are having a shotgun wedding and there are a number of commercial Java ORBs - a commonly used one is Visibroker.

28. Java, CORBA and RMIVisual Components and Systems Integration • In fact Sun have their own CORBA compliant technology called Java IDL (Interface Definition Language). • It enables distributed Web-enabled Java applications to transparently invoke operations over IIOP (Internet Inter-ORB Protocol) defined by the Object Management Group. • Remote Method Invocation (RMI) is a feature of the of Java JDK that competes with CORBA. • RMI allows a Java client to instantiate objects that may be located on a remote server. • However: the server application must also be written in Java and must use the tools provided with the JDK. • RMI can also suffer from poor performance due to limitations inherent in the Java virtual machine

29. Microsoft’s DCOMVisual Components and Systems Integration • Microsoft has its own competitor to CORBA and RMI - Distributed Component Object Model (DCOM). • DCOM, like CORBA, is language-independent, and objects are described via their interfaces using Microsoft's Object Description Language (ODL). It is only available for Windows OS’s. • Note as well that it is defined and controlled by a single vendor (Microsoft), which greatly reduces the options the DCOM developer can choose from when working (tools and features, for example). • DCOM is also a very immature technology when compared with CORBA.

30. SummaryVisual Components and Systems Integration • We have introduced a lot of new concepts in this lecture. • These concepts include the component technologies, JavaBeans, and ActiveX. • You don’t need to know any practical programming examples based around this techniques. • You do need to know, in general terms, how all they technologies might fit together to create a distributed application. • In particular you should be able to describe how JavaBeans differs from other types of Java programs (especially applets), explain common Beans terminology, and explain why you might choose to use JavaBeans over ActiveX and other software technologies.