CORBA, DCOM and Java - PowerPoint PPT Presentation

Loading...

PPT – CORBA, DCOM and Java PowerPoint presentation | free to download - id: 622e02-NjQ2N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

CORBA, DCOM and Java

Description:

... Visual Basic, and Visual J++ ... driver currently sits between the ODBC Drivers (provided by database ... of SQL based on the Object Database Management Group ... – PowerPoint PPT presentation

Number of Views:136
Avg rating:3.0/5.0
Slides: 143
Provided by: ChadC3
Learn more at: http://www.csee.wvu.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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.
About PowerShow.com