2. Distributed SystemDistributed System
• Distributed System referred to computer networks where individual
computers were physically distributed within some geographical
area.
Fig A. Difference Between Distributed & Parallel Computing
3. Distributed ObjectDistributed Object
• Distributed objects refers to software modules that are designed to
work together, but reside either in multiple computers connected
via a network or in different processes inside the same computer
Fig B. Distributed objects residing in different machines.
4. Working of Distributed ObjectsWorking of Distributed Objects
Fig C. Working of Distributed Objects
6. DISTRIBUTED OBJECTSDISTRIBUTED OBJECTS
• Remote object references:
Globally unique reference for a distributed objects may
be passed as a parameter.
• Distributed actions:
Initiated by a method invocation, potentially resulting in
invocation chains.
• Distributed exceptions:
Additional exceptions generated from the distributed
nature of the system, including message loss or process
failure
7. DISTRIBUTED OBJECTSDISTRIBUTED OBJECTS
• Remote interfaces:
Provides an abstract specification of the methods that
can be invoked on the remote object.
Fig D. Remote Interfaces
8. EVOLUTION OF DISTRIBUTED OBJECTSEVOLUTION OF DISTRIBUTED OBJECTS
• Distributed objects as a natural evolution from three
strands of activity:
1. Distributed systems:
Earlier middleware was based on the client-server model
and there was a desire for more sophisticated programming
abstractions.
2. Programming languages:
Earlier work in object-oriented languages such as Simula-67
and Smalltalk led to the emergence of more mainstream and
heavily. Used programming languages such as Java and C++
9. EVOLUTION OF DISTRIBUTED OBJECTSEVOLUTION OF DISTRIBUTED OBJECTS
Fig E: OOP Distributed Objects
3. Software engineering:
In software engineering, significant progress was made in
the development of Object-oriented design methods, leading to
the emergence of the Unified Modeling Language
10. DISTRIBUTED OBJECT TECHNOLOGIESDISTRIBUTED OBJECT TECHNOLOGIES
• DCOM:
DCOM is used for single platform, multiple languages.
• JINI:
• CORBA:
CORBA is use for Multiple platforms, multiple languages
12. INTRODUCTION
Definition:
• CORBA is a distributed object-based systems.
• Provides inter-operability
• CORBA is a middle ware neither 2-tier or 3-tier
architecture.
• CORBA is a technology to communicate 2 objects
which are of heterogeneous type.
• CORBA can be written in c, c++, COBOL and JAVA
13. • CORBA was created by OMG(Object management
group).
• OMG was created in 1989.
• OMG does not provide any s/w products.
• The first version of CORBA was released in July ,1992
as
• “OBJECT MANAGEMENT ARCITECTURE GUIDE”
• Concept of CORBA came from OLE.
15. ORBORB
• Object Request Broker.
• Gives the communication infrastructure that is
capable of relaying object requests across
distributed platforms.
• Client calls the Object implementation through
interfaces provided by ORB.
• Advantages:
• Separates Client and Server implementation
• Separates both client and Server from underlying
communication infrastructure and protocol stack and so
replaceable while migration from one implementation to
other
16. • In Java we cannot separate a class’s definition
from its implementations as we can in C++
• CORBA allows the separation of definition and
implementation
• CORBA uses IDL for defining interfaces between
clients and servers
• ORB Vendors provide specific IDL compilers for
supported languages
– create target language stubs and skeletons for
building CORBA clients and servers
• C, C++, Smalltalk, Java, COBOL …
Interface Definition LanguageInterface Definition Language
17. Client StubsClient Stubs
• Client side proxy for server.
• Joins to the client at one end and to the ORB
core at the other end.
• Client-to-stub interface is decided by the
standard OMG language mapping for the
chosen programming language.
• Clients actually invoke methods on stub
objects.
18. Server SkeletonsServer Skeletons
• Acts as client proxy for server
implementation.
• Connects
– to the server object via the mapping defined for
its programming language on .
– To the Object Adapter via a proprietary interface.
• Invocation pass through Object Adapter to
skeletons, which in turn actually invoke
methods on server object.
19. Object AdapterObject Adapter
• Different kind of object implementations -
– objects residing in their own process and requiring
activation.
– others not requiring activation.
• OA helps the ORB to operate with different
type of objects.
• Most widely used OA - BOA (Basic OA)
• Recently standardized - POA (Portable OA)
20. Interface RepositoryInterface Repository
• Contains information regarding the interfaces to ORB
objects.
• Can be used by the ORB in 2 ways -
– To provide type-checking of request signatures, whether a request
was issued through DII or stub.
– To check correctness of inheritance graph.
• Client objects can use it -
– To manage installation and distribution of interface definitions
around your network.
– Language compilers may use them to generate stubs and skeletons.
• Can be shared by more than one ORB or one ORB may refer
to more than one interface repository.
21. Implementation RepositoryImplementation Repository
• Contains all the information regarding
object implementation.
• Provides a persistent record of how to
activate and invoke operations on object
implementations.
• CORBA gives vendors free-hand in handling
implementations.
22. • Generic interface for making remote
invocations.
• Uses interface repository at run-time to
discover interfaces.
• No need of pre-compiled stubs.
Dynamic Invocation InterfaceDynamic Invocation Interface
23. Dynamic Skeleton InterfaceDynamic Skeleton Interface
• Allows the ORB and OA to deliver requests
to an object without the need of pre-
compiled skeletons.
• Implemented via a DIR (Dynamic Invocation
Routine).
• ORB invokes DIR for every DSI request it
makes.
24. Differences between DynamicDifferences between Dynamic
invocation and static invocationinvocation and static invocation
• Use
• SI used for general purpose
• DI used for special purpose where extra flexibility is needed
• In SI interfaces should be known at compile time , In DI
interfaces are discovered during run time using data in
interface repository
• Static Interface are easier to use and code
25. CORBA servicesCORBA services
• Clock service maintains synchronized time
• Authentication service validates user id’s
• Object storage service: a file system for objects
• Life cycle service: oversees activation,
deactivation, storage, check pointing, etc.
• Transactions and replication services
• Naming services
• Security services
26. CORBA Advantages:
• Interaction with legacy systems.
• Static and dynamic method invocations
• High-level language bindings
• Location transparency
• Built-in security and transactions
27. • Design and process deficiencies.
• Problems with Firewalls.
• Problems with implementation.
CORBA PROBLEMSCORBA PROBLEMS
28. RMI Vs CORBARMI Vs CORBA
• Language Barrier.
• RMI can be easier to master than corba.corba
is rich and extensive family of std and
interfaces.
• Corba is peer-to-peer orb communication
model and Rmi is server centric model.
• RMI interface is defined in RMI-IIOP and corba
interfaces are defined in IDL.
29. • Distributed object can be used like a regular object,
but from anywhere on the network
• Creation, migration and deletion of distributed
objects is different from local objects
• CORBA RMI is multi-language RMI
• Distributed objects may be executed in parallel.
CONCLUSIONCONCLUSION
