P.

A COLLEGE OF ENGINEERING AND TECHNOLOGY, POLLACHI-2

DEPARTMENT OF INFORMATION TECHNOLOGY

UNIT II- DISTRIBUTED ENTERPRISE COMMUNICATIONS ENABLING

TWO MARKS

1.What is the use of distributed system

The distributed enterprise systems problem can involve issues such as scalability,
wide-area geographical distribution, and heterogeneous platform interfacing. A
distributed system in the context of information technology is a system composed of
many physically independent computing mechanisms.

2. List the issues in Distributed Systems

Reliable Transport Communications,Language Dependencies,Platform
Dependencies,Client/Server Interfacing,Object Activation Activation,Object Name
Binding Creation and Deletion,Copying and Moving,Event Handling Generation
Persistence Security.

3. Represent the network client model

4. Define STUB and SKELETON

A stub for a remote object is the clients local representative or proxy for the remote
object.The stub hides the serialization of parameters and the network level
communication inorder to present a simple invocation mechanism.
Skeleton is responsible for dispatching the call to the actual remote object
implementation.

5. What are the actions performed when stub method is invoked

 Initilization of the connection with the remote object
 Marshalling the parameters to the remote methods
 Waiting for the result of the method invocation
  Unmarshalling the return value or exception returned
 Returning the value to the caller

6. Define CORBA ?
The Common Object Request Broker Architecture (CORBA) is a language- and
platform neutral body of specifications for building distributed object applications.
CORBA applications are built in such a way that they are largely isolated from the details
of communications code.Common Object Request Broker Architecture represents a
standard model for creating objects and components whose services are to be
distributable to remote clients.

6.Specify the enhancement made in CORBA3.0 rather than using CORBA

CORBA 3.0 will enhance the basic OMA with two fundamental additions:
minimumCORBA and CORBAcomponents. The ORB layer of CORBA most suited for
enterprise applications will known as minimumCORBA. the CORBAcomponents
specification will define a standard set of interfaces to which CORBA components can be
programmed to automatically inherit the services offered by a component container
environment.

7. What is CORBA's Java Enterprise System Role

The ORB will help communications-enable your distributed objects, the
CORBAservices, CORBAfacilities,CORBA Domain Interfaces, and CORBA 3.0's
CORBAcomponents all provide higher-level services and frameworks that help build
entire enterprise applications

8. How is ORB specification done in CORBA

The ORB is really just a set of CORBA specifications. The term ORB actually refers
to a collection of software libraries used either by CORBA clients to access distributed
services or by CORBA servers to make their services distributed. The CORBA server is a
distributed object offering up some of its method calls for remote access. CORBA clients
are those objects that make remote method calls on CORBA servers.

9.Define the IDL specification in CORBA

Interfaces are language-independent descriptions of interfaces to CORBA server
objects. Most ORB vendors or other third-party vendors provide IDL compilers that map
IDL interface specifications into CORBA static interfaces and CORBA client stubs The
CORBA client stubs handle the transformation of calls made on the CORBA static
interfaces into calls that can be made over the wire on a distributed CORBA server.

10.What is the use of marshaling and unmarshaling the data stream

Client stubs handle packing (that is, marshaling) method-call parameters and
unpacking (that is, unmarshaling) method-call return values to and from CORBA
communications protocol message formats. Stubs also handle identifying which method
on a particular CORBA server is being invoked by packing such identifying information
into the marshaled data stream to be sent to the server

11.What is the use of interface repositories in CORBA

Interface Repositories are small databases used in some ORB implementations to
hold the metadata descriptions of CORBA server interfaces in a machine-readable
version of the CORBA Interface Definition Language. Interface Repositories have a
standard API callable by CORBA clients and are also used by DII implementations.
12.What are the two different protocols for CORBA based application
The General Inter-Orb Protocol (GIOP) and Internet Inter-Orb Protocol (IIOP)
represent the communications layer above TCP/IP for CORBA-based applications. Both
protocols offer the capability to build scalable CORBA servers. GIOP defines a means
for mapping marshaled IDL data into a common way to represent data over the wire and
a set of message formats encapsulating the request and reply semantics of distributed
calls. IIOP maps GIOP message data into TCP/IP connection behavior.

