CORBA, DCOM and Java

1
CORBA, DCOM and Java
V. Juggy Jagannathan CareFlowNet, Inc.
2
CORBA

• Distributed Object Infrastructure

3
References

• Robert Orfali, Dan Harkey, Client/Server
  Programming with Java and CORBA, Second Edition.
  John Wiley and Sons, 1998.
• Andreas Vogel and Keith Duddy, Java Programming
  with CORBA, Second Edition, Advanced Techniques
  for Building Distributed Applications, John
  Wiles and Sons, 1998.
• John Siegal (written and edited by), CORBA
  Fundamentals and Programming, John Wiley and
  Sons, 1996.

4
Outline

• Overview
• CORBA 1.1, 2.0, 3.0
• IDL and Interface Repository
• CORBA services

5
Background

• Not-for-profit company based in United States,
  with representation in Italy, United Kingdom,
  Germany, Japan, Australia India.
• Founded April 1989.
• Small staff (35 full time) no internal
  development.
• Almost all technical work done by engineers in
  member companies
• Almost 800 members (4/98)

Viewfoil courtesy OMG http//www.omg.org/librar
y/diego.ppt
6
Worldwide Scope
Andersen APM Alta AITECH ATT BaaN Bull British
Telecom Bankers Trust
Data Access Eurocontrol EDS Ericsson FinSiel Fujit
su Genesis HP Harlequin
ICL Informix Intel IBM IONA Tech. Microsoft MITRE
Netscape
Sun Microsystems Sybase Thomson CSF Telecom
Italia Telefonica Telia AB TRW Unisys Valtech.
Nortel Novell OHRA Insurances Oracle Open
Group POSC Sodalia Siemens Nixdorf Software AG
Viewfoil courtesy OMG http//www.omg.org/librar
y/diego.ppt
7
Adoption Process

• RFI (Request for Information) to establish range
  of commercially available software.
• RFP (Request for Proposals) to gather explicit
  descriptions of available software Architecture
  Board approves.
• Letters of Intent to establish corporate
  direction.
• Task Force evaluation recommendation
  simultaneous evaluation by Business Committee.
• Architecture Board consideration for consistency.
• Board decision based on recommendations from the
  appropriate Technology Committee Business
  Committee.
• Fast Track Process.

Viewfoil courtesy OMG http//www.omg.org/librar
y/diego.ppt
8
Integration Technology - CORBA

• The Common Object Request Broker Architecture is
  the standard adopted by OMG as a framework to
  provide common ORB services and interfaces to
  support portable clients and services.
• The Object Request Broker (ORB) provides the
  mechanisms by which clients transparently make
  requests and receive responses.

9
CORBA (continued)

• Advantages offered by CORBA
• architecture independence
• language independence
• location independence
• The standard specifies the Interface Definition
  Language (IDL) - language used to describe the
  interfaces that client objects call and object
  implementations provide.

10
De-facto Standards and products available
Viewfoil courtesy OMG http//www.omg.org/librar
y/diego.ppt
11
The Evolution of CORBA

• CORBA 1.1 (1992)
• Basic ORB, IR, BOA, C Bindings, Naming, Events,
  Lifecycle etc.
• CORBA 2.0 (1995)
• IIOP, Federated IR, C Bindings, Transactions,
  Concurrency, Externalization, Relationships,
  Query, Licensing, Trader, Security, Collections,
  Time etc.
• CORBA 3.0 (1999)
• Messaging (MOM), Server Portability (POA),
  Business Objects (JavaBeans), Java Bindings,
  Objects-by-value, CORBA/DCOM, IIOP Firewall,
  Workflow, Domain-level Frameworks, Mobile Agents
  etc.

Adapted from Orafali and Harkeys Book
12
ORB services

• Multiple language bindings - C, C, Java,
  Smalltalk, Ada, Cobol
• Interface Repository stores the interface
  specifications of all services
• Transparency of object location

13
ORB services - Contd

• Object-oriented - provides for encapsulation,
  polymorphism and inheritance
• Can provide security for content and
  context-sensitive transactions

14
Common Object Service Specification 1(COSS1)

• Life cycle service - for instantiating, copying,
  moving and deleting objects
• Persistence service - interface for storing
  objects - relational and OODBMS backends -
  Deprecated.
• Naming service - to locate using OSF DCE, Sun NIS
  or X.500 naming conventions. Can work with
  Internet standards such as LDAP.
