Given by Wojtek Furmanski,Nancy McCracken, Chao Wei Ou, Geoffrey Fox at ARL Database Tutorial and CPS616 on February 98. Foils prepared 14 Feb 98
Outside Index
Summary of Material
This describes CORBA in general with a description of architecture including:
|
We give an example of a simple counter using the Visigenic ORB |
Another presentation describes JavaIDL ORB |
We describe and illustrate role of CORBA in a 3 tier distributed information system and describe role of Javabeans and use of CORBA and Javabeans to wrap existing applications |
Outside Index Summary of Material
Geoffrey Fox, Wojtek Furmanski, Nancy McCracken, Chao-Wei Ou |
NPAC at Syracuse University |
111 College Place, Syracuse NY 13244 4100 |
See resources listed at http://www.npac.syr.edu/projects/tutorials |
http://www.npac.syr.edu/users/gcf/corbagenfeb98/ |
http://www.npac.syr.edu/users/gcf/corbajavaidlfeb98/ |
This describes CORBA in general with a description of architecture including:
|
We give an example of a simple counter using the Visigenic ORB |
Another presentation describes JavaIDL ORB |
We describe and illustrate role of CORBA in a 3 tier distributed information system and describe role of Javabeans and use of CORBA and Javabeans to wrap existing applications |
OMG 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 |
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 |
CORBA provides a uniform distributed object model |
Today we see a more complex distributed heterogeneous server (as proxy for service) model which we view as a 3 tier architecture on next foil |
COM from Microsoft is a similar model largely focused on PC's with a richer (in terms of implemented objects) current implementation but a less elegant architecture |
RMI from JavaSoft is cross platform distributed object model like CORBA but confined to one language (Java) whereas CORBA is multi-language and multi-platform |
W is Web Server |
PD Parallel Database |
DC Distributed Computer |
PC Parallel Computer |
O Object Broker |
N Network Server e.g. Netsolve |
T Collaboratory Server |
Clients |
Middle Layer (Server Tier) |
Third Backend Tier |
Previous diagram (foil 6) 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 |
WorkFlow |
ORB |
System Management |
Computation? |
.............. |
Trader |
Security |
.......... |
Naming |
Persistence |
Oil & Gas |
DMSO Modeling and Simulation |
Imagery |
Banking |
Manufacturing |
...... |
...... |
Services |
Horizontal Facilities |
Vertical |
Facilities |
Standard Interfaces |
i.e. Frameworks |
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 using Visigenic VisiBroker ORB, to be used for timing the client/server communication overhead in CORBA |
We will use Visigenic ORB which is packaged in every Netscape communicator and so can be driven simply from applets |
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 |
package Counter; |
public interface Count extends org.omg.CORBA.Object { |
/* Attribute Writer */ |
public void sum(int sum); |
/* Attribute Reader */ |
public int sum(); |
/*Implement Remote Operation */ |
public int increment(); |
} |
Note: This code is created automatically by IDL->Java pre-compiler from the IDL spec |
Note: All client programs invoking the remote count object must use this as interface definition for remote object |
Another auxiliary file generated by IDL->Java pre-compiler is client-side stub (here called _st_Count) |
It implements Count interface and extends org.omg.CORBA.portable.ObjectImpl superclass |
Count methods and attribute accessors are implemented by opening CORBA runtime libraries implementing I/O, 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 org.omg.CORBA.portable.ObjectImpl implements Counter.Count { |
public int increment() { try { |
org.omg.CORBA.portable.OutputStream _output = this._request("increment",true); /* Call Remote Object */ |
org.omg.CORBA.portable.InputStream _input = this._invoke(_output, null); /* Detect Answer */ |
int _result; _result =_input.read_long(); /* Returned value */ |
return _result; } |
catch(org.omg.CORBA.TRANSIENT _exception) { |
return increment(); } } |
public int sum() { ... } |
Note: This code is created automatically by IDL->Java pre-compiler from the IDL spec and is a fragment of full stub that implements all methods |
There is a "base" server side Count object _CountImplBase which is used to implement by different extensions, both the skeleton and the actual object. |
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 _execute method of the org.omg.CORBA.portable.Skeleton object |
_execute is called with the methodId value that uniquely identifies a given method |
_execute is implemented as a switch which jumps to the appropriate method implementation |
the actual method execution is performed by CountImpl instance, passed as _self argument |
package Counter; |
abstract public class _sk_Count extends _CountImplBase { |
protected _sk_Count(java.lang.String name) { |
super(name); |
} |
protected _sk_Count() { |
} |
} |
Note: This code is created automatically by |
IDL->Java pre-compiler from the IDL spec |
This is generated automatically from IDL and is extended by both skeleton and example implementation template |
abstract public class _CountImplBase extends org.omg.CORBA.portable.Skeleton implements Counter.Count { |
public static boolean _execute(Counter.Count _self, int _method_id, org.omg.CORBA.portable.InputStream _input, org.omg.CORBA.portable.OutputStream _output) { switch(_method_id) { |
case 0: { |
int _result = _self.increment(); /* Increment and return result */ |
_output.write_long(_result); return false; } |
case 1: { |
int sum; |
sum = _input.read_long(); /* Set value of sum */ |
_self.sum(sum); return false; } ................. } |
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 Counter._CountImplBase { |
/** Construct a persistently named object. */ |
public _example_Count(java.lang.String name) { |
super(name); |
} |
/** Construct a transient object. */ |
public _example_Count() { |
super(); |
} |
Note: This code is generated by IDL->Java pre-compiler and needs to be |
completed by the developer (by implementing the indicated methods) |
public int increment() { // implement operation... return 0; } |
public void sum(int sum) { // implement attribute writer... } |
public int sum() { // implement attribute reader... return 0; } } // End _example_Count |
Implementer must complete these methods as CountImpl.java |
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 three foils |
Remember 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 |
public class CountImpl extends Counter._CountImplBase { |
private int sum; |
public CountImpl(java.lang.String name) { // Construct a persistent object. |
super(name); sum=0; |
System.out.println("Count Object Created"); } |
public CountImpl() { // Construct a transient object |
super(); } |
public int increment() { // Implementation of remote operation |
sum++; |
return sum; } |
public void sum(int val) { // implement attribute writer... |
sum = val; } |
public int sum() { // implement attribute reader... |
return sum; } |
} |
The main server program performs the following operations:
|
class CountServer |
{ static public void main(String[] args) |
{ try { // Initialize the ORB. |
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(); |
org.omg.CORBA.BOA boa = orb.BOA_init(); // Initialize the BOA. |
// Create the Coordinator object. |
CountImpl _count = new CountImpl("Counter"); |
boa.obj_is_ready(_count); // Export the newly created object. |
System.out.println("Exported " + _count); |
System.out.println("CountImpl waiting for requests"); |
boa.impl_is_ready(); } |
catch(org.omg.CORBA.SystemException e) |
{ System.err.println(e); } |
} } |
Note: This code is created by the developer |
public class |
CountClient extends Applet { |
................... Method to Initialize .................... |
private void connectToCountObject() { |
// Initialize the ORB. |
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(this); |
// Calculate Start time |
long startTime = System.currentTimeMillis(); |
counter = Counter.CountHelper.bind(orb, "Counter"); |
long stopTime = System.currentTimeMillis(); |
System.out.println("Avg time to setup Orblet = " |
+ ((stopTime - startTime)/1000f) + " secs"); |
} |
} |
The main client program is an applet (because we are using Visigenic which is supported by Netscape browser) and processes button clicks which include
|
Count.idl -- the IDL |
_st_Count.java the Stub |
_CountImplBase.java The Base Implementation |
_sk_Count.java The Skeleton |
_example_Count.java Example Server Side Object |
CountServer.java Server Side Manager |
CountImpl.java Server Side Count object |
CountClient.java Client program invoking remote Count object |
Generated by pre-compiler |
} |
Support for out and inout parameter passing modes requires the use of additional "holder" classes. |
These classes are available for all of the basic IDL datatypes in the org.omg.CORBA package and are generated for all named user defined types except those defined by typedefs. |
For user defined IDL types, the holder class name is constructed by appending Holder to the mapped (Java) name of the type. |
For the basic IDL datatypes, the holder class name is the Java type name (with its initial letter capitalized) to which the datatype is mapped with an appended Holder, e.g. IntHolder. |
Each holder class has a constructor from an instance, a default constructor, and has a public instance member, value, which is the typed value. |
The default constructor sets the value field to the default value for the type as defined by the Java language:
|
In order to support portable stubs and skeletons, holder classes for user defined types also have to implement the org.omg.CORBA.portable.Streamable interface. |
The holder classes for the basic types are illustrated on next foil. Note that they do not implement the Streamable interface. They are in the org.omg.CORBA package. |
package org.omg.CORBA;
|
The Holder class for a User defined type foo
|
All user defined IDL types have an additional "helper" Java class with the suffix Helper appended to the type name generated. |
Several static methods needed to manipulate the type are supplied. These include Any insert and extract operations for the type, getting the repository id (bind), getting the typecode, and reading and writing the type from and to a stream. |
For any user defined IDL type, the following is the Java code generated for the type. |
In addition, the helper class for a mapped IDL interface also has a narrow operation defined for it. |
public class fooHelper {
|
// only for interface helpers |
public static narrow(org.omg.CORBA.Object obj); |
} |
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) |
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
|
Middle Tier |
Basic Web Server |
Custom Web Server |
TP Server |
Business Transaction Management |
You Write Software |
at Client and Server |
Old and New Useful Backend Software |
Client Applet |
with JDBC and user (form) |
interface |
Oracle Database |
Java Socket |
Oracle Driver |
OCI |
Client with Applet Javabean |
Vendor Specific |
Object Broker |
Object |
Database |
IIOP |
Custom |
CORBA |
Within the Sun philosophy of '100% Java', distributed objects can be developed using RMI interconnect. However, the rest of the industry tries to protect their C++ investments while converting to Java in new applications. |
Hence, in parallel with Java development, the Web industry explores now the linkage of Java with CORBA based distributed object technologies which offer an full C++/Java interoperability. |
CORBA supports cross-language remote object invocation as well as IIOP (Internet Inter-ORB Protocol) based interoperability between object brokers from various vendors. |
Java is a wonderful language with which to develop object brokers |
Of particular interest are Java based ORBs or ORBlets which can be downloaded as applets to enable CORBA capabilities also at the client/browser side. |
An alternative, offered by Netscape, is a resident ORB support in all browser and server products. |
Java based ORBs will soon turn the Web, so far acting as a largely passive document publishing framework, into a powerful dynamic world-wide distributed object-based computing environment. |
This implies servers that combine role of Web Servers and object brokers and link HTTP RMI and IIOP protocols (and perhaps also COM!) |
The current incoherent but highly creative Web will merge with distributed object technology in a multi-tier client-server-service architecture with Java based combined Web-ORB's |
COM(Microsoft) and CORBA(world) are competing cross platform and language object technologies
|
Need to abstract entities (Web Pages, simulations) and services as objects with methods(interfaces) |
How do we do this while infrastructure still being designed! |
One can anticipate this by building systems in terms of Java objects e.g. develop Web-based databases with Java objects using standard JDBC (Java Database Connectivity) interfaces |
Even better use Javabeans which are Java's componentware offering visual interfaces, containers (here they are consistent with CORBA standard) and standard software engineering interfacing rules |
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
|
One expects Javabeans to become the CORBA component interface (defining containers in CORBA) |
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
|
CORBA is natural distributed object formalism |
Java (with visual interfaces i.e. JavaBeans) is natural interface language
|
Linking this to tier 3 "classic applications" gives rise to JavaBean/CORBA wrappers for existing applications |
This turns legacy applications into CORBA distributed objects and so can be remotely executed and documented (via CORBA trader or yellow pages service) |
Further these applications now have a visual interface for linking them together in containers and inspecting their parameters |
A 2 Tier implementation is shown above |
The CORBA wrapper uses IDL for language of original (legacy) application (use CORBA C IDL for Fortran) |
One designs an IDL to reflect "application class" and re-uses it for several elated applications |
Javabean frontend can be same for each application class |