Corba and Java

CORBA and Java
 by Alex Chaffee
 alex@jguru.com
 http://www.jguru.com/
 Java online resources
 http://www.purpletech.com/
 Java training and consulting
Copyright © 1998 Purple Technolog

Abstract
 CORBA loves Java! CORBA provides a platform-independent,
language-independent way to write applications that can invoke
objects that live across the room or across the planet. Java is
an object-oriented language that's ideal for writing the clients
and servers living on the Object Bus. In this session, we
examine the ways they interoperate programmatically, as we
walk you step-by-step from a CORBA IDL, to a server and client
both written in Java, running on top of a 100%-Java ORB. We
also discuss the relationship between CORBA and RMI, and
discuss some of the real-world issues involved in deploying a
CORBA-based application. Recommended: some knowledge of
CORBA, ability to read Java source code.

Introduction
 Purple Technology
 http://www.purpletech.com
 Java Training and Consulting
 Alex Chaffee
 Creator of Gamelan
 Cool Java Dude

Part I: CORBA Overview

y, Inc.
What is CORBA?
 Common Object Request Broker
Architecture
 Communication infrastructure for
distributed objects
 Allows a heterogeneous, distributed
collection of objects to collaborate
transparently

What is CORBA good for?
 Developing distributed applications
 Locating remote objects on a network
 Sending messages to those objects
 Common interface for transactions,
security, etc.
 CORBA Services (more later)

Why Distributed
Applications?
 Data is distributed
 Administrative and ownership reasons
 Heterogeneous systems
 Shared by multiple applications
 Scalability

Why Distributed
Applications?
 Computation is distributed
 Scalability: multiprocessing
 Take computation to data
 Heterogeneous architectures
 Users are distributed
 Multiple users interacting and
communicating via distributed applications

Distributed Object Systems
 All entities are modeled as objects

 Systems support location transparency
 Interfaces, not implementations, define
objects
 Good distributed object systems are
open, federated systems

What is the OMG?
 Designers of CORBA
 Consortium of 700+ companies
 Not including Microsoft
 Members:
 platform vendors
 database vendors
 software tool developers
 corporate developers
 software application vendors

It’s Just A Spec
 Has never been fully implemented
 Probably never will be
 Industry moves quickly and spec has to
keep up
 Interoperability vs. portability
 Pass-by-value

Basic CORBA Architecture
Client Server
request response
ORB ORB
“Object Bus”

CORBA Objects
 Examples
 Service
 Client
 Component
 Business object
 CORBA objects approach universal accessibility
 Any Language
 Any Host on network
 Any Platform

CORBA Elements
 1. ORB
 2. CORBA Services
 3. CORBA Facilities
 4. Application Objects

ORB
 Object Request Broker
 “Object Bus”
 Handles all communication among
objects
 Each host (machine) has its own ORB
 ORBs know how to talk to each other
 ORB also provides basic services to client

ORB Responsibilities
 Find the object implementation for the
request
 Prepare the object implementation to
receive the request
 Communicate the data making up the
request
 Retrieve results of request

Network of ORBs
 There’s an ORB on the server too
 ORB receives request

IIOP
 Internet Inter-Orb Protocol
 Network or “wire” protocol
 Works across TCP/IP (the Internet
protocol)

ORB Features
 Method invocations
 Static and Dynamic
 Remote objects or CORBA services
 High-level language bindings
 Use your favorite language; ORB translates
 Self-describing
 Provides metadata for all objects and services

ORB Features
 Local or remote
 Same API wherever target object lives
 Preserves context
 Distributed security and transactions
 Coexistence with legacy code
 Just provide a wrapper object

What is an ORB really?
 Not a separate process
 Library code that executes in-process
 Listens to TCP ports for connections
 One port per local object
 Opens TCP sockets to other objects
 N ports per remote machine

IDL
 Interface Definition Language
 Defines protocol to access objects
 Like a contract
 Well-specified
 Language-independent

IDL Example
module Calc {
interface Adder {
long add(in long x, in long y);
}
}
 Defines an object called Adder with a
method called add

Stubs and Skeletons
 Stub
 lives on client
 pretends to be remote object
 Skeleton
 lives on server
 receives requests from stub
 talks to true remote object
 delivers response to stub