• Event Service - dynamically register interest in
  events - using a global object called event
  channel

15
COSS2

• Concurrecny control service - to provide for
  locking
• Transaction service - to provide for two-phase
  commit coordination
• Relationship service - to connect and group
  multiple objects
• Externalization service - to export and
  interchange data

16
COSS3

• Security
• Time management

17
CORBA Architecture
Servers
Server
Clients
Service
IDL-based
ORB
18
COSS4

• Query service - it is a superset of SQL based on
  the Object Database Management Group (ODMG)
• Licensing service - to support metering and
  support for payment for use of components
• Properties service - to associate dynamic
  properties with components

19
COSS5

• Trader
• Collections
• Change management

20
Common Facilities

• Horizontal facilities - useful across different
  application domains
• Vertical facilities - targeted support for
  specific domains such as healthcare, finance and
  retail

21
Horizontal Common Facilities

• User Interface - in place editing service such as
  provided by OpenDoc and OLE
• Information management service - compound
  document storage and data interchange facilities
• Systems management services - that manage,
  instrument and configure objects
• Task management services - workflow, long
  transactions, agents, scripting, rules

22
CORBA 2.0

• Adds multivendor ORB interoperability to CORBA
  1.1 specifications adopted in 1991
• An ORB mediates requests for services from
  client applications and service providers

23
Client/Server Request Using the ORB 2.0
24
Client IDL Stubs

• Provides local proxies for remote services
• Provides for marshaling of parameters into
  standard formats

25
Dynamic Invocation Interface

• Late binding of method calls
• Run time discovery of service IDL interface

26
Interface Repository

• Runtime database of interfaces of all registered
  objects
• Supports the query of, registration of, and
  update of interfaces of objects mediated by the
  ORB
• Repository IDs - uniquely and globally identify
  interface repository across multivendor ORBs

27
ORB Interface

• Provides for API that provide a number of
  utilities
• Object-to-string converts object reference to a
  string
• String-to-object converts a string reference to
  object
• get-interface to find the location of interface
  repository for a given object
• get-implementation to find the reference to
  implementation repository of an object

28
Server IDL Stubs

• Also called skeletons
• provide static interfaces to each service
  provided
• both client side and server side stubs are
  generated using IDL compilers

29
Dynamic Skeleton Interface (DSI)

• to implement dynamic services or dynamically
  changing services
• run-time binding of new services using scripting
  languages and interpreters
• to redirect messages to objects for which a
  compiled idl-interface is not known

30
Object Adapter

• responsible for managing a collection of server
  objects
• instantiates server objects when needed and
  provides them with object IDs called object
  references
• registers the classes and instances in the
  Implementation Repository
• All CORBA implementations must support a Basic
  Object Adapter

31
Implementation Repository

• Keeps track of classes and run-time instances of
  server objects supported by the ORB
• Allows for mechanisms to support audit trails,
  trace information and security related
  infrastructure

32
Using the Static interface

• Definition of object services using IDL
• Precompiler generates server and client stubs
• Implementation code added to the server stubs
• Compilation client stubs, server stubs, code
  that implements server classes and code to
  describe the classes to Interface Repository
• Register with Interface Repository
• Instantiate server objects
• Register run time instances with Implementation
  Repository

33
Using the Dynamic interface

• Lookup service name and get its interface
  specification from Interface Repository
• Put together a request made up of object
  reference, method name and argument list
• Invoke the method call on the desired object

34
Basic Object Adapter

• Must provide for the following functionality
• An implementation repository
• Manage instantiation and destruction of objects
• Manage object references and invoking methods
• Mechanism to authenticate clients

35
BOA Object Activation Alternatives

• Shared Server First time call to any object
  causes the server process to startup. Future
  requests are handled by the server directly. BOA
  notified with impl_is_ready and deactivate_impl.
• Unshared Server A new server process is started
  to support each object requests.
• Server-per-method A new server process is
  started for each request made (method call).
• Persistent server Servers are persistent and
  started independently.

36
CORBA 2.0 Interoperability Standard

• CORBA 1.1 allowed for portability
• CORBA 2.0 specifies the Internet Inter-ORB
  Protocol (IIOP)
• Public domain IIOPs are now available (from Sun
  for instance)
• Every CORBA-compliant ORB must implement IIOP or
  provide a half bridge to it

37
General Inter-ORB Protocol (GIOP)

• Common Data Representations (CDR) used in
  communications
