Given by Geoffrey C. Fox, Wojtek Furmanski at UC Web applications Certificate on Aug 11,14 97. Foils prepared Aug 14 1997
Outside Index
Summary of Material
General Issues -- why Java Beans are important and what do they look like! |
Background: ComponentWare, Corba, Opendoc, DCOM, ActiveX |
An Example JavaBean (see separate JavaBeanStroll and tutorials) |
Object Web Development including IIOP for interoperability among Corba2 systems |
Detailed Technologies of JavaBeans (see next foil for summary)
|
These foils do not cover DCOM or ActiveX in detail
|
Outside Index Summary of Material
Geoffrey Fox, Wojtek Furmanski |
Syracuse University NPAC |
111 College Place Syracuse NY 13244 4100 |
3154432163 |
General Issues -- why Java Beans are important and what do they look like! |
Background: ComponentWare, Corba, Opendoc, DCOM, ActiveX |
An Example JavaBean (see separate JavaBeanStroll and tutorials) |
Object Web Development including IIOP for interoperability among Corba2 systems |
Detailed Technologies of JavaBeans (see next foil for summary)
|
These foils do not cover DCOM or ActiveX in detail
|
Properties -- setting and inspecting parameters |
Object Serialization (JDK1.1) -- jar files, saving JavaBeans |
Persistence -- Saved JavaBeans become object oriented database |
Reflection (JDK1.1) -- find out class structure |
BeanInfo -- general Bean Information |
Custom Editors -- Bean Specific Editors |
Event Model (JDK1.1) is same as for AWT |
Linkage of Beans using event model |
Java Remote Method Invocation (RMI) Java's answer to Corba |
Distributed JavaBeans for web computing and information systems |
O'Reilly: Java in a Nutshell by David Flanagan describes JavaBeans as part of extensive JDK1.1 description |
Sybex: Java 1.1 Developer's Handbook by Philip Heller, Simon Roberts, Peter Seymour and Tom McGinn is a very detailed description of JDK1.1 including JavaBeans |
O'Reilly: Developing JAVA Beans by Robert Englander is a focussed description of JavaBeans from a Java Programmers point of view |
Coriolis Group Books: Web developer's guide to javabeans by Jalal Feghhi is an interesting discussion from ComponentWare perspective. Also has CORBA DCOM ActiveX OpenDoc |
See resources listed at http://www.npac.syr.edu/education/web |
OBM site: http://www.omg.org |
NPAC Links to CORBA, DIS & HLA (Distributed Simulation): http://king.syr.edu:2006/src/hasan/DIS |
NPAC page withJava and CORBAbooks: http:// king.syr.edu:2006/src/webflow/0.1/notes/books |
Netscape CORBA and Crossware white papers: http://developer.netscape.com/library/wpapers/ {crossware,corba}/index.html |
They are Java's implementation of "component-based" visual programming |
This modern software engineering technique produces a new approach to libraries which become a "software component infrastructure(SCI)" |
There is a visual interface to discovery of and setting of values of and information about parameters used in a particular software component |
JavaBeans uses the event model of JDK1.1 to communicate between components
|
The visual interface allows inspection of and implementation of both individual beans and their linkage . This visual construction of linkage allows one to form nontrivial programs with multiple communicating components |
Apart from the event mechanism which is a communication/linkage mechanism, ComponentWare (and JavaBeans in particular) "just" give a set of universal rules (needed for interoperability) for rather uncontroversial (albeit good) object-oriented and visual programming practices
|
A JavaBean is "just" a Java Object which is part of some application for the end-user. |
JavaBeans implement the JDK1.1 event linkage mechanism for exchanging changes in values of properties and hence invoking responses to these changes. |
JavaBeans implement JDK1.1 Object Serialization to represent JavaBeans in "databases" (disk files) and hence define JavaBeans as persistent objects |
JavaBeans do not need to implement any particular class or interface.
|
These patterns are "discovered" automatically by the "introspection" capability of the reflection API in Java which is invoked by the BeanBox |
A BeanBox is a visual interface that displays (and allows changes to be made to) the properties of a JavaBean and further allows one to see and change the linkage between JavaBeans. |
A JavaBean consists of Java Code and possible associated files such as one or more icons, an image or two, a help file etc. This collection of entities is stored in a jar file which is based on the well-known UNIX tar file concept |
JavaBeans are naturally used as distributed objects in CORBA and can be linked to both JDBC (and hence databases) and COM from Microsoft. |
There is a Java native distributed communication model RMI (Remote Method Invocation) which provides CORBA like capabilities for a pure Java world
|
JavaBeans use the same event model as the AWT to communicate between Beans. This involves an indirect structure with Listeners acting as a bridge or broker between Sources (of information) and Sinks or what is synonymous observers. |
Source Bean |
Listener |
Sink Bean |
2) Notification of need to communicate |
1) |
Source Bean |
Sink Bean |
3) Communicate |
In the simplest case when one combines sink with listener, then one typically finds cycle (with any number of sinks)
|
Bean |
Bean |
Bean |
Bean |
JDB |
JDBC |
Java Beans Framework |
Java Server |
CORBA Server |
Database Server |
RMI |
IIOP |
Particular |
Database Protocol |
IIOP is Internet InterORB Protocol |
This is Java's version of a UNIX tar file and contains a variety of files including .class, image, sound, HTML pages |
The JAR file is stored in compressed (zip) fashion and can also be signed using standard digital signature techniques.
|
There is a "control" file called a manifest which inter alia is used to identify any JavaBean present. It also specifies message digest algorithm |
JavaBeans must be stored in JAR files and must be identified in manifest |
JAR files can be accessed from HTML using <APPLET> tag
|
Java looks first in .jar files for requested class |
First note that the terms component and control are synonymous |
DCOM is the distributed version of COM but COM has essentially all the critical object ideas |
OLE Controls and ActiveX Controls are variants of COM objects with different additional rules as what services (methods) the object must support |
A COM object offers services (methods) through one or more interfaces |
All COM objects must offer IUnknown interface which contains methods which are equivalent to JavaBean reflection API (find out about allowed methods) and garbage collection (find out when component no longer needed) |
One can use MIDL -- Microsoft Interface Definition Language -- to specify interfaces that can be accessed in a COM object |
ActiveX controls have, like JavaBeans, properties that can be queried and modified, a user interface, a set of methods that can be invoked and finally it can generate and send events |
JavaBeans can be wrapped into ActiveX components that can be used in an ActiveX container
|
DCOM provides the following services:
|
ComponentWare in General -- follows
|
CORBA |
JavaBeans |
ActiveX/DCOM Not covered in this talk except for brief summary in last 2 foils! |
Client runs custom software produced with components such as Visual Basic |
Application Server |
runs custom software currently |
produced in ad-hoc fashion but will adopt |
component |
approach |
Critical |
Generic Services such as databases |
In the Microsoft world, one can use Visual Basic and Active-X for a component based approach to both client and middle (application server) levels |
On the middle tier, one uses IIS (Microsoft Internet Information Server i.e. their HTTP server) and MTS (Microsoft Transaction Server)
|
Microsoft supports multiple languages (C, C++, Java, Visual Basic) but essentially only the Windows operating system |
Middle Tier |
Web Server |
Application Server |
TP Server |
Resource Management |
Perl CGI Java Servlets ActiveX |
DCOM RMI IIOP HTTP |
These are essentially JavaBeans implemented in the middle tier (as opposed to "normal" client side application) |
They naturally involve use of a Java Server (such as Jeeves from JavaSoft) and servlets which are server-side equivalent of applets |
They have resource management and security features and are aimed at multi-user server -- not typically single user client applications |
They access
|
Java Capable Web Browser with JavaBean Client Software |
RMI or IIOP |
HTTP |
Components are modular reusable atomic software units that enable cross-language cross-platform application development |
This is opposed to objects in traditional OO programming models which are usually platform and/or language specific |
Java is the first true cross-platform OO language but - it can't be a cross-language model... |
ComponentWare models integrate objects in Java, C++, Smalltalk etc. , running on any node in heterogeneous distributed environment |
New revolution on the Internet is driven by converging and/or competing ComponentWare technologies such as CORBA, DCOM/ActiveX, RMI, JavaBeans. |
We illustrate this rather complex process in the following chart which decomposes the evolution of distributed ComponentWare into vertical (system /complexity) axis and horizontal (user/simplicity) axis |
The chart includes also our approach at NPAC towards Web based HPCC in which we build high performance visual ComponentWare on top of Web technologies |
Components interact via Object Bus which offers porable platform for remote method invocation |
Applications are conveniently assembled from templates or common frameworks by developing and adding ensembles of application-specific components |
Examples of frameworks include:
|
We illustrate here a simple but fully operational Web based ComponentWare model - WebFlow at NPAC |
Components are given by Java modules, connected by dataflow channels using visual programming tools |
Object Bus is given by a mesh of Java Web Servers, hosting WebFlow modules via specialized servlets |
Framework is provided by the visual graph editor applet plus domain specific module libraries (HPCC, imaging, collaboratory are examples shown in next 3 foils) |
Ensembles are given by user-developed modules, following the WebFlow API |
Client Tier |
Middle Tier |
Third Tier |
is Parallel |
Computers |
for |
HPCC |
Simulation |
Basic Display |
Image Filter |
Output Display after Filter |
Bunch of Filters and Displays |
defined in |
Java Graph editor |
Original Image |
Collaboration Server |
Collaborating Modules |
ComponentWare in General |
CORBA -- follows |
JavaBeans |
ActiveX/DCOM Not covered in this talk! |
CORBA (Common Object Request Broker Architecture) is an Object Bus based distributed computing environment |
CORBA standards are developed since by OMG (Object Management Group) of some 700 companies (including IBM, Oracle, Sun, HP, Netscape) |
Cross-language support is provided by architecture-neutral IDL (Interface Description Language) |
Cross-platform support is provided by IDL->Native Language pre-compilers that generate platform-specific ORB servers, exporting IDL interfaces |
The following diagram illustrates the overall structure of an ORB, including its client and server components |
In fact, distinction between CORBA clients and servers is transient and dynamic, i.e. each ORB on the CORBA bus can act as client and as server |
CORBA supports both static ("precompiled") and dynamic ("scripted") remote method invocation models |
Here we illustrate in more detail steps involved in building (using Java) a simple static CORBA object and the associated client and server software |
Clients and Servers both have ORB capability |
In some sense |
CORBA is |
a server-server |
not |
client-server |
model |
Note it supports |
server object |
call-back to |
client object |
Previous diagram illustrated software components involved in enabling remote method invocation for a single object |
The next diagram categorizes various objects plugged in and playing on the CORBA bus |
The system itself (i.e. ORB vendors) provides a set of base object services and high level facilities |
Application objects built by users can refer to CORBA services/facilities as distributed OO libraries |
The process, illustrated in the following diagram, starts from specifying the object interface in IDL (which is a static subset of C++) |
Next, IDL->Native Language pre-compiler generates appropriate client stubs and server skeletons |
Next, the developer completes the pre-compiler work by implementing individual methods of the object under construction |
Finally, the modified stubs and skeletons are compiled to build suitable client and server executables |
In the following, we will illustrate all software pieces created in this process |
We will build CORBA object for the Count class, to be used for timing the client/server communication overhead in CORBA |
The following code elements are displayed:
|
The first step in the CORBA object development process is to specify object in IDL |
IDL looks like a static subset of C++ |
Atomic IDL unit is called a module and it contains a set of class interfaces |
Class interfaces contain attributes and methods (similar to Java interfaces) |
Method arguments can be scalars, vectors or lists of scalars, vectors or lists (but not general objects, at least in CORBA 2.0) |
Module Counter { |
interface Count { // our object |
attribute long sum; // current count value |
long increment(); // does sum++ |
}; |
} |
Note: this code is provided by developer and |
passed to IDL->XXX language pre-compiler |
IDL->Native Language pre-compiler takes IDL specification as input and generates a suite of auxiliary and/or temporary files |
These intermediate files are ORB and Native Language dependent |
For example, if Native language is Java, pre-compiler generates Java interface for each IDL interface (next foil) by following IDL->Java mapping rules |
Both client and server codes are using this Java interface to refer to the object implementation |
The JavaIDL is one way of doing this |
package Counter; |
public interface Count extends CORBA.Object { |
public int sum() throws CORBA.Exception; |
public void sum(int val) throws CORBA.Exception; |
public int increment() throws CORBA.Exception; |
} |
} |
Note: This code is created automatically by |
IDL->Java pre-compiler from the IDL spec |
Another auxiliary file generated by IDL->Java pre-compiler is client-side stub (here called _st_Count) |
It implements Count interface and extends CORBA.Stub superclass |
Count methods and attribute accessors are implemented by opening CORBA.IOStream, submitting the invocation request to the server, retrieving the results from the stream, and returning to the client |
package Counter; |
public class _st_Count extends CORBA.Stub |
implements Count { |
public int increment() { |
CORBA.IOStream _stream = this._create_request("increment",true); |
_invoke(_stream,true); |
int _result = _stream.read_int(); |
return _result; |
} |
public int sum() { ... } |
Note: This code is created automatically by |
IDL->Java pre-compiler from the IDL spec |
A server-side skeleton, here called _sk_Count, plays similar role to the client stub but at the server side, i.e. handles remote method invocation |
Skeleton implements Count in terms of the generic exec method of the CORBA.Object |
exec is called with the methodId value that uniquely identifies a given method |
exec is implemented as a switch which jumps to the appropriate method implementation |
the actual method execution is performed by CountImpl instance, here passed as _self argument |
package Counter; |
abstract public class _sk_Count implements CORBA.Object, Count { |
public static void exec(Count _self, IOStream _stream, int _methodId) { |
switch(methodId) { |
case 0: // call increment |
int result = _self.increment(); |
_stream.write_int(_result); return; |
case 1: // set sum value |
int value = _stream.read_int(); |
_self.sum(value); return; |
case 2: // get sum value |
int value = _self.sum(); |
_stream.write_int(value); |
} |
} |
Note: This code is created automatically by |
IDL->Java pre-compiler from the IDL spec |
IDL->Java preprocessor also generates server-side implementation template for the object under construction |
The user needs only to:
|
Note that the pre-compiler generates two accessor methods (for set and get operations) for each object attribute specified by IDL |
package Counter; |
public class example_Count extends Skeleton implements Count { |
private int sum; |
example_CountImpl(String name) { // Count object constructor |
super(name); sum = 0; |
System.out.println("Count Object Created!"); |
} |
public int sum() throws CORBA.Exception { // accessor method: getSum |
} |
public void sum(int val) throws CORBA.Exception { // accessor method: setSum |
} |
public int increment() throws CORBA.Exception { // increment method |
} |
} |
Note: This code is generated by IDL->Java pre-compiler and needs to be |
completed by the developer (by implementing the indicated methods) |
Note: This code is created automatically by |
IDL->Java pre-compiler from the IDL spec |
Finally, we provide the server-side implementation of the object under construction, here given by the CountImpl class |
It is constructed by completing the implementation template as discussed in the previous two foils |
Note that our Count is in fact a very simple object: it maintains a counter value called sum and it increments it whenever its increment() method is invoked |
package Counter; |
public class CountImpl extends _sk_Count implements Count { |
private int sum; |
CountImpl(String name) { // Count object constructor |
super(name); sum = 0; |
System.out.println("Count Object Created!"); |
} |
public int sum() throws CORBA.Exception { // accessor method: getSum |
return sum; |
} |
public void sum(int val) throws CORBA.Exception { // accessor method: setSum |
sum = val; |
} |
public int increment() throws CORBA.Exception { // increment method |
sum++; return sum: |
} |
} |
Note: This code is created automatically by |
IDL->Java pre-compiler from the IDL spec |
The main server program performs the following operations:
|
package Counter; |
class CountServer { |
static public void main(String[] args) { |
try { |
CORBA.ORB orb = CORBA.ORB.init(); // Initialize the ORB |
CORBA.BOA boa = orb.BOA_init(); // Initialize the Basic Object Adapter |
CountImpl count = new CountImpl("My Count"); // create Count object |
boa.obj_is_ready(count); // export new object to the ORB |
boa.impl_is_ready(); // ready to service requests |
} catch(CORBA.Exception e) { System.err.println(e); } |
} |
} |
Note: This code is created by the developer |
package Counter; |
class CountClient { |
static public void main(String[] args) { |
try { |
CORBA.ORB orb = CORBA.ORB.init(); // Initialize the ORB |
// binding by name to the Counter instance on the server |
Counter.Count counter = Counter.Count_var.bind("My Count"); |
counter.sum(0); // initialize counter to zero |
long startTime = System.currentTimeMillis(); |
for(int j=0; j򒮨 j++) { // now increment 1000 times by |
counter.increment(); // calling increment() method on server object |
} |
long stopTime = System.currentTimeMillis(); |
System.out.println((stopTime-startTime)/1000f); |
} catch(CORBA.Exception e) { System.err.println(e); } |
}} |
Note: This code is created by the developer |
This becomes general hierarchical address for arbitrary server |
The main client program performs the following functions:
|
The following two diagrams superimpose all files generated in the Count example on the following charts presented previously:
|
Note: the whole process looks complicated and messy but only for (multi-language) CORBA object developer/installer - the user program is very simple! (see Main Client code) |
IIOP (Internet Inter-ORB Protocol) introduced and enforced by CORBA 2 in 1995 offers a standard communication protocol between ORB servers coming from various vendors |
In consequence, CORBA 2 compliant ORBs enable true World-Wide distributed computing |
Netscape, Oracle, IBM and other major Web and OBM companies recognized recently the strategic role of IIOP for enabling Web based Enterprise Computing |
IIOP is stateful object-oriented binary communication protocol, suitable for general purpose distributed computing |
HTTP is stateless ASCII communication protocol, suitable for hypertext information delivery |
Java appears to be a perfect language for Web based ORB engineering |
Combination of IIOP & HTTP servers, based on Java platform and referred to as Object Web, will drive soon a new phase transition on the Internet. |
Object Web is turning the Internet into a universal global computing system. |
Netscape is the major promoter of the Object Web |
Netscape believes IIOP will integrate anti-Microsoft coalition to successfully compete with DCOM/ActiveX |
All Netscape browser and server products are coming with built-in IIOP support |
Other browsers can acquire ORB capabilities by downloading suitable ORBlets as applets
|
Integration of the 3-tier Object Web with JavaBeans via JavaScript based Bean-Connect technology towards Crossware (see next slide) is under way |
Crossware is more of a CORBA enabled object web "philosophy" than a product |
IIOP joins the family of open network protocols maintained and supported within Netscape ONE (Open Network Environment) |
JFC (Java Foundation Classes), under joint development by JavaSoft, Netscape, IBM and others, form the portable core for Netscape ONE
|
In particular, Netscape intends to use JavaBeans as the universal encapsulation model for terminal endpoints between various protocols |
ONE is a library of tools to build Web Technology applications -- an unbundling of current servers and browsers |
At the moment, the main focus in JavaBeans development is at the client side for GUI/widgets engineering |
However, the technology is applicable also at the server or middle tier (where JavaSoft calls it Enterprise JavaBeans and develops the specification) |
We are currently building new version of WebFlow that uses JavaBeans both for visual editing and for server-side ComponentWare |
The strength of CORBA stems from a solid core, augmented by a broad family of standardized interfaces, developed over the last 7 years by OMG |
The core layer is given by the ORB model and the associated support to enable remote object invocation |
On top of the ORB layer, CORBA offers the Common Object Services (COS) layer |
On top of the COS layer, CORBA offers Common (Horizontal) and Vertical Market Facilities |
The whole collection is functionally equivalent to an object-oriented distributed operating system |
At present, the following Services are fully specified and published:
|
Externalization - the same as Serialization in Java |
Query - search in the object space |
Collection - operations on the query results |
Relationship - building relations among objects |
Licensing - support for object licensing |
Time - support for synchronized global clock |
CORBA Facilities are high level software concepts that build on top of Services |
Facilities split into Horizontal (general purpose) and Vertical (market specific) segments |
At the moment, most facilities are at the level of requirement specifications or Requests for Proposals |
The OMG process of specifying Services and Facilities is ongoing, never ending and reflecting the software technology evolution |
In the following, we list the major Facilities, discussed in the recent OMG publication |
User Interface
|
Information Management
|
System Management |
Task Management
|
Vertical Market Facilities
|
If the current Object Web program succeeds, IIOP will become a `cosmic' message passing protocol |
In HPCC domain, people are typically using low level high performance communication packages such as PVM, MPI or Nexus and they consider CORBA/IIOP as not very useful as too low performance |
However, it seems possible and natural to build High Performance CORBA support by providing dedicated HP-ORB that offers optimized IIOP on top of Nexus |
The resulting HP-CORBA (see next slide) offers an interesting paradigm for new Web based HPCC |
ComponentWare in General |
CORBA |
JavaBeans -- follows
|
ActiveX/DCOM Not covered in this talk! |
5)Actual Data Transfer |
This involves sources, listeners and observers and is an interesting multi-tier model of linkage/communication |
One can (in some cases) merge observer and listener but not the listener and source |
Registration involves sending an object name -- termed the callback object -- from the listener to the source. |
When event occurs, the source invokes a particular (event dependent) method of the callback object |
Events can be distinguished by using different callback methods (demultiplexing) or by inspecting the argument of a more generic method. |
Sources and Listeners use a "controlled syntax" but there are no special interfaces or methods for linkage of observers and listeners as usually(often) these are combined. |
The various listeners and events are named in pairs XListener (an interface extending java.util.EventListener) and XEvent (an object extending java.util.EventObject) |
Registration involves methods for the source called
|
Such naming conventions are part of the design pattern for the JavaBean (JDK1.1) framework |
X = Component, Focus, Key, Mouse, MouseMotion, Window, Container, Text, Action, Adjustment and Item in JDK1.1 AWT |
Source of any class |
Listener implementing XListener |
Source contains method addXListener |
Source creates Event of type XEvent |
Listener contains a callback object with several methods each accepting argument of |
type XEvent |
Register |
callback |
object |
Invoke Callback |
Here we contrast the simple "A sends a message to B" model normally used in computing with the more general approach in the JavaBean Linkage model |
Define an event ADataReadyEvent with A as source and B as combined sink and listener |
A defines an instance Evtcontrol of ADataReadyEvent which has a method transferdata |
B instantiates an object Bcallback implementing interface ADataReadyListener with a method readytogo() |
B registers this listener object as a callback with A |
When A is ready to send data to B, A callbacks Bcallback.readtogo(ADataReadyEvent Evtcontrol) |
B calls back Evtcontrol.transferdata(sink information) |
Note that "control" mechanism uses powerful JavaBean approach (this is handshake) whereas one can use a totally different and faster approach to actually send data |
Traditional (in my world) mechanisms combine control and data transfer |
Persistence of an object implies that one can save its value to some permanent store (e.g. a disk) and read it back |
This is implemented using Serializable (default saving) or Externalizable (user defined saving) |
In saving a Java Object, we save the values of data members but assume that the entity reading back object has access to class definition so that one just needs data member values to define instance
|
One needs to flatten the hierarchical linkage of objects to any root Java object |
In diagram, one needs to output members of A, B, C and D with D only output once! |
Object A |
Object B |
Object C |
Object D |
Root object |
Leaf object |
The Serialization interface is essentially a flag as there are NO methods or data attached to this interface -- implementing Serialization implies your willingness to be saved using default Java mechanism! |
The Serialization process is typically implemented by a container (Java Applet, Application, Java Beans Container) |
Typically one serializes to an output stream and deserializes from an input stream |
DataOutput Interface describes streams that can write out data in a machine independent fashion |
ObjectOutputStream class extends DataOutput (and an ObjectOutput Interface) and defines methods to write out variables of all the primitive types with a general
|
java.awt.Component class implements the Serializable interface and any bean extending this class or any of its subclasses is automatically Serializable and hence can be persistent |
Note Object class is not Serializable and so one must inherit from a subclass of Object that is Serializable in order to automatically get this property |
One can explicitly implement the Serializable Interface by supplying writeObject() and readObject() |
Beans should store references to external Beans as transient as linkage is responsibility of BeanBox |
Externalizable Objects must implement writeExternal() and readExternal() methods for user implemented persistency |
This is Java's CORBA-like capability to allow Java objects to access each other's methods remotely |
Note COM is Microsoft's (remote) object model |
CORBA is Industry (OMG) remote object model |
RMI is Java's way for remote objects to communicate |
It extends the well known Remote Procedure Call (RPC) used in UNIX |
RMI is thus part of a JavaBean global object model
|
RPC was designed for UNIX systems |
RPC serializes parameter and return values but is simpler than RMI as one was not using objects |
External Data Representation (XDR) is used by RPC to support data serialization |
RPC uses fast but unreliable UDP protocol |
RMI uses slower but reliable TCP/IP |
This involves transport of serialized objects |
RMI Client |
RMI Server |
Client Side Stubs |
RRL: Remote Reference Layer |
Transport Layer |
Server Side Skeleton |
RRL: Remote Reference Layer |
Transport Layer |
Created by rmic command |
Stubs are the client side proxies representing the remote server side objects
|
The skeleton is server side interface of server side method to RRL
|
The RRL takes care of references between client and server |
The transport layer is responsible for establishing connection between client and server |
The RMI Registry must be started before the server side application and maintains a list of "published objects"
|
Security is implemented using RMISecurityManager which customizes the normal Java Security Manager |
Note RMI essentially uses Java as its IDL and does not have a special skeleton/stub definition language |
Introspection refers to the process by which JavaBeans are inspected to discover their characteristics. This a combination of
|
The Java Core Reflection API allows one to determine information about objects at runtime.
|
The reflection API is used in two ways:
|
First one invokes for any Object obj
|
Second process instance cl of class Class, has methods
|
These return public instances only |
Thirdly process arrays like Field, Method, Constructor etc. which are in java.lang.reflect and have a whole set of methods to find out further information including
|
The java.beans.BeanInfo interface is used to define everything about a Bean that is not implied by reflection and design patterns |
extend java.beans.SimpleBeanInfo which defaults all the methods to null which implies that one use reflection
|
BeanInfo can supply
|
BeanDescriptor is one of entities you can get from BeanInfo and this holds overall information about the Bean |
Beans of name B:
|
Property P of type T is gotten by public T getP()
|
Bound and Constrained Properties are each supported by a single list of event listeners and B must support methods
|
Events with name E
|
No constraints on names for methods |
BeanInfo class (for Bean B) is BBeanInfo |
Property Editor for properties of type T are Teditor
|
Customizer for Bean B is typically called BCustomizer and must be a component with a no argument constructor
|