Components by 2et9rgM7

VIEWS: 0 PAGES: 62

									       Distributed Objects and
             Components




NJIT
1             10/15/01
    Distributed Objects
    The benefits of an object oriented approach
     to software development are greatly
     enhanced when they can be distributed over
     a network.
    A classical object encapsulates code and
     data.
    A distributed object is an object that can live
     anywhere on a network, and can be invoked
     by remote clients via method invocations.
2                       10/15/01
    Components
       Distributed objects are independent
        software components. Components are
        not bound to a particular program,
        computer language, or implementation.
       Components are packaged as the basic
        unit of work and distribution for an
        application made up of distributed objects.


3                        10/15/01
    Key Characteristic
       Possibly the most important distinguishing
        characteristic between an application and
        a component is that components can be
        used in unpredictable combinations, while
        applications tend to be focused on a
        particular task or environment.



4                        10/15/01
    Why Components?
       Interoperability between:
        Different Languages
        Different Compilers
        Different Vendors
        Different Operating Systems
        Different Tools
        Different Networks
        Different Applications
        Different Address Spaces
    (Microsoft doesn’t believe in Vendor independence.)

5                        10/15/01
    Properties of Components
       A marketable entity
       Not a complete application
       Usable in unpredictable combinations
       Well specified interface
       Toolability
       Event notification
       Configuration and property management
       Scripting
       Metadata and Inspection
       Interoperability
       Ease of Use
6                         10/15/01
    Server Side Components
       Components on the Server side need
        added intelligence. They need to be more
        concerned with Security, Licensing,
        Versioning, Life Cycle Management,
        Transaction Control and Locking,
        Persistence, Relationships, Self-Testing,
        Semantic Messaging and Self-installation
        than Client side components.

7                        10/15/01
    Server Security Issues
    Distributed Objects create special security
     problems for Servers:
       They can play both Client and Server roles
       Distributed objects evolve constantly
       Their interactions are not well understood
       Distributed objects are less predictable
       Distributed objects are polymorphic
       Distributed objects can scale without limit
       Distributed objects are very dynamic
    Most of these problems can be solved by moving
     security into the CORBA ORB.
8                       10/15/01
    Distributed Object
    Technologies
       CORBA
       Enterprise Java Beans
       COM+
       Object Oriented Databases
       JINI



9                      10/15/01
 Component Standards
    On the desktop, Java Beans and ActiveX
     are competing component standards.
    On the server, component standards
     include Enterprise Java Beans, CORBA
     Beans, and COM+.
    CORBA Internet Inter-ORB Protocol (IIOP)
     provides a transactional pipe for EJBs,
     linking Java and CORBA.
10                   10/15/01
 Distributed Object Topics
    Object Brokers
    Object Services
    Object Transaction Monitors
    Object Groupware
    Object Databases
    Object Web Technology
    Object Linking
    Object Frameworks

11                   10/15/01
 Object Request Brokers
    An Object Request Broker (ORB) provides
     the connections that allow components to
     interoperate.
    An ORB must be augmented with a high-
     level component infrastructure that defines
     how the objects can work together.
    This component infrastructure defines how
     object operate within containers (or
     frameworks).
12                    10/15/01
 Object Transaction Monitors
    OTMs are the state of the art in
     component management. Instead of the
     ORB approach, where you need to write
     separate code to call each needed service
     separately, an OTM provides a suite of
     services with a common call structure.



13                   10/15/01
 Enterprise Java Beans
    Possibly the most fashionable components
     today are Enterprise Java Beans, a
     component structure in Java that has been
     designed from the ground up to be
     compatible with CORBA.
    EJBs use the RMI/IDL CORBA subset for
     their distributed object model, and the
     Java Transaction Service, a subset of the
     CORBA OTS, for distributed transactions.
14                    10/15/01
 An EJB Application Example




15            10/15/01
 Internet Inter-ORB Protocol
    Enterprise Java Beans use the CORBA
     IIOP (Internet Inter-ORB Protocol) to
        Operate across multi-vendor servers
        Propagate transaction and security contexts
        Service multilingual clients
        Support ActiveX clients with DCOM to
         CORBA bridges