• CDR maps data types defined using IDL into a flat
  representation for use in network layer
• CDR takes care of inter-platform issues such as
  byte ordering
• Specifies Interoperable Object References for use
  in multi-vendor ORB environments

38
Internet Inter-ORB Protocol (IIOP)

• Standardizes the way GIOP messages can be
  exchanged using TCP/IP
• Mandatory for CORBA 2.0 compliance

39
Environment-Specific Inter-ORB Protocols (ESIOPs)

• Example is DCE/ESIOP
• GIOP CDR-based messages defined using OMG IDL are
  transported using DCE RPC using DCE native
  Network Data Representation (NDR)

40
ORB-to-ORB Bridging
Server
Client
DII
DSI
ORB From Vendor A
ORB From Vendor B
41
IDL and Interface Repository

• Interface Definition Language (IDL) fundamental
  mechanism supported by all ORBs to separate
  interfaces and implementations
• Interface Repository is a queriable and
  updateable runtime information store of interface
  specification generated from IDL

42
IDL users

• Client programmers who want to access the
  services provided by an object - they need the
  IDL to determine how to call the services
• Server programmers who want to extend the service
  provided - they need the IDL to subclass and
  provide additional capabilities

43
IDL Structure

• Module groups a collection of class definitions
  (interfaces)
• Interface defines a class attributes and
  exceptions
• Operation defines a method the arguments
  argument types in, out or in-out exceptions
  optional context description
• Data types basic (short , float, char...) and
  constructed

44
IDL Example type codes

• typedef string Date_T
• typedef string PersonID_T
• typedef string Address_T
• typedef char MaritalStatus_T
• typedef char Sex_T
• typedef long PolicyID_T

45
IDL Example Interfaces

• interface FamilyMember
• interface Employer
• interface InsurancePolicy
• interface InsuranceCompany

46
IDL Example Interface definition

• interface Demographics PRObject
• readonly attribute PersonID_T personID
• attribute string
  lastName
• attribute string
  firstName
• attribute long
  SSN
• attribute Date_T DOB
• attribute string
  birthPlace
• attribute MaritalStatus_T
  maritalStatus
• readonly attribute sequenceltInsurancePolicygt
  insurancePolicies
• readonly attribute sequenceltFamilyMembergt
  familyMembers
• readonly attribute sequenceltEmployergt
  employers

47
IDL Example Interface definition

• interface InsurancePolicy PRObject
• readonly attribute PolicyID_T policyID
• attribute string
  insuranceType
• attribute string
  carrierProgram
• attribute long
  groupNo
• attribute long
  payorNo
• attribute long
  controlNo
• attribute string
  relationshipToPolicyHolder
• readonly attribute Demographics
  policyHolder
• readonly attribute InsuranceCompany
  insuranceCompany

48
Type Codes

• represent IDL-defined data types
• provide for self-describing data
• Used by DII, IIOP, Interface Repositories and
  any data type

49
Interface Repository - where used

• Run-time type checking on method invocation
  parameters
• Connecting multi-vendor ORBs
• Support dynamic discovery of object interfaces
  and support for DII
• Provide for self-describing objects

50
CORBA 3.0

• Trader Service
• POA
• Workflow
• Business Objects Facility
• CORBA Component Model
• CORBA Scripting Language
• IIOP over firewall

• Java to IDL mapping
• Real-time CORBA
• Asynchronous Messaging
• Domain-specific frameworks
• Manufacturing, Transportation, Finance,
  Healthcare, Telecom, Electronic Commerce
• and more!

See http//www.omg.org/news/pr98/9_9.htm for a
press release on CORBA 3.0 by major vendors for
an early 1999 commercial availability.
51
Trader Service

• Naming Service is like white pages
• Trader is like yellow pages

Trader
Server Exporter
Export Service
Import Service
Invoke Service
52
Portable Object Adapter (POA)

• To quote Orafali Harkey The POA is simply the
  BOA done right.
• Similar to BOA, POA supports management of
• separate process for each method
• separate process for each object
• shared process for multiple objects
• In addition, POA supports the notions of
• servants and servant managers (instance managers)
• transient and persistent servants and instances
• Essentially addresses scalability and flexibility
  in server implementations

53
CORBA/Java Security

• Reference Andreas Vogel Keith Duddy, Java
  Programming With CORBA, Second Edition, John
  Wiley Sons, 1998.

