Download Java

Java component technology
Visual 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).
Java
Visual 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.
Java class files
Visual 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.
Java packages
Visual 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.
Applets and applications
Visual 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.
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.
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
Application from a local drive
Applet loaded into an applet viewer from
a local drive
Applet loaded into a browser from
a local drive
Applet loaded into browser
from a remote server
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.
Javabeans
Visual Components and Systems Integration
 JavaBeans is a portable, platformindependent component model
written in Java.
 It is developed by Javasoft, Sun
Microsystems’s Java business
group and was originally put
together 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.
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.
Javabeans terminology
Visual 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.
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.
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.
Serialization
Visual 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.
JAR Files
Visual 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 METAINF/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.
JavaBeans vs. applets
Visual 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 sandbox
security features provided in the JVM to reassure users
that they are downloading harmless code.
JavaBeans vs. applets
Visual 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.
The BDK
Visual Components and Systems Integration
 The BDK, or Beans Development 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.
Potential of JavaBeans
Visual 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 dragand-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.
Microsoft components
Visual 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.
Microsoft components
Visual 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.
Microsoft components
Visual 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.
ActiveX controls
Visual 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.
JavaBeans vs. ActiveX
Visual 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.
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.
Java Servlets
Visual 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.
Java and CORBA
Visual 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.
Java, CORBA and RMI
Visual 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 InterORB 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
Microsoft’s DCOM
Visual 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.
Summary
Visual 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.