Beruflich Dokumente
Kultur Dokumente
Molecule Bean
It displays a three-dimensional view of a molecule. It may be configured to present one of the
following molecules: hyaluronic acid, benzene, buckminsterfullerene, cyclohexane, ethane, or
water. This component also has methods that allow the molecule to be rotated in space along its X
or Y-axis.
Create and Configure an Instance of the Molecule Bean Steps
1. Position the cursor on the Toolbox entry labeled Molecule and clicks the left mouse button.
You should see the cursor change to a cross.
2. Move the cursor to the Bean Box display area and click the left mouse button in approximately
the area where you wish the Bean to be displayed. You should see a rectangular region appear that
contains a 3-D display of a molecule. A hatched border, indicating that it is currently selected,
surrounds this area.
3. You can reposition the Molecule Bean by positioning the cursor over one of the hatched
borders and dragging the Bean.
4. You can change the molecule that is displayed by changing the selection in the Properties
window. Notice that the Bean display changes immediately when you change the selected
molecule.
Create and configure an Instance of the Our Button Bean and connect it to the Molecule
Bean Steps
NOTE: Our Button Bean provides a push-button functionality.
1. Position the cursor on the Toolbox entry labeled Our Button and clicks the left Mouse button.
You should see the cursor change to a cross.
2. Move the cursor to the Bean Box display area and click the left mouse button in approximately
the area where you wish the Bean to be displayed. You should see a rectangular region appear that
contains a button. A hatched border indicating that it is currently selected surrounds this area.
3. You may reposition the Our Button Bean by positioning the cursor over one of the hatched
borders and dragging the Bean.
4. Go to the Properties window and change the label of the Bean to Rotate X. The button
appearance changes immediately when this property is changed.
5. Go to the menu bar of the Bean Box and select Edit | Events | action | action Performed. You
should now see a line extending from the button to the cursor. Notice that one end of the line
moves as the cursor moves. However, the other end of the line remains fixed at the button.
6. Move the cursor so that it is inside the Molecule Bean display area, and click the left mouse
button. You should see the Event Target Dialog dialog box.
7. The dialog box allows you to choose a method that should be invoked when this button is
clicked. Select the entry labeled rotateOnX and click the OK button. You should see a message
box appear very briefly, stating that the tool is Generating and compiling adaptor class.
Test the application. Each time you press the button; the molecule should move a few degrees
around one of its axes.
Now create another instance of the OurButton Bean. Label it Rotate Y and map its action event
to the rotateY method of the Molecule Bean. The steps to do this are very similar to those just
described for the button labeled Rotate X. Test the application by clicking these buttons and
observing how the molecule moves.
JAR Files
1. It means JAR (Java Archive) files.
2. BDK expects Beans to be packaged within JAR files to create our own bean.
3. A JAR file allows you to efficiently deploy a set of classes and their associated resources.
For example, a developer may build a multimedia application that uses various sound and image
files. A set of Beans can control how and when this information is presented. All of these pieces
can be placed into one JAR file.
4. JAR technology makes it much easier to deliver and install software.
5. Elements in a JAR file are compressed, which makes downloading a JAR file much faster than
separately downloading several uncompressed files. Digital signatures may also be associated
with the individual elements in a JAR file. This allows a consumer to be sure that a specific
organization or individual produced these elements.
6. The package java.util.zip contains classes that read and write JAR files.
Manifest Files (MFT)
1. A developer must provide a manifest file to indicate which of the components in a JAR file are
Java Beans.
2. A manifest file may reference several dot class files. If a dot class file is a Java Bean, its entry
must be immediately followed by the line Java-Bean: True.
Example of a manifest file
It defines a JAR file that contains two .gif files and one dot class file. The last entry is a Bean.
Name: sunw/demo/slides/slide0.gif
Name: sunw/demo/slides/slide1.gif
Name: sunw/demo/slides/Slides.class
Java-Bean: True
JAR Utility
A utility is used to generate a JAR file. Its syntax is shown here:
Usage:
jar {ctxu}[vfm0Mi] [jar-file] [manifest-file] [-C dir] files...
Jar options files
-c
-T
-X
-U
-V
-f
-m
-0
-M
-i
-C
Meaning
Create new archive
List table of contents for archive
Extract named (or all) files from archive
Update existing archive
Generate verbose output on standard output
Specify archive file name
Include manifest information from specified manifest file
Store only; use no ZIP compression
Do not create a manifest file for the entries
Generate index information for the specified jar files
Change to the specified directory and include the following file
Note
1.If any file is a directory then it is processed recursively. The manifest file name and the archive
file name need to be specified in the same order the 'm' and 'f' flags are specified.
Creating a JAR File
To create a JAR file named Xyz.jar that contains all of the dot class and dot gif files in the current
directory:
Jar cf Xyz.jar *.class *.gif
If a manifest file such as Yxz.mf is available, it can be used with the following command:
Jar cfm Xyz.jar Yxz.mf *.class *.gif.
Tabulating the Contents of a JAR File
The command lists the contents of Xyz.jar:
Jar tf Xyz.jar
Extracting Files from a JAR File
The command extracts the contents of Xyz.jar and places those files in the current directory:
Jar xf Xyz.jar
Updating an Existing JAR File
The following command adds the file file1.class to Xyz.jar:
Jar -uf Xyz.jar file1.class
Recursing Directories
The following command adds all files below directoryX to Xyz.jar:
Jar -uf Xyz.jar -C directoryX *
Introspection
1. It is the process of analyzing a Bean to determine its capabilities and essential feature of the
Java Beans API.
2. It allows an application builder tool to present information about a component to a software
designer.
3. Without introspection, the Java Beans technology could not operate.
4. There are two ways in which the developer of a Bean can indicate which of its properties,
events, and an application builder tool should expose methods.
First way
Simple naming conventions are used to allow the introspection mechanisms to infer information
about a Bean.
Second way
The design patterns for properties and events that enable the functionality of a Bean to be
determined.
colors.mft
Name: sunw/demo/week6/vbean.class
Java-Bean: True
Vbean.java
package sunw.demo.week6;
import java.awt.*;
import java.awt.event.*;
public class vbean extends Canvas
{
transient private Color color;
private boolean square;
public vbean()
{
addMouseListener(new MouseAdapter()
{
public void mousePressed(MouseEvent me)
{
change();
}
}
);
square=false;
setSize(200,200);
change();
}
public boolean getSquare()
{
return square;
}
public void setSquare(boolean flag)
{
this.square=flag;
repaint();
}
public void change()
{
color=randomColor();
repaint();
}
private Color randomColor()
{
int r=(int)(255*Math.random());
int g=(int)(255*Math.random());
int b=(int)(255*Math.random());
Steps
For this example, start the BDK and create an instance of the Colors Bean in the Bean Box
window. Create an instance of the TickTock Bean. The Properties window should show one
property for this component. It is Interval and its initial value is 5. This represents the number
of seconds that elapse between property change events generated by theTickTock Bean. Change
the value to 1.
Now you need to map events generated by the TickTock Bean into method calls on
the Colors Bean. Follow these steps:
1. Go to the menu bar of the BeanBox and select Edit | Events | propertyChange| propertyChange.
You should now see a line extending from the button to the cursor.
2. Move the cursor so that it is inside the Colors Bean display area, and click the left mouse
button. You should see the Event Target Dialog dialog box.
3. The dialog box allows you to choose a method that should be invoked when this event occurs.
Select the entry labeled change and click the OK button. You should see a message box appear
very briefly, stating that the tool is Generating and compiling adaptor class.
You should now see the color of your component change every second.
Using the Bean Info Interface
Design patterns were used to determine the information that was provided to a Bean user. This
section describes how a developer can use the BeanInfo interface to explicitly control this
process.
This interface defines several methods, including these:
PropertyDescriptor[ ] getPropertyDescriptors( )
EventSetDescriptor[ ] getEventSetDescriptors( )
MethodDescriptor[ ] getMethodDescriptors( )
They return arrays of objects that provide information about the properties, events, and methods
of a Bean. By implementing these methods, a developer can designate exactly what is presented
to a user. SimpleBeanInfo is a class that provides default implementations of the BeanInfo
interface, including the three methods just shown. You may extend this class and override one or
more of them. The following listing shows how this is done for the Colors Bean that was
developed earlier. ColorsBeanInfo is a subclass of SimpleBeanInfo. It overrides
Constrained Properties
A Bean that has a constrained property generates an event when an attempt is made to change its
value. The event is of type PropertyChangeEvent. It is sent to objects that previously registered
an interest in receiving such notifications. Those other objects have the ability to veto the
proposed change. This capability allows a Bean to operate differently according to its run-time
environment.
Persistence
It is the ability to save a Bean to nonvolatile storage and retrieve it at a later time. The
information that is particularly important are the configuration settings.
BDK allows you to save a set of Beans that have been configured and connected together to form
an application. The rectangular property of the Colors Bean was changed to true, and the interval
property of the TickTock Bean was changed to one second. These changes can be saved.
To save the application, go to the menu bar of the BeanBox and select File | Save. A dialog box
should appear, allowing you to specify the name of a file to which the Beans and their
configuration parameters should be saved. Supply a filename and click the OK button on that
dialog box. Exit from the BDK. Start the BDK again.
To restore the application go to the menu bar of the Bean Box and select File | Load. A dialog
box should appear, allowing you to specify the name of the file from which an application should
be restored. Supply the name of the file in which the application was saved, and click the OK
button.
Confirm that the rectangular property of the Colors Bean is true and that the interval property for
the TickTock Bean is equal to one second. The object serialization capabilities provided by the
Java class libraries are used to provide persistence for Beans. If a Bean inherits directly or
indirectly from java.awt.Component, it is automatically serializable, because that class
implements the java.io.Serializable interface. If a Bean does not inherit an implementation of the
Serializable interface, you must provide this yourself. Otherwise, containers cannot save the
configuration of your component.
The transient keyword can be used to designate data members of a Bean that should not be
serialized. The color variable of the Colors class is an example of such an item.
Customizers
The Properties window of the BDK allows a developer to modify the properties of a Bean.
However, this may not be the best user interface for a complex component with many interrelated
properties. Therefore, a Bean developer can provide a customizer that helps another developer
configure this software. A customizer can provide a step-by-step guide through the process that
must be followed to use the component in a specific context. Online documentation can also be
provided. A Bean developer has great flexibility to develop a customizer that can differentiate his
or her product in the marketplace.
Interface
AppletInitializer
Bean Info
Customizer
Exception Listener
Design Mode
PropertyChangeListener
PropertyEditior
VetoableChangeListner
Visibility
Class
Bean Descriptor
Beans
IntrospectionException
PropertyChangeEvent
PropertyDescriptor
Description
This class provides information about a Bean.
This class is used to obtain information about a Bean
An exception of this type is generated if a problem occurs when
analyzing a bean.
This event is generated when bound or constrained properties
are changed.
Instances of this class describe a property o f a Bean
Class
DefaultPersistenceDelegate
Encoder
EventHandler
EventSetDescriptor
Expression
FeatureDescriptor
Indexed Property Descriptor
Introspection Exception
Introspector
MethodDescriptor
ParameterDescriptor
PersistenceDelegate
PropertyChangeEvent
Class
PropertyChangeListenerProxy
PropertyChangeSupport
PropertyDescriptor
PropertyEditorManager
PropertyEditorSupport
PropertyVetoException
SinpleBeanInfo
Statement
VetoableChangeListenerProxy
Description
A concrete subclass of Persistence Delegate.
(Added by java2, version 1.4)
Encodes the state of set of beans. Can be used to write this
information to a stream. (Added by java2, version 1.4)
Supports dynamic event listener creation. (Added by
java2, V 1.4)
Instances of this class describe an event that can be
generated by a bean.
Encapsulate a call to a method that returns a result.
This is the super class of the property Descriptor, Event
Set Descriptor, and Method Descriptor classes.
Instances of this class describe an indexed property of a
bean.
An Exception of this type is generated if a problem occurs
when analyzing the bean
This class analyzes a bean and constructs a BeanInfo
object that describe the component.
Instances of this class describe a method of a bean.
Instances of this class describe a method parameter.
Handles the state information of an object.
This is generated when bound or constrained properties
are changed. It is sent to objects that registered an interest
in these events and implement either the
PropertyChangeListner or VetoableChangeListener
interfaces.
Description
Extends EventListenerProxy and implements
PropertyChangeListener. (Added by java2, V 1.4)
Beans that support bound properties can use this class to
notify PropertyChangeListener objects.
Instances of this class describe a property of a bean.
This class locates a Property Editor object for a given
type.
This class provides functionality that can be used when
writing property editors.
An exception of this type is generated if a change to a
constrained property is vetoed.
This class provides functionality that can be used when
writing bean info classes.
Encapsulates a call a method. (Added by java2, V 1.4)
Extends EventListnerProxy and implements
VetoableChangeSupport
XlmDecoder
XlmEncoder
component
key
mouseMotion
focus
mouse
hierarchyBounds
First, create a new project by selecting New from the File menu. Next, select javax.swing.JFrame
in the list at the top of the Property Inspector window. JFrame is the top-level Swing class for the
design window. Next, scroll down in the Property Inspector window until you find title. Change
the title to A Bean Builder App.Your screen should look like the one shown in Figure 25-7.
of the Swing class JScrollbar. By default, both the slider and the scroll bar have the same range (0
to 100), so the value of one will translate directly to the value of the other. To make your
application look like the one in this book, position them as shown in Figure 25-9.
Now it is time to wire the components together. To do this, you will position the mouse pointer
over one of the connection handles, then drag a wire from the connection handle on one
component to a connection handle on another component. The component at which you start is
the source of some event and the component at which you end is the recipient of the event. Each
component has four connection
WARE
DEVELOPMENTUSING
Containers Handle
1. Concurrency
2. Security
3. Availability
4. Scalability
5. Transactions
6. Distribution
Components Handle
1. Presentation of JSP, Servlets and Applets
2. Business Logic of EJB
3. Data Access Logic (optional) of EJB
Note
1. The container is the car. The component is the driver
2. The container is the platform. The component is your application
EJB specifications
The Enterprise Java Beans (EJB) specification is a foundation for the Java 2 Platform,
Enterprise Edition (J2EE) defined by Sun. Vendors use this specification to implement an
infrastructure in which components can be deployed, and use a set of services such as
distributed transactions, security, or life-cycle management. As a developer, you just
reuse the services detailed in the specification. For example, you do not need to include
any code in your components to make them transactional. This lets you concentrate on
the business logic of the application.
Enterprise beans are designed to be portable from one vendors execution environment to
another, independent of the choices made by the vendor to implement the services
described in the specification. The quality of service required by an enterprise bean is
described outside of the component in a deployment descriptor. The deployment
descriptor is analyzed at deployment time by a tool provided by the vendor. This feature
provides a great level of flexibility for reusing your component. For example, if you wish
to change the transactional behavior of an enterprise bean, you have to change only the
transaction attribute stored in the deployment descriptor, not the EJB business logic.
Changes are taken into account when you re-deploy the enterprise bean in the container.
Features and limitations of EJB 1.0
Features
1. Enterprise bean instances are created and managed at runtime by a container.
2. An enterprise bean can be customized at deployment time by editing its environment
properties.
3. Client access is mediated by the container and the EJB server on which the enterprise
bean is deployed.
4. Flexible component model.
5. Support for component distributions and security.
6. Stateless and state full session beans are defined and must be supported.
7. Container-managed persistence and bean-managed persistence entity beans are defined
and are not mandatory in this version.
8. For transaction support, either the original javax.jts package or the new
javax.transaction package can be used.
Limitations
1. Entity bean support is not mandatory.
2. Java RMI-IIOP support is not mandatory, which defies interoperability with other
heterogeneous components.
3. The deployment descriptor is not available in text format.
4. Requires a separate deployment file for each enterprise bean, causing large
applications composed of many beans to slow down.
5. Interoperability between containers is not defined.
6. No standard container API.
EJB Provides
1. Easier development
2. Open industry standard support
3. Multi-tiered architecture
4. Scalability
5. Distributed transaction support
6. Portable cross platform component model, Platform independence
7. EJB Components provide reusable Data and Business Logic
8. EJB Servers provide transactions and security support
9. N-tier Architecture provides scalability and performance
10. Component container contract provides cross platform portability
4. Server provider
The job of the server provider is to provide a runtime EJB server environment that is
compliant with the EJB specification. IBM is a server provider of the WebSphere
Application Server.
5. Container provider
The job of the container provider is to provide a runtime EJB container environment that
is compliant with the EJB specification, and is generally the same as the server provider.
The server and container cooperate to provide the quality-of-service runtime environment
for the EJBs.
6. Systems administrator
The system administrators task is to ensure that the runtime environment is configured in
such a way that the application can function correctly, and is integrated with all of the
required external components.
EJB framework Main components
There are six main framework components of EJB technology. They were
1. EJB server
It provides the actual primary services to all EJBs. An EJB server may host one or more
EJB containers. It is also called generically an Enterprise Java Server (EJS). WebSphere
Application Server is an EJBS.
2. EJB container
It provides the runtime environment for the enterprise bean instances, and is the
intermediary between the EJB component and the server.
3. EJB component
These represent the actual EJBS themselves. There are three types of enterprise beans:
entity, session, and message-driven beans.
4. EJB interfaces and EJB bean
The interfaces for client access (EJB home and EJB object) and the EJB bean class.
5. EJB deployment descriptor
The descriptor defines the runtime quality of service settings for the bean when it is
deployed. Many of the settings of an EJB, such as the transactional settings, are defined
in the deployment descriptor. The deployment descriptor is an external entity from the
bean, and therefore decouples the bean component itself from the runtime characteristics.
6. EJB client
A client that accesses EJBs.
EJB server
It is that part of the application server that hosts EJB containers. This is sometimes
referred to as an Enterprise Java Server (EJS). Containers are transparent to the client
there is no client API to manipulate the container, and there is no way for a client to tell
in which container an enterprise bean is deployed. The EJB server provides the
implementation for the common services to all EJBs. The EJB servers responsibility is to
hide the complexities of these services from the applications requiring them, thereby
obtaining access to the service on behalf of the EJB, but hiding it from the EJB.
The EJB specification outlines seven services that must be provided by an EJB server:
The responsibilities that an EJB container must satisfy can be defined in terms of the
primary services. Specific EJB container responsibilities are as follows:
Primary services
1. Naming
A client can invoke an enterprise bean by looking up the name of the bean in a
centralized naming space called a naming service, and this is accessed via the Java
Naming and Directory Interface (JNDI) API. The container is responsible for registering
the (unique) lookup name in the JNDI namespace when the server starts up, and binding
the appropriate object type into the JNDI namespace.
2. Transaction
A transaction is defined as a set of tasks that must execute together; either all must work
or all must be undone. The EJB container handles the transaction operations, as well as
the coordination activities between the transactions of the beans. The EJBs transaction
behavior is described in the deployment descriptor, and this is also referred to as
container-managed transactions (CMT). Because the container manages the
transactions, applications can be written without explicit transaction demarcation.
3. Security
The EJB container provides a security domain for enterprise beans. The container is
responsible for enforcing the security policies defined at deployment time whenever there
is a method call, through access control lists (ACL). An ACL is a list of users, the groups
they belong to, and their rights, and it ensures that users access only those resources and
perform only those tasks for which they have been given permission.
4. Persistence
The container is also responsible for managing the persistence of a bean (all storage and
retrieval of data) by synchronizing the state of the bean instance in memory with the
respective record in the data source. Concurrent access to the data from multiple clients is
managed through the concurrency and transaction services (entity beans only).
5. Concurrency
It is defined as access by two or more clients to the same bean, and the container manages
concurrency according to the rules of the bean type. Additionally, for message-driven
beans, concurrency is defined as managing the processing of the same message.
6. Life cycle
The container is responsible for controlling the life cycle of the deployed components. As
EJB clients start giving requests to the container, the container dynamically instantiates,
destroys, and reuses the beans as appropriate. The specific life-cycle management that the
container performs is dependent upon the type of bean. The container may ultimately
provide for some resource utilization optimizations, and employ techniques for bean
instance pooling. Bean state-management is a type of life-cycle management, where
activating and passivating of beans based on usage can be achieved. These techniques
become part of the bean life cycle that the container must manage.
7. Messaging
The container must provide for asynchronous messaging. Specifically, it must provide for
the reliable routing of messages from JMS clients to message-driven beans.
Bear in mind that the EJB container and the EJB server are not clearly separated
constructs. EJBs do not interact directly with the EJB server, but rather, do so through the
EJB container, which acts as a broker to the services provided by the EJB server. So,
from the EJBs perspective, it appears that the EJB container is in fact providing those
services. Additionally, the specification only defines a bean-container contract and does
not define a container-server contract, so determining who actually does what is a little
ambiguous. The container does not actually provide the service itself; rather it
communicates with the EJB server that actually implements the service, but how this is
actually implemented is up the individual EJB vendors. Therefore, for the sake of
simplicity, the seven services defined above will simply be referred to generically as EJB
services.
EJB container
The EJB container is a system that functions as a runtime environment for enterprise
beans by managing and applying the primary services that are needed for bean
management at runtime. In addition to being an intermediary to the seven services above
provided by the EJB server, the EJB container will also provide for EJB instance lifecycle management, and EJB instance identification. EJB containers create bean instances,
manage pools of instances, and destroy them. The container provides the service level
specified at deployment time in the deployment descriptor. For example, it will start a
transaction or check for security policies.
All the services are well defined within the EJB framework. The framework is
implemented through the bean callback methods. These methods are purely for system
management purposes and only the container calls them when it is interacting with the
deployed beans, and are invoked when the appropriate life-cycle event occurs. The
specification is clear on what actions trigger what events, and subsequently what callback
methods are invoked, and this provides the bean developer with a predictable runtime
model. All the interaction takes place in a way transparent to the bean developer and also
to the client.
Remote accessibility
Ultimately, EJBs are (usually) remote, distributed objects, and the containers primary
responsibility is to provide the means to access these remote objects. Remote
accessibility enables remote invocation of a native component by converting it into a
network component. EJB containers use the Java RMI interfaces to specify remote
accessibility to clients of the EJBs.
Purpose
Shared Access
Persistence
Session Bean
Represents Process.Performs
a task, or process for a client.
One instance per client
Not persistent. When the
Client terminates its session
bean is no longer available.
Entity Bean
Represents Data: represents a business
entity object that exists in persistent
storage.
Shared instance for multiple clients
Persistent. Even when the EJB
container terminates, the entity state
remains in a database.
Callback methods
EJBs interact with the container through a well-defined component model that is
implemented by the callback methods that a bean must implement. At runtime, the
container invokes the callback methods on the bean instance when the appropriate lifecycle event occurs, such as create or remove. The type of bean determines the callback
methods a bean must implement: entity, session, or message-driven bean.
EJBContext
It is also part of the bean-container contract is the EJBContext interface, which provides
the bean information about the container. Each bean type has its own type of EJBContext:
EntityContext, SessionContext, and MessageDrivenContext, all inheriting from
EJBContext.
Environment naming context
Is a localized JNDI namespace for the bean that the container provides, also called the
environment-naming context. Contains references to environment information, resources,
or other EJBs.
Additional flavors of EJB types
Other are two different flavors of both entity and session beans:
Flavors of an entity bean
The entity beans represent persistent data. There are two types of entity beans that govern
how the persistency behavior will be managed by the container.
a. Through container-managed persistence (CMP),
b. Through bean-managed persistence (BMP) Or by the bean itself.
Flavors of a session bean
There are two types of session beans. Stateless session beans are beans that maintain no
state, and are pooled by the container to be reused. Stateful session beans are beans that
represent a conversational state with a client, where the state is maintained between client
invocations.
Although the classifications above (CMP versus BMP, and stateful versus stateless) are
often referred to as types of EJBs, they are not really different types in the sense that
there are no new classes or interfaces to represent these types (they are still just session
and entity beans). Rather, how the container manages these beans is what makes them
different. All information regarding the way the container has to handle these different
bean flavors is managed in the deployment descriptor. For entity beans, the deployment
element of <persistence-type> determines if this bean is container or bean managed. For
session beans, the deployment element of <session-type> determines if it is stateful or
stateless. Figure 2-31 shows the types of beans, updated to show the additional types:
EJB interactions
And finally, we can see how each of the EJBs that we identified will work together
as part of the banking application (Figure 2-33).
2. New business methods that wrap entity bean finder methods and format the retrieved
entity beans into usable data for the client.
Advantages of using facade session beans:
1. The persistence model is hidden from the client. Entity beans are viewed as generalpurpose data sources and are not visible to client applications.
2. Session beans can tie together multiple data sources and act as the single point of entry
to the business data layer.
3. Centralized control of transactions and security is delegated to the session facade layer
and managed more efficiently for the application.
Figure Show session beans can act as a facade layer to entity beans in front of clients.