54
Applet Security Issues

• Java Virtual Machine for applet execution are
  restricted in their ability to access local
  resources - referred to as applet sandboxing.
• Applets are only allowed to communicate with the
  server they are downloaded from
• CORBA clients can in principle communicate with
  any object for which there is an IOR reference.
• Two approaches have been identified to address
  applet security restrictions.

55
Working with Applet Security restrictions

• Establish an IIOP gateway which serves as a proxy
  to the real server
• Use signed applets

Server Implementation
Download Applet
IIOP
IIOP
56
Firewalls

• Firewalls restrict and filter network traffic
• In a client-server environment, in the general
  case, there may be a client-side and a
  server-side firewall involved.

57
Types of firewalls

• Origin/Destination Filtering - router-based
• filtering based on IP address of target and
  specific port numbers on that address
• filtering based on IP addresses of specific set
  of source machines
• Gateway firewall
• A machine with dual network cards - one connects
  to Internet and the other to Intranet.
• Only way for packet traffic to bridge the two
  networks is a protocol-specific bridge that
  forwards packets to the appropriate applications

58
Client-side firewalls
Browser
Client-side Firewall
Server Implementation
Client Applet
Port 80
HTTP
Gatekeeper
IIOP
IIOP
Gatekeeper with dual functionality
59
IIOP over Secure Socket Layer (SSL)

• SSL is layered on top of TCP/IP
• It is the basis for secure electronic commerce
  over the Web - using Secure HTTP (SHTTP)
• SSL authentication is based on public key
  cryptography
• Authentication is based on digitally signed
  certificates.

60
Digital Signature - Concept
Signature Validation
Compare
61
Overview of CORBA Security Service
62
Goals of a security service

• Confidentiality
• Integrity
• Accountability
• Availability

63
Sample threats to security

• An authorized user accessing information they
  should not
• A user pretending to be someone else to access
  information
• Eavesdropping on others communication
• Modifying, deleting or maliciously tampering with
  information

64
Features of the Security Service

• Identification and authentication
• Authorization and access control
• Auditing
• Communications security
• Non-repudiation
• Administration of security policy

65
Security Conformance Levels

• Security Level 1 - targeted at securing
  security-unaware applications. Allows for client
  authentication, secure communications and
  method-level access control based on security
  policies.
• Security Level 2 - supports all of the above and
  supports integrity, trust and auditing. Targets
  security-aware application which may enforce
  their own policies.

66
CORBA World Players

• Netscape (bundle CORBA-clients with their web
  browser)
• Oracle has adopted CORBA/Java as their base
  platform
• JavaSoft - is layering RMI on top of CORBA IIOP.
  Sun has also adopted Visibroker as its ORB
  technology.
• IBM/Lotus Adopted base infrastructure is
  CORBA/Java.

67
CORBA World Players - Others

• Iona
• Visigenic/Inprise
• HP
• Tandem
• Novell
• I-Kinetics
• Expersoft
• BEA

• Symantec
• ParcPlace
• Penumra
• Inprise
• Sybase
• NetDynamics
• Vignette
• Allaire
• and 800 more!

68
Distributed Component Object Model (DCOM)

• Microsoft Version of Distributed Object Computing

Material for this tutorial is based on Orafali
and Harkey book on Client Server Programming with
Java and CORBA and Richard Grimes book on DCOM
Programming.
69
DCOM and CORBA

• Like CORBA, DCOM adheres to separation of
  interface from implementation using Microsoft
  Interface Definition Language (IDL) based on DCE.
  Not compatible with CORBA IDL.
• Also provides an additional IDL for OLE
  automation called Object Definition Language
  (ODL).

70
DCOM

• Unlike CORBA, DCOM does not support multiple
  inheritance. It supports multiple interfaces and
  compositional architectures.
• Like CORBA, DCOM provides both static and dynamic
  bindings for methods
• Type Library in DCOM corresponds to Interface
  Repository in CORBA.
• DCOM registry corresponds to Implementation
  Repository.

71
DCOM Interface

• DCOM Interface is collection of method calls.
• DCOM interface is language neutral
• Microsoft provides language bindings for Visual
  C, Visual Basic, and Visual J.
• Inprise s Delphi products provide bindings for
  Pascal.

72
DCOM Interface

• To access DCOM interface, clients use pointer to
  an array of function pointers - called virtual
  table or vtable.

73
DCOM Conventions