16                        10/15/01
JavaBeans Component Model

                    BeanInfo


                                    Customizer
       Methods       JavaBean
                     Component   Events


       Properties


                                                 JAR
                                                 (.jar)


17                    10/15/01
 The Promise of Distributed
 Objects
    Assemble complex client/server
     applications with reusable software
     components
    Objects can be modified or replaced
     without affecting the rest of the
     components in the system or their
     interactions.


18                   10/15/01
Packaging Distributed Objects

    Components will be delivered in suites
     that run within application frameworks.
    Within an application framework, all pieces
     are known to work together to perform
     domain level applications.




19                    10/15/01
 Benefits of Distributed
 Objects
    Visual tools and other applications can
     discover an object’s interfaces, events,
     and properties dynamically.
    Granular components can be visually
     assembled with tools, interoperate across
     networks, run on different platforms, and
     manage themselves and their resources.


20                    10/15/01
 Benefits of Distributed
 Objects (2)
    Object Oriented client server applications
     can be more flexible than traditional
     approaches.
    Components can be mixed and matched
     without sacrificing robustness.
    Interfaces are separated from
     implementations, so you can use an object
     wrapper to make an existing legacy
     application look like an object.
21                    10/15/01
 Defining Standards
    The Object Management Group and
     Microsoft Corporation are the key
     competitors that are driving the movement
     toward distributed objects.
    OMG is the force behind CORBA and its
     integration with Java.
    Microsoft is trying to establish its own
     proprietary standard based on DCOM,
     ActiveX, COM+ and .NET
22                   10/15/01
 What is CORBA?
    CORBA is a middleware that that sits
     between the application and the system.
    CORBA is based on the OO model.
    CORBA allows software reusability.
    CORBA uses a broker to handle
     messages.
    The broker provides the ability to choose
     servers that best fill the client’s request.
23                      10/15/01
 Comparing CORBA to DCE
    DCE uses a procedure-oriented
     distributed model (RPC), while CORBA is
     based on objects.
    DCE clients need to know what servers
     are available. CORBA clients request from
     the ORB, which connects them to a
     server.
    CORBA provides a more abstract level of
     programming
24                    10/15/01
 OMA (Orfali, Harkey, Edwards, Figure 22-2)
                                                   Common Facilities

                                            Vertical Common Facilities

        Application                         Horizontal Common Facilities
         Objects               Distributed Information Systems    Task
                               Documents Management Management Management


                              Object Request Broker


     Naming Persistence    Life Cycle                              Collection
                                            Properties Concurrency

     Security   Trader    Externalization          Events   Time    Relationships
         Transactions     Startup    Licensing          Query

                   Common Object Services (CORBA Services)
25                                      10/15/01
The Object Request Broker
(ORB)
    ORB is the object bus.
    ORB is the middleware that establishes
     the client/server relationship between
     objects.
    ORB lets objects communicate
     transparently without concern for :
        the hosts where the objects run
        the operating systems
        the programming languages
26                         10/15/01
                      RPC vs. ORB
                       (Orfali, Harkey, Edwards, Figure 22-4)

     Client            Server                        Client               Server

                                                                        Object X Object Y
                                                 Invoke      Invoke
                                                 foo on      foo on
                                                                         foo       foo
     Call foo          Code   Data               Object X    Object Y




                RPC link                                    Object Request Broker



27                                    10/15/01
 Structure of a CORBA 2.0
 ORB (Orfali, Harkey, Edwards, Figure 22-4)

             Client
                                                 Object Implementation



                       Client                             Dynamic
Interface                                     Static                  Object Imple-
           Dynamic                ORB                     Skeleton
Repos-                  IDL                 Skeletons                 Adapter mentation
          Invocation            Interface                Invocation
itory                  Stub                                                   Repository


                            Object Request Broker Core


28                                    10/15/01
 CORBA Beans
    The CORBA 3.0 Components model will
     include an extension of Enterprise Java
     Beans to CORBA’s language independent
     model, so that you are not locked into
     Java for all your components.