Copyright © 1997 Alex Chaffee

Stubs and Skeletons (Fig.)
Client Host Machine Server Host Machine
Client Remote
Object Object
Stub Skeleton
ORB IIOP ORB

Client vs. Server
 in CORBA, a client is a client relative to a
particular object
 i.e. an object with a reference to a “server”
object
 A client may also act as a server
 If it has an IDL and stubs and skeletons
 Technically, a CORBA server contains
one or more CORBA objects
Different Meanings of
“Server”
 Host machine
 Program running on host machine
 CORBA object running inside program
 has IDL, stub, skeleton
 Sometimes called a Servant

Stubs and Skeletons ->
Platform Independence
 Client code has no knowledge of the
implementation of the object or which ORB
is used to access the implementation.

CORBA Services
 APIs for low-level, common tasks
 Life Cycle Service
 creating, copying, moving, removing
objects
 Naming Service
 Register objects with a name
 Look up objects by name

CORBA Services
 Concurrency Control Service
 Obtain and release exclusive locks
 Transaction Service
 Two-phase commit coordination
 Supports nested transactions
 Persistence Service
 Storing objects in a variety of databases
 RDBMS, OODBMS, file systems

CORBA Services
 Security Service
 Authentication, ACLs, encryption, etc.
 Event Service
 Uncoupled notifications

CORBA Services
 Relationship
 Externalization
 Query
 Licensing
 Properties
 Time
 Trader
 Collection
 … and so on…
 See what I mean about it never being
implemented?

CORBA Facilities
 Frameworks for specialized applications
 Distributed Document Component Facility
 OpenDoc
 In progress:
 Agents
 Business Objects
 Internationalization

N-Tier Design with CORBA
Storage “Tier”
DB
ORB ORB
ORB ORB
DB
Data Object
ORB
ORB
TP Monitor
ORB
ORB
ORB
Service “Tier”
Business Object
Client Tier Tier
(after diagram in Orfali et al.)
Three Tiers
 User Interface Tier
 Business Logic Tier
 Data Storage Tier
 Can use CORBA objects in each tier

Part II: Java IDL - Using
CORBA from Java

y, Inc.
Java CORBA Products
 The Java 2 ORB

 VisiBroker for Java
 OrbixWeb
 Netscape Communicator
 Various free or shareware ORBs

Java IDL
 Should be named “Java CORBA”
 More than just IDL
 Full (?) implementation of CORBA in 100% Java
 Three Parts
 ORB
 Naming Service
 idltojava compiler
 Ships with JDK 1.2

Transparent API
 JavaIDL turns IDL into direct method
calls
 Easy to program
 Clients have no knowledge of
implementation
 Highly portable

The Java ORB
 100% Java
 Generic
 Allows Java IDL applications to run
either as stand-alone Java applications,
or as applets within Java-enabled
browsers
 Uses IIOP

Other Java ORBs
 Visigenic (Inprise) VisiBroker
 Netscape Communicator
 Oracle Web Server 3.0
 Free download
 Iona OrbixWeb

IDL to Java Mapping
 Defined by OMG
 Translates IDL concepts into Java
language constructs
 Everything is accessible by writing
normal-looking Java code

IDL to Java Type Mapping
IDL Type Java Type
boolean boolean
char / wchar char
octet byte
short / unsigned short short
long / unsigned long int
long long / unsigned long long long
float float
double double
string / wstring String

IDL vs. Java vs. C++
concepts
IDL Java C++
module package namespace
interface interface abstract
class
operation method member
function
attribute pair of pair of
methods functions

IDL Modules
 Map to Java packages
 Unfortunately, it has the root level name of
the module
 Clutters up your package hierarchy
 e.g. module Calc ->
 package Calc
 interface Calc.Adder
 not package ORG.omg.CORBA.modules.Calc

IDL Interfaces
 Map to Java interfaces

IDL Operations
 Map to Java methods

IDL Attributes
 Map to pair of functions
 IDL
 string name;
 Java
 public void name(String val);
 public String name();
 Yes, it looks stupid. Sorry.

idltojava
 Development tool
 Automatically generates java stubs,
skeletons, helpers, holders, ...
 Generates stubs for specific remote
interfaces

Stubs
 Java objects call stub methods
 Stubs communicate with CORBA