• Plug-in-jack pictorial representation of
  components.
• Interface by convention is named with a letter
  beginning with capital I - e.g. IDispatch
• At run time, interfaces are known by their
  Interface Identifier (IID)
• IID is globally unique (GIID) - 128-bit IDs.

74
DCOM Object

• Also known as ActiveX object.
• DCOM object implements all the interfaces the
  object supports.
• Identified by a unique 128-bit Class ID (CLSID)
• Implements IUnknown interface

IUnknown
Interface A
DCOM Object
Interface B
Interface C
75
DCOM Server

• DCOM servers is a DLL or EXE or a Java Class.
• Server must provide a class factory for
  instantiating new objects
• IClassFactory2 interface needs to be supported if
  object is instantiated only if a valid license
  file is present

76
DCOM Local/Remote Transparency

• In-process servers server DLLs that can be
  loaded in the same process as the client.
• Local servers clients use DCOMs Lightweight RPC
  (LRPC) to communicate with server running on a
  different process space in the same machine.
• Remote servers clients use DCE RPC-like
  mechanisms to make method invocation.

77
DCOM IUnknown Interface

• IUnknown Interface consists of
• QueryInterface - for supporting interface
  negotiations
• AddRef - to support garbage collection
• Release - to support life cycle management

78
DCOMs Dynamic Invocation Facilities
79
Writing a Java Client/Server Application in DCOM
2. Generate GUIDs
1. Create DCOM IDL
3. MIDL
Summary.txt
4. JavaTLB
Interface
Class Proxy
Interface
5. Implement Server
8. Implement Client
6. jvc
9. jvc
10. JavaReg
7. JavaReg
11. jview
Server
Client
80
DCOM Conclusions

• DCOM is maturing rapidly
• Java support is there, although it is for
  Microsoft version of Java