29                   10/15/01
CORBA Beans Component
Model
                     Component Info/IDL


                                              Customizer
                Methods        CORBA
                               Component   Events


                Properties


                                                           CAR (XML)
 This model should                                         (.car)
 look familiar!

30                             10/15/01
 General Inter-ORB Protocol
    Key to the interoperability of CORBA is the bus
     structure that allows different Object Request
     Brokers on different hosts in different networks
     to communicate with each other.
    The CORBA specification anticipates several of
     these, all based on the General Inter-ORB
     Protocol. (GIOP)
    GIOP specifies seven message formats to cover
     all ORB request reply formats and a Common
     Data Representation (CDR).
31                      10/15/01
 Internet Inter-Orb Protocol
    The first implementation of a CORBA GIOP is the
     Internet Inter-ORB Protocol. (IIOP).
    The IIOP specifies how GIOP messages are to be
     exchanged over a TCP/IP network.
    Future specifications may cover other networks,
     but all CORBA implementations after 2.0 must
     either support IIOP or connect to it via a half
     bridge.



32                      10/15/01
 A CORBA/EJB application




33           10/15/01
                            COM+
                  The Component Bus
                       From Microsoft


NJIT
34     10/15/01
 The other component model
    Microsoft, as one of the world’s largest and most
     profitable companies, must protect and increase
     its revenues to survive.
    Its primary approach has been to attempt to
     make all computing within most corporations
     dependent upon proprietary products for which
     high fees must be paid to Microsoft.
    It has already succeeded in capturing the
     desktop with Windows and Microsoft Office. Now
     it wants to capture the Network and the Internet.

35                       10/15/01
 Server, COM+, and .NET
    The Microsoft product to drive Unix out of
     corporations is MS Windows Server.
    To capture the Internet, Microsoft is deploying the
     Microsoft Component Object Model (COM) and
     extending it to the Internet and Client/Server in
     general with COM+ and .NET
    If Microsoft succeeds, a lot of companies will go out
     of business as dBase, Netscape, and Word Perfect
     did, and everyone will pay a lot more for software.
     They use low prices and good features to kill the
     competition, then raise prices.
36                         10/15/01
 Parallels between COM and
 CORBA
    CORBA and COM provide competing
     Object Request Brokers (ORB).
    Both attempt to provide a universal
     approach to connecting components
    Both require interfaces to be standardized
     through an IDL. The COM IDL is based
     on DCE and is not CORBA compliant.


37                    10/15/01
 COM Interfaces
    A COM interface is a collection of function
     calls (methods or member functions)
     based on a table of pointers. A COM
     client uses pointers to a virtual table or
     vtable, which is an array of function
     pointers. The functions addressed
     through those pointers are the server
     object’s implementation methods.

38                    10/15/01
 COM Plug-in Jacks
    COM traditionally uses bullet-and-stick
     diagrams, or plug-in jacks, to represent
     the vtable in Interface descriptions,
     because they are less intimidating.

                       Plug-in Jack
          Client                          Component
        Application                         Object
                      Interface Pointer


39                          10/15/01
 COM IIDs
    By convention, an interface in COM is
     given a name beginning with I, such as
     IFoo. This name is only a symbol for a
     source level programming tool. At run time
     each interface is known by a unique
     Interface Identifier (IID). An IID is a COM
     generated 128-bit globally-unique identifier
     (GUID) for interfaces.

40                    10/15/01
 DCOM Objects
    A COM object, also known as an ActiveX
     object, is a component that supports one
     or more interfaces defined by the object’s
     class.
    A COM interface refers to a predefined
     group of related functions.
    A COM Interface implements one or more
     interfaces and has a unique 128 bit Class
     ID (CLSID).
41                    10/15/01
 IUnknown
    All COM objects must implement the
     IUnknown interface to control the lifetime
     of the object and handle interface
     negotiations.
                                    IUnknown

      Interface A
                                 DCOM
      Interface B
                                 Object
      Interface C

42                    10/15/01
 A Key Difference
    In CORBA, Objects have unique IDS.
    COM does not support Object IDs. With
     COM, clients obtain a pointer to an
     interface. DCOM clients cannot reconnect
     to the same object instance at a later time
     with the same state. This greatly reduces
     the role of object instances in COM as
     opposed to classic object systems.

