CORBA introduction - Index of

Document Sample
CORBA introduction - Index of Powered By Docstoc
					CORBA, DCOM and Java

       V. “Juggy” Jagannathan
         CareFlow|Net, Inc.

   Distributed Object

   Robert Orfali, Dan Harkey, “Client/Server
    Programming with Java and CORBA,
    Second Edition.” John Wiley and Sons,
   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.

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

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

    * Viewfoil courtesy OMG:
 Worldwide Scope                           *

Andersen        Data Access   ICL              Nortel            Sun
APM             Eurocontrol   Informix         Novell
Alta            EDS           Intel            OHRA Insurances
                                               Oracle            Thomson CSF
AITECH          Ericsson      IBM
                                               Open Group        Telecom Italia
AT&T            FinSiel       IONA Tech.
                                               POSC              Telefonica
BaaN            Fujitsu       Microsoft
                                               Sodalia           Telia AB
Bull            Genesis       MITRE
British Telecom HP            Netscape         Siemens Nixdorf TRW
                                               Software AG     Unisys
Bankers Trust   Harlequin

* Viewfoil courtesy OMG:
  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
     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
     Fast Track Process.

* Viewfoil courtesy OMG:
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
   The Object Request Broker (ORB) provides the
    mechanisms by which clients transparently make
    requests and receive responses.
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.
                  De-facto Standards and products
- Manufacturing:
- Electronic Commerce:
- Healthcare:
                                                                   - Architecture guide and roadmap
-Telecommunications:                                               - Working on Internet facilities.
- Finance
- …..
  CORBA applications

                                   CORBA 2 (IIOP)

         - Naming
         - Security (...ICL)        CORBAservices                          - ORBIX  - IONA
                                                                           - Obj Broker BEA
         - Transactions (..Bull)
         - Query Service                                                   - VisiBroker Borland
         - Persistence                                                     - Omni Orb Olivetti
         - Lifecycle                                                       - Component Broker IBM

           * Viewfoil courtesy OMG:
 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 Harkey’s Book
ORB services

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

   Object-oriented - provides for encapsulation,
    polymorphism and inheritance
   Can provide security for content and context-
    sensitive transactions
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

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

   Security
   Time management
            CORBA Architecture

             Clients                            Server
     C++ Java Ada   C   other         C++ Java Ada   C    other

Client Requests                         Service
      IDL-based                       IDL-based


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

   Trader
   Collections
   Change management

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


                                            Static  Dynamic       Implementation
             Dyamic Client       ORB
                                          Skeletons Skeletons       Repository
             Invoc-  IDL        Inter-
              ation Stubs        face            Object Adapter

                             Object Request Broker
Client IDL Stubs

          Provides local proxies for remote
          Provides for marshaling of
           parameters into standard formats
Dynamic Invocation Interface

   Late binding of method calls
   Run time discovery of service IDL interface
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
   Repository IDs - uniquely and globally identify
    interface repository across multivendor ORBs
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
Server IDL Stubs

   Also called skeletons
   provide static interfaces to each service
   both client side and server side stubs are
    generated using IDL compilers
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
Object Adapter

   responsible for managing a collection of server
   instantiates server objects when needed and
    provides them with object IDs called object
   registers the classes and instances in the
    Implementation Repository
   All CORBA implementations must support a
    Basic Object Adapter
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
    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
   Register with Interface Repository
   Instantiate server objects
   Register run time instances with Implementation Repository
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
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
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
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
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
Internet Inter-ORB Protocol (IIOP)

         Standardizes the way GIOP messages can be
         exchanged using TCP/IP
         Mandatory for CORBA 2.0 compliance
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)
         ORB-to-ORB Bridging

Client                              Server

             DSI          DII

ORB From Vendor A        ORB From Vendor B
IDL and Interface Repository

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

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

    Module: groups a collection of class definitions
    Interface: defines a class; attributes and
    Operation: defines a method; the arguments;
     argument types; in, out or in-out; exceptions;
     optional context description
    Data types: basic (short , float, char...) and
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;
IDL Example: Interfaces

