CTIS 490 DISTRIBUTED SYSTEMS

1
CTIS 490DISTRIBUTED SYSTEMS

• WEEK 12
• DISTRIBUTED OBJECT-BASED SYSTEMS

2
INTRODUCTION

• In distributed object-based systems, the notion
  of an object plays a key role in establishing
  distribution transparency.
• Most object-based distributed systems use a
  remote-object model in which an object is hosted
  by a server that allows remote clients to do
  method invocations.
• In other words, clients are offered remote
  services in the form of objects that they can
  invoke.

3
DISTRIBUTED OBJECTS

• Common organization of a remote object with
  client-side
• proxy.

4
DISTRIBUTED OBJECTS

• An object encapsulates data, called state and
  operations on those data, called methods.
• Methods made available through an interface.
• A process can access the state of an object by
  invoking methods made available to it via an
  objects interface.
• The separation between interfaces and the objects
  implementing these interfaces is crucial for
  distributed systems.

5
DISTRIBUTED OBJECTS

• This separation allows to place an interface at
  one machine, while the object itself resides on
  another machine. This scheme is referred as
  distributed object.
• When a client binds to a distributed object, an
  implementation of the objects interface, called
  a proxy is loaded into clients address space.
• A proxy is analogous to a client stub in RPC
  systems. It marshals method invocations into
  messages and unmarshals reply messages.

6
DISTRIBUTED OBJECTS

• The actual object resides at a server machine.
  Invocation requests are passed to a server stub,
  which unmarshals them to make method invocations
  at the objects interface at the server.
• The server-side stub is often referred as
  skeleton, and it provides the bare means of
  letting the server middleware access the
  user-defined objects.
• In a general distributed object, the state of an
  an object may also be distributed. However, in
  most distributed systems this is not the case,
  and they reside on one remote machine.These
  objects are also referred as remote objects.

7
COMPILE TIME / RUNTIME OBJECTS

• Objects in distributed systems appear in many
  forms.
• The basic ones are those supported by Java, C,
  and other object-oriented languages, which are
  referred as compile-time objects. In this case,
  an object is defined as the instance of a class.
• For example, compiling class definitions results
  in code that allows it instantiate Java objects.
  Interfaces can be compiled into client-side and
  server-side stubs, allowing Java objects to be
  invoked from a remote machine.
• A Java developer is unaware of the distribution
  of objects.

8
COMPILE TIME / RUNTIME OBJECTS

• The drawback of compile-time objects is the
  dependency on a particular programming language.
  Therefore, an alternative way of constructing
  distributed objects is to do this during runtime.
• An object-adapter is used as a wrapper around the
  object implementation.
• An implementation of an interface can be
  registered at an adapter, which can make that
  interface available for remote invocations.
• The adapter will take care the invocation
  requests, thus providing an image of remote
  objects to its clients.

9
PERSISTENT and TRANSIENT OBJECTS

• A persistent object is one that continues to
  exist even if it is currently not contained in
  the address space of any server process.
• A server process can store the objects state on
  a secondary storage and then exit. Later, a newly
  started server can read the objects state from
  storage to its own address space.
• In contrast, a transient object exists only as
  long as the server that is hosting it.

10
ENTERPRISE JAVA BEANS

• With inherent capability built into the Java
  language for distributed objects, several
  facilities have been provided that would ease the
  development of distributed applications.
• These facilities provide a runtime environment
  that supports client-server architectures. One
  such facility is the Enterprise Java Beans (EJB).
• An EJB is a Java object that is hosted by a
  special server offering different ways for remote
  clients to invoke that object.
• The server provides the support the
  system-oriented functionality, such as looking up
  for objects and storing objects.

11
ENTERPRISE JAVA BEANS

• General architecture
• of an EJB server.

12
ENTERPRISE JAVA BEANS

• An EJB is embedded inside a container which
  provides interfaces to underlying services that
  are implemented by an application server.
• Typical services include
• Remote Method Invocation (RMI)
• Database Access (JDBC)
• Naming (JNDI)
• Messaging (JMS)
• There are 4 types of EJBs
• Stateless session beans
• Stateful session beans
• Entity beans
• Message-driven beans