43                    10/15/01
 COM Server Functions
    Implement a class factory interface
    Register the supported classes
    Initialize the COM Library
    Verify compatibility of the library
    Provide an unloading mechanism
    Uninitialize the COM library after use



44                     10/15/01
 Variations of COM Servers
    In-process Servers execute in the same process
     space as clients, and are implemented as
     Dynamic Link Libraries (DLL)
    Local Servers execute in a separate process
     and use DCOMs Lightweight RPC (LRPC)
     mechanism to communicate. Local servers
     have their own EXE file.
    Remote Servers execute in a separate process
     on a remote machine and use a DCE-like RPC
     mechanism to communicate.

45                      10/15/01
 DCOM Client Server
 Boundaries (Figure 23-5)

     Client Process                              Local Server Process
                         In-Process
                           Object
                                                    Stub            Local    Local
       Client         In-Process Server                             Object
                                                 DCOM                        Server
     Application
                         Local
                         Object        LRPC
                         Proxy
                                                            Remote Machine

                        DCOM                     Remote Server Process
                                                 Remote Server Process
                        Remote         RPC           Stub           Remote
                        Object                                               Remote
                                                                    Object
                        Proxy                     DCOM                       Server



46                                    10/15/01
 IUnknown member functions
    Every COM interface must implement
     three key IUnknown functions:
        QueryInterface for interface negotiations
        AddRef to create an interface instance
        Release to destroy an interface instance
    IUnknown is the base interface from
     which all other interfaces inherit.

47                       10/15/01
 MIDL, the COM IDL
    To develop a COM interface, you create a
     file that describes the interface’s methods
     and their arguments and run that file
     through the Microsoft IDL (MIDL) Compiler.
    The MIDL Compiler is actually a
     precompiler that turns text descriptions of
     the interface into code for proxies and
     stubs, and creates header files with the
     interface definition.
48                    10/15/01
 .NET Products and Services
    Microsoft offers:
      Visual Studio .NET, a web development
       platform using multiple languages, but the
       programs will only run on .NET
      .NET myServices, that developers can use to
       create services. Microsoft will use those as a
       base to offer “user experiences” that will
       capture data and get people to subscribe.
      A .NET version of Office by subscription
      bCentral for small business by subscription


49                       10/15/01
 A Comparison of 3 most popular distributed object paradigms


    Microsoft's Distributed Component Object Model (DCOM),
 OMG's Common Object Request Broker Architecture (CORBA)
   and JavaSoft's Java/Remote Method Invocation (Java/RMI).




Source: A Detailed Comparison of CORBA, DCOM and Java/RMI by Gopalan Suresh Raj
DCOM                                       CORBA                                    Java/RMI
Supports multiple interfaces for objects   Supports multiple inheritance at the     Supports multiple inheritance at the
and uses the QueryInterface()              interface level                          interface level
method to navigate among interfaces.
This means that a client proxy
dynamically loads multiple server stubs
in the remoting layer depending on the
number of interfaces being used.

Every object implements IUnknown.          Every interface inherits from            Every server object implements
                                           CORBA.Object                             java.rmi.Remote (Note :
                                                                                    java.rmi.UnicastRemoteObject is
                                                                                    merely a convenience class which
                                                                                    happens to call
                                                                                    UnicastRemoteObject.exportObject(
                                                                                    this) in its constructors and provide
                                                                                    equals() and hashCode() methods)

Uniquely identifies a remote server        Uniquely identifies remote server        Uniquely identifies remote server
object through its interface pointer,      objects through object                   objects with the ObjID, which serves as
which serves as the object handle at       references(objref), which serves as      the object handle at run-time. When
run-time.                                  the object handle at run-time. These     you .toString() a remote reference,
                                           object references can be externalized    there will be a substring such as
                                           (persistified) into strings which can    "[1db35d7f:d32ec5b8d3:-8000, 0]"
                                           then be converted back into an objref.   which is unique to the remote server
                                                                                    object.