• Biggest differences with CORBA
• Support limited to Wintel platforms
• Range of services available limited (CORBA has
  from Workflow to security to vertical domain
  standardization efforts
• Biggest drivers
• Freely available with Windows NT
• MTS and MSMQ and other internet Microsoft
  technologies

81
Java Technology
82
Why Java

• Java is a simple, efficient, secure, portable
  high-performance programming language.
• It is similar to C, easy to learn.
• It has no pointer arithmetic, no need to free
  memory which is a serious problem in C/C.
• Very compact Runtime.

83
Why Java (Contd.)

• Can be used to implement executable content on
  the Web.
• Tremendous support from industries such as SUN,
  Inprise , Oracle, Silicon Graphics, Symanatec,
  IBM and even Microsoft.
• ideal for multimedia, graphics, animation

84
Some Java Modules
HTML
JavaBeans
Servlets
IIOP RMI and other Protocols
ENTERPRISE JAVABEANS COMPONENTS
85
Other Java APIs

• Java Telephony API
• Java Wallet
• Java Server API
• Java Security API

86
JDBC
87
JDBC (Database Connectivity)

• JDBC is a call level SQL interface from Java.
  This facilitates the execution of SQL statements
  and return the results.
• JDBC is an interface level specification.
• JDBC API is implemented on top of existing SQL
  level API -- ODBC.

88
JDBC (Contd)

• The most important JDBC interfaces are
• java.sql.Environment provides support for
  creating new database connections
• java.sql.Connection to connect to a particular
  database
• java.sql.Statement for executing a SQL statement
  on a given Connection
• java.sql.ResultSet to access the resultset for a
  given SQL statement.

89
JDBC (Contd.)

• Furthermore java.sql.Statement has two additional
  interfaces
• java.sql.PreparedStatement for executing a
  pre-compiled SQL statement
• java.sql.CallableStatement for executing a
  database stored procedure

90
JDBC (Contd)

• A JDBC-ODBC Bridge driver currently sits between
  the ODBC Drivers (provided by database vendors)
  and the JDBC API.

91
JavaBeans
92
JavaBeans

• JavaBeans is a software Component model for Java.
• Facilitate third party ISVs to create and Ship
  Java Components that can be composed together by
  end -users (VB model)

93
JavaBean Component Model
Customizer
BeanInfo
JavaBean Component
JAR
From Orafalis book
94
CORBA Component Model
Customizer
Component Info/IDL
CORBA Component
CAR
From Orafalis book based on the main
submission team
95
JavaBeans

• JavaBeans provides a platform independent
  component architecture.
• Will bridge to ActiveX, OpenDoc and LiveConnect.

96
JavaBean

• A JavaBean is a Reusable Software Component that
  can be manipulated visually in a builder Tool.

97
Characteristics of a Bean

• Support Introspection
• Support Customization
• Support Events using simple communication
  metaphors
• Support for properties
• Support for persistence through Java
  Serialization.

98
Bean

• Three important features of a Bean are
• the set of properties it exposes
• the set of methods available externally
• the set of events it fires.

99
Events

• AWT generates Event Objects form these low-level
  events.
• When a user interacts with a GUI, either through
  a mouse, a keyboard, audio or a video device,
  events are generated by the hardware and the
  Operating System.

100
Distributed Beans
Database Server
JDBC
CORBA SERVER
IIOP
RMI
JAVA
101
JAR

• Java Beans are packaged as JAR (Java Archive).
  (Beans come in a JAR -)

102
Pragmatics

• How does one create a Bean??

103
Creating Beans

• Write the component in Java using the JDK 1.1
  Event model (Event Delegation model) and
  implement the appropriate Listeners and add the
  listeners to the sources.
• Creating a BeanInfo class is highly recommended.
• Use Design Patterns for Creating the Java Beans

104
Design Patterns

• In very simplistic terms, design patterns are
  naming conventions.
• For example, if there is a property named Label,
  you would have
• public String getLabel()
• public void setLabel(String labelname)

105
Design Patterns

• Boolean Properties
• public boolean isRed()
• public void setRed( Color red)

106
Design Patterns

• EventListeners
• public void addltListenerTypegt (ltListenerTypegt
  listener)
• public void removeltListenerTypegt (ltListenerTypegt
  listener)

107
Example

• addSriniEventListener(SriniEventListener srevt)
• removeSriniEventListener(SriniEventListener srevt)

108
Bean Analysis
Introspection
Java beans
Bean Boxes
Design Patterns
Reflection
109
Introspection

• Discovers Events, Properties and Methods when the
  Bean Designer provides a BeanInfo Class

110
Reflection

• Reads Events, Properties and Methods using
  Design Patterns

111
JAR Files

• is similar to Zip Archives and may optionally
  have a MANIFEST file with information describing
  the contents of the JAR file.
• JAR files are used to collect class files,
  serialized objects, images help files and similar
  resource files.

112
MANIFEST FILES

• A JAR file that wants to advertise its contents
  should have a MANIFESTS file. The MANIFEST file
  will indicate which of the potential beans in the
  JAR archive are actual beans. If there is no
  MANIFEST every potential class is regarded as a
  bean.

113
Authentication

• JAR files can be signed to provide authentication.

114
Lotus InfoBus
115
What is Infobus

• Component Architectures such as JavaBeans provide
  mechanisms to build reusable software components.
• But Applications consist of multiple components
  that need to communicate

116
Infobus

• Communication also implies data exchange and
  information sharing.
• The data exchange and information sharing can
  either be done in Java itself or by using
  Scripting languages such as Tcl/Tk, PERL and
  others

117
The Problem ...

• The problem with scripting or using the
  programming language itself may result in ad hoc
  solutions.

118
What is needed for Component Communication...

• A standard for discovering the data to be
  exchanged.
• A standard for accessing and representing data.
• Preferably a dynamic mechanism with possible
  run-time discovery

119
Infobus

• Infobus provides mechanisms for discovery and
  data access amongst Java components.
• It works with applets, applications, JavaBeans
  and other Java Components

120
What Does Infobus Provide??

• Provides standard interfaces to access internal
  data structures.
• Ability to provide data to other applications.
• It provides dynamic change notification

121
Infobus Standard

• It is an open, vendor independent, free standard.

122
Reduces Complexity

• The infobus provides a mechanism for
  inter-component communication while hiding the
  complexity of low-level issues such as
  synchronization
• Synchronization based on Rendezvous

123
Producer
Infobus
Consumers
124
Change Notification

• Producers and Consumers notify changes performed
  by each other to the shared data.
• An Event based mechanism.
• Supports security and access control

125
More Information

• Can be found including specs and such at
• http//java.sun.com/beans/infobus

126
Java Blend
127
What is Java Blend

• Java Blend Integrates Objects in the Java
  Programming language with Enterprise Objects.
• Provides a single consistent, coherent object
  model for enterprise based on the Java object.

128
Java Blend

• Jointly developed by JavaSoft and Baan.
• Currently the programmer must explicitly convert
  to and from Java objects and database objects.
• Current applications are split into Java part and
  SQL part and both interacting through JDBC or
  some similar mechanism.

129
Object-Relational Mapping

• Currently done by the programmer.
• Decomposition of Objects into many tables or
  build objects from many tables.
• Mappings between foreign keys and Object
  references
• Mappings between field types and SQL types

130
Object Relational Mapping

• Map and or Infer Inheritance Relationships from
  Foreign keys
• Perform Transactions and process the results of
  transactions.

131
Java Blend

• Java Blend provides automatic mapping between
  Java Objects and backend relational database
  tables.
• The programmer only deals with Java Objects and
  is unaware of the SQL.
• SQL translations, Database representations
  (relational) are transparent to the programmer.

132
Advantages

• Easy access to enterprise relational data from
  Java Programming Language.
• No need to know, SQL, DDL and other relational
  database specific ideas.
• Significant reduction in application development
  time.

133
Java Blend Environment

• development environment supports automatic
  objectlt--gt Relational Mapping.
• Runtime environment supports
• Transaction Management
• Caching
• Query Processing

134
Development Process

• A mapping tool is used to map business objects
  written in Java to database schema.
• Queries can be written in OQL (ODMG compliant)

135
Enterprise Application
Persistent Objects
Java Blend Runtime
JDBC
JVM
136
Java Blend Runtime Architecture
Transaction Manager
Run Time Cache
Query Engine
137
Other Advantages

• Multiple threads for multiple user transactions
• Multiple simultaneous transactions per
  application
• Upon commit stores objects in the database
• Rollback mechanisms

138
Performance

• Increases performance by optimistic concurrency
  control(i.e., does not hold read and write locks
  on server)
• Runtime caching
• Support for stored procedures

139
EJB and Java Blend

• Java Blend works with EJB APIs
• Extremely scalable.

140
Enterprise Java Beans
141
What is EJB

• It is a distributed Software Component
  Architecture.
• It is a Framework for Creating Middleware.
• EJB is part of the Enterprise Java API

142
EJB

• It is a Server side Component model
• It focuses on Business Logic.

143
Enterprise Java Bean Architecture
From EJB specification document
144
Enterprise Java Bean Containers
OTS/JTS
Activation/ Deactivation
State Management
Container Metadata
Security
Factories
EJB1
EJB2
EJB3
Orafalis Book
145
EJB Architecture

• EJB architecture consists of
• EJB Servers
• EJB Containers
• EJB Clients
• EJB
• Auxiliary Systems such as JNDI, JTS and others.

146
The Various Players

• EJB Providers
• Provide Enterprise Java Beans (Components)
• EJB Server Providers
• Creates and sells EJB servers
• EJB Container Providers
• sell EJB containers
• Usually the server provider will also provide
  containers

147
The Various Players

• EJB Application Assemblers
• Will enable application building using EJB
  components, servers and Containers.

148
EJB Servers

• EJB Servers are similar to CORBA ORBs
• It Provides Naming(JNDI) and Transaction Services
  (JTS)
• Makes containers visible to clients

149
EJB Containers

• Encapsulate the Bean
• Client accesses Beans methods through the
  container methods
• Container methods map to Bean methods
• Client only knows about container methods.

150
EJB Clients

• First discover the services (ala CORBA ) using
  mechanisms such as JNI
• Request Bean Services through Container Services.

151
Types of Enterprise Java Beans

• Usually categorized as Session Beans or Entity
  Beans

152
Session EJB

• Is associated with a Single Client.
• It is created and destroyed by a client

153
Entity EJB

• Are Shared by multiple clients
• Persistence is supported.

154
Structure of an EJB Client

• First Locate a EJB container using a directory
  service
• Allocate a bean
• Use the bean services
• Dispose the bean.

155
EJB Support

• IBM
• Oracle
• Lotus
• Novell
• Iona
• Netscape
• Inprise
• and many many others

156
More on EJB

• can be found at www.java.sun.com/products/ejb/inde
  x.html

157
Some concluding thoughts....
158
CORBA/DCOM/JAVA Interoperability
Acknowledgement Adapted from a view foil by Tad
Davis, CareFlowNet
159
Bottom Line for Distributed Object Computing

• You can develop using CORBA
• You can develop using DCOM
• You can certainly use Java
• They all in reality can inter-operate in fairly
  straight forward fashion.