13
ENTERPRISE JAVA BEANS

• Stateless session bean is a transient object. For
  example, it can be used to implement an SQL query
  submitted for a database.
• Statefull session bean maintains client-side
  state. For example, it can be used to implement
  an electronic shopping cart like the ones for
  electronic commerce. Its lifetime is limited by
  its client. When the client is finished, it is
  automatically destroyed.
• Entity bean can be considered a long-lived
  persistent object. It will generally be stored in
  a database. Typically, it stores information that
  is needed the next time a specific client
  accesses the server.
• Message-driven bean is not called directly by a
  cient. It would react to incoming messages, and
  it can send messages through the server.

14
OBJECT SERVER

• An object server is a server tailored to support
  distributed objects. The important difference
  between a general object server and other servers
  is that it does not provide an application
  specific service.
• An object server acts as a place where objects
  live.
• An object server provides only the means to
  invoke local objects based on requests from
  remote clients. As a result, it is easy to change
  services by simply adding and removing objects.

15
OBJECT SERVER

• An object server supports different policies.
• For example, commercial J2EE application servers
  from Oracle, IBM, and BEA compete on how well
  they design and implement these policies
• It can create a transient object at the first
  invocation request and destroy it as soon as no
  clients are bound to it anymore.
• It can create all transient objects at the time
  the server is initialized, at the cost of
  consuming resources even no client is making use
  of the object
• It can place each object in a memory segment of
  its own. In other words, objects share neither
  code nor data.
• It can let objects at least share code by
  implementing various threading policies, for
  example one thread for each object.

16
OBJECT SERVER

• Organization of an Object
• Server.

17
OBJECT ADAPTER

• An object adapter brings the object into servers
  address space.
• An object adapter has one or more objects under
  its control, and several object adapters may
  reside in the same server at the same time.
• When an object invocation is delivered to the
  server, it is first dispatched to the appropriate
  object adapter.
• An object adapter can extract an object reference
  from an invocation request, and subsequently
  dispatch the request to the referenced object
  through the server-side stub of that object.
• They dispatch requests from server-side ORB and
  directs them to the programming language specific
  servant (code) providing the service.

18
BINDING A CLIENT TO AN OBJECT

• Distributed object systems support system-wide
  object references. Such object references can be
  freely passed between processes on different
  machines, for example as parameters to method
  invocations.
• A process should first bind to the object before
  invoking any of its methods.
• Binding results in a proxy being placed in the
  processs address space, which implements the
  interface containing the methods the process can
  invoke.
• Binding is done automatically. The underlying
  system locates the server that manages the actual
  object when it is given an object reference.

19
OBJECT REFERENCE IMPLEMENTATION

• Object reference must contain enough information
  to allow a client to bind to an object.
• A simple object reference includes
• network address of the machine where the actual
  object resides
• an end point identifying the server that manages
  the object
• indication of which object
• A server can handle both TCP and UDP. As a
  result, an object reference may also include to
  indicate which protocol to use.

20
STATIC - DYNAMIC INVOCATIONS

• After a client is bound to an object, it can
  invoke the objects methods through the proxy.
  This is called Remote Method Invocation (RMI).
• Objects interfaces may be specified in an
  interface definition language.
• Alternatively, we can make use of an object-based
  language such as Java, that will handle stub
  generation automatically, which is referred as
  static invocation.
• Static invocations require that the interfaces of
  an object are known when the client application
  is being developed.
• It also implies that if interfaces change, then
  the client application must be recompiled before
  it can make use of new interfaces.

21
STATIC - DYNAMIC INVOCATIONS

• As an alternative, method invocations can also be
  done more dynamic fashion, i.e. method
  invocations are composed at runtime, referred as
  dynamic invocation.
• Dynamic invocation is usually in the form of
• invoke (object, method, input_par, output_par)
• For example, to append an integer int to a file
  object fobject which the object provides the
  method append