Uniquely identifies an interface using     Uniquely identifies an interface using   Uniquely identifies an interface using
the concept of Interface IDs (IID) and     the interface name and uniquely          the interface name and uniquely
uniquely identifies a named                identifies a named implementation of     identifies a named implementation of
implementation of the server object        the server object by its mapping to a    the server object by its mapping to a
using the concept of Class IDs (CLSID)     name in the Implementation               URL in the Registry
the mapping of which is found in the       Repository
registry.
The remote server object reference         The remote server object reference       The remote server object reference
generation is performed on the wire        generation is performed on the wire      generation is performed by the call to
protocol by the Object Exporter            protocol by the Object Adapter           the method
                                                                                    UnicastRemoteObject.exportObject(
                                                                                    this)
Tasks like object registration, skeleton                            The constructor implicitly performs                                The RMIRegistry performs common
instantiation etc. are either explicitly                            common tasks like object registration,                             tasks like object registration through
performed by the server program or                                  skeleton instantiation etc                                         the Naming class.
handled dynamically by the COM run-                                                                                                    UnicastRemoteObject.exportObject(
time system.                                                                                                                           this) method performs skeleton
                                                                                                                                       instantiation and it is implicitly called in
                                                                                                                                       the object constructor.

Uses the Object Remote Procedure                                    Uses the Internet Inter-ORB                                        Uses the Java Remote Method
Call(ORPC) as its underlying remoting                               Protocol(IIOP) as its underlying                                   Protocol(JRMP) as its underlying
protocol                                                            remoting protocol                                                  remoting protocol (at least for now)

When a client object needs to activate                              When a client object needs to activate                             When a client object needs a server
a server object, it can do a                                        a server object, it binds to a naming or                           object reference, it has to do a
CoCreateInstance()- (Note:There are other                           a trader service - (Note:There are other ways that                 lookup() on the remote server object's
ways that the client can get a server's interface pointer, but we
won't go into that here)
                                                                    the client can get a server reference, but we won't go into that
                                                                    here)                                                              URL name.

The object handle that the client uses                              The object handle that the client uses                             The object handle that the client uses
is the interface pointer                                            is the Object Reference                                            is the Object Reference

The mapping of Object Name to its                                   The mapping of Object Name to its                                  The mapping of Object Name to its
Implementation is handled by the                                    Implementation is handled by the                                   Implementation is handled by the
Registry                                                            Implementation Repository                                          RMIRegistry

The type information for methods is                                 The type information for methods is                                Any type information is held by the
held in the Type Library                                            held in the Interface Repository                                   Object itself which can be queried
                                                                                                                                       using Reflection and Introspection

The responsibility of locating an object                            The responsibility of locating an object                           The responsibility of locating an object
implementation falls on the Service                                 implementation falls on the Object                                 implementation falls on the Java Virtual
Control Manager (SCM)                                               Request Broker (ORB)                                               Machine (JVM)

The responsibility of activating an                                 The responsibility of locating an object                           The responsibility of activating an
object implementation falls on the                                  implementation falls on the Object                                 object implementation falls on the Java
Service Control Manager (SCM)                                       Adapter (OA) - either the Basic Object                             Virtual Machine (JVM)
                                                                    Adapter (BOA) or the Portable Object
                                                                    Adapter (POA)
The client side stub is called a proxy                              The client side stub is called a proxy or                          The client side stub is called a proxy or
                                                                    stub                                                               stub
The server side stub is called stub                                 The server side stub is called a                                   The server side stub is called a
                                                                    skeleton                                                           skeleton
All parameters passed between the          When passing parameters between the        When passing parameters between the
client and server objects are defined in   client and the remote server object, all   client and the remote server object, all
the Interface Definition file. Hence,      interface types are passed by              objects implementing interfaces
depending on what the IDL specifies,       reference. All other objects are passed    extending java.rmi.Remote are
parameters are passed either by value      by value including highly complex data     passed by remote reference. All other
or by reference.                           types                                      objects are passed by value
Attempts to perform distributed            Does not attempt to perform                Attempts to perform distributed
garbage collection on the wire by          general-purpose distributed                garbage collection of remote server
pinging. The DCOM wire protocol uses       garbage collection.                        objects using the mechanisms bundled
a Pinging mechanism to garbage collect                                                in the JVM
remote server object references. These
are encapsulated in the IOXIDResolver
interface.
Allows you to define arbitrarily complex   Complex types that will cross interface    Any Serializable Java object can be
structs, discriminated unions and          boundaries must be declared in the IDL     passed as a parameter across
conformant arrays in IDL and pass                                                     processes.
these as method parameters. Complex
types that will cross interface
boundaries must be declared in the
IDL.
Will run on any platform as long as        Will run on any platform as long as        Will run on any platform as long as
there is a COM Service implementation      there is a CORBA ORB implementation        there is a Java Virtual Machine
for that platform (like Software AG's      for that platform (like Inprise's          implementation for that platform
EntireX)                                   VisiBroker)                                (provided by a whole lot of companies
                                                                                      in addition to JavaSoft and Microsoft)