interface FamilyMember;
interface Employer;
interface InsurancePolicy;
interface InsuranceCompany;
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 sequence<InsurancePolicy> insurancePolicies;
    readonly attribute sequence<FamilyMember> familyMembers;
    readonly attribute sequence<Employer>    employers;
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;
Type Codes

represent IDL-defined data types
provide for self-describing data
Used by: DII, IIOP, Interface Repositories and any data type
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
Provide for self-describing objects
     CORBA 3.0

     Trader Service                     Java to IDL mapping
     POA                                Real-time CORBA
     Workflow                           Asynchronous Messaging
     Business Objects Facility          Domain-specific frameworks
     CORBA Component Model                Manufacturing, Transportation,
     CORBA Scripting Language              Finance, Healthcare, Telecom,
                                           Electronic Commerce
     IIOP over firewall
                                        and more!

See: for a press release
on CORBA 3.0 by major vendors for an early 1999 commercial availability.
         Trader Service

         Naming Service is like white pages
         Trader is like yellow pages


  Client                                                   Server
“Importer”                                               “Exporter”

                 Import Service         Export Service
   ORB                                                     ORB

                            Invoke Service
 Portable Object Adapter (POA)

To quote Orafali & Harkey: “The POA is simply the BOA done
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
CORBA/Java Security

Reference: Andreas Vogel & Keith
Duddy, “Java Programming With
CORBA,” Second Edition, John Wiley
& Sons, 1998.
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
   Two approaches have been identified to
    address applet security restrictions.
 Working with Applet Security restrictions

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

          Download   WWW Server                Server
           Applet                          Implementation
Applet               IIOP Gateway
           IIOP                     IIOP

   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
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
    Client-side firewalls

Browser   Client-side
          Firewall                                   Server
 Proxy                      Gatekeeper
          HTTP                           IIOP

            HTTP Tunneling With Gatekeeper

Browser   Client-side
          Firewall                                   Server
Client                  Port 80
              HTTP                               Implementation
 Proxy                      Gatekeeper
          IIOP                           IIOP

            Gatekeeper with dual functionality
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
   Authentication is based on digitally signed
Overview of CORBA Security

Goals of a security service

         Confidentiality
         Integrity
         Accountability
         Availability
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
Features of the Security Service

   Identification and authentication
   Authorization and access control
   Auditing
   Communications security
   Non-repudiation
   Administration of security policy
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
   Security Level 2 - supports all of the above
    and supports integrity, trust and auditing.
    Targets security-aware application which may
    enforce their own policies.
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 World Players - Others

Iona                Symantec
Visigenic/Inprise   ParcPlace
HP                  Penumra
Tandem              Inprise
Novell              Sybase
I-Kinetics          NetDynamics
Expersoft           Vignette
BEA                 Allaire
                    and 800 more!
Distributed Component Object Model

    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.

   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

   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
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
          DCOM Interface

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

                     Interface               Implementation
                     Function                  of Member
                       Table                   Functions

Object                                                         Internal
 User                                                            Data

                                  Pointers                    DCOM Object
DCOM Conventions

   Plug-in-jack pictorial
    representation of
   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.
DCOM Object

   Also known as
    ActiveX object.
   DCOM object                            IUnknown
    implements all the
    interfaces the object
   Identified by a unique   Interface A
    128-bit Class ID                       DCOM
                             Interface B
    (CLSID)                                Object
   Implements               Interface C
    IUnknown interface
DCOM Server

   DCOM servers is a
    DLL or EXE or a                         IUnknown
    Java Class.
   Server must
    provide a class
    factory for
    instantiating new
    objects                  Object         DCOM
                           Interfaces       Object
   IClassFactory2
    interface needs to
    be supported if
    object is             IClassFactory
                                or           Class
    instantiated only if                    Factory
    a valid license file
    is present                            DCOM Server
DCOM Local/Remote Transparency

   In-process servers: server DLLs that can be loaded in
    the same process as the client.
   Local servers: clients use DCOM’s 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.
DCOM IUnknown Interface

IUnknown Interface consists of:
   QueryInterface - for supporting interface
   AddRef - to support garbage collection
   Release - to support life cycle management
            Writing a Java Client/Server Application in DCOM

                          1. Create DCOM       2. Generate
                                IDL               GUIDs

                             3. MIDL

                                              Interface      Summary.txt
                            4. JavaTLB
              Class                        Interface