• Static invocation fobject.append (int)
• Dynamic invocation invoke (fobject, id (append),
  int) where the operation id (append) returns an
  identifier for the method append.

22
OBJECT-BASED MESSAGING

• Although RMI is the preferred way of handling
  communication in object-based distributed
  systems, messaging is also used as an
  alternative.
• There are several object-based messaging systems,
  one of them being the CORBA messaging system.
• CORBA messaging combines method invocation and
  message-oriented communication.
• In asynchronous method invocation, the caller
  continues after initiating the invocation without
  waiting for the result.
• There are two types of asynchronous method
  invocation models in CORBA
• Callback model
• Polling model

23
OBJECT-BASED MESSAGING

• In CORBAs callback model, a client provides an
  object that implements an interface containing
  callback methods.
• These methods can be called by the underlying
  communication system to pass the results of an
  asynchronous invocation.
• Constructing an asynchronous invocation is done
  in two steps
• As an example, consider an object implementing a
  simple interface with just one method.
• int add(in int i, in int j, out int k)

24
OBJECT-BASED MESSAGING

• To methods should be generated.
• void sendcd_add (in int i, in int j)
• // downcall by client
• void replycd_add(in int ret_val, in int k)
• // upcall to client
• Client will need to provide an implementation for
  the callback interface containing method
  replycd_add.
• This method is called by the clients local
  Runtime System (RTS), resulting in an upcall to
  the client application.

25
OBJECT BASED MESSAGING

• CORBAs callback model for asynchronous method
  invocation.

26
OBJECT-BASED MESSAGING

• As an alternative to callbacks, CORBA provides a
  polling model.
• In this model, the client can poll its local
  runtime system (RTS) for incoming results.
• void sendpoll_add(in int i, in int j)
• // called by client
• void replypoll_add(out int ret_val, out int k)
• //called by client
• The method replypoll_add has to be implemented by
  the clients RTS.
• As a note, Java has also its own Java Messaging
  Service (JMS) which is very similar.

27
OBJECT-BASED MESSAGING

• CORBAs polling model for asynchronous method
  invocation.

28
CORBA

• CORBA has been specified by the Object Management
  Group (OMG).

29
CORBA

• Object Request Broker (ORB) It is the
  middleware that handles communications between
  the distributed objects.
• The objects in the system may be implemented
  using different programming languages, and the
  objects may run on different platforms.
• The ORB provides the services to ensure seamless
  object communication.
• The Object Management Group (OMG) defines
  approximately 15 services. Some examples of these
  services are
• Naming service it is a directory service that
  allows objects to be named and discovered.

30
CORBA

• Notification service allows objects to notify
  other objects that some event has occurred.
  Objects may register their interest in a
  particular event with the service, and when that
  event occurs, they are automatically notified.
  For example, the system may have a print spooler
  that queues documents to be printed and a number
  of printer objects. The spooler can register that
  it is interested in an end-of-printing event
  from a printer object.
• Transaction service provides transactions and
  rollback on failure. Transaction are a
  fault-tolerant facility that supports recovery
  from errors during an update operations. If an
  object update operation fails, then the object
  state can be rolled back to its state before the
  update was started.

31
CORBA

• Interface Definition Language (IDL)
  Language-neutral interface definition language of
  a CORBA object.
• If an object wishes to use services provided by
  another object, then it accesses these services
  through the IDL interface.
• Unlike C or Java, IDL is not a programming
  language. Its sole purpose is to allow object
  interfaces to be defined in a manner that is
  independent of any particular programming
  language. An example is
• interface Employee
• long number ()
• Language mappings specify how IDL is translated
  into different programming languages.

32
CORBA

• The calling object o1 has an associated IDL stub
  that defines the interface of the object
  providing the service.
• The object providing the service o2 has an
  associated IDL skeleton that links the interface
  to the implementation.
• When a service is called through the interface
  skeleton translates this into a call to the
  service in whatever implementation language is
  used.

33
CORBA

• The ORB handles object communications. It knows
  of all objects in the system and their
  interfaces.