13.Specify the header format present in GIOP

. The header format simply consists of these elements:
• Four bytes of characters always of the form: GIOP.
• Two GIOP protocol version numbers.
• A Boolean value indicating the byte order of the message (used in GIOP v1.0
messages only).
• A byte of bit flags used to indicate things like byte ordering, as well as whether this
message is fragmented into multiple subsequent messages (used in GIOP v1.1 and
v1.2 messages).
• A single byte message type identifier.
• The size of the message following the header.

14.When will the Naming Service be used by CORBA

Naming is the principal mechanism for locating objects via a human-readable
name. The Naming Service maps these human-readable names to object references.
Resolving a name means obtaining an object reference associated with the name. Binding
a name means to create a name to-object relation. A name binding is always defined in
terms of naming context.

15.What are the services provided by the CORBAfacilities

CORBAfacilities represent higher-level and more application-specific services and
frameworks used in building distributed systems than is the case with CORBAservices.
CORBAfacilities can provide component services such as email, printing, and
globalpositioning information. CORBAfacilities are further broken down into two
categories: Horizontal Common Facilities and Vertical Market Facilities.

16.What are the steps involved in CORBA Development Process

Define your IDL interface, Compile your IDL file, Implement the CORBA server,
Implement a CORBA server registrar, Possibly register interfaces with an Interface
Repository, Implement the CORBA client

17.Define RMI
The Remote Method Invocation platform is a Java-centric distributed object
communications model in Java. By using the RMI packages and infrastructure, RMI-
based Java clients can remotely invoke methods on RMI-based Java server objects. RMI
is a purely distributed object communications model. RMI allows for client and server
passing of objects as method parameters and return values either by value or by
reference.

18. What are the set of tools that are used to implement RMI applications
• RMI Compiler(rmic):
• IDL-to-Java Compiler(idlj):
• RMI Registry(rmiregistry)
• RMI/IIOP Naming Service(tnameserv):
• RMI Activation Daemon(rmid):

19.How can be COM defined as component interface model

COM can defined as a component interface model for Windows-based applications.
COM clients can make use of such components by interfacing with COM libraries to
obtain component handles and then making calls to such interfaces, which in turn map to
local procedure calls. Such local calls map to a call on the actual COM component
service. Although COM interfaces were defined at a binary level in the past, COM now
has evolved to enable the definition of components using higher-level language
interfaces.

20.What are the steps involved in client side DCOM

 On the client side of DCOM, a DCOM client talks with the DCOM libraries to
create an instance of a DCOM object interface
 The DCOM libraries then consult the Windows Registry to extract information on
how to create and find such an object.
 The activation information will be preregistered with the Windows Registry.
Information extracted from the Registry identifies a remote DCOM component
location. This information can point the DCOM libraries to interact with the
Service Control Manager.
 The DCOM libraries consult a Service Control Manager to induce the activation
of a remote DCOM object instance

21.DCOM Development Process

Define your IDL interface, Generate your GUIDs, Generate a type library, Generate
Java bindings, Implement the DCOM server interfaces, Register the DCOM server,
Implement the DCOM client, Register the DCOM client-side interfaces, Run the Client

22.What is the communication messaging model available in RMI

 The messaging model available to RMI is JRMP and IIOP
 The myRemoteImpl is defined and UnicastRemoteObject supports remote
reference in JRMP
 The difference between declaring an RMI/IIOP server and declaring an
RMI/JRMP server is to extend the javax.rmi.PortableRemoteObject class instead
of the UnicastRemoteObject class.
 Thus, the MyRemoteImpl for RMI/IIOP can have the same method signatures
exception throwing and the same method implementations. RMI/IIOP servers can
also export themselves as a remote server object using the exportObject() method
on PortableRemoteObject instead of subclassing PortableRemoteObject.

23.What is the difference between Bind and Rebind methods

The server registrar can use the static Naming.bind() or Naming.rebind() method to
register an instantiated server object implementation with a name in the RMI registry.
The difference between bind() and rebind() is that bind() throws an
AlreadyBoundException if an object of that name is registered with the RMI registry,
whereas rebind() replaces any objects already bound with that name. The Naming class
actually uses a java.rmi.registry.Registry interface to an object that talks with the
associated rmiregistry instance running.