Introspection

Introspection is the automatic process of analyzing a bean's design patterns to reveal the bean's properties, events, and methods. This process controls the publishing and discovery of bean operations and properties.

Advantages in introspection
Portability Reuse

Introspection
Events and properties are supported by a combination of new standard interfaces and classes. Examples are EventListener, EventObject, EventSetDescriptor, and PropertyDescriptor A method pattern is a combination of rules for the formation of a methods signature, its return type, and even its name. For example, here is the method pattern used to indicate a pair of getter and setter methods for a specific property: public <PropertyType> get<PropertyName> (); public void set<PropertyName> (<PropertyType> a);

Introspection
a bean can implement interface java.beans.BeanInfo. If this interface is implemented, an assembly tool will use it to query a bean instance explicitly for the names of property getters, property setters, and event source registration methods.

JAR FILES
. A JAR file (or Java ARchive) is used for aggregating many files into one. It is generally used to distribute Java classes and associated metadata. . WAR (Web Application aRchive) files are also Java archives which store XML files, Java classes, JavaServer Pages and other objects for Web Applications. . RAR (Resource Adapter aRchive) files, not to be confused with the RAR file format, are also Java archives which store XML files, Java classes and other objects for J2EE Connector Architecture (JCA) applications. . EAR (Enterprise ARchive) files are composite Java archives which combine XML files, Java classes and other objects including JAR, WAR and RAR Java archive files for Enterprise Applications.

jar cf archive_name.jar files Let's look at each part of that command line. . jar The command to run the jar utility. . CF Create a new archive with the file name specified. These two options are from this list of common options: . - c create new archive - t list table of contents for archive - x extract named (or all) files from archive - u update existing archive - v generate verbose output on standard output - f specify archive file name - m include manifest information from specified manifest file - 0 store only; use no ZIP compression - M do not create a manifest file for the entries - i generate index information for the specified jar files - C change to the specified directory and include the following file

Jar files

Jar files
Technically, a JAR file is a ZIP-format archive file that includes a manifest file. Manifest files are used to provide information on the contents of an archive file

Jar files
The archive may include: a set of class files; a set of serialized objects that is often used for bean prototype instances; optional help files in HTML; optional localization information used by the bean to localize itself; optional icons held in .icon files in GIF format; other resource files needed by the bean.

Jar files
The serialized prototype contained in the JAR file allows a bean to be shipped in an initialized default form. Serialization is performed using the object serialization service. New instances of such a bean are created by deserializing the prototype, effectively producing a copy. There can be multiple beans in a single JAR file potentially, each of the contained classes can be a bean and each of the serialized objects can be a bean instance. The manifest file in the JAR file can be used to name the beans in the JAR file.

Basic Java services

Reflection Object Serialization Java Native Interface Java AWT and JFC/Swing

Reflection
The Java core reflection service is a combination of original Java language features, a set of support classes (introduced with JDK 1.1), and a language feature to support class literals (expressions of type Class).

Reflection
The reflection service, curbed by the active security policy, allows:
inspection of classes and interfaces for their fields and methods; construction of new class instances and new arrays; access to and modification of fields of objects and classes; access to and modification of elements of arrays; invocation of methods on objects and classes.

Reflection
To enable reflective operations, the reflection service introduces a package java.lang.reflect. Classes Field, Method, and Constructor provide reflective information about the field, method, or constructor that they describe and allow for type-safe use of this field, method, or constructor.

OBJECT SERIALIZATION
. serialization is the process of saving an object onto a storage medium (such as a file, or a memory buffer) or to transmit it across a network connection link in binary form. The series of bytes or the format can be used to re-create an object that is identical in its internal state to the original object (actually, a clone). . This process of serializing an object is also called deflating or marshalling an object. The opposite operation, extracting a data structure from a series of bytes, is deserialization (which is also called inflating or unmarshalling).

Object serialization
Up to JDK 1.0.2, Java did not support serialization of objects into bytestreams only primitive types were supported. If an application wanted to write an entire web of objects to an output stream, it needed to traverse and serialize the objects itself, using some ad hoc encoding scheme. The Java object serialization service overcomes this by defining a standard serial encoding scheme and by providing the mechanisms to code and decode (serialize and deserialize) webs of objects.

Object serialization
To be serializable, an object has to implement interface java.io.Serializable. For objects implementing Serializable, sufficient information is written to a stream such that deserialization continues to work, even if different (but compatible) versions of classes are used.

Object serialization
Methods readObject and writeObject can be implemented to control further what information is written or to append further information to the stream. If these methods are not implemented, all non-transient fields referring to serializable objects are automatically serialized. Shared references to objects are preserved.

Object serialization
To make serialization safe and configurable, methods readObject and writeObject are private Reflection is used to find these methods for each extension level. If these methods exist, they should call a method defaultReadObject (or defaultWriteObject) before handling additional private data. The reason is that readObject and writeObject on a given class extension level handle only the fields introduced in this level, not those in subclasses or superclasses.

Object serialization
As an alternative to implementing interface java.io.Serializable, a class can implement interface Externalizable. Then none of the objects fields is automatically handled and it is up to the object to save and store its contents. Externalizable has methods writeExternal and readExternal for this purpose. These methods are public, and objects implementing Externalizable open themselves for access to their state that bypasses their regular public interface. This requires some care to avoid safety problems.

Object serialization
Object serialization creates a stream of bytes in a single-pass process that is, with no back-patching. Hence, while still serializing a web of objects, the part of the stream that has been produced already can be forwarded to filters or the destination. The stream is fully self-describing down to the level of Java primitive types a tag that describes the type of the following item precedes every value in the stream. Compared with compact native formats, this can be quite costly.

Object serialization
A major drawback of the current serialization service is the missing support for graceful degradation in the case of missing or incompatible classes at the receiving end. For example, if the serialized object is a document, then it should be possible to deserialize and use that document even if some of its embedded objects cannot (currently) be supported on the receiving platform The current service simply throws a ClassNotFound exception and does not offer means to resynchronize and continue deserialization.

ENTERPRISE JAVA BEANS

The EJB specification intends to provide a standard way to implement the backend 'business' code typically found in enterprise applications (as opposed to 'frontend user-interface code). Such code was frequently found to reproduce the same types of problems, and it was found that solutions to these problems are often repeatedly reimplemented by programmers. Enterprise Java Beans were intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand. Accordingly, the EJB specification details how an application server provides: . Persistence . Transaction processing . Concurrency control . Events using Java Message Service . Java Naming and directory services (JNDI) . Security ( Java Cryptography Extension (JCE) and JAAS ) . Deployment of software components in an application server . Remote procedure calls using RMI-IIOP. . Exposing business methods as Web Services.