Since the specification is at the binary   Since this is just a specification,        Since it relies heavily on Java Object
level, diverse programming languages       diverse programming languages can be       Serialization, these objects can only be
like C++, Java, Object Pascal (Delphi),    used to code these objects as long as      coded in the Java language
Visual Basic and even COBOL can be         there are ORB libraries you can use to
used to code these objects                 code in that language
Each method call returns a well-defined    Exception handling is taken care of by     Allows throwing exceptions which are
"flat" structure of type HRESULT,          Exception Objects. When a distributed      then serialized and marshaled across
whose bit settings encode the return       object throws an exception object, the     the wire.
status. For richer exception handling it   ORB transparently serializes and
uses Error Objects (of type                marshals it across the wire.
IErrorInfo), and the server object has
to implement the ISupportErrorInfo
interface.
             Object Databases
       The Next Step in Components?




NJIT
54         10/15/01
 Object Databases
    An Object Database Management System
     provides a persistent store for objects in a
     multi-user client/server environment.
    The intent is to avoid mangling objects
     and tearing them apart to store their data
     in relational tables by storing objects in
     their natural form.


55                     10/15/01
 ODBMS Features
    Freedom to create new forms of information
    Fast access
    Flexible views of composite structures
    Tight integration with OO Languages
    Support customizable information structures with
     multiple inheritance
    Support versioning, nesting, long-lived transactions
    Repositories for distributed objects
    Life cycle management for composite objects


56                        10/15/01
 ODMG
    There is an Object Database Management
     Group that is working on a standard that
     will be the ODBMS answer to SQL for
     Relational Databases.
    They have already released standards for
     ODBMS built on the OMG object model.



57                   10/15/01
 ODBMS Standards
    Object Definition Language (ODL)
    Object Query Language (OQL)
    C++, Smalltalk and Java Language
     bindings




58                  10/15/01
 Example: Java code
 accessing ODBMS
    This example uses the ODMG Java Binding and
     the ODMG Object Query Language (OQL). Notice
     that all the code is Java, with the exception of the
     query string. You will not find a database sub-
     language in this example.

     import org.odmg.*;
     import java.util.Collection;
     Implementation impl = new
     com.vendor.odmg.Implementation();
         Database db = impl.newDatabase();

59                        10/15/01
 Example: Java code
 accessing ODBMS
     Transaction txn = impl.newTransaction();
     try {
        db.open("addressDB",
           Database.OPEN_READ_WRITE);
        txn.begin();
        // perform query
        OQLQuery query = new OQLQuery(
           "select x from Person x where x.name = \"Doug
                          Barry\"");
        Collection result = (Collection) query.execute();
        Iterator iter = result.iterator();

60                          10/15/01
 Example: Java code
 accessing ODBMS
       // iterate over the results
       while ( iter.hasNext() )
       {
           Person person = (Person) iter.next();
           // do some addition processing on the person (now
                         shown)
           // now traverse to the address object and update its
                         value
           person.address.street = "13504 4th Avenue South";
       }
       txn.commit();
       db.close();
     }
     //exception handling would go here ...
61                          10/15/01
 Reference
    Robert Orfali, Dan Harkey, Jeri Edwards,
     Client Server Survival Guide, Third
     Edition, Wiley, 1999.




62                    10/15/01

								
To top