objects
 and vice versa
 Transparent integration

Skeletons
 ORB passes request to skeleton (like a
stub)
 Skeleton calls local implementation

Remote Interfaces and
Stubs
IDL Interface
implements implements
extends
Remote Object
Client Stub Skeleton
(Server)

Show Me The Source Code
 OK, here it comes...

idltojava input
 Calc.idl
module Calc {
interface Adder {
long add(in long x, in long y);
}
}

idltojava output
 idltojava Calc.idl
 Adder.java (a Java interface that maps
the IDL interface)
 _AdderStub.java (a client stub)
 _AdderImplBase.java (a server skeleton)
 AdderHelper.java (a helper class)
 AdderHolder.java (a holder class)
 Must compile these files and put them in
your CLASSPATH

Adder.java
 Created for you by idltojava
package Calc;
public interface Adder
extends
org.omg.CORBA.Object {
int add(int x, int y);
}

Implementing a server
 Extend base class
 Implement all methods declared in IDL
 Provide a main method
 Create an ORB instance
 Create a server instance
 Inform the ORB about the instance
 Acquire a Naming Context
 Register the instance in that Naming Context
under some name

AdderServer.java
class AdderServer extends _AdderImplBase
{
public int add( int x, int y ) {
System.out.println(x + " + " + y + "
= " + (x+y));
return x + y;
}

AdderServer.java (cont.)
public static void main(String args[]) {
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// create server and register it with
the ORB
AdderServer adderRef = new
AdderServer();
orb.connect(adderRef);

AdderServer.java (cont.)
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef =
NamingContextHelper.narrow(objRef);
// bind the Object Reference in Naming
NameComponent nc = new NameComponent("Adder",
"");
NameComponent path[] = {nc};
ncRef.rebind(path, adderRef);
}

Implementing a client
 Create an ORB
 Get a reference to the Naming Context
 Look up the correct name in that Naming
Context
 Receive an object reference to that object
 Actually, to its Stub
 Invoke methods on the reference

AdderClient.java

Object Reference
 Two Meanings
 1. An abstract concept referring to a specific object
living on a specific host, attached to a specific ORB
 2. A local Java reference to an object that relays
messages to that object
 Obtained from
 new keyword
 a Factory Object
 the Naming Service

Naming Service
 tnameserv
 t is for “transient”
 Maps name to object reference
 An implementation of the CORBA Object
Service (COS) name service
 to run the Naming Service
 UNIX: tnameserv &
 Win32: start /m tnameserv

Fire it up
 start /m tnameserv
 start java AdderServer
 java AdderClient
 2+2=?

CORBA Flow
Client Virtual Machine Server Virtual Machine
Client Remote
Object
Stub Skeleton
Server
“Fred”
Name Server Virtual Machine Copyright © 1997 Alex Chaffee

CORBA Flow
1. Server Creates Remote Object
2. Server Registers Remote Object
Client Remote
Object
1
Stub Skeleton
Server
“Fred”

CORBA Flow
Client 3. Client requests object fromRemote
Name Server
4. Name Server returns remote reference
Object
(and stub gets created)
Stub Skeleton
Server
3 4
“Fred”

RMI Flow
Client Remote
Object
5 7
6
Stub Skeleton
Server
5. Client invokes stub method

6. Stub talks to skeleton
7. Skeleton invokes remote object
method “Fred”

Pseudo-objects
 The ORB is a pseudo-object
 It works just like a remote object, only
it’s local

The Basic Object Adapter
(BOA)
 Another pseudo-object
 Helps register objects with the ORB
 Functions
 Maintain Implementation Repository
 Generate and interpret object references
 Activate and deactivate implementation
objects
 Invoke methods via skeletons

Why do you need both an
ORB and a BOA?
 I’m not really sure
 Allows vendors to optimize or enhance
functionality
 register many objects en masse
 cache object state elsewhere
 E.g. Object database

Using the BOA
 Slightly different procedure for initializing
objects
 Hides name service from you
 Ask the BOA to register the object
 Ask the Helper object to bind the object
 Once the object is created, interface is
identical
 Just call methods using normal Java syntax

BOA Object Activation
 Shared server
 Multiple objects, one server
 Normal procedure
 Multithreaded (handled by CORBA
implementation)
 Unshared server
 New process for each object

(cont.)
 Server-per-method
 Batch processing
 Persistent server
 Shared server, but object not created by
ORB

Scenario
 Server creates object instance
 obj = new MyObject();
 Server registers object with BOA
 boa.create(interface_name,
implementation_name, reference_data)
 VisiBroker does this for you in superclass
constructor

Scenario (cont.)
 Server tells BOA the object is ready
 boa.obj_is_ready(obj)
 Server tells BOA that all objects are ready
 boa.impl_is_ready()
 Objects shut down
 boa.deactivate_obj(this)
 Server shuts down
 boa.deactivate_impl()

Threads in JavaIDL
 Remote invocations happen on a
separate thread
 Must make sure your remote objects
are thread-safe

Callbacks
 Pass in a reference to some CORBA
object
 The server object can invoke methods on
that reference
 ORB automatically generates a stub on
the server side
 The server has become the client, and
vice versa
Obtaining Object
References
 From the ORB
 orb.resolve_initial_references(“NameService
”)
 From a Naming Context
 From a Stringified reference
 From another object
 From a parameter to your remote method

Helper Objects
 How CORBA does casting
 narrow method changes the type of an
object reference
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameSer
vice");
NamingContext ncRef =
NamingContextHelper.narrow(objRef);

Naming Contexts
 Directory structure for CORBA
 Naming Component = file
 Naming Context = directory
 Can add a Context as a Component
 like subdirectories
 Can add a Context on a different name
server
 like symbolic links

Stringification
 Stringified reference is ORB-independent
 Object to string
org.omg.CORBA.Object obj = ...
String str = orb.object_to_string(obj);
 String to object
 org.omg.CORBA.Object obj =
orb.string_to_object(str);

Visigenic: Caffeine
 Java to IDL compiler

Symantec: Visual Café 3.0
Enterprise Suite
 Java to IDL compiler
 Automatic client adapter bean generation
 Makes a JavaBean that’s a proxy to a
CORBA object
 Distributed debugging
 Follow call chain, examine variables, et al.
 Across many VMs, many hosts, many OSs

Part III: Example
Application

Publish-Subscribe System
 Channel: an avenue for real-time data
exchange
 Consumers can subscribe to arbitrary
data channels
 Producers can publish data on channels
 Invokes callback method on consumer

Object Model
 PSServer
 Channel getChannel(String channelName)
 creates channel if it doesn’t already exist
 Channel
 void subscribe(Subscriber sub)
 void publish(Object data)
 Subscriber
 void dataArrived(Object data)

Flow: Subscriber-side
 Client acquires PSServer reference
 Client acquires channel from PSServer
 Client creates subscriber locally, passing
reference to channel
 Subscriber registers self with channel
 channel.subscribe(this)
 Client waits for callback to its dataArrived
method

Flow: Publisher-side
 Client acquires PSServer reference
 Client acquires channel from PSServer
 Client creates publisher locally, passing
reference to channel
 Publisher acquires data
 From a database
 From a data feed
 Publisher calls channel.publish(data)
Example Application: Stock
data
 Channel name = stock symbol name
 Source code available

Design issues
 Name space for channels
 TIBCO et al. use hierarchical directory
structure
 Caching prior messages
 Subscribe should spawn a thread that
sends previous N messages

Design issues
 Maintain local cache of data sent
 Don’t want to go back across the network
every time you draw a graph
 Create local version of class

Part IV: Advanced Topics

Exceptions
 CORBA exceptions are mapped to Java
exceptions
 System Exceptions
 They’re subclasses of RuntimeException, so the
compiler won’t complain if you forget to catch them
 Minor codes
 additional information
 vendor-specific :-(
 Completion Status

Exceptions (cont.)
 User Exceptions
 Generated by idltojava
 Subclasses of Exception (declared)

Dynamic Invocation Interface
(DII)
 CORBA is fully self-aware
 Methods for acquiring
 List of all services
 List of known objects
 Interfaces of known objects
 Etc.
 Well-documented elsewhere

Interface Repositories
 JavaIDL clients do not typically need or
use an Interface Repository
 All of the needed type information is
available in the stubs or is resolved by an
object's server
 JavaIDL supports access to Interface
Repository information made available by
other CORBA object implementations.
Implementation Repository
 contains information that allows the ORB to
locate and activate implementations of
objects
 also store additional information associated
with implementations of ORB objects.
 Debugging information
 Administrative control
 Resource allocation
 Security

Value Objects
 CORBA 3.0
 Blobs
 Avoids network latency of pass-by-
reference objects

RMI over IIOP
 In Development
 Uses IIOP as transport protocol
 Uses Value Objects to pass Java
serialized objects

CORBA via RMI
 Possible using middleware server
 RMI from client to middleware
 IIOP from middleware to other servers
 Can use Servlet as middleware

CORBA and EJB
 Transport
 EJB uses RMI interface, RMI uses IIOP
 CORBA 3.0 promises object
compatibility with EJB
 Not quite sure what that means
 Some EJB Servers contain an ORB
 All EJB Objects are also CORBA objects

CORBA and EJB (Cont.)
 All EJB Servers use CORBA
Transactions (via JTS)
 That means that any client can make a
distributed transaction that includes both
CORBA and EJB Objects
 Not an either-or decision
 You can have both EJB and CORBA
working together in a single system

Java Transactions
 Java Transaction Service (JTS)
 A standard Java mapping of the OMG Object
Transaction Service (OTS)
 packages org.omg.CosTransaction and
org.omg.CosTSPortability
 Java Transaction API (JTA)
 High-level transaction management specification
 package javax.transaction
 class UserTransaction

Object Transaction Service
(OTS)
 Distributed transaction specification
 Part of CORBA, but also standalone
 Transactions can span
 multiple queries
 multiple objects
 multiple servers
 multiple databases
 multiple vendors’ products

OTS Features
 Distributed transactions
 Flat or nested transactions
 Two-phase commit
 Vendor interoperability (?)

OTS Object Model
 Transactional Object
 Can participate in a transaction
 Recoverable Object
 Actually performs commit or rollback on its own data
 Resource
 A system or server that can commit or rollback data
stored inside it
 E.g. a database server

OTS Object Model (Cont.)
 Current
 Reference/wrapper to currently active transaction
 Control / Coordinator / Terminator
 Registers objects
 Performs distributed commit/rollback
 Synchronization
 An object that gets informed of the progress of the
ongoing transaction
 Implements callback methods

Part V: CORBA/Java Case
Studies

y, Inc.
CORBA Case Study
 Kaiser Permanente Northern California
 KAHUNA a/k/a WebChart
 http://www.javaworld.com/jw-11-
1998/jw-11-kaiser.html?101698txt

Problem: Specific
 Medical records, patient histories, clinical
schedules, lab results, and medical
images all stored in disparate databases
 Many patients per doctor, many doctors
per patient
 Need immediate access to all
information

Problem: General
 getting data
 from a multitude of sources
 in a multitude of media
 putting data
 into a single system
 distributing data
 to a wide variety of desktops
 throughout a very large company

Solution: Java/CORBA
 “Not only did Java/CORBA solve all
these problems, but Java/CORBA
development is cheap, fast, scalable
and works over the Internet.”

WebChart Architecture

This is your brain on Java.
Any questions?

Conclusion

y, Inc.
Where to Get More
Information
 Orfali & Harkey, Client/Server Programming with
Java and CORBA (Wiley)
 Orfali, Harkey & Edwards, Instant CORBA (Wiley)

More Info: Links
 This Presentation
 http://www.purpletech.com/
 JDK 1.2 CORBA documentation
 http://java.sun.com/products/jdk/1.2/docs/guide/idl/
 Glerum, WebChart serves up Kaiser patients,
JavaWorld
 http://www.javaworld.com/jw-11-1998/jw-11-kaiser.html?
101698txt

More Info: Links
 Object Management Group - http://www.omg.org
 Java Transactions
 http://java.sun.com/products/jta/
 http://java.sun.com/products/jts/
 ftp://www.omg.org/pub/docs/formal/97-12-17.pdf

Corba and Java

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Corba and Java

Uploaded by

Copyright:

Available Formats

CORBA and Java

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

 All entities are modeled as objects

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1997 Alex Chaffee

ORB IIOP ORB

Copyright © 1997 Alex Chaffee

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

 The Java 2 ORB

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1997 Alex Chaffee

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog

Copyright © 1998 Purple Technolog