• Using an ORB, the calling object binds an IDL
  stub that defines the interface of the called
  object.
• Calling this stub results in calls to the ORB
  which then calls the required object through a
  published IDL skeleton that links the interface
  to the service implementation.

34
CORBA

• Static invocation and dispatch IDL is
  translated into language-specific stubs and
  skeletons that are compiled into applications.
• Dynamic invocation and dispatch (Dynamic
  Invocation Interface, DII) construction and
  dispatch of CORBA requests at runtime rather than
  compile time. This approach requires access to
  services than can supply information from the
  interface repository to IDL definitions.

35
CORBA

• ORB-to-ORB communication is provided by Internet
• Inter-ORB Protocol (IIOP) which allows
  independently
• developed ORBs communicate.

36
CORBA OBJECT REFERENCES

• ORB interoperability requires standardized object
  reference formats.
• CORBA systems support language-independent
  representation of an object reference, which is
  called an Interoperable Object Reference (IOR).
• An IOR contains all the information needed to
  identify a CORBA object.
• IIOP is a protocol for remote method invocations
  in CORBA environment.

37
CORBA OBJECT REFERENCES

• The organization of an IOR with specific
  information for IIOP.

38
CORBA OBJECT REFERENCES

• Each IOR starts with a repository identifier.
  This identifier is assigned to an interface so
  that it can be stored and looked up in an
  interface repository. It is used for type
  checking or dynamically constructing an
  invocation.
• Tagged profile contains the complete information
  to invoke an object. If the object server
  supports several protocols, information on each
  protocol can be included in a separate tagged
  profile.

39
CORBA OBJECT REFERENCES

• The IIOP profile is identified by a ProfileID
  field.
• IIOP version field identifies the version of IIOP
  used in this profile.
• Host field is a string identifying on which host
  the object is located. The host can be specified
  either by a DNS domain name or IP address.
• The Port field contains the port number to which
  the objects server is listening for incoming
  requests.
• Object key field contains server-specific
  information for de-multiplexing incoming requests
  to the appropriate object.
• Components field optionally may contain security
  information indicating how the reference should
  be handled.

40
JAVA RMI

• Java RMI Application Programming Interface (API)
  has been developed by Sun Microsystems.
• There are two implementations of the API
• Java Remote Method Protocol (JRMP) Java
  specific protocol for looking up and referencing
  remote objects. It only support objects running
  inside the Java Virtual Machines (JVM).
• RMI-IIOP Combination of Java and CORBA
  technologies, and it runs over the IIOP protocol.
  It is part of Java 2 Enterprise Edition (J2EE)
  platform to provide enterprise platform
  interoperability.

41
JAVA RMI

• When a reference to a remote object is received,
  a new proxy is created.
• When the reference to the remote object is no
  longer needed, the proxy is deleted.
• Define a Remote Interface
• extends java.rmi.Remote
• Define a class that implements the Remote
  Interface
• extends java.rmi.UnicastRemoteObject

42
JAVA RMI-INTERFACE

• Calculator interface example which defines all
  of the remote features offered by the service
• Sourcehttp//java.sun.com/developer/onlineTrainin
  g/rmi/RMI.html (The full description of
  developing a RMI Calculator Application).
• public interface Calculator
• extends java.rmi.Remote
• public long add(long a, long b)
• throws java.rmi.RemoteException
• public long sub(long a, long b)
• throws java.rmi.RemoteException
• public long mul(long a, long b)
• throws java.rmi.RemoteException
• public long div(long a, long b)
• throws java.rmi.RemoteException

43
JAVA RMI - IMPLEMENTATION

• Next, write the implementation, CalculatorImpl
  class for the remote service. The implementation
  class uses UnicastRemoteObject to link into RMI
  system.
• public class CalculatorImpl
• extends
• java.rmi.server.UnicastRemoteObject
• implements Calculator
• public CalculatorImpl()
• throws java.rmi.RemoteException
• super()
• public long add(long a, long b)
• throws java.rmi.RemoteException
• return a b
• .sub...
• .mul...
• .div...