8. Implement                               5. Implement
    Client                                     Server

   9. jvc                                      6. jvc

10. JavaReg                                 7. JavaReg

  11. jview
                 Client                                 Server
DCOM Conclusions

DCOM is maturing rapidly
Java support is there, although it is for Microsoft version of
Biggest differences with CORBA
  Support limited to Wintel platforms

  Range of services available limited (CORBA has from

   Workflow to security to vertical domain standardization
Biggest drivers
  Freely available with Windows NT

  MTS and MSMQ and other internet Microsoft

Java Technology
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.
            Some Java Modules


                       IIOP RMI and other Protocols


                                  J            J      J                  J
                       J          M
 Server                                                   J
                                  A            N      I                  D
Platform                          P                       M
                                               D      D                  B
                       S          I                       S
                                               I      L                  C
Other Java APIs

Java Telephony API
Java Wallet
Java Server API
Java Security API
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.
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
   java.sql.Statement for executing a SQL
    statement on a given Connection
   java.sql.ResultSet to access the resultset for a
    given SQL statement.
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
JDBC (Contd)

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

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


              Methods        Component   Events


* From Orafali’s book                      JAR
               CORBA Component Model*

                Component Info/IDL

              Methods          Component                  Events


* From Orafali’s book based on the main submission team     CAR

   JavaBeans provides a platform independent
    component architecture.
   Will bridge to ActiveX, OpenDoc and
Distributed Beans


            IIOP    SERVER

            RMI      JAVA

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

How does one create a Bean??
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
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) { }
Design Patterns

Boolean Properties
       public boolean isRed() { }
       public void setRed( Color red) { }
Design Patterns

    public void add<ListenerType> (<ListenerType> listener)
    public void remove<ListenerType> (<ListenerType> listener)

addSriniEventListener(SriniEventListener srevt)
removeSriniEventListener(SriniEventListener srevt)
   Bean Analysis


                            Java beans


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

Reads Events, Properties and Methods using Design Patterns
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.

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.

JAR files can be signed to provide authentication.
Lotus InfoBus
Producer   Infobus   Consumers
Change Notification

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

Can be found including specs and such at
Java Blend
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.
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.
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
Object Relational Mapping

Map and or Infer Inheritance Relationships from Foreign keys
Perform Transactions and process the results of transactions.
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.

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

development environment supports automatic object<-->
Relational Mapping.
Runtime environment supports
    Transaction Management
    Caching
    Query Processing
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)
Enterprise Application

  Persistent Objects

 Java Blend Runtime


Java Blend Runtime Architecture

                Run Time
Transaction                       Query
 Manager                          Engine
Other Advantages

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

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

Java Blend works with EJB APIs
Extremely scalable.
Enterprise Java Beans
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

  It is a Server side Component model
  It focuses on Business Logic.
               Enterprise Java Bean Architecture*

*From EJB specification document
         Enterprise Java Bean Containers*

                         Activation/       State
                         Deactivation   Management


* Orafali’s Book
EJB Architecture

EJB architecture consists of
    EJB Servers
    EJB Containers
    EJB Clients
    EJB
    Auxiliary Systems such as JNDI, JTS and others.
         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
The Various Players

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

EJB Servers are similar to CORBA ORBs
It Provides Naming(JNDI) and Transaction Services (JTS)
Makes containers visible to clients
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.
EJB Clients

First discover the services (ala CORBA ) using mechanisms such
as JNI
Request Bean Services through Container Services.
Types of Enterprise Java Beans

    Usually categorized as Session Beans or Entity Beans
Session EJB

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

    Are Shared by multiple clients
    Persistence is supported.
Structure of an EJB Client

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

and many many others
More on EJB

can be found at
Some concluding thoughts....
          CORBA/DCOM/JAVA Interoperability

                Bridge                          CORBA      Orbix

                           Java Beans                                              Srvc
                                                CORBA         Visi          Visi    Java
Clients                      Proxy                                                  Code
                                                              Orb           Srvc
                                                                               Java Beans

     Acknowledgement: Adapted from a view foil by Tad Davis, CareFlow|Net
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

Shared By: