CBT

IF362- COMPONENT BASED TECHNOLOGY
UNIT -1
BASIC CONCEPTS : SOFTWARE COMPONENTS – COM/DCOM – JAVA BEANS –
ENTERPRISE JAVA BEANS- COBRA – DISTRIBUTED OBJECTS – REQUEST AND
RESPONSE – REMOTE REFERENCE – IDL INTERFACE – PROXY- MARSHALLING.
1. What is mean by COM?

COM is a platform-independent, distributed, object-oriented system for creating binary software
components that can interact. COM is the foundation technology for Microsoft's OLE (compound
documents) and ActiveX® (Internet-enabled components) technologies, as well as others.
2.Where COM is applicable?

COM objects can be created with a variety of programming languages. Object-oriented
languages, such as C++, provide programming mechanisms that simplify the implementation of
COM objects. These objects can be within a single process, in other processes, even on remote
machines.
3.what is mean byCORBA?

Common Object Request Broker Architecture (CORBA) is an architecture and specification for
creating, distributing, and managing distributed program objects in a network.
4.What is the purpose of CORBA?

It allows programs at different locations and developed by different vendors to communicate in a
network through an "interface broker."
5.How CORBA was developed?

CORBA was developed by a consortium of vendors through the Object Management Group
(OMG), which currently includes over 500 member companies. Both International Organization
for Standardization (ISO) and X/Open have sanctioned CORBA as the standard architecture for
distributed objects (which are also known as components).
6.what is mean by OMG?

The OMG (Object Management Group) was formed in 1989 by a group of vendors for the
purpose of creating a standard architecture for distributed objects (also known as "components")
in networks. The architecture that resulted is the Common Object Request Broker Architecture
(CORBA).
7.What is mean by ORB?

A central element in CORBA is the Object Request Broker (ORB). An ORB makes it possible for
a client object to make a server request without having to know where in a network the server
object or component is located and exactly what its interfaces are
8.What is mean by components?

. In programming and engineering disciplines, a component is an identifiable part of a larger
program or construction. Usually, a component provides a particular function or group of related
functions. In programming design, a system is divided into components that in turn are made up
of modules.
9.what is mean by component test?

Component test means testing all related modules that form a component as a group to make
sure they work together.
10.what is mean by container?

A component runs within a context called a container. Examples of containers include pages on a
Web site, Web browsers, and word processors.
11.what is mean by javabean?

JavaBeans technology is the component architecture for the Java 2 Platform, Standard Edition
(J2SE). Components (JavaBeans) are reusable software programs that you can develop and
assemble easily to create sophisticated applications. JavaBeans technology is based on the
JavaBeans specification.
12.what is mean by enterprise java bean?

Enterprise JavaBeans (EJB) technology is the server-side component architecture for the Java 2
Platform, Enterprise Edition (J2EE) platform. EJB technology enables rapid and simplified
development of distributed, transactional, secure and portable applications based on Java
technology.
13.what is mean by proxy?

a person authorized to act for another person, or upon request by another person .
14.what is mean by proxyserver?

A proxy server is a computer network service that allows clients to make indirect network
connections to other network services.
15.what is mean by request & response?

Client sends request(processing information) to server.server validates that request ,if it validated
then it will send response to client.
16.what is the use of COM?

COM is used in applications such as the Microsoft Office Family of products. For example COM
OLE technology allows Word documents to dynamically link to data in Excel spreadsheets and
COM Automation allows users to build scripts in their applications to perform repetitive tasks or
control one application from another.
17. What is mean by marshalling?
Converting request & response into suitable format for transmission from client to server.
18.What is mean by objects?
It is a real time entity. it may be a person ,a bank account. It has properties and methods.
19.what is mean by distributed objects?
Objects are distributed any where in the client and server,which accessed from any operating
systems.
20.what is the use of java bean?
• It is a usable software. so by which we can utilize software at more than times.
• It is a platform neutral so we can use this language in platform.

• It is used for build applications for software projects.
21.what is the use of RMI?
EJBs are based conceptually on the Java Remote Method Invocation (RMI) model. For example,
remote object access and parameter passing for EJBs follow the RMI specification.
22.what are the CORBA features?
• It specifies an interface description language (IDL), that allows you to specify the
interfaces to objects. IDL object interfaces describe, among other things:
o The data that the object makes public.
o The operations that the object can respond to, including the complete signature
of the operation. CORBA operations are mapped to Java methods, and the IDL operation
parameter types map to Java datatypes.
o Exceptions that the object can throw. IDL exceptions are also mapped to Java
exceptions, and the mapping is very direct.
23.what is mean by ORB?
The object request broker, or ORB, is the fundamental part of a CORBA implementation. It is
the ORB that makes it possible for a client to send messages to a server, and the server to
returns values to the client. The ORB handles all communication between a client and a
server object.
24.what is mean by IDL?
IDL is the language that CORBA uses to specify its objects. You do not write procedural code
in IDL--its only use is to specify data, methods, and exceptions.
25.what are the parts of IDL?
An IDL interface body contains the following kinds of declarations:
types Type definitions.

exceptions Exception structures that the interface exports.
attributes Any associated attributes exported by the interface.
operations Operations are the methods that the interface supports.
26.What is mean by software component?
"Components are self-contained elements of software that can be controlled dynamically and
assembled to form applications."
27.what are the features of javabeans?

introspection
customization
events
properties
persistence
28.what is mean by introspection?
Allows a builder tool to analyze how a bean works
29.what is mean by customization?
The appearance and behavior of a bean can be customized
30.what is mean by event?
Which is Used to connect beans together.
31.what is the use of properties?
Properties are used for customization and for programmatic use.
32.what is mean by persistence?
Allows the customized state to be saved and reloaded later.
33.what is mean by class library?
Class libraries are an appropriate way of providing functionality that is useful to programmers, but
which doesn't benefit from visual manipulation
34.what are the CORBA services?
• System management
• Task management
• Information management
35.Define OLE?
OLE defines the Component Object Model, which specifies a programming-language-

independent binary standard for object implementations (i.e., it specifies what the implementation
of the objects has to look like).
36.Define interface?
An interface is "a set of semantically related functions implemented on an object" [Bro94a]. The
Component Object Model uses the word "interface" by itself to refer to the definition (signatures)
of those functions.
37.what is mean by binding?
Binding", meaning the choice of a method to be executed in response to a request, is handled by

directly calling the object function identified in the request. OLE does not support implementation
inheritance
38.write about OMG object model?

The OMG Object Model is based on a small number of basic concepts: objects, operations,
types, and sub typing. An object can model any kind of entity, for example a person, a ship, a
document, a department, a tuple, a file, a window manager, or a lexical scanner.
39.what are the system management?
1. Naming Service
2. Life Cycle Service
3. Licensing Service
4. Object Trader Service
40.what are the COM libraries?
CoCreateInstance(Ex) Creates an interface pointer to an uninitialized instance of

(<CLSID>Ã‚Â…) the object class <CLSID>.
CoGetInstanceFromFile Creates a new instance and initializes it from a file.
CoGetInstanceFromStorage Creates a new instance and initializes it from a storage.
CoGetClassObject (<CLSID>Ã‚Â…) Returns an interface pointer to a "class factory object"
that can be used to create one or more uninitialized
instances of the object class <CLSID>.
CoGetClassObjectFromURL Returns an interface pointer to a class factory object for a
given class. If no class is specified, this function will
choose the appropriate class for a specified Multipurpose
Internet Mail Extension (MIME) type. If the desired object
is installed on the system, it is instantiated. Otherwise, the
necessary code is downloaded and installed from a
specified Universal Resource Locator (URL).
41. How IDL working?
ORB interfaces are defined via an Interface Definition Language (IDL). The IDL defines the
interface between one object and the next. OLE (DCOM) uses a similar mechanism, known as
the ODL (Object Definition Language).
42.what are the software components?
1.COM
2.DCOM
3.CORBA
4.JAVABEANS
5.ENTERPRISE JAVABEANS
43.How data’s are marshalling?
marshalling is the process of gathering data from one or more applications or non-contiguous
sources in computer storage, putting the data pieces into a message buffer, and organizing or
converting the data into a format that is prescribed for a particular receiver or programming
interface.
44. where RPC using?
DCOM uses the RPC mechanism to transparently send and receive information between COM
components (i.e., clients and servers) on the same network. DCOM was first made available in
1995 with the initial release of Windows NT 4.
45.what is serialization?
Execution order of transactions in the database. In the Java world, serialization is the storing of
an object's current state on any permanent storage media for later reuse. This is done using
when you use the seriazlizable interface or when using the ObjectOutputStream and
ObjectInputStream classes.
BIG QUESTIONS AND ANSWER
1.what is DCOM& advantages of DCOM?
DCOM (pronounced as in D-COM) is the abbreviation for Distributed Component Object Model,
or Distributed COM. It is an extension of Component Object Model protocol (COM). DCOM was
first introduced by Microsoft in 1996, shortly after COM was introduced. Readers may recall that
COM allows an application to be built from many binary components (objects). DCOM takes that
notion one step further as it allows an application to be built from many COM objects that reside
in different machines. As an extension of COM, DCOM enhances COM's security model, and
defines the process of data transferring across machines. Some characteristics of DCOM are:
• Ability to use existing COM objects: Since DCOM is built on top of COM, all COM-
compliant objects are automatically supported by DCOM. Organizations will be able to
reuse their existing COM objects, reducing the cost of developing new distributed
applications. Furthermore, since the ActiveX control development market is one of the
fastest growing software development markets, this increases the chance that developers
will be able to find an existing component to use with their distributed applications.
• Platform-Neutral: DCOM is platform-neutral where components on different platforms
(that implement DCOM) will be able to inter-operate. Currently, DCOM, like COM, is
available in aforementioned Win32 platforms, Unix, and Macintosh. However, DCOM
remains widely implemented and used only in Win32 platforms. Having said that, this
paper will focus on DCOM’s implementation on Windows NT platform.
• Language-Neutral: Microsoft claims that COM (and thus DCOM) could be written in any
programming language. This is only true to some extent; for example, the standard Java
language cannot work with COM, only Microsoft’s implementation of Java will work with
COM. Within Win32 platforms, C++, Visual Basic, Microsoft VJ++, Delphi are the
languages that are mostly used to write COM objects.
• Transport-Neutral: DCOM currently works with TCP/IP, UDP, IPX/SPX, NetBIOS and
AppleTalk. Since DCOM works with TCP/IP, it is Internet-ready.
2.what are the advantages of DCOM?
Advantages of distributed component computing
Why is there so much hype around distributed computing? - This section will briefly discuss some
of the advantages of distributed component computing. These advantages are applicable to all
distributed computing technologies, including CORBA, RMI and DCOM.
• Speeding up development processes: Since applications can be built from existing

pre-built components, this helps speed up the development process tremendously.
• Improving deployment flexibility: Organizations can easily customize an application for
different areas by simply changing certain components in the overall application.
• Lowering maintenance costs: Certain functions of an application can be grouped into
discreet components, which can be upgraded without retrofitting the whole application.
• Improving scalability: Since applications are built from many objects, the objects can be
redeployed to different machines when needs arise or even multiple copies of the same
components can run simultaneously on different machines.
• Load balancing: The technique of referral-component, where all clients will connect to
the component first and then will be assigned to an appropriate server depending on the
servers’ load by the component, is inherently supported by the distributed component
computing model.
3.explain about DCOM architecture?
DCOM Architecture
We'll now take you on a guided tour through the inner and outer workings of DCOM to show you
how DCOM realizes the promise of easy distributed computing, without compromising flexibility,
scalability, and robustness.
DCOM sits right in the middle of the components of your application; it provides the invisible glue
that ties things together. Figure 1 shows how it all fits together.
Figure 1
Return to Contents
Locating Objects: Activation

"In the beginning, there was . . . a lonely, solitary client component looking for something to do. It
wanted to connect to some other, smarter and stronger components that would help it out of its
isolated existence on the overloaded client machine."
One of the central pieces of COM is a mechanism for establishing connections to components
and creating new instances of components. These mechanisms are commonly referred to as
activation mechanisms.
Creating Objects, Local or Remote

One of the most basic requirements of a distributed system is the ability to create components. In
the COM world, object classes are named with globally unique identifiers (GUIDs). When GUIDs
are used to refer to particular classes of objects, they are called Class IDs. These Class IDs are
nothing more than fairly large integers (128 bits) that provide a collision free, decentralized
namespace for object classes. If a COM programmer wants to create a new object, she calls one
of several functions in the COM libraries, as displayed in Table 1.
Table 1
CoCreateInstance(Ex) Creates an interface pointer to an uninitialized instance of

(<CLSID>Ã‚Â…) the object class <CLSID>.
CoGetInstanceFromFile Creates a new instance and initializes it from a file.
CoGetInstanceFromStorage Creates a new instance and initializes it from a storage.
CoGetClassObject (<CLSID>Ã‚Â…) Returns an interface pointer to a "class factory object"
that can be used to create one or more uninitialized
instances of the object class <CLSID>.
CoGetClassObjectFromURL Returns an interface pointer to a class factory object for a
given class. If no class is specified, this function will
choose the appropriate class for a specified Multipurpose
Internet Mail Extension (MIME) type. If the desired object
is installed on the system, it is instantiated. Otherwise, the
necessary code is downloaded and installed from a
specified Universal Resource Locator (URL).
The COM libraries look up the appropriate binary (dynamic-link library or executable) in the
system registry, create the object, and return an interface pointer to the caller.
For DCOM, the object creation mechanism in the COM libraries is enhanced to allow object
creation on other machines. In order to be able to create a remote object, the COM libraries need
to know the network name of the server. Once the server name and the Class Identifier (CLSID)
are known, a portion of the COM libraries called the service control manager (SCM) on the client
machine connects to the SCM on the server machine and requests creation of this object.
DCOM provides two fundamental mechanisms that allow clients to indicate the remote server
name when an object is created (a third mechanism involves monikers and is described below):
1. As a fixed configuration in the system registry or in the DCOM Class Store (see below for
details)
2. As an explicit parameter to CoCreateInstanceEx, CoGetInstanceFromFile,

CoGetInstanceFromStorage, or CoGetClassObject
External RemoteServerName configuration
The first mechanism is extremely useful for maintaining location transparency: clients should not
know whether a component is running locally or remotely. By making the remote server name
part of the server component's configuration information on the client machine, clients do not
have to worry about maintaining or obtaining the server location. All a client ever needs to know is
the CLSID of the component. It simply calls CoCreateInstance (or CreateObject in Microsoft
Visual Basic® or "new" in Java), and the COM libraries transparently create the correct
component on the preconfigured server. Even existing COM clients that were designed before the
availability of DCOM can transparently use remote components using this mechanism.
Note that a server machine cannot forward creation requests to yet another machine using
RemoteServerName. If machine X uses RemoteServerName to indicate that objects of CLSID C
should be created on machine Y, and if machine Y has a RemoteServerName specified for
CLSID C pointing to machine Z, objects requested by machine X will still only be created on
machine Y. See "Referrals" in the section "Connection Management," for more information.
For many applications, having a single, externally configured server name for each component is
sufficient. It keeps the client's code free from managing this configuration data: if the server name
changes, the registry (or the class store) is changed and the application continues to work without
further action.
The remote server name is stored in the system registry under a new key in
HKEY_CLASSES_ROOT (HKCR):
[HKEY_CLASSES_ROOT\APPID\{<appid-guid>}]
"RemoteServerName"="<DNS name>"
The Class ID entry for the component in turn has a new named value that points to the
Application ID (AppID):
[HKEY_CLASSES_ROOT\CLSID\{<clsid-guid>}]
"AppId"="<appid-guid>"
The AppID concept was introduced as part of the security support in COM and is fully described
in the security section below. The AppID essentially represents a process that is shared by
multiple CLSIDs. All objects in this process share the same default security settings.
The APPID concept can be used to avoid redundant registry keys that all contain the same server
name. CLSIDs that are known to always run on the same server machine (typically because they
are implemented in the same executable or DLL) can all point to the same AppID key and thus all
share the same RemoteServerName registry key.
4.Expalin about enterprise javabeans?
EJB Architecture
The figure above illustrates the architecture of EJB technology. The EJB specification allows for
any kind of client. This is because the specification does not mandate any remote object "wire"
protocol. This means that a server can support multiple protocols like RMI, IIOP (CORBA), and
DCOM. This implies that a client to an EJB server does not have to be written in the Java
language.
The EJB server is a collection of services for supporting an EJB installation. These services
include management of distributed transactions, management of distributed objects and
distributed invocations on these objects, and low-level system services. In short, an EJB server
manages the resources needed to support EJB components. An EJB server provider can provide
an implementation of a container, (described below) and it can provide an API for third party
vendors to plug-in additional EJB containers. The EJB specification allows developers a great
deal of freedom in the design and implementation of servers.
An EJB container is just that: a home for EJB components. A container is where a Bean lives, just
as a record "lives" in a database. It provides a scalable, secure, transactional environment in
which Beans can operate. It is the container that handles the object life cycle, including creating
and destroying an object. The container, among other things, also handles the state management
of Beans.
A container is transparent to the client. There is no client API to it. When a Bean is installed in a
container, the container provides two implementations: an implementation of the Bean's
EJBHome interface, discussed below; and the Bean's remote interface. The container is also
responsible for making the Bean's EJBHome interface available in JNDI, the Java Naming and
Directory Interface1.
To construct a Bean, you must first implement the business methods. For example, if you are
writing a checking account Bean, you might implement a "debit" method as part of its interface.
You must also implement one of two types of EJB interfaces, SessionBean or EntityBean. These
interfaces include methods related to working set management, for example, and are not
exposed to a client.
To this end, when a Bean is installed on a server, the remote interface, usually called a skeleton
in CORBA, is automatically generated. The implementation of the remote interface is called the
EJBObject and is an object that exposes only the remote interface specified by the programmer.
The enterprise Bean class does not implement the remote interface, though it does contain
methods with the same signatures. The EJBObject acts like a proxy, intercepting the remote
object invocations and calling the appropriate methods on the enterprise Bean instance.
An EJB container implements the EJBHome interface of each enterprise Bean installed in the
container. It allows for the creation of a Bean, deletion of a Bean and querying information or
"metadata" about a Bean. The container makes the EJBHome interfaces available to the client
through JNDI. For entity Beans, the EJBHome interface also contains one or more "finder"
methods that allow a client to look up a Bean by a primary key.
5.Explain about Features of enterprise javabeans?
One of the most complex tasks application developers face is writing distributed transactional
applications. A key feature of EJB technology is its support for distributed transactions. It lets you
write applications that access multiple distributed databases, across multiple EJB servers. To
make it easier, the EJB specification allows you to specify the transactional behavior declaratively
at deployment time. The burden of managing transactional behavior is shifted to the server,
specifically the container and EJB server providers. In the event that the Bean developer has
more advanced transactional needs, the Bean can manage the transaction boundaries
programmatically.
Security is a requirement for all enterprise products. The EJB component model leverages off the
core Java platform security model, giving you two ways to set up security. First, you can set the
security descriptor in the Bean's EJB-JAR file. Second, you can use the java.security package to
manage security programmatically.
Another main design feature of EJB is that it is object communication protocol-neutral. This has a
number of benefits. First, it frees the programmer to implement the client part of the application in
the protocol of choice. Second, it allows the EJB server builder to implement the protocols that
are most important to its customer base. For example, an ORB vendor might only implement the
CORBA protocols, while a UNIX system provider might implement RMI and CORBA. In any case,
the protocol used is transparent to the Bean developer who writes only to the Java platform.
The Java platform provides a number of inherent benefits to an EJB server. The most obvious of
these is that once a Bean-based application is written it can run anywhere an enterprise Bean
server is running. An adjunct benefit to this is scalability. If your current EJB application is hitting a
performance wall, you can move your application part-and-parcel to another higher performing
platform's EJB server.
Specialized containers can greatly simplify access to existing enterprise applications. Such a
container can make existing non-Java language applications appear as Beans, enabling the Java
language developer to access these applications without learning the specifics of the existing
systems and applications.
6. What is Enterprise JavaBeans Technology?
The EJB architecture is a server-side component model for the Java platform. Its purpose is to
solve the problems described above by allowing the enterprise developer to focus only on writing
business logic. EJB technology has removed the need to write "plumbing" code. For example, the
enterprise developer no longer needs to write code that handles transactional behavior, security,
connection pooling, or threading, because the architecture delegates this task to the server
vendor.
There are several benefits for the users and implementers of this technology:
• Productivity: Enterprise developers will be more productive using this technology. Not
only do developers get all the productivity gains of developing on the Java platform, but they
also get a boost from the fact that they only have to focus on writing their business logic.
• Industry Support: Customers attempting to build EJB systems will have a range of
solutions to choose from. Enterprise JavaBeans technology has been adopted, supported
and put on the product roadmaps of over 25 companies.
• Protection of Investments: Enterprise JavaBeans technology builds on top of the
systems that exist in the enterprise today. In fact, many of the EJB products coming out will
be built on top of established enterprise systems. The systems that exist in enterprises today
will be running Enterprise JavaBeans components tomorrow.
• Architectural Independence: Enterprise JavaBeans technology insulates the developer
from the underlying middleware. The developer sees only the Java platform. In addition to the
cross-platform benefits described below, this allows the EJB server vendor the opportunity to
improve and change the middleware layer without disturbing a user's EJB applications.
• Server-Side Write Once, Run Anywhere: By leveraging the Java platform, EJB
technology takes the notion of Write Once, Run Anywhere to a new level. It does this by
guaranteeing that an EJB application will run on any server that faithfully provides the
Enterprise JavaBeans APIs.
• 7.explain about enterprise java beans application?
In addition to providing the infrastructure, EJB technology addresses an additional issue. There
are two fundamental models for building enterprise applications. In the first model, the client
begins a session with an object that acts like an application, executing a unit of work on behalf of
the client, possibly including multiple database transactions. In the second model, the client
accesses an object that represents an entity in a database. EJB was designed to be broadly
applicable, and as such covers both these models.
• Session Beans cover the first model. A session Bean is an object that represents a
transient conversation with a client, and it executes database reads and writes for the client.
These database accesses can be in the context of a transaction. A session Bean's fields
contain the state of the conversation and are transient. The implication being that if either the
server or the client crashes, the session Bean is gone. This model is typically used with
database programming languages such as PL/SQL.
• Entity Beans cover the second model. An entity Bean represents data in a database,
along with the methods to act on that data. In a relational database context, for a table of
employee information, there is one Bean for each row in the table. Entity Beans are
transactional, and are long-lived. As long as the data remains in the database, the entity
Bean exists. This model is most typically used today in the object-oriented database market.
Note that in the EJB specification, support for session Beans is mandatory. Support for entity
Beans is currently optional, but will become mandatory for version 2.0 of the specification.
8.What is the relationship between Enterprise JavaBeans and JavaBeans?
Enterprise JavaBeans (EJB) is an API specification for building scalable, distributed, component-
based, multi-tier applications. It leverages and extends the JavaBeans component model to
provide a rich object-oriented transactional environment for developers building enterprise
applications.
Enterprise JavaBeans (EJB) technology is the basis of Java 2 Platform, Enterprise Edition
(J2EE). EJB technology provides the scalable architecture for executing business logic in a
distributed computing environment. J2EE makes the life of an enterprise developer easier by
combining the EJB component architecture with other enterprise technologies to solutions on the
Java platform for seamless development and deployment of server side applications.
Enterprise JavaBeans extends the JavaBeans component model to handle the needs of
transactional business applications.
JavaBeans is a component model for visual construction of reusable components for the Java
platform. Enterprise JavaBeans extends JavaBeans to middle-tier/server side business
applications. The extensions that Enterprise JavaBeans adds to JavaBeans include support for
transactions, state management, and deployment time attributes.
Although applications deploying the Enterprise JavaBeans architecture are independent from the
underlying communication protocol, the Enterprise JavaBeans architecture specifies how
communication among components maps into the underlying communication protocols, such as
CORBA/IIOP.
9.explain about basic concepts of java beans?
Basic Bean Concepts

Individual Java Beans will vary in functionality, but most share certain common defining features.
• Support for introspection allowing a builder tool to analyze how a bean

works.
• Support for customization allowing a user to alter the appearance and
behavior of a bean.
• Support for events allowing beans to fire events, and informing builder
tools about both the events they can fire and the events they can handle.
• Support for properties allowing beans to be manipulated
programatically, as well as to support the customization mentioned above.
• Support for persistence allowing beans that have been customized in an
application builder to have their state saved and restored. Typically persistence is
used with an application builder's save and load menu commands to restore any
work that has gone into constructing an application.
While Beans are intended to be used primarily with builder tools, they need not be. Beans can be
manually manipulated by text tools through programatic interfaces. All key APIs, including support
for events, properties, and persistence, have been designed to be easily read and understood by
human programmers as well as by builder tools.
10. Explain about java beans?
The basic idea of the Beans tutorial is to get you to the point where you can quickly create beans.
You may want to write new beans from scratch, or you may want to take existing components,
applets, or other classes and turn them into beans.
A second goal is to help you understand basic Beans concepts. It can be difficult to assimilate
concepts and turn them into pragmatic programming techniques strictly by reading Beans source
code, API interfaces, or even the Beans specification.
This tutorial is not a replacement for reading the Beans specification. Rather, it is designed to
enhance your comprehension of the specification by providing concrete examples, and step-by-
step guidelines for building and using Beans.
After working through sections fo this tutorial, you will find it helpful to reread corresponding
sections of the Beans specification. You should also study the example source code provided by
the BDK to further your understanding of beans.
If you have used Delphi, or Visual Basic, you are already familiar with the notion of a bean. The
idea is the same; the programming language is different. A Java Bean is a reusable software
component that works with Java. More specifically: a Java Bean is a reusable software
component that can be visually manipulated in builder tools.
Definition: A Java Bean is a reusable software component that can be visually manipulated in
builder tools.
To understand the precise meaning of this definition of a Bean, clarification is required for the
following terms:
• Software component
• Builder tool
• Visual manipulation
Each of these will be addressed in turn.
11. Explain what are reusable software components?
Reusable Software Components

Reusable software components are designed to apply the power and benefit of reusable,
interchangeable parts from other industries to the field of software construction. Other industries
have long profited from reusable components. Reusable electronic components are found on
circuit boards. A typical part in your car can be replaced by a component made from one of many
different competing manufactuers. Lucrative industries are built around parts construction and
supply in most competitive fields. The idea is that standard interfaces allow for interchangeable,
reusable components.
Reusable software components can be simple like familiar push buttons, text fields list boxes,
scrollbars, dialogs, for example
Button Beans
Slider Beans
12. Explain COM?
Microsoft COM (Component Object Model) technology in the Microsoft Windows-family of

Operating Systems enables software components to communicate. COM is used by developers
to create re-usable software components, link components together to build applications, and
take advantage of Windows services. The family of COM technologies includes COM+,
Distributed COM (DCOM) and ActiveX® Controls.
COM is used in applications such as the Microsoft Office Family of products. For example COM
OLE technology allows Word documents to dynamically link to data in Excel spreadsheets and
COM Automation allows users to build scripts in their applications to perform repetitive tasks or
control one application from another.
Microsoft provides COM interfaces for many Windows application services such as Microsoft
Message Queuing (MSMQ) Microsoft Active Directory (AD) and Windows Management and
Instrumentation (WMI).Microsoft recommends that developers use the .NET Framework rather
than COM for new development.
UNIT II
BASIC PATTERNS AND INHERENT ISSUES:
BASIC PATTERNS AND INHERENT ISSUE : FACTORY – BROKER -GARBAGE

COLLECTION ON THE CLIENT AND SERVER- PERSISTENCE OF REMOTE REFERENCE
BOOKS- TRANSACTIONS-CONCURRENCY IN SERVER.OBJECTS – APPLLYING CLIENT /
SERVER OBJECTS – APPLYING CLIENT/SERVER RELATION RECURSIVELY – EVENT
DRIVEN PROGRAMMING.
1.what is mean by remote call?

a remote call is issued in an address space separate to the address space where the target
object resides.
2. What is the goal of client and server abstraction?
An important goal of the client and server abstractions is to make it transparent how "far" the
client and server spaces actually are - whether they reside on the same machine, are on different
nodes of a local network, or even reside on different Internet URLs (thus being "intergalactic"); as
a special case, client and server may share the same address space.
3. How remote method working?
a remote method call is typically divided into the request (asking the service) and response
(bringing results back to the client) parts.
4.what is mean by synchronous and deferred synchronous call?
In principle, from the client’s view, the request and the response corresponding to a remote
method call can be done as one atomic action (synchronous call), or they can be separated,
where the client issues the request and than, as a future action, issues a wait for the response
(deferred-synchronous call).
5.write about IDL interface?
In principle, a client’s code and the server object that is subject to a remote call from the client
can be implemented in different languages and can run on heterogenous architectures. To span
this kind of difference, the interfaces of a server object are specified in an architecture-neutral
Interface Definition Language (IDL). Typically, IDL provides constructs for specification of types,
interfaces, modules, and (in some cases) object state.
6.what is mean by client and server side proxies?
To bridge the conceptual gap between the remote and local style of references, both in the client
and server code, the actual manipulation with remote references is typically encapsulated in
wrapper-like objects known as client-side and server-side proxies.
7.what is mean by marshalling?
Both the request and response of a call are to be converted into a form suitable for transmitting
over the network communication infrastructure (a message, or a TCP socket connection for
transmitting streams might be an example of the infrastructure).
8.what is mean by unmarshalling?
Typically, serialization into a byte stream is the technical base of such conversion. By convention,
this conversion is referred to as marshalling (the reverse process is unmarshalling).
9.what is mean by design pattern?
Design pattern are the "smallest recurring architecture in object oriented systems.
10.write about broker pattern?
The Broker pattern reflects the classical client/server relationship implementation in distributed
environment. The Broker object, which is in this pattern to capture the communication between
Client-side Proxy and corresponding Server-side Proxy. In a loop, the Broker forwards requests
and responses to the corresponding proxies. These requests and responses are encoded in
messages by which the Broker communicates with the proxies.
11.what is the use of class factory?
Factory used to create objects, by which we can form classes to complete any function.
12. What is mean by object?
Object is a real time entity.Ex:It may be a person, bank account.
13. What is mean by class?
A class is a collection of objects. Class is the keyword of class.
14. What is mean by serialization?
It is the process by which the programs are converted into byte stream which is
understand by java virtual machine.
15. What is the use of java virtual machine?
It is the main part of java program. This is used to interpret the java programs. By which
only we can run the java programs.
16. What is mean by garbage collection?
In C program the programmer has care of that memory allocation. in java program no need
to care of memory allocation. If there is no use of object automatically will goes to garbage
collector. It is called garbage collection.
17.write about abstarct factory pattern?
In principle, a factory is an object which creates other object; usually a factory is specialized for
creating objects of a particular type. In distributed environments, factories are typically used on
the server side (after a server has been initialized) to create new objects on a client’s demand.
The main reason for using factories by clients is that the usual language tools like "new" cannot
be used in distributed environments.
18.what is mean by naming?

A naming defines a name space and tools for associating a name with a remote reference.
Classical operations for resolving a name into a remote reference and associating a name with a
remote reference are provided.
19.what is the use of trading?
trading utility (an analogy of yellow pages) to provide a list of remote references to the remote
services possessing the properties which the client indicated as the search key.
20.write about static invocation and delivery?
Static invocation and delivery

When the client was compiled with the knowledge of the requested service interface (e.g., in the
form of an IDL specification), the remote methods’ calls can be encoded statically in the clients
code as calls of the proxy methods (static invocation). This is done fully in compliance with the
proxy pattern (Section Similarly, if the server code was compiled with full knowledge of a
particular service’s interface, the corresponding server-side proxy can contain statically encoded
local calls to service’s methods (static delivery).
21.write about dynamic invocation and delivery?
dynamic invocation and delivery
In principle, the client and the server can be compiled separately; thus they might not always be
current with respect to the static knowledge of available interfaces. Moreover, there are specific
applications in which the exact knowledge of the service interfaces is inherently not available at
compile time (e.g., debugger, viewer, bridge). To overcome this obstacle at the client side, a
proxy is usually provided with an interface (say IRemote) which allows issuing dynamically set-up
calls (dynamic invocation).
22. what are approaches of garbage collection?
three basic approaches to garbage collection of distributed objects: (1) Garbage collection
is done in the under laying platform, e.g. at a distributed operating system level; this approach
remains in an experimental stage [23]). (2) The broker evaluates the number of live references
(e.g., derived from the number of live connections). (3) The server keeps track of the number of
references provided to the outside; each of its clients has to cooperate in the sense that if it does
not need a remote reference any more, it should report this to the server. This technique is called
cooperative garbage collection.
23.what is mean by cooperative garbage collection?
The server keeps track of the number of references provided to the outside; each of its clients
has to cooperate in the sense that if it does not need a remote reference any more, it should
report this to the server. This technique is called cooperative garbage collection.
24.write about transactions?
Transactions
Transaction are an important tool in making distributed object applications robust. Three
consequences of working with distributed objects with respect to transactions should be
emphasized: (1) Because of transitive nature of the client-server relation (Section 2.4.5), nested
transactions are almost inevitable. (2) Employing multiple databases (one type of resources) is
inherent to the distributed environment. This implies that two-phase commit has to be applied
(prepare and commit phases). (3) As objects possess state, they can also be considered as
resources taking part in transactions.
25.what are the basic principles of distributed objects?
• Request & response
• Remote reference
• Marshalling
• Unmarshalling
• IDL interface
• Local representative
26.what is mean by request and response?
In CORBA, a client issues a request to execute a method of an object implementation. There is no
constraint imposed on the location of the client and the requested object implementation (remote object);
they can share an address space, can be located in separate address spaces on the same node, or can be
located on separate nodes. A server (process) can contain implementation of several objects or a single
object, or even provide an implementation of one particular method only. However, typically, a
multithreaded server encapsulates implementations of multiple objects.
27.write about remote reference?
Remote references are called Object References and the target of an Object Reference must be an object
that supports the CORBA::Object IDL interface (such objects are called CORBA objects).
28.Write about IDL interface?
CORBA specifies the CORBA IDL Language and its mapping to several programming languages (e.g.,
C++, Java, Smalltalk). The IDL language provides means for interface definitions; there are no constructs
related to object implementation (object state definitions have been proposed recently by OMG).
29.what is mean by local representative?
Proxy: local representative
Using the Broker Pattern terminology, the client-side proxy code is called IDL stub; the server-side proxy
code is referred to as IDL skeleton. However, in CORBA, the concept "proxy" is used to denote an object
created on the client side which contains the IDL stub plus provides some other functionality, e.g. support
for dynamic invocation.
30.waht is mean by Transmitting request and response?
Marshalling: transmitting request & response
Both request and response are delivered in the canonical format defined by the IIOP protocol which is the
base for the CORBA interoperability over the Internet. On the client side, marshalling is done in the IDL
stub or via the functionality of the dynamic invocation interface . On the server side, unmarshalling is done
in the IDL Skeletons (or in the Dynamic Skeleton Interface, DSI) and partially in the Object Adapter. In
a request (response), Object References can be provided as parameters; remote objects can be passes by
reference. Passing objects by value has been the subject of a resent OMG proposal .
31.what is mean by binding?
The client is bound to the requested server after it receives one of its Object References (and a
corresponding proxy is created.
32.what is mena by persistence remote refernce?
Lifecycles of clients and servers are not synchronized. For example, a server can time-out or crash, and its
client can still hold a remote reference to an object located in the server. Thus, remote references can
persist with respect to the server they target.
33.how many ways to handle distributed objects?
Currently, there are two ways to handle distributed objects in the Java environment: (1) Employing the
Java RMI (Remote Method Invocation) service together with the Java Object Serialization service, or (2)
employing the CORBA IIOP protocol
34.how to employ CORBA IIOP protocol?
(a) in a Java-written client code via stubs which speak
the CORBA IIOP protocol, or (b) directly in a CORBA ORB fully implemented in the Java environment
(e.g., OrbixWeb, VisiBroker)).
35.write about the IDL interface in COM?
The IDL language used by COM/DCOM is called MIDL. Interface specifications are compiled by the
standard Microsoft IDL Compiler (also denoted as MIDL), which creates the code of sever stubs and
client.
36.write about event service?
The event service is a mechanism for communicating information between loosely coupled
applications. Event suppliers are decoupled from event consumers by an event channel that
handles client registration and dissemination of events. Suppliers can therefore focus on
application logic since the channel handles dissemination of events as well as error situations
such as slow or unavailable event consumers.
37. Write about synchronous communications?
Bit stream is delivered with a fixed delay and given error rate .Each bit reaches the destination
with the same time delay after leaving the source
38. Write about Asynchronous communications?

Asynchronous communications
Bit stream is divided into packets are received with varying delays, so packets can arrive out of
order Some packets are not received correctly .
39. What are the types of Transparencies available in CORBA?
1) Location transparency - A remote object appears the same as a local object
An Object Request Broker (ORB) is used to locate objects
2)Language transparency - remote object do not have to be implemented in the same
language (Java, C++, Smalltalk) as local objects
40. What is location transparency in CORBA?
Location transparency -A remote object appears the same as a local object
An Object Request Broker (ORB) is used to locate objects
41. What is Language transparency in CORBA?
Language transparency- remote object do not have to be implemented in the same language
(Java, C++, Smalltalk) as local objects.
42.write about CORBA basic pattern?
The CORBA architecture very much follows the Broker pattern. The Broker object in the Broker
Pattern is mapped as the ORB Core; it is employed for establishing the connection between a client and
a server. The code of the Client-side Proxy of the Broker pattern is reflected as an IDL stub (and DII stub,
the code for dynamic invocations), and the code of the Server-side Proxy is reflected in POA (
IDL skeleton, and DSI skeleton serving for dynamic delivery).
43.what are the inherent issues?
• Server objects garbage collection problem
• Persistent remote references
• Transactions
• Concurrency in server objects
• Applying client-server relation transitively
• Reactive programming
44.what is mean by reactive programming?
Reactive programming used to support the Observer (Publisher-Subscriber) pattern, Java Beans
event model is defined in the Java environment. The basic idea behind these abstractions is that
a Publisher (a Bean) announces a set of "outgoing" interfaces it will call to report on an event
(there are event objects defined for this purpose). A subscriber, event listener, implements some
of the "outgoing" interfaces and subscribes with the Bean to be called on these interfaces.
45. How to avoid concurrent problem in java?
The RMI system can deliver multiple calls at the same time to a particular server object and they will
executed in separate threads. (Nothing can be assumed about the actual dispatching strategy.) The
standard Java synchronization tools are to be employed to handle concurrent access/modification to the
server object’s state. For this purpose, Java provides, e.g. the synchronized clauses, and the wait,
response.
BIG QUESTION AND ANSWERS:
1.Explain about Basic principles of distributed objects?
Request & response

Under the term distributed objects, we usually understand objects which reside in separate
address spaces and methods of which can be subject of remote method calls (a remote call is
issued in an address space separate to the address space where the target object resides). By
convention, the code issuing the call is referred to as the client; the target object is referred to as
the server object (or simply remote object); the set of methods which implements one of the
server object’s interfaces is sometimes designated as a service that this object provides.
Similarly, the process in which the server object is located is referred to as a server.
An important goal of the client and server abstractions is to make it transparent how "far" the
client and server spaces actually are - whether they reside on the same machine, are on different
nodes of a local network, or even reside on different Internet URLs (thus being "intergalactic"); as
a special case, client and server may share the same address space.
Because it is inherently delivered over a network communication infrastructure, a remote method

call is typically divided into the request (asking the service) and response (bringing results back to
the client) parts. In principle, from the client’s view, the request and the response corresponding
to a remote method call can be done as one atomic action (synchronous call), or they can be
separated, where the client issues the request and than, as a future action, issues a wait for the
response (deferred-synchronous call).
Sometimes the response part may be empty (no out parameters and no functional value). In this
case, the corresponding method is usually termed a one-way method. A one-way method can be
called asynchronously, where the client does not have to wait till the call is finished. In a
distributed environment the exactly-once semantics of remote calls is practically impossible to
achieve; real distributed platforms ensure the at-most-once semantics of a synchronous and
deferred-synchronous call (exactly-once semantics in case of a successful call, at-most-once
semantics otherwise); best-effort semantics is ensured for a oneway method.
Remote reference
One of the key issues of remote method calls is referencing of remote objects. Classically, in a
"local" case, in a method call rro.m(p1,p2, ..., pn) , rro contains a reference to the target object, m
identifiesthe method called, and some of the parameters can contain references to other objects
as well; let us suppose only one of the parameters, say pj, contains a reference. However, in a
distributed environment we face the following issue: rro should identify a remote object over the
network, and so should pj. It is obvious that classical addresses will not do as the references, at
least for the following reasons: in addition to the data record of the target object, a reference has
also to identify the node and the server in which the target object resides. Moreover, the target
object may implement more (non polymorphic) interfaces; thus, rro should also identify the
particular interface which the target object implements, and to which m belongs. By convention, a
reference that contains all this information is termed a remote reference. Hence, a remote
reference identifies a service. In addition, representation of a remote reference has to span the
differences in the hardware architectures of the nodes where the objects involved in a
particular remote method call reside.
IDL Interface
In principle, a client’s code and the server object that is subject to a remote call from the client
can be implemented in different languages and can run on heterogenous architectures. To span
this kind of difference, the interfaces of a server object are specified in an architecture-neutral
Interface Definition Language (IDL). Typically, IDL provides constructs for specification of types,
interfaces, modules, and (in some cases) object state. However, there is no means for specifying
code of methods. Usually a mapping from IDL to standard programming languages, such as C++
and Java, is a part of an IDL definition. CORBA IDL and Microsoft MIDL are examples of IDL
languages.
To bridge the conceptual gap between the remote and local style of references, both in the client
and server code, the actual manipulation with remote references is typically encapsulated in
wrapper-like objects known as client-side and server-side proxies. The client-side proxy and the
corresponding serverside proxy communicate with each other to transmit requests and
responses. Basically, the client-side proxy supports the same interface as the remote object
does. The key idea behind proxies [17] is that the client calls a method m of the client-side proxy
to achieve the effect of calling m of the remote object. Thus, the client-side proxy can be
considered a local representative of the corresponding remote object. Similarly, the key task of a
server-side proxy is to delegate and transform an incoming request into a local call form
and to transform the result of the call to a form suitable for transmitting to the client-proxy. Thus, a
serverside
proxy can be considered as the representative of all potential clients of the remote object.
Both the request and response of a call are to be converted into a form suitable for transmitting
over the network communication infrastructure (a message, or a TCP socket connection for
transmitting streams might be an example of the infrastructure). Typically, serialization into a byte
stream is the technical base of such conversion. By convention, this conversion is referred to as
marshalling (the reverse process is unmarshalling). Some authors use these concepts in a
narrower sense, where marshalling/unmarshalling refers only to conversions of the parameters of
a remote call. The key issue of marshalling and unmarshalling is dealing with objects as
parameters. The following two approaches indicate the basic options: passing remote references
and passing objects by value. Suppose rro.m(rp,lp) is a remote call issued by a client C. The rro
reference identifies a proxy which encapsulates a remote reference to a remote object RO in a
server S; the rp represents a remote reference, lp is a reference to a local object which is to be
passed by value. Typically, when the request corresponding to the call is delivered to S, a client-
proxy encapsulating rp is automatically created in S.
On the contrary, a copy of the lp object is created in S.
2Explain about basic patterns?
Design pattern are the "smallest recurring architecture in object oriented systems" [24]. For more
details on design patterns (patterns for short) refer, e.g., to Buschmann et al. [1] or Pree [14], and
particularly to the classical catalog of design patterns by Gamma et al. [3]. We will use informally
just a few of them in the following sections to explain the basic ideas behind the architectural
concept of the distributed object platforms.
Broker pattern
The Broker pattern in Fig.1 reflects the classical client/server relationship implementation in
distributed environment. The role of the Client, Client-side Proxy, Server-side Proxy and Server
was explained in the previous sections, so we can focus on the Broker object, which is in this
pattern to capture the communication between Client-side Proxy and corresponding Server-side
Proxy. In a loop, the Broker forwards requests and responses to the corresponding proxies.
These requests and responses are encoded in messages by which the Broker communicates
with the proxies. Figure 2 demonstrates a typical scenario of object interaction for delivering a
request and receiving a response. Another scenario (Fig.3), illustrates how a server registers the
service it provides with the Broker object. The Broker pattern, as described so far, is a Broker
with indirect communication between proxies. In the typical modification of the Broker pattern
referred to as Broker with direct communication, the Client-side Proxy and the corresponding
Server-side Proxy communicate directly after a communication channel was initially established.
A Bridge
object is used to communicate with other Brokers.
Proxy pattern
The essence of the proxy idea (Sect. 2.1.4, 2.2.1) is captured in Fig.4. Both the Proxy and
Original classes support the same interface defined by AbstractOriginal. A typical scenario of
interaction among instances of these objects is depicted in Fig. 5.
Abstract Factory pattern
In principle, a factory is an object which creates other object; usually a factory is specialized for
creating objects of a particular type. In distributed environments, factories are typically used on
the server side (after a server has been initialized) to create new objects on a client’s demand.
The main reason for using factories by clients is that the usual language tools like "new" cannot
be used in distributed environments. In a routine scenario the client issues a request to an object
factory to create a new object; the object factory returns a remote reference of the newly created
object. Typically, the created object resides in the same server as does the Object Factory
involved in the request. The essence of the factory idea is captured by the Abstract Factory
pattern (Fig.6). In particular, it illustrates that a Concrete Factory is devoted to
creation of products of specific types.
3.How to Provide and employing a service?
Registering a service with broker
In order to be remotely accessible, any service provided by a server has to be registered with a
broker. As a result of the registration operation, the broker a creates a remote reference to the
service (i.e. to a particular interface of the corresponding remote object). The remote reference is
returned to the server and,e.g., can be registered with a naming and/or trading service (Sections
2.3.2, 2.3.3). Typically, following the Abstract Factory pattern, an object factory residing in the
server would be used to create the new remote object implementing the service being registered.
Naming
Because the remote references are supplied by brokers in scarcely legible form, and so to enable
the use of ordinary names, a distributed object platform typically provides a naming utility (naming
for short).A naming defines a name space and tools for associating a name with a remote
reference. Classical operations for resolving a name into a remote reference and associating a
name with a remote reference are provided. Typical scenarios for a naming implementation
include (a) providing a naming service accessible via a well-known remote reference, (b)
embodying naming in the Broker’s functionality.
Finding a service, trading
For a client, there are two ways to obtain a remote reference which identifies the requested
service. First, it can ask naming to resolve the name the client knows, or, alternatively, the client
can ask a trading utility (an analogy of yellow pages) to provide a list of remote references to the
remote services possessing the properties which the client indicated as the search key. The
typical scenario for trading implementation includes provision of a trading service accessible via a
well-known remote reference.
Binding
As mentioned in Sections 2.1.5, 2.3.2, and 2.3.3., the client can receive a remote reference via
naming or trading, or as a result of another remote method call (in fact if naming and trading are
implemented as services, the client always receives remote references as a result of other
remote methods calls – except for well-known remote references of, e.g., naming and trading
services). It is a general rule of all the distributed object platforms that when a client receives a
remote reference to a service, a proxy is created (if it does not already exist) in the client’s
address space, and the client is provided with reference to the proxy. At the latest with the first
remote call that the client issues via the proxy, the connection between the client and the server
is established (some authors also say that the client is bound to the server).
When the client was compiled with the knowledge of the requested service interface (e.g., in the
form of an IDL specification), the remote methods’ calls can be encoded statically in the clients
code as calls of the proxy methods (static invocation). This is done fully in compliance with the
proxy pattern (Section Similarly, if the server code was compiled with full knowledge of a
particular service’s interface, the corresponding server-side proxy can contain statically encoded
local calls to service’s methods (static delivery).
Dynamic invocation and delivery
In principle, the client and the server can be compiled separately; thus they might not always be
current with respect to the static knowledge of available interfaces. Moreover, there are specific
applications in which the exact knowledge of the service interfaces is inherently not available at
compile time (e.g., debugger, viewer, bridge). To overcome this obstacle at the client side, a
proxy is usually provided with an interface (say IRemote) which allows issuing dynamically set-up
calls (dynamic invocation). The name of the corresponding method is typically invoke(). As an
example, suppose the rop.m(p1, ..., pn) call is to be issued dynamically as the signature of m was
not known at compile time (rop is a reference to the proxy of the remote object). So at compile
time the client code can contain the following call: rop.invoke
(method_name, paramlist_array). Thus before executing the invoke method we have to assign m
to method_name, and fill paramlist_array with the parameters p1, ..., pn. Usually some kind of
introspection is necessary to obtain/check details on the target interface at run time (types and
numbers of method’s parameters, etc.).
Similarly, new objects can be created in a server with interfaces not known at compile time (e.g.,
in a viewer or a bridge). Calls to these objects can be delivered dynamically if these objects are
equipped accordingly. The usual technique employed is the following: Suppose the
rop.m(p1,...,pn) call is to be delivered to the object RO identified by the rop remote reference;
however, the object is located in a server which was compiled without any knowledge of RO’s
interfaces - except for the IRemote interface supported by all remote objects. IRemote contains
the invoke() method which accepts dynamically created calls and forwards them to the actual
methods of RO. Thus to be able to accept dynamic calls, RO has to implement the Invoke
method. The server-side proxy associated with RO is very simple – it supports just the IRemote
interface; therefore the code of the server-side-proxy can be very generic and can be used for
any server object supporting the IRemote interface. Some Broker implementations, e.g. CORBA,
even allow for combining static invocation at the client side with dynamic delivery at the server
side and vice versa (combining dynamic invocation with staticdelivery).
4.Explain about Inherent issues?
Server objects garbage collection problem
The server objects not targeted by any remote reference can be disposed and should be handled
by a garbage collector. As opposed to the classical techniques used in single address space,
garbage collection in distributed environment is a more complex issue that has been the subject
of much research (e.g., Ferreira et al.[2]). We identify the following three basic approaches to
garbage collection of distributed objects: (1) Garbage collection is done in the underlaying
platform, e.g. at a distributed operating system level; this approach remains in an experimental
stage [23]). (2) The broker evaluates the number of live references (e.g., derived from the number
of live connections). (3) The server keeps track of the number of references provided to the
outside; each of its clients has to cooperate in the sense that if it does not need a remote
reference any more, it should report this to the server. This technique is called cooperative
garbage collection.
The approaches (2) and (3) are based on reference counting: once the reference count drops to
zero, the target object can be disposed of. Despite of its simplicity, reference counting suffers
from a serious problem - cyclic referencing among otherwise unreachable object prevents zeroing
of reference counts.
Persistent remote references
Lifecycles of clients and servers are not synchronized. For example, a server can time-out or
crash, and its client can still hold a remote reference to an object located in the server. Thus,
remote references can persist with respect to the server they target. In most of the distributed
object platforms, using a remote reference to an inactive server is solved by an automatic
reactivation of the server. Typically, before the server times-out, it is given a chance to externalize
the state of its objects; after the server is reactivated, its objects can be recreated and their state
renewed (some kind of lazy loading can be employed in the reactivation process).
Transactions
Transaction are an important tool in making distributed object applications robust. Three
consequences of working with distributed objects with respect to transactions should be
emphasized: (1) Because of transitive nature of the client-server relation (Section 2.4.5), nested
transactions are almost inevitable. (2) Employing multiple databases (one type of resources) is
inherent to the distributed environment. This implies that two-phase commit has to be applied
(prepare and commit phases). (3) As objects possess state, they can also be considered as
resources taking part in transactions. It is a well-known problem that if a resource needs another
resource in order to finish its prepare phase, the requests to prepare have to be issued in a
specific order (respecting the implied partial ordering of resources) to avoid deadlock [11,16]. As
an example, consider an object A, which when asked to prepare, is to be stored into a database
B. It is obvious that A cannot prepare after B is requested to prepare. Thus, a transactional
system to be used in distributed object applications should provide some support for dealing
with this problem.
Concurrency in server objects
In the basic variant of the Broker pattern (Section 2.2.1), the Server enters a loop and waits for
incoming requests. In this variant, the Server responds to the requests sequentially. However,
many implementations employ multithreading; the following is an example of this approach: the
Broker, sharing address space with the Server, forwards each of the incoming requests to a
separate thread in the Server (there can be, alternatively, a pool of available threads, a thread
can be created for each request, etc.). As the Server is now multithreaded, a server object may
be subject to invocation of several of its methods simultaneously. Naturally, synchronization tools
have to be applied in code of the Server’s objects in order to avoid race conditions, etc. In
addition, several threads running in the Server may call the Broker at the same, e.g., to register a
newly created object. By convention, a Broker supporting this concurrency is called a
multithreaded Broker.
Applying client-server relation transitively
It is very natural for a server S be become a client of another server S’. Simply an object O in S
contains Object Reference to an object O" in S’. Thus any method of O can invoke a method of
O’’. This very likely happens when a remote reference is passed as a parameter in a request to S.
In fact, we face a transitive application of the master/slave pattern [3]. Furthermore, this is also
the underlying idea of n-tier architectures [13]. Similarly, we can also achieve callbacks from a
server to its client by passing a remote reference of the interface, which is to be the subject of a
callback from the client to the server .
Reactive programming
The advantage of easy passing of remote references as parameters makes it relatively easy to
employ even based (reactive) programming style without introducing specific callbacks
constructs. Most of the distributed object platforms define some abstractions to support this style
of programming with significant comfort. In principle, all of them are based on the Observer
(Publisher-Subscriber) pattern [3]. The basic idea here is that a listener object (Subscriber) can
subscribe to an event source (Publisher) to be notified about and event (asynchronous signal)
occurrence. The Publisher announces what interfaces its listeners have to honor and what
methods of these interfaces will be called to report on an event. This reporting can be just a
notification (one-way method will do), or a callback (some results can be delivered to the
Publisher). One of the key benefits of this approach is that the Publisher does not have to know
its
listeners at compile time; listeners subscribe dynamically.
5.Explain about Distributed objects in CORBA?
Basic principles
Request & response
they can share an address space, can be located in separate address spaces on the same node, or can be
Remote reference
Remote references are called Object References and the target of an Object Reference must be an object
IDL Interface
base for the CORBA interoperability over the Internet (other protocols are defined in the OMG standard
[12] as well, but IIOP prevails). On the client side, marshalling is done in the IDL stub or via the
functionality of the dynamic invocation interface (Section 3.2). On the server side, unmarshalling is done
a request (response), Object References can be provided as parameters; remote objects can be passes by
reference. Passing objects by value has been the subject of a resent OMG proposal [7].
6. Explain about Combining basic principles of CORBA architecture as pattern combination.
The CORBA architecture (Fig.7) very much follows the Broker pattern. The Broker object in the Broker
the code for dynamic invocations), and the code of the Server-side Proxy is reflected in POA (Sect. 3.3.1,
IDL skeleton, and DSI skeleton serving for dynamic delivery. More specifically, the direct communication
variant of the Broker pattern is employed in many of the CORBA implementation (e.g., in Orbix), where
the client stubs directly communicate with a POA. The Interface Repository is used for introspection
(particularly in case of a dynamic invocation and dynamic delivery). The Implementation Repository is
used for reactivation of servers. The CORBA Lifecycle Service [9] employs the Abstract Factory pattern:
In addition to a classical factory, the Lifecycle Service defines also factory finder (returns an object factory
able to create object of a given type) and generic factory (which encapsulates the functionality of multiple
factories).
Providing and employing a service
Registering the object which represents the service is the task of the Object Adapter. Its currently
mandatory version, POA, provides, e.g., the activate_object(), activate() methods to support
registration. In principle, activate_object() registers the object with POA and assigns a new Object
Reference, which will serve for referencing the newly created object; activate() signals that a particular
server (or a particular POA, to be precise) is ready to accept requests. Finally, calling ORB::run() tells
the ORB to enter the main request processing loop.
Naming
Officially there is the CORBA Naming Service which should provide for name spaces and for mappings
among Object References and names. However, in addition to the standard Naming Service, most of the
CORBA implementations provide a vendor specific way to locate objects associated directly with
registering of a service at the server side and a "binding" operation on the client side.
For a client, there are two ways to obtain an Object Reference which identifies the requested service: first,
asking a naming service to resolve a known name into the corresponding Object Reference; second,
asking
the CORBA trading service (in analogy to yellow pages) to provide a list of services (Object References)
that possess the properties used as the search key. Some CORBA implementations (e.g. Orbix and
VisiBroker), provide a proprietary location service. In a sense, this service is a hybrid between naming
and trading. In searching for a service, the client provides a partial information on the service (e.g. using
"incomplete names", providing the interface the target object should support, etc.); however, the location
service does not cover the functionality of the CORBA Naming Service or CORBA Trading Service.
Binding
corresponding proxy is created.
When the client was compiled with knowledge of the requested service IDL specification, the proxy
implements the mapped IDL interface methods. The corresponding code of the proxy is encapsulated in
the IDL stub (Sect. 3.2). Similarly, the corresponding IDL skeleton is the code of the server-side proxy
which implements static delivery.
For dynamic invocations, the proxy contains the create_request() method which returns a Request
object. There is also a way to submit arguments with the request. When creating a request, the Interface
Repository can be consulted for details about the target interface. The actual dynamic invocation is
initiated by calling invoke(), a method of the Request object.
As far as dynamic delivery is concerned, the server-side proxy contains the Dynamic Skeleton code which
delivers the request via the invoke() method supported by the PortableServer::DynamicImplementation
interface. CORBA allows for combining static invocation at the client side with dynamic delivery at the
server side and vice versa. At the server side, the choice between static and dynamic delivery is made by
the server object itself (it can be determined, e.g., as a part of the registration with POA), regardless of
the way a request was created, i.e., via a dynamic or static invocation.
A half-way between static and dynamic invocation is dynamic downloading of stubs which can be applied
in CORBA clients implemented in Java. In this case, the client code can be compiled without employing
the IDL compiler (just the knowledge about the interface form will do).
7. Explain about CORBA’S Inherent issues?
CORBA addresses the garbage collection problem via the third method (with assistance of the clients’
code, the server is supposed to keep track of the number of references to a given object provided to the
outside of the server). It is assumed that if the client to which the reference was provided does not need
it any more, it lets the server know. For this purpose, every CORBA::Object (proxy and the implementation
object are considered as separate entities - both are CORBA::Objects) possesses the duplicate() method
to be called if new reference to this object is to be created. If the reference is not needed any more, the
release() method of ORB is to be called. However, most of the CORBA implementations employ
slightly modified semantics of these methods: every CORBA::Object is associated with its reference
counter, duplicate() increases and release() decreased the counter. If the counter reaches zero the object
(proxy or the implementation object) is disposed of.
Object references themselves should be persistent in principle. In its IIOP format, an Object Reference
contains, in addition to the identification of the target object, the identification of the target machine
(hostname:socket) together with the interface type id. An Object Reference R is valid until the server
deletes the target object of R. However, especially for effectivity reasons, the run of a server S which has
not been answering any request for a time-out period is usually terminated. More specifically, the server’s
loop inherently contained in this operation is terminated after the timeout period expires. Just before being
actually terminated, S can store its state (this also includes some kind externalization of S’s objects, e.g.,
[4]). Thus when a request with R as the target comes via ORB and S has been already terminated, S is
typically reactivated, the target of R is recreated, and its state is internalized again. Currently, the
reactivation of servers is done in a vendor-dependent way (e.g., Orbix uses loaders for this purpose). With
introduction of POA, the reactivation of server has been standardized: a servant manager supplied with
the server assumes the role of reactivating all necessary server objects.
Transactions
There is no implicit support for transactions upon remote objects. On the other hand, the CORBA
Transaction Service (OTS), closely cooperating with the CORBA Concurrency Control Service, has been
specified. The CORBA implementations supporting OTS include Orbix and VisiBroker. The OTS
specification [11] addresses the problem of respecting the partial ordering of resources in the prepare
phase
by introducing synchronization objects which are given a chance to store themselves before the very first
prepare action starts.
In multithreaded servers, standard implementation (language-dependent) synchronization tools are
supposed to be employed in server object to avoid race conditions. Note that the CORBA Concurrency
Control
Service is used at different level of granularity - it provides locking only and was designed in particular
to support locking in nested transaction. The other important point is that the implementation of ORB and
POA has to reflect the multithreading in servers. As multithreading inherently complicates the
implementation, some vendors offer their ORB alternatively in single and multithreaded versions (e.g.,
ORBIX).
Applying client-server relation transitively, callbacks
Applying client-server relation transitively is straightforward in CORBA. Implementing a callback from
a server S to its client C (via the approach mentioned in Section 2.4.5) typically requires the code of C
to include also the library code supporting servers. To avoid deadlock when a callback takes place while
responding a request from C, the client C has to be of multithreaded implementation, or the callback is
to be a one-way (asynchronous) call.
Reactive programming in CORBA is supported by the CORBA Event Service [10]. This service provides
the event channel abstraction. To an event channel, an object can subscribe as an event supplier or event
listener. A supplier generates an event which can be associated with event data. Both push and pull
models
of delivering events to consumers are provided. Thus the CORBA Event Service fully implements the
Observer Pattern. A more sophisticated model of reactive programming, the CORBA Component Model,
(very similar to Java Beans, Section 4.5) is being prepared by OMG [8].
8.Expalin about Distributed Objects in Java?
Basic principles
employing the CORBA IIOP protocol, alternatively: (a) in a Java-written client code via stubs which speak
(e.g., OrbixWeb, VisiBroker)). In this section we limit ourselves to RMI (JDK1.2, [22]).
Request & response
The Java RMI architecture is based on the Broker pattern (Section 2.2.1). In addition to the classical
scenario of a client request targeting a particular interface of a single server object, the RMI architecture
is open to support also, e.g., replication of server objects (transparent to the client request). At present, the
Sun Java RMI implementation includes only simple point-to-point requests and responses based upon the
underlying TCP-based streams; we will further limit ourselves to this variant of RMI. In principle, "server"
means an object extending the RemoteServer class residing in a JVM (Java Virtual Machine) separate (in
general) to the client’s JVM.
Remote reference
Remote references are handles to remote objects (those implementing the Remote interface). Remote
references are not directly accessible; they are encapsulated in proxies (stubs and skeletons, Sect. 4.2). A
key RMI feature is that, from a client’s point of view, a remote reference can always be employed only
via an interface (derived from Remote). This conceptually separates the interfaces and implementations of
objects.
IDL Interface
RMI uses the Java language constructs for interface specification (instead of employing a separate IDL
language). The rmic compiler generates client stub and server skeleton classes to a particular remote object
class from the bytecode.
Anytime a remote reference is provided to a client, a proxy is automatically created (if it does not already
exist). In compliance with the Broker pattern, the proxy supports the same remote interface as the target
interface. The client always works with a local reference to the proxy. As for proxy creating, the basic
strategy (at least in the current Sun Java RMI implementation) is that anytime a remote reference is
brought into a Java address space, a new proxy is created; thus more proxies can coexist in one address
space even though they embed the same remote reference.
RMI uses a proprietary internal format for request and response marshalling. As far as parameter passing
in remote calls is concerned, local objects are passed by copy using the Java object serialization (the
objects have to support the Serializable interface). When a remote object is passed as a parameter (a
reference to a proxy is indicated as the parameter) the proxy itself is passed (serialized); this complies with
the idea of multiple proxies in one address space (Section 4.1.4). As the proxy contains the remote
reference, the RMI specification [22] also says "a remote object is passed by reference".
Combining basic principles: basic patterns
The RMI architecture is organized in three cooperating layers (bottom-up): transport layer, remote
reference layer, and stub/skeleton layer. This very much follows the Broker pattern - in RMI, the Broker
object is implemented by the transport and remote reference layers.
9.Explain about Providing and employing a service in java?
A server object can implement multiple Remote interfaces (those inheriting from Remote). Not very much
reflecting the key RMI policy to strictly separate interfaces and their implementations (Section 4.1.2), a
server object is registered together with all the Remote interfaces it implements. The actual registration
withthe RMI Broker (with the remote reference layer) is done via the exportObject() method of the
UnicastRemoteObject class (e.g., it can be inherited into the Remote object implementation). The result
of the registration is a proxy supporting all of the Remote interfaces the object implements.
Naming
At every node supporting RMI, there is the daemon process called RMI Registry. In principle, an RMI
Registry is a name server which supports a flat name space and registers pairs <name, proxy>
associated
with the Remote objects existing in this node. A Remote object is registered under a chosen name by
calling the operation bind() (or rebind()) of the RMI Registry at a particular node. The RMI Registry
is accessible form the outside of the node via its Internet address.
There is no trading or location service in RMI at present.
Binding
To establish a connection from a client C to a server object SO located on a node N and registered there
under the name name_SO, C contacts the RMI Registry at N and via its operation lookup() resolves
name_SO into the registered proxy of SO; a copy of this proxy is delivered to C as the result of the
lookup() operation. Moreover, via introspection C can get from the proxy the information on all of the
Remote interfaces SO (and thus also the proxy) supports. The client can of course receive a proxy as a
result of another remote call not targeting a RMI registry. The client is bound to a server object at the
moment it receives the proxy.
If the client was compiled with knowledge of the requested service interface, it can use the methods of
the corresponding proxy via statically encoded calls. Similarly, the corresponding skeleton at the
serverside
implements static delivery.
There is no support for dynamic delivery on the server side. On the client side, however, dynamic
invocation is always possible via the implicit opportunity to use the introspection features provided for any
object to dynamically set up a call of a particular method in one of the proxy’s interfaces. The key benefit
of the Java code mobility is that a proxy code can be always dynamically downloaded into a running
application (no recompilation is necessary).
10.Explain about Inherent issues of java?
The RMI system uses the second approach mentioned in Section 2.4.1: it keeps track of the live TCP/IP
connections. Basically, each registration of a remote reference in the RMI Registry implies also one live
connection. If the number of live connections reaches zero, the server object is handled as if it was a local
object in the server’s JVM and thus being a subject of the standard local garbage collection process.
Remote references can be persistent in the RMI system in the following sense. If a client uses a remote
reference and the connection from its proxy to the target skeleton does not exist any more, the
corresponding server object can be reactivated supposing it is activatable (via the exportObject()
method of the Activatable class). In the current Sun Java RMI implementation, an activatable object AO
can register with the RMID (RMI Daemon) running at its node, and, consequently, a remote reference
to AO will contain also an information on the RMID. In case the remote reference is used and the
corresponding connection to the target skeleton does not exist any more, the RMID indicated in the
reference is contacted instead; the RMID reactivates the server object and provides the client proxy with
an updated remote reference.
Transactions
Recently, the Java Transaction Service (JTS) has been announced. Essentially, JTS is a mapping of the
CORBA Transaction Service (Sect. 3.4.3) to the Java environment.
Following the Reactor pattern [15] in principle, the RMI system can deliver multiple calls at the same time
to a particular server object and they will executed in separate threads. (Nothing can be assumed about
the
actual dispatching strategy.) The standard Java synchronization tools are to be employed to handle
concurrent access/modification to the server object’s state. For this purpose, Java provides, e.g. the
synchronized clauses, and the wait, resp. notify methods.
Applying a client/server relation transitively is straightforward in Java RMI by providing the server with
a remote reference to another server as described in Section 2.4.5. When a callback from a server S to its
client C is implemented this way, deadlock should be avoided by creating a dedicated thread to accept
the
callback in the client (there is no guarantee as for the number of the threads available for delivering
requests, Sect. 4.4.4). As an aside, the Java Beans event model (Sect. 4.5) can also be also employed
for
callbacks (with a significant comfort).
To support the Observer (Publisher-Subscriber) pattern, Java Beans event model is defined in the Java
environment. The basic idea behind these abstraction is that a Publisher (a Bean) announces a set of
"outgoing" interfaces it will call to report on an event (there are event objects defined for this purpose).
A subscriber, event listener, implements some of the "outgoing" interfaces and subscribes with the Bean
[21] to be called on these interfaces. The Bean notifies all of its subscribers by systematically calling the
method, which corresponds to the event being reported, of all these subscribers. The new version of Java
Beans, Glasgow, supports BeanContext services. One the proposed services is the Infobus [20]. The
basic
idea of the Infobus is that, a subscriber does not have to know the particular remote reference of the Bean
notifying of the event in which the subscriber is interested. The subscription targets just the common
"event bus" and addresses the event directly (not a specific source of the event).
11.Explain about Distributed objects in COM/DCOM?
Basic principles
Microsoft’s distributed object infrastructure is based on its Distributed Component Object Model (DCOM)
[6]. It is an enhancement of the Component Object Model (COM) which is a means for component-
baseddevelopment in the Windows environment. While COM supports component interaction on local
machine,
both in one address space (process) and across separate address spaces, DCOM provides similar
functionality across node boundaries. We focus on COM interaction across separate address spaces and
will emphasize some of the key DCOM’s architectural enhancements to COM. An important part of
Microsoft’s object technology is OLE (Object Linking and Embedding); originally designed to support
compound documents, OLE is mainly a library of predefined interfaces and default implementation of
some of them.
In COM, the key concept is COM object. Here "object" is not a classical object, it is a component
composed of (classical) objects and providing a set of interfaces to the outside. Using the terminology of
Sect. 2, a client residing in one address space calls a remote method of an interface of a COM Object
residing in a server (in this paper: server COM object, or server object for short). Each interface of the
server COM object corresponds to one service provided by this object.
Request & response
The COM/DCOM architecture is based on the Broker pattern. In COM, a client issues a request targeting
a particular interface of a server object; the server object can reside in the same process as the client
does
(inprocess server), in a separate process (local server) but on the same node as the client. DCOM
supports clients and servers residing on separate nodes (remote server). In both COM and DCOM,
remote method calls are synchronous. In COM, request and responses are delivered via the Lightweight
Remote Procedure
Calls (LRPC); DCOM uses the Object-Oriented RPCs (ORPCs) developed upon the base of DCE remote
procedure calls from OSF.
Remote reference
Remote references are handles to server objects’ interfaces. Each of the separate interfaces of a server
object is associated with its own remote reference. Remote references are stored in proxy objects. When
used for remote calls, remote references are referred to as binding information, which can contain, for
example, information on the transport protocol, host address, and the port number. When transferred as
a parameter of a remote call, a remote reference is referred to as an Object Reference (OBJREF). In
DCOM. an Object Reference is a tuple <OXID, OID, IPID, binding_info_on_OXID_resolver>. Briefly,
OXID (Object Exporter Identifier is identification of the server, OID identifies the target object, IPID
identifies the target interface, binding_info_on_OXID_resolver identifies the resolver process which can
resolve the rest of the tuple into the corresponding binding information.
IDL Interface
The IDL language used by COM/DCOM is called MIDL. Interface specifications are compiled by the
standard Microsoft IDL Compiler (also denoted as MIDL), which creates the code of sever stubs and
client
proxies. However, the code of stubs and proxies is generated by other Microsoft compilers as well (e.g.,
by Visual C++). It should be emphasized that the binary form of generated interfaces (the physical layout)
is predefined in COM. In addition, MIDL can generate type libraries (analogous to interface repository
entries in CORBA).
Anytime a remote reference is provided to a client, a proxy object is automatically created (if it does not
already exist) in the client’s process. Naturally, in compliance with the Broker pattern, the proxy object
supports the same interface as the target of the remote reference. The client always works with a local
reference to the proxy object. The basic philosophy is that anytime a new remote reference is brought into
a process, a proxy object is created; in principle, there is a proxy object per each interface of a server
object.
COM uses a proprietary internal format for request and response marshalling. As far as parameter
passing
of remote calls is concerned (with DCOM on mind), data are marshalled in a platform independent format
called network data representation. When a reference to a server object’s interface is passed as a
parameter
(a reference to a proxy object is indicated as the parameter), the corresponding tuple <OXID, OID, IPID,
binding_info_on_OXID_resolver> is passed as explained in Section 5.1.2. During this process, the
necessary stub and proxy objects (Section 5.2) are always created automatically.
12.Explain about Combining basic principles& basic patterns of COM/DCOM?
COM/ DCOM closely follows the Broker pattern. The client-side proxy of the Broker pattern is reflected
in a proxy object, and the server-side proxy in a stub object. More specifically, the direct communication
variant of the Broker pattern is employed, as proxies directly communicate with corresponding stubs. The
Abstract Factory pattern plays a very important role in COM/DCOM: In servers, new objects are
instantiated with the help of object factories. In a server, each of the server COM object (component)
classes is associated with an object factory instance residing in the server which creates new server
objects
based on this particular class. (To follow the COM convention, we refer to "object factory" as class
factory.)
Providing and employing a service
Compared to CORBA and JAVA RMI, the basic philosophy of remote references in COM/DCOM is
different: they are not expected to persist; they are not intended to be directly used for reactivation of
servers (the persistent information necessary do reactivate a server can be delegated to a moniker - Sects.
5.3.2, 5.4.2). The basic strategy of working with remote objects is that the client asks a remote factory
residing also in the server for a remote object creation and at the same time indicates the interface used
for accessing the object. During this process the corresponding stub and proxy objects are created. The
proxy object contains the linking information to that particular interface of the server object. If the proxy
object’s reference were not passed as a parameter of another remote call, no registration with "Broker"
would be necessary - the linking information in the proxy object would do. However, if such proxy
object’s reference passing takes place, the corresponding Object Reference has to be passed instead (i.e.,
<OXID, OID, IPID, binding_info_on_OXID_resolver>). In its target node, this tuple has to be resolved
into the linking information. Therefore, a server (object exporter) has to be registered with the OXID
Resolver Process running at its node.
Naming
There are two separate name spaces used in COM/DCOM, each of them dedicated to a particular purpose.
The first name space is global and contains the GIUDs (globally unique identifiers) used (a) to identify
classes of COM objects (these identifiers are called CLSIDs) and (b) to identify interfaces of COM objects
(these identifiers are IIDs). The second, also global name space, names of monikers, contains names of
monikers (persistent objects used to internalize and externalize the state of COM objects). The names of
monikers are based on indication of the URL together with the logical path to data stored on a permanent
storage (e.g., a file of or an object in a COM structured storage).
There is no trading service available in COM/DCOM. However, there is an option one could call
emulation service: a class can emulate the functionality of a set of classes being generic or parametrized
via an "emulation configuration".
Binding
A client can bind to remote service (an interface of a server COM object) in two ways. First, it can ask
a known class factory to create a server object and provide access to its particular interface, reflecting the
basic strategy of work with remote objects. The creation is done by calling the
CreateInstance(...,iid,...) method of the corresponding class factory; iid indicates the required
interfaces of the created COM object. Second, it can use the method BindToObject() of a Moniker
associated with externalized state of a remote object. This method either creates a new COM object and
internalizes its state, or recognizes that such a COM object already exists. In both cases, the final effect
is that the client is provided with a reference to a proxy object supporting the required interface of the
server COM object.
When the client code was compiled with knowledge of the requested service interface, the remote calls
can be encoded statically as calls of the proxy object’s methods. Recall that in COM/DCOM the
granularity of proxies is such that there is a proxy object per each interface of a server object (Section
5.1.4). Similarly, static delivery is done by statically encoded calls executed in the corresponding Stub
object..
As far as dynamic invocation is concerned, COM/DCOM follows very much the approach described in
Sect. 2.3.6. A COM object can support an IDispatch interface (predefined in OLE), the implementation
of which is associated with an "indirect interface" (our concept). As an aside, a description of this
interface’s methods is available through a type library. IDispatch contains the Invoke() method; via its
parameter of type DISPID, a method of the indirect interface can be called (the call is delegated in the
implementation of invoke()). The DISPID value can be obtained from the type library. Similarly, another
parameter of Invoke(), a variant record, supplies the parameters of the delegated call. The supplied
parameters are to be provided in an encoded form (there are rules for encoding both the simple and
composite types).
As opposed to CORBA, in COM the client decides if the delivery of a call will be dynamical or statical.
However, if the call is to be delivered statically, the server object has to support a "classical" interface;
if the call is to be delivered dynamically, the server object has to support an IDispatch interface the
implementation of which delegates calls to the "classical" interface. However, the server COM object does
not have to support both interfaces at the same time. If it supports only the IDispatch interface, the client
is forced to use only dynamic invocation, even though it knows the "classical" interface at compile time.
To achieve flexibility (and to improve efficiency), COM defines dual interfaces. In principle, a dual
interface combines both the "classical" interface and the corresponding IDispatch interface. The dynamic
invocation is in OLE referred to as automation.
13.Explain about Inherent issues of COM/DCOM?
The cooperative garbage collection technique is employed in COM/DCOM (Section 2.4.1). The reference
counting may be, alternatively, applied on a COM object as one entity, or separately for each of its
interfaces. The first variant is the usual approach. However, some of the COM object’s interface
implementation can be associated with large data structures - in a similar case separate reference counting
may be applied in order to dispose the interface implementation as soon as possible.
In COM/DCOM remote references are not persistent. The way to approximate persistence of remote
references and their target server objects is to associate a server COM object with a moniker object and
renew the reference via the moniker’s BindToObject() method as described in Sect. 5.3.4.
Transactions
Through the Microsoft Transaction Server (MTS), transparent addition of transactional capabilities to a
COM object is possible; references to other COM objects are automatically detected and the target COM
objects are made transactional components as well (transitive closures of related COM objects are
evaluated). Nested transaction are supported. The hart of the MTS, the MTS Executive, maintains a pool
of threads to handle requests from clients to (a potentially large) number of transactional COM objects.
There is another pool of threads to handle database connections. As an aside, COM structural storage
operations have been announced to be subject to simple transactions in Windows NT 5.0.
In COM, there are two basic models of threading related to access to the objects made externally available
by servers (to server objects): the apartment model and the free threading model. For a server object,
being
in an apartment means that there is only one thread to call its methods in response to the requests
incoming from clients; in other words, the methods of all its interfaces are implicitly mutually excluded
and no synchronization is necessary. On the contrary, if the free threading model is applied to the address
space a server object resides, the methods of all its interfaces can be called and executed simultaneously
by any number of threads. Appropriate synchronization has to be applied in implementation of these
methods to handle the concurrent access/modification to the server object’s state.
Applying client-server relation transitively is straightforward in COM/DCOM. To avoid deadlock while
emulating a callback from a server S to its client C (via the approach mentioned in Sect. 2.4.5), the
client C has to be of a multithreaded implementation (the free threading model has to be applied at the
client side).
14 .Explain about Distributed objects of RMI?

Basic principles
Request & response
Under the term distributed objects, we usually understand objects which reside in separate address
spaces
and methods of which can be subject of remote method calls (a remote call is issued in an address space
separate to the address space where the target object resides). By convention, the code issuing the call is
referred to as the client; the target object is referred to as the server object (or simply remote object); the
set of methods which implements one of the server object’s interfaces is sometimes designated as a
service that this object provides. Similarly, the process in which the server object is located is referred to
as a server.
An important goal of the client and server abstractions is to make it transparent how "far" the client and
server spaces actually are - whether they reside on the same machine, are on different nodes of a local
network, or even reside on different Internet URLs (thus being "intergalactic"); as a special case, client
and server may share the same address space.
Because it is inherently delivered over a network communication infrastructure, a remote method call is
typically divided into the request (asking the service) and response (bringing results back to the client)
parts. In principle, from the client’s view, the request and the response corresponding to a remote method
call can be done as one atomic action (synchronous call), or they can be separated, where the client
issues
the request and than, as a future action, issues a wait for the response (deferred-synchronous call).
Sometimes the response part may be empty (no out parameters and no functional value). In this case, the
corresponding method is usually termed a one-way method. A one-way method can be called
asynchronously, where the client does not have to wait till the call is finished. In a distributed environment
the exactly-once semantics of remote calls is practically impossible to achieve; real distributed platforms
ensure the at-most-once semantics of a synchronous and deferred-synchronous call (exactly-once
semantics
in case of a successful call, at-most-once semantics otherwise); best-effort semantics is ensured for a
oneway
method.
2.1.2 Remote reference
One of the key issues of remote method calls is referencing of remote objects. Classically, in a "local"
case, in a method call rro.m(p1,p2, ..., pn) , rro contains a reference to the target object, m identifies
the method called, and some of the parameters can contain references to other objects as well; let us
suppose only one of the parameters, say pj, contains a reference. However, in a distributed environment
we face the following issue: rro should identify a remote object over the network, and so should pj. It
is obvious that classical addresses will not do as the references, at least for the following reasons: in
addition to the data record of the target object, a reference has also to identify the node and the server in
which the target object resides. Moreover, the target object may implement more (non polymorphic)
interfaces; thus, rro should also identify the particular interface which the target object implements, and
to which m belongs. By convention, a reference that contains all this information is termed a remote
reference. Hence, a remote reference identifies a service. In addition, representation of a remote
reference
has to span the differences in the hardware architectures of the nodes where the objects involved in a
particular remote method call reside.
2.1.3 IDL Interface
In principle, a client’s code and the server object that is subject to a remote call from the client can be
implemented in different languages and can run on heterogenous architectures. To span this kind of
difference, the interfaces of a server object are specified in an architecture-neutral Interface Definition
Language (IDL). Typically, IDL provides constructs for specification of types, interfaces, modules, and
(in some cases) object state. However, there is no means for specifying code of methods. Usually a
mapping from IDL to standard programming languages, such as C++ and Java, is a part of an IDL
definition. CORBA IDL and Microsoft MIDL are examples of IDL languages.
2.1.4 Proxy: local representative
To bridge the conceptual gap between the remote and local style of references, both in the client and
server code, the actual manipulation with remote references is typically encapsulated in wrapper-like
objects known as client-side and server-side proxies. The client-side proxy and the corresponding
serverside
proxy communicate with each other to transmit requests and responses. Basically, the client-side proxy
supports the same interface as the remote object does. The key idea behind proxies [17] is that the client
calls a method m of the client-side proxy to achieve the effect of calling m of the remote object. Thus, the
client-side proxy can be considered a local representative of the corresponding remote object. Similarly,
the key task of a server-side proxy is to delegate and transform an incoming request into a local call form
and to transform the result of the call to a form suitable for transmitting to the client-proxy. Thus, a
serverside
proxy can be considered as the representative of all potential clients of the remote object.
2.1.5 Marshalling: transmitting request & response
Both the request and response of a call are to be converted into a form suitable for transmitting over the
network communication infrastructure (a message, or a TCP socket connection for transmitting streams
might be an example of the infrastructure). Typically, serialization into a byte stream is the technical base
of such conversion. By convention, this conversion is referred to as marshalling (the reverse process is
unmarshalling). Some authors use these concepts in a narrower sense, where marshalling/unmarshalling
refers only to conversions of the parameters of a remote call.
The key issue of marshalling and unmarshalling is dealing with objects as parameters. The following two
approaches indicate the basic options: passing remote references and passing objects by value. Suppose
rro.m(rp,lp) is a remote call issued by a client C. The rro reference identifies a proxy which
encapsulates a remote reference to a remote object RO in a server S; the rp represents a remote
reference,
lp is a reference to a local object which is to be passed by value. Typically, when the request
corresponding to the call is delivered to S, a client-proxy encapsulating rp is automatically created in S.
On the contrary, a copy of the lp object is created in S.
13.Expalin about Combining basic principles& basic patterns of RMI?
Design pattern are the "smallest recurring architecture in object oriented systems" [24]. For more details
on design patterns (patterns for short) refer, e.g., to Buschmann et al. [1] or Pree [14], and particularly to
the classical catalog of design patterns by Gamma et al. [3]. We will use informally just a few of them
in the following sections to explain the basic ideas behind the architectural concept of the distributed
object
platforms.
2.2.1 Broker pattern
The Broker pattern in Fig.1 reflects the classical client/server relationship implementation in distributed
environment. The role of the Client, Client-side Proxy, Server-side Proxy and Server was explained in the
previous sections, so we can focus on the Broker object, which is in this pattern to capture the
communication between Client-side Proxy and corresponding Server-side Proxy. In a loop, the Broker
forwards requests and responses to the corresponding proxies. These requests and responses are
encoded
in messages by which the Broker communicates with the proxies. Figure 2 demonstrates a typical
scenario
of object interaction for delivering a request and receiving a response. Another scenario (Fig.3), illustrates
how a server registers the service it provides with the Broker object. The Broker pattern, as described so
far, is a Broker with indirect communication between proxies. In the typical modification of the Broker
pattern referred to as Broker with direct communication, the Client-side Proxy and the corresponding
Server-side Proxy communicate directly after a communication channel was initially established. A Bridge
object is used to communicate with other Brokers.
2.2.2 Proxy pattern
The essence of the proxy idea (Sect. 2.1.4, 2.2.1) is captured in Fig.4. Both the Proxy and Original
classes
support the same interface defined by AbstractOriginal. A typical scenario of interaction among instances
of these objects is depicted in Fig. 5.
2.2.3 Abstract Factory pattern
In principle, a factory is an object which creates other object; usually a factory is specialized for creating
objects of a particular type. In distributed environments, factories are typically used on the server side
(after a server has been initialized) to create new objects on a client’s demand. The main reason for using
factories by clients is that the usual language tools like "new" cannot be used in distributed environments.
In a routine scenario the client issues a request to an object factory to create a new object; the object
factory returns a remote reference of the newly created object. Typically, the created object resides in the
same server as does the Object Factory involved in the request. The essence of the factory idea is
captured
by the Abstract Factory pattern (Fig.6). In particular, it illustrates that a Concrete Factory is devoted to
creation of products of specific types.
14.Explain about Providing and employing a service of RMI?
2.3.1 Registering a service with broker
In order to be remotely accessible, any service provided by a server has to be registered with a broker. As
a result of the registration operation, the broker a creates a remote reference to the service (i.e. to a
particular interface of the corresponding remote object). The remote reference is returned to the server
and,
e.g., can be registered with a naming and/or trading service (Sections 2.3.2, 2.3.3). Typically, following
the Abstract Factory pattern, an object factory residing in the server would be used to create the new
remote object implementing the service being registered.
2.3.2 Naming
Because the remote references are supplied by brokers in scarcely legible form, and so to enable the use
of ordinary names, a distributed object platform typically provides a naming utility (naming for short).
A naming defines a name space and tools for associating a name with a remote reference. Classical
operations for resolving a name into a remote reference and associating a name with a remote reference
are provided. Typical scenarios for a naming implementation include (a) providing a naming service
accessible via a well-known remote reference, (b) embodying naming in the Broker’s functionality.
2.3.3 Finding a service, trading
For a client, there are two ways to obtain a remote reference which identifies the requested service. First,
it can ask naming to resolve the name the client knows, or, alternatively, the client can ask a trading utility
(an analogy of yellow pages) to provide a list of remote references to the remote services possessing the
properties which the client indicated as the search key. The typical scenario for trading implementation
includes provision of a trading service accessible via a well-known remote reference.
2.3.4 Binding
As mentioned in Sections 2.1.5, 2.3.2, and 2.3.3., the client can receive a remote reference via naming or
trading, or as a result of another remote method call (in fact if naming and trading are implemented as
services, the client always receives remote references as a result of other remote methods calls - except
for well-known remote references of, e.g., naming and trading services). It is a general rule of all the
distributed object platforms that when a client receives a remote reference to a service, a proxy is created
(if it does not already exist) in the client’s address space, and the client is provided with reference to the
proxy. At the latest with the first remote call that the client issues via the proxy, the connection between
the client and the server is established (some authors also say that the client is bound to the server).
2.3.5 Static invocation and delivery
When the client was compiled with the knowledge of the requested service interface (e.g., in the form of
an IDL specification), the remote methods’ calls can be encoded statically in the clients code as calls of
the proxy methods (static invocation). This is done fully in compliance with the proxy pattern (Section
2.2.2). Similarly, if the server code was compiled with full knowledge of a particular service’s interface,
the corresponding server-side proxy can contain statically encoded local calls to service’s methods (static
delivery).
2.3.6 Dynamic invocation and delivery
In principle, the client and the server can be compiled separately; thus they might not always be current
with respect to the static knowledge of available interfaces. Moreover, there are specific applications in
which the exact knowledge of the service interfaces is inherently not available at compile time (e.g.,
debugger, viewer, bridge). To overcome this obstacle at the client side, a proxy is usually provided with
an interface (say IRemote) which allows issuing dynamically set-up calls (dynamic invocation). The name
of the corresponding method is typically invoke(). As an example, suppose the rop.m(p1, ..., pn) call
is to be issued dynamically as the signature of m was not known at compile time (rop is a reference to the
proxy of the remote object). So at compile time the client code can contain the following call: rop.invoke
(method_name, paramlist_array). Thus before executing the invoke method we have to assign m to
method_name, and fill paramlist_array with the parameters p1, ..., pn. Usually some kind of
introspection is necessary to obtain/check details on the target interface at run time (types and numbers
of method’s parameters, etc.).
Similarly, new objects can be created in a server with interfaces not known at compile time (e.g., in a
viewer or a bridge). Calls to these objects can be delivered dynamically if these objects are equipped
accordingly. The usual technique employed is the following: Suppose the rop.m(p1,...,pn) call is to
be delivered to the object RO identified by the rop remote reference; however, the object is located in a
server which was compiled without any knowledge of RO’s interfaces - except for the IRemote interface
supported by all remote objects. IRemote contains the invoke() method which accepts dynamically
created calls and forwards them to the actual methods of RO. Thus to be able to accept dynamic calls,
RO
has to implement the Invoke method. The server-side proxy associated with RO is very simple - it
supports just the IRemote interface; therefore the code of the server-side-proxy can be very generic and
can be used for any server object supporting the IRemote interface.
Some Broker implementations, e.g. CORBA, even allow for combining static invocation at the client side
with dynamic delivery at the server side and vice versa (combining dynamic invocation with static
delivery).
15Explain about Inherent issues of RMI?
The server objects not targeted by any remote reference can be disposed and should be handled by a
garbage collector. As opposed to the classical techniques used in single address space, garbage
collection
in distributed environment is a more complex issue that has been the subject of much research (e.g.,
Ferreira et al.[2]). We identify the following three basic approaches to garbage collection of distributed
objects: (1) Garbage collection is done in the underlaying platform, e.g. at a distributed operating system
level; this approach remains in an experimental stage [23]). (2) The broker evaluates the number of live
references (e.g., derived from the number of live connections). (3) The server keeps track of the number
of references provided to the outside; each of its clients has to cooperate in the sense that if it does not
need a remote reference any more, it should report this to the server. This technique is called cooperative
garbage collection.
The approaches (2) and (3) are based on reference counting: once the reference count drops to zero, the
target object can be disposed of. Despite of its simplicity, reference counting suffers from a serious
problem - cyclic referencing among otherwise unreachable object prevents zeroing of reference counts.
Lifecycles of clients and servers are not synchronized. For example, a server can time-out or crash, and
its client can still hold a remote reference to an object located in the server. Thus, remote references can
persist with respect to the server they target. In most of the distributed object platforms, using a remote
reference to an inactive server is solved by an automatic reactivation of the server. Typically, before the
server times-out, it is given a chance to externalize the state of its objects; after the server is reactivated,
its objects can be recreated and their state renewed (some kind of lazy loading can be employed in the
reactivation process).
Transactions
Transaction are an important tool in making distributed object applications robust. Three consequences of
working with distributed objects with respect to transactions should be emphasized: (1) Because of
transitive nature of the client-server relation (Section 2.4.5), nested transactions are almost inevitable.
(2) Employing multiple databases (one type of resources) is inherent to the distributed environment. This
implies that two-phase commit has to be applied (prepare and commit phases). (3) As objects possess
state,
they can also be considered as resources taking part in transactions.
It is a well-known problem that if a resource needs another resource in order to finish its prepare phase,
the requests to prepare have to be issued in a specific order (respecting the implied partial ordering of
resources) to avoid deadlock [11,16]. As an example, consider an object A, which when asked to prepare,
is to be stored into a database B. It is obvious that A cannot prepare after B is requested to prepare.
Thus,
a transactional system to be used in distributed object applications should provide some support for
dealing
with this problem.
In the basic variant of the Broker pattern (Section 2.2.1), the Server enters a loop and waits for incoming
requests. In this variant, the Server responds to the requests sequentially. However, many
implementations
employ multithreading; the following is an example of this approach: the Broker, sharing address space
with the Server, forwards each of the incoming requests to a separate thread in the Server (there can be,
alternatively, a pool of available threads, a thread can be created for each request, etc.). As the Server is
now multithreaded, a server object may be subject to invocation of several of its methods simultaneously.
Naturally, synchronization tools have to be applied in code of the Server’s objects in order to avoid race
conditions, etc. In addition, several threads running in the Server may call the Broker at the same, e.g.,
to register a newly created object. By convention, a Broker supporting this concurrency is called a
multithreaded Broker.
It is very natural for a server S be become a client of another server S’. Simply an object O in S contains
Object Reference to an object O" in S’. Thus any method of O can invoke a method of O’’. This very
likely happens when a remote reference is passed as a parameter in a request to S. In fact, we face a
transitive application of the master/slave pattern [3]. Furthermore, this is also the underlying idea of n-tier
architectures [13]. Similarly, we can also achieve callbacks from a server to its client by passing a remote
reference of the interface, which is to be the subject of a callback from the client to the server (see also
Section 2.5).
The advantage of easy passing of remote references as parameters makes it relatively easy to employ
evenbased
(reactive) programming style without introducing specific callbacks constructs. Most of the
distributed object platforms define some abstractions to support this style of programming with significant
comfort. In principle, all of them are based on the Observer (Publisher-Subscriber) pattern [3]. The basic
idea here is that a listener object (Subscriber) can subscribe to an event source (Publisher) to be notified
about and event (asynchronous signal) occurrence. The Publisher announces what interfaces its listeners
have to honor and what methods of these interfaces will be called to report on an event. This reporting
can be just a notification (one-way method will do), or a callback (some results can be delivered to the
Publisher). One of the key benefits of this approach is that the Publisher does not have to know its
listeners at compile time; listeners subscribe dynamically.
16. Distributed objects in CORBA
3.1 Basic principles
3.1.1 Request & response
they can share an address space, can be located in separate address spaces on the same node, or can
be
Remote references are called Object References and the target of an Object Reference must be an
object
3.1.3 IDL Interface
base for the CORBA interoperability over the Internet (other protocols are defined in the OMG standard
[12] as well, but IIOP prevails). On the client side, marshalling is done in the IDL stub or via the
functionality of the dynamic invocation interface (Section 3.2). On the server side, unmarshalling is done
a request (response), Object References can be provided as parameters; remote objects can be passes
by
reference. Passing objects by value has been the subject of a resent OMG proposal [7].
3.2 Combining basic principles: CORBA architecture as pattern combination.
The CORBA architecture (Fig.7) very much follows the Broker pattern. The Broker object in the Broker
the code for dynamic invocations), and the code of the Server-side Proxy is reflected in POA (Sect. 3.3.1,
IDL skeleton, and DSI skeleton serving for dynamic delivery. More specifically, the direct communication
variant of the Broker pattern is employed in many of the CORBA implementation (e.g., in Orbix), where
the client stubs directly communicate with a POA. The Interface Repository is used for introspection
(particularly in case of a dynamic invocation and dynamic delivery). The Implementation Repository is
used for reactivation of servers. The CORBA Lifecycle Service [9] employs the Abstract Factory pattern:
In addition to a classical factory, the Lifecycle Service defines also factory finder (returns an object factory
able to create object of a given type) and generic factory (which encapsulates the functionality of multiple
factories).
3.3 Providing and employing a service
Registering the object which represents the service is the task of the Object Adapter. Its currently
mandatory version, POA, provides, e.g., the activate_object(), activate() methods to support
registration. In principle, activate_object() registers the object with POA and assigns a new Object
Reference, which will serve for referencing the newly created object; activate() signals that a particular
server (or a particular POA, to be precise) is ready to accept requests. Finally, calling ORB::run() tells
the ORB to enter the main request processing loop.
3.3.2 Naming
Officially there is the CORBA Naming Service which should provide for name spaces and for mappings
among Object References and names. However, in addition to the standard Naming Service, most of the
CORBA implementations provide a vendor specific way to locate objects associated directly with
registering of a service at the server side and a "binding" operation on the client side.
For a client, there are two ways to obtain an Object Reference which identifies the requested service: first,
asking a naming service to resolve a known name into the corresponding Object Reference; second,
asking
the CORBA trading service (in analogy to yellow pages) to provide a list of services (Object References)
that possess the properties used as the search key. Some CORBA implementations (e.g. Orbix and
VisiBroker), provide a proprietary location service. In a sense, this service is a hybrid between naming
and trading. In searching for a service, the client provides a partial information on the service (e.g. using
"incomplete names", providing the interface the target object should support, etc.); however, the location
service does not cover the functionality of the CORBA Naming Service or CORBA Trading Service.
3.3.4 Binding
corresponding proxy is created, Section 2.3.4).
When the client was compiled with knowledge of the requested service IDL specification, the proxy
implements the mapped IDL interface methods. The corresponding code of the proxy is encapsulated in
the IDL stub (Sect. 3.2). Similarly, the corresponding IDL skeleton is the code of the server-side proxy
which implements static delivery.
For dynamic invocations, the proxy contains the create_request() method which returns a Request
object. There is also a way to submit arguments with the request. When creating a request, the Interface
Repository can be consulted for details about the target interface. The actual dynamic invocation is
initiated by calling invoke(), a method of the Request object.
As far as dynamic delivery is concerned, the server-side proxy contains the Dynamic Skeleton code which
delivers the request via the invoke() method supported by the PortableServer::DynamicImplementation
interface. CORBA allows for combining static invocation at the client side with dynamic delivery at the
server side and vice versa. At the server side, the choice between static and dynamic delivery is made by
the server object itself (it can be determined, e.g., as a part of the registration with POA), regardless of
the way a request was created, i.e., via a dynamic or static invocation.
A half-way between static and dynamic invocation is dynamic downloading of stubs which can be applied
in CORBA clients implemented in Java. In this case, the client code can be compiled without employing
the IDL compiler (just the knowledge about the interface form will do).
16.Expalin about Distributed Objects in Java?
4.1 Basic principles
employing the CORBA IIOP protocol, alternatively: (a) in a Java-written client code via stubs which speak
(e.g., OrbixWeb, VisiBroker)). In this section we limit ourselves to RMI (JDK1.2, [22]).
4.1.1 Request & response
The Java RMI architecture is based on the Broker pattern (Section 2.2.1). In addition to the classical
scenario of a client request targeting a particular interface of a single server object, the RMI architecture
is open to support also, e.g., replication of server objects (transparent to the client request). At present,
the
Sun Java RMI implementation includes only simple point-to-point requests and responses based upon the
underlying TCP-based streams; we will further limit ourselves to this variant of RMI. In principle, "server"
means an object extending the RemoteServer class residing in a JVM (Java Virtual Machine) separate (in
general) to the client’s JVM.
Remote references are handles to remote objects (those implementing the Remote interface). Remote
references are not directly accessible; they are encapsulated in proxies (stubs and skeletons, Sect. 4.2).
A
key RMI feature is that, from a client’s point of view, a remote reference can always be employed only
via an interface (derived from Remote). This conceptually separates the interfaces and implementations
of
objects.
4.1.3 IDL Interface
RMI uses the Java language constructs for interface specification (instead of employing a separate IDL
language). The rmic compiler generates client stub and server skeleton classes to a particular remote
object
class from the bytecode.
Anytime a remote reference is provided to a client, a proxy is automatically created (if it does not already
exist). In compliance with the Broker pattern, the proxy supports the same remote interface as the target
interface. The client always works with a local reference to the proxy. As for proxy creating, the basic
strategy (at least in the current Sun Java RMI implementation) is that anytime a remote reference is
brought into a Java address space, a new proxy is created; thus more proxies can coexist in one address
space even though they embed the same remote reference.
RMI uses a proprietary internal format for request and response marshalling. As far as parameter passing
in remote calls is concerned, local objects are passed by copy using the Java object serialization (the
objects have to support the Serializable interface). When a remote object is passed as a parameter (a
reference to a proxy is indicated as the parameter) the proxy itself is passed (serialized); this complies
with
the idea of multiple proxies in one address space (Section 4.1.4). As the proxy contains the remote
reference, the RMI specification [22] also says "a remote object is passed by reference".
4.2 Combining basic principles: basic patterns
The RMI architecture is organized in three cooperating layers (bottom-up): transport layer, remote
reference layer, and stub/skeleton layer. This very much follows the Broker pattern - in RMI, the Broker
object is implemented by the transport and remote reference layers.
4.3 Providing and employing a service
A server object can implement multiple Remote interfaces (those inheriting from Remote). Not very much
reflecting the key RMI policy to strictly separate interfaces and their implementations (Section 4.1.2), a
server object is registered together with all the Remote interfaces it implements. The actual registration
with
the RMI Broker (with the remote reference layer) is done via the exportObject() method of the
UnicastRemoteObject class (e.g., it can be inherited into the Remote object implementation). The result
of the registration is a proxy supporting all of the Remote interfaces the object implements.
4.3.2 Naming
At every node supporting RMI, there is the daemon process called RMI Registry. In principle, an RMI
Registry is a name server which supports a flat name space and registers pairs <name, proxy>
associated
with the Remote objects existing in this node. A Remote object is registered under a chosen name by
calling the operation bind() (or rebind()) of the RMI Registry at a particular node. The RMI Registry
is accessible form the outside of the node via its Internet address.
There is no trading or location service in RMI at present.
4.3.4 Binding
To establish a connection from a client C to a server object SO located on a node N and registered there
under the name name_SO, C contacts the RMI Registry at N and via its operation lookup() resolves
name_SO into the registered proxy of SO; a copy of this proxy is delivered to C as the result of the
lookup() operation. Moreover, via introspection C can get from the proxy the information on all of the
Remote interfaces SO (and thus also the proxy) supports. The client can of course receive a proxy as a
result of another remote call not targeting a RMI registry. The client is bound to a server object at the
moment it receives the proxy.
If the client was compiled with knowledge of the requested service interface, it can use the methods of
the corresponding proxy via statically encoded calls. Similarly, the corresponding skeleton at the
serverside
implements static delivery.
There is no support for dynamic delivery on the server side. On the client side, however, dynamic
invocation is always possible via the implicit opportunity to use the introspection features provided for any
object to dynamically set up a call of a particular method in one of the proxy’s interfaces. The key benefit
of the Java code mobility is that a proxy code can be always dynamically downloaded into a running
application (no recompilation is necessary).
UNIT -III
JAVA VS CORBA : JAVA PROGRAMMING WITH CORBA – OVERVIEW OF JAVA ORBs –
FIRST JAVA ORB APPLICATION – OMG IDL TO JAVA MAPPING – ORB RUN – TIME
SYSTEM – DISCOVERING SERVICES
( NAMING ,TRADING) – BUILDING APPLICATIONS-ADVANCED FEATURES
(DSI,DII,INTERFACE DEPOSITORY) – CORBA EVENTS – PRACTICAL APPLICATIONS.
1 .What are the two major ORB technologies ?
There are two major ORB technologies:
• The Object Management Group's (OMG) Common Object Request Broker Architecture
(CORBA) specification
• Microsoft's Component Object Model ( Component Object Model (COM), DCOM, and
Related Capabilities)
2.What is mean by ORB ?

An object request broker (ORB) is a middleware technology that manages communication and
data exchange between objects. ORB’s promote interoperability of distributed object systems
because they enable users to build systems by piecing together objects- from different vendors-
that communicate with each other via the ORB .
3. How to implement ORB?
The implementation details of the ORB are generally not important to developers building
distributed systems. The developers are only concerned with the object interface details. This
form of information hiding enhances system maintainability since the object communication
details are hidden from the developers and isolated in the ORB
4. What are all the relevant functions of an ORB technologies ?

ORB technology promotes the goal of object communication across machine, software, and
vendor boundaries. The relevant functions of an ORB technology are
• interface definition
• location and possible activation of remote objects
Communication between clients and object
5. Draw a diagram for ORB
6.write about OMG Object Model ?

The OMG Object Model The OMG Object Model defines common object semantics for
specifying the externally visible characteristics of objects in a standard and implementation-
independent way. In this model clients request services from objects (which will also be called
servers) through a well-defined interface. This interface is specified in OMG IDL (Interface
Definition Language). A client accesses an object by issuing a request to the object. The
request is an event, and it carries information including an operation, the object reference of
the service provider, and actual parameters (if any). The object reference is an object name
that defines an object reliably.
7.write about CORBA Event Service ?
The CORBA Event Service specification defines a model of communication that allows an
application to send an event that will be received by any number of objects. The model
provides two approaches to initiating event communication. For each of these approaches,
event communication can take two forms.
8.write about Orbix event service?
OrbixEvents implements the CORBA Event Service specification. This specification defines a
model for communications between ORB applications that supplements the direct operation call
system that client/server applications normally use.
9. Write a short notes on Java IDL?

Java IDL adds CORBA (Common Object Request Broker Architecture) capability to the Java
platform, providing standards-based interoperability and connectivity. Java IDL enables
distributed Web-enabled Java applications to transparently invoke operations on remote network
services using the industry standard IDL (Object Management GroupInterface Definition
Language) and IIOP (Internet Inter-ORB Protocol) defined by the Object Management Group.
Runtime components include Java ORB for distributed computing using IIOP communication.
10.Write a short notes on IDL to Java Language Mapping ?
CORBA objects are defined in OMG IDL (Object Management Group Interface Definition
Language). J2SE v1.3 includes idl, the IDL-to-Java compiler that maps the IDL-defined interfaces
to Java classes and interfaces.
This overview shows the correspondence between OMG IDL constructs and Java constructs.
Note that OMG IDL, as its name implies, defines interfaces. Like Java interfaces, IDL interfaces
contain no implementations for their operations (methods in Java). In other words, IDL interfaces
define only the signature for an operation (the name of the operation, the data type of its return
value, the data types of the parameters that it takes, and any exceptions that it raises). The
implementations for these operations need to be supplied in Java classes written by a Java
programmer.
11.write constucts for mapping IDL to JAVA?
IDL Construct Java Construct
module package
interface (non-abstract) signature interface and an operations interface, helper class,
holder class
interface (abstract) signature interface, helper class, holder class
constant (not within an interface) public interface
boolean boolean
char, wchar char
octet byte
string, wstring java.lang.String
short, unsigned short short
long, unsigned long int
long long, unsigned long long long
float float
double double
fixed java.math.BigDecimal
enum, struct, union class
sequence, array array
exception class
readonly attribute accessor method
readwrite attribute accessor and modifer methods
operation method
12. Draw the diagram for OMG Object Model
OMG Object Model
13.When should we use the IDL programming model?

The OMG IDL (Interface Definition Language) is a purely declarative language designed for
specifying programming-language-independent operational interfaces for distributed
applications .OMG specifies a mapping from IDL to several different programming languages,
including C,C++, Lisp, Python, Smalltalk, COBOL, ADA, and Java. When mapped, each
statement in OMG IDL is translated to a corresponding statement in the programming language
of choice. Java IDL is an implementation of the CORBA specification. For example, you could use
the Java IDL Compiler, IDLJ, to map an IDL interface to Java and implement the client class in
Java. If you map the same IDL to C++, using another vendor's IDL-to-C++ compiler and C++
ORB, and implement the server in that language, the Java client and C++ server interoperate
through the ORB as though they were written in the same language.
14.write about enterprise bean?
14..What Is an Enterprise Bean?
Written in the Java programming language, an enterprise bean is a server-side component that
encapsulates the business logic of an application. The business logic is the code that fulfills the
purpose of the application.
15.what are the the types of enterprise bean?
• Session bean
• Entity bean
16.what are the two types of session bean?
• Stateful session bean
• Stateless session bean
17. what are the types of entity bean?
• Container bean
• Persistent Managed bean
18. Write about session bean?

session bean is not shared--it may have just one client, in the same way that an interactive
session may have just one user. Like an interactive session, a session bean is not persistent.
(That is, its data is not saved to a database.) When the client terminates, its session bean
appears to terminate and is no longer associated with the client.
19. Write about state full session bean?
The state is retained for the duration of the client-bean session. If the client removes the bean or
terminates, the session ends and the state disappears. This transient nature of the state is not a
problem, however, because when the conversation between the client and the bean ends there is
no need to retain the state.
20. Write about stateless session bean?
A stateless session bean does not maintain a conversational state for a particular client. When a
client invokes the method of a stateless bean, the bean's instance variables may contain a state,
but only for the duration of the invocation. When the method is finished, the state is no longer
retained. Except during method invocation, all instances of a stateless bean are equivalent,
allowing the EJB container to assign an instance to any client.
21. What is mean by multithreading?
A thread is nothing but task. More than one task completed at a same time it is called
multithreading. Java supporting multithreading.
22.what is mean by interface?
Interface used to coherent the classes. by which we can implement more than classes in a
single class.
23. What is the use of org.omg.CORBA?
Provides the mapping of the OMG CORBA APIs to the Java TM programming language, including
the class ORB, which is implemented so that a programmer can use it as a fully-functional Object
Request Broker (ORB).
24.what is the use of org.omg.CORBA.portable ?
Provides a portability layer, that is, a set of ORB APIs that makes it possible for code generated
by one vendor to run on another vendor's ORB.
25.what are the CORBA services?
CORBA services includes specifications for Naming, Life Cycle, Trader, Relationships,
Transactions, Security, and Query, to name a few (there are a total of 13 services at present).
These services are essential to real-world distributed object applications
26.what are the object services?
Object Services -- These are domain-independent interfaces that are used by many distributed
object programs. For example, a service providing for the discovery of other available services is
almost always necessary regardless of the application domain. Two examples of Object Services
that fulfill this role are:
o The Naming Service -- which allows clients to find objects based on names;
o The Trading Service -- which allows clients to find objects based on their
properties.
27.what is mean by client?
Client -- This is the program entity that invokes an operation on an object implementation.
Accessing the services of a remote object should be transparent to the caller. Ideally, it should be
as simple as calling a method on an object, i.e., obj->op(args). The remaining components in
Figure 2 help to support this level of transparency.
28.write about ORB?
Object Request Broker (ORB) -- The ORB provides a mechanism for transparently
communicating client requests to target object implementations. The ORB simplifies distributed
programming by decoupling the client from the details of the method invocations. This makes
client requests appear to be local procedure calls. When a client invokes an operation, the ORB
is responsible for finding the object implementation, transparently activating it if necessary,
delivering the request to the object, and returning any response to the caller.
29.write about ORB interface?
ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as
one or more processes or a set of libraries). To decouple applications from implementation
details, the CORBA specification defines an abstract interface for an ORB. This interface provides
various helper functions such as converting object references to strings and vice versa, and
creating argument lists for requests made through the dynamic invocation interface described
below.
30.write short notes on stub and skeleton?
CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue''
between the client and server applications, respectively, and the ORB. The transformation
between CORBA IDL definitions and the target programming language is automated by a
CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies
between client stubs and server skeletons and increases opportunities for automated
compiler optimizations.
31.write about DII?
Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the
underlying request mechanisms provided by an ORB. Applications use the DII to dynamically
issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL
stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking
deferred synchronous (separate send and receive operations) and oneway (send-only) calls.
32.write short notes on DSI?
Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII.
The DSI allows an ORB to deliver requests to an object implementation that does not have
compile-time knowledge of the type of the object it is implementing. The client making the request
has no idea whether the implementation is using the type-specific IDL skeletons or is using the
dynamic skeletons.
33.write short notes on object adapter?
• Object Adapter -- This assists the ORB with delivering requests to the object and with
activating the object. More importantly, an object adapter associates object
implementations with the ORB. Object adapters can be specialized to provide support for
certain object implementation styles (such as OODB object adapters for persistence and
library object adapters for non-remote objects).
34Write about RMI?
RMI is native to Java. It is, in essence, an extension to the core language. RMI depends on many
of the other features of Java-object serialization, portable, down-loadable object implementations,
and Java interface definitions, among others. The resulting mechanism is very natural for Java
programmers to use. They never have to leave the Java programming environment or learn any
new "foreign" technology. On the other hand, RMI has some limitations, principle among which is
a consequence of its greatest strength-its tight integration with Java makes it impractical for use
with objects or applications written in any other language.
35.Draw OMG Reference model?
F
igure 1. OMG Reference Model Architecture
36.Draw CORBA ORB architecture?

Figure 2. CORBA ORB Architecture
37.what is mean by encapsulation?
The wrapping up of data into a single unit is called data encapsulation.It supports data hiding
concepts.
38.what are the steps you have to follow when you writing client as an applet application?
When writing a client as an applet you have to follow the same steps as for the application client.
You also have to make the following additions and alterations:
• Anchor the applet in an HTML page to make it addressable and loadable.

• Provide a GUI to enable interaction through a Web browser.
• Extend the Java applet class and override some of its methods.
• Use a different ORB initialization.
39.write about OMG?
The Object Management Group, Inc. (OMG) is an international organization supported by over
800 members, including information system vendors, software developers and users. Founded in
1989, the OMG promotes the theory and practice of object-oriented technology in software
development. The organization's charter includes the establishment of industry guidelines and
object management specifications to provide a common framework for application development.
40.What is mean by servant and object?
• Object -- This is a CORBA programming entity that consists of an identity, an interface,

and an implementation, which is known as a Servant.
• Servant -- This is an implementation programming language entity that defines the
operations that support a CORBA IDL interface. Servants can be written in a variety of
languages, including C, C++, Java, Smalltalk, and Ada.
41.what are the java features?
• Object oriented
• Multithreaded
• Platform independent
• Portable
• Simple and small
42.what is mean by applet program?
Applet is a web based program .Which is run on internet explorer, Netscape navigator.
43. Why java is robust?
• It is strongly corrected coding when compile time rather than runtime.

• Each and every part of program are compiled into byte codes next which is interpreted by
JVM then verified code is executed.
44. Why java is called an object oriented language?
• It is an object based language.

• Each and every part of program are considered as to be object which is under the class.
because class is a collection of objects.
45.what is mean by application program?
Application program is a java program.which run by using JVM(java virtual machine).application

program stored on PC through JVM which is interpreted
PART – B
SHORT ANSWER
1. Explain about Java and CORBA?

Java and CORBA, to a great extent, appear to be made for each other. In their recent book,
Client/Server Programming with Java and CORBA, Robert Orfali and Dan Harkey put it this way-
"Java is the first step toward creating an Object Web, but it is still not enough. Java offers
tremendous flexibility for distributed application development, but it currently does not support a
client/server paradigm. To do this, Java needs to be augmented with a distributed object
infrastructure, which is where OMG's CORBA comes into the picture. CORBA provides the
missing link between the Java portable application environment and the world of intergalactic
back-end services. The intersection of Java and CORBA object technologies is the natural next
step in the evolution of the Object Web."
The respective object models of Java and CORBA correspond closely to one another-they both
support the notion of abstract interfaces distinct from implementations or classes; CORBA IDL
data types map very naturally to Java data types; their interface inheritance mechanisms are
nearly identical; CORBA name spaces-modules-map directly onto Java packages; the list could
continue. Beyond having highly compatible object models, the architectural roles they play in
building systems are naturally complementary. Simply put, Java allows you to create portable
objects and easily distribute them; CORBA allows you to connect them together and to integrate
them with rest of you computing environment-databases, legacy systems, objects or applications
written in other languages, what have you.
2.What about RMI?

With the release of JDK version 1.1, Java has its own, built-in native ORB, called RMI (Remote
Method Invocation). Though RMI is an ORB in the generic sense that it supports making method
invocations on remote objects, it's not a CORBA-compliant ORB. RMI is native to Java. It is, in
essence, an extension to the core language. RMI depends on many of the other features of Java-
object serialization, portable, down-loadable object implementations, and Java interface
definitions, among others. The resulting mechanism is very natural for Java programmers to use.
They never have to leave the Java programming environment or learn any new "foreign"
technology. On the other hand, RMI has some limitations, principle among which is a
consequence of its greatest strength-its tight integration with Java makes it impractical for use
with objects or applications written in any other language.
The point of this paper is not to discredit RMI; it's a viable alternative to CORBA for some
applications. What we want to show is that Java RMI and CORBA each meet a certain set of
needs, and are appropriate for a certain range of applications. There is overlap between the two,
in that there are applications that could be adequately built with either technology, but there many
more applications for which one of the two technologies has distinct advantages over the other.
We want to examine what the differences are, and where one technology might be more
appropriate than the other.
3. Write about Programming or Integration?

Java (with RMI by extension) is a concrete programming technology. It is primarily designed to
solve the problems of writing and organizing executable code, programs. It achieves this end
admirably. As such, it constitutes a specific point in the space of programming technologies.
Consider the illustration below.
The chasm that exists between programming languages is always painful to cross. That pain may
vary (metaphorically speaking) from that of a hangnail to that of a limb amputation, depending on
the languages being used and their relative differences. In this respect, programming
technologies are like islands, or peaks separated by deep canyons (Figure 1-A). Building systems
in multiple languages requires that you somehow bridge these canyons, which is a non-trivial
programming task at best (Figure 1-B). The techniques and skills required depend to a great
extent on the particular pair of languages being used together, so that the techniques used to
make Java call Ada code are somewhat different from those used to call C++, and so on. This
causes the complexity of building systems in a multilingual environment to increase significantly
(sometimes non-linearly) with the number of languages being used.
Java supplies an API called JNI, or Java Native Interface, that allows Java code to call and be
called by routines in other languages. It is primarily geared toward inter-operating with C and C++
, and it is a rather difficult interface to master. RMI is a Java-to-Java technology. If you want a
Java client to use RMI to communicate with a remote object in another language, you must do it
by way of a Java intermediary that is co-located with the "foreign" remote object (see Figure 2).
The underlying problem here is that Java is a programming technology that, by definition, works
within the boundaries of the languages itself. Using a programming language to solve the
problem of crossing gaps between programming languages is like using rats to kill mice-at the
end of the day, you still have a rodent problem.
By contrast, CORBA is an integration technology, not a programming technology. It is specifically

designed to be the glue that binds disparate programming technologies together. It does not exist
as a point in the programming space; by design, it occupies the spaces between the peaks
representing individual languages (see Figure 3).
When a Java client uses CORBA technology to communicate with a C++ object, for example,
both the C++ programmer are the Java programmer work completely within their respective
language environments. The CORBA ORB presents the Java client with a Java stub interface
and the C++ programmer with a C++ skeleton interface (see Figure 4). CORBA takes care of the
cross-language issues automatically. This picture reflects the fact that CORBA is specifically
designed as an integration technology, not a programming technology.
The medium that CORBA uses to perform this integration is OMG IDL (Interface Definition
Language). IDL isn't a programming language. It describes interfaces between distributed
components. It doesn't depend on any particular programming language technology. From IDL
interface descriptions, an ORB product automatically generates code in the language of your
choice to effect integration and distribution-the "glue" that connects components and manages
communication between them.
You may ask, "why should I have to learn another language (IDL) in order to use CORBA
technology ?". First, note that IDL is an extremely simple language. Since it only describes
interfaces, almost all of the complex issues faced by programming languages-control flow,
memory management, functional composition, and so on-are absent from IDL. Learning and
using IDL is trivial in comparison to using a new programming language. Second, having a single
descriptive language as the basis for agreeing on interfaces is extremely important. Other
approaches, such as the attempt to describe POSIX APIs separately in both C and FORTRAN,
usually lead to subtle but troublesome differences in behavior. Finally, IDL can be generated from
some programming languages' native interface descriptions. This capability is currently available
is some ORB products, such as Visigenic's Caffeine product, or IBM's Direct to SOM compilers.
By taking this approach, it is possible to get the benefits of IDL's language neutrality and power
as an integration medium without leaving your favorite programming language.
4.explain about CORBA Core?

The core ORB specification itself does not dictate a specific implementation architecture. It
describes an abstract model for ORB semantics and a set of standard interfaces, extensible
through a standard Interface Definition Language. ORB implementers are free to construct their
ORBs in any way they choose, as long as they support the proper interfaces and semantics. This
freedom is extremely important to ORB users. It means:
• ORBs can be tailored to specific run-time environments or unique system requirements.

For example, several vendors offer ORBs specialized for embedded real-time
requirements, where an ORB designed for workstations in a client-server system would
be completely inappropriate. Though ORBs may have diverse implementations, they can
still inter-operate, and applications will still be ported among them. In contrast, RMI is, in
essence, a single, specific implementation architecture. If its one-size-fits-all approach
doesn't work for you, or your requirements are evolving in ways you might not be able to
predict, you're out of luck.
• ORB implementations can evolve rapidly to offer increased performance, reliability, and
scaleability without breaking applications. For example, many ORB vendors have begun
to integrate their products with high-performance, highly-reliable middleware messaging
systems. These ORBs offer builders of large enterprise systems very high quality-of-
service communication, with logging, persistent queuing, and so on. Because CORBA is
an interface specification and not a concrete code base, ORBs are free to evolve in this
way.
CORBA ORBs have been subjected to strong evolutionary pressures for several years now. A
diverse, flexible range of products has emerged, ranging from small-footprint "ORBlets" for widely
distributed web-based clients, to industrial-strength ORBs suitable for high volume, mission-
critical transactional systems. In comparison, RMI, while quite useful, can best be described as a
lightweight mechanism suited for a narrower range of tasks.
5.write about CORBA services?

The OMA also includes a comprehensive set of object services, designed to provide application
builders with a foundation of commonly-required capabilities. CORBAservices includes
specifications for Naming, Life Cycle, Trader, Relationships, Transactions, Security, and Query,
to name a few (there are a total of 13 services at present). These services are essential to real-
world distributed object applications.
The builders of Java are also creating services for use with RMI, including a naming and directory
service and a security service, among others. So far, these services are not as complete or
mature as CORBAservices, and there is a much smaller set of them. Interestingly enough,
JavaSoft has adopted the OMG Object Transaction Service (OTS) as the basis for the Java
Transaction Service, JTS. We hope this is the beginning of a trend. In the OMG's
CORBAservices, the Java community has an opportunity to leverage existing technology without
compromising usability or functionality. These wheels don't need re-inventing.
6.explain about overview of CORBA?
The Common Object Request Broker Architecture (CORBA) [OMG:95a] is an emerging open
distributed object computing infrastructure being standardized by the Object Management Group
(OMG). CORBA automates many common network programming tasks such as object
registration, location, and activation; request demultiplexing; framing and error-handling;
parameter marshalling and demarshalling; and operation dispatching. See the OMG Web site for
more overview material on CORBA. See my CORBA page for additional information on CORBA,
including our tutorials and research on high-performance and real-time ORBs. Results from our
research on high-performance and real-time CORBA are freely available for downloading in the
open-source TAO ORB.
The following figure illustrates the primary components in the OMG Reference Model
architecture. Descriptions of these components are available further below. Portions of these
descriptions are based on material from [Vinoski].
F
igure 1. OMG Reference Model Architecture
• Object Services -- These are domain-independent interfaces that are used by many
distributed object programs. For example, a service providing for the discovery of other
available services is almost always necessary regardless of the application domain. Two
examples of Object Services that fulfill this role are:
o The Naming Service -- which allows clients to find objects based on names;
o The Trading Service -- which allows clients to find objects based on their
properties.
There are also Object Service specifications for lifecycle management, security,
transactions, and event notification, as well as many others [OMG:95b].
• Common Facilities -- Like Object Service interfaces, these interfaces are also
horizontally-oriented, but unlike Object Services they are oriented towards end-user
applications. An example of such a facility is the Distributed Document Component
Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF
allows for the presentation and interchange of objects based on a document model, for
example, facilitating the linking of a spreadsheet object into a report document.
• Domain Interfaces -- These interfaces fill roles similar to Object Services and Common
Facilities but are oriented towards specific application domains. For example, one of the
first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM)
Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the
telecommunications, medical, and financial domains.
• Application Interfaces - These are interfaces developed specifically for a given
application. Because they are application-specific, and because the OMG does not
develop applications (only specifications), these interfaces are not standardized.
However, if over time it appears that certain broadly useful services emerge out of a
particular application domain, they might become candidates for future OMG
standardization.
7.explain about CORBA ORB Architecture?

The following figure illustrates the primary components in the CORBA ORB architecture.
Descriptions of these components are available below the figure.
Figure 2. CORBA ORB Architecture
• Object -- This is a CORBA programming entity that consists of an identity, an interface,

and an implementation, which is known as a Servant.
• Servant -- This is an implementation programming language entity that defines the
operations that support a CORBA IDL interface. Servants can be written in a variety of
languages, including C, C++, Java, Smalltalk, and Ada.
• Client -- This is the program entity that invokes an operation on an object
implementation. Accessing the services of a remote object should be transparent to the
caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args).
The remaining components in Figure 2 help to support this level of transparency.
• Object Request Broker (ORB) -- The ORB provides a mechanism for transparently
communicating client requests to target object implementations. The ORB simplifies
distributed programming by decoupling the client from the details of the method
invocations. This makes client requests appear to be local procedure calls. When a client
invokes an operation, the ORB is responsible for finding the object implementation,
transparently activating it if necessary, delivering the request to the object, and returning
any response to the caller.
• ORB Interface -- An ORB is a logical entity that may be implemented in various ways
(such as one or more processes or a set of libraries). To decouple applications from
implementation details, the CORBA specification defines an abstract interface for an
ORB. This interface provides various helper functions such as converting object
references to strings and vice versa, and creating argument lists for requests made
through the dynamic invocation interface described below.
• CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the
``glue'' between the client and server applications, respectively, and the ORB. The
transformation between CORBA IDL definitions and the target programming language is
automated by a CORBA IDL compiler. The use of a compiler reduces the potential for
inconsistencies between client stubs and server skeletons and increases opportunities for
automated compiler optimizations.
• Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the
underlying request mechanisms provided by an ORB. Applications use the DII to
dynamically issue requests to objects without requiring IDL interface-specific stubs to be
linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows
clients to make non-blocking deferred synchronous (separate send and receive
operations) and oneway (send-only) calls.
• Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client
side's DII. The DSI allows an ORB to deliver requests to an object implementation that
does not have compile-time knowledge of the type of the object it is implementing. The
client making the request has no idea whether the implementation is using the type-
specific IDL skeletons or is using the dynamic skeletons.
• Object Adapter -- This assists the ORB with delivering requests to the object and with
activating the object. More importantly, an object adapter associates object
implementations with the ORB. Object adapters can be specialized to provide support for
certain object implementation styles (such as OODB object adapters for persistence and
library object adapters for non-remote objects).
My CORBA page also contains additional information on patterns and techniques for designing
CORBA ORBs and CORBA services. Examples of these patterns and techniques can be found in
the TAO real-time CORBA implementation.
8.Explain about main constructs of IDL and the corresponding constructs in Java?
The following table lists the main constructs of IDL and the corresponding constructs in Java.
IDL Type Java Type
module package
boolean boolean
char, wchar char
octet byte
string, wstring java.lang.String
short, unsigned short short
long, unsigned long int
long long, unsigned long long long

IDL Type Java Type
float float
double double
fixed java.math.BigDecimal
enum, struct, union class
sequence, array array
signature interface and an operations interface, helper class,

interface (non-abstract)
holder class
interface (abstract) signature interface, helper class, holder class
constant (not within an

public interface
interface)
fields in the Java signature interface for non-abstract, or the sole

constant (within an interface)
Java interface for abstract
exception class
Any org.omg.CORBA.Any
type declarations nested

"scoped" package
within interfaces
typedef helper classes
pseudo objects pseudo interface
readonly attribute accessor method
readwrite attribute accessor and modifer methods
operation method
9.explain about Object Request Broker (ORB)& OMG?
The Object Request Broker (ORB) is middleware that uses the CORBA specification. The Object
Request Broker or ORB takes care of all of the details involved in routing a request from client to
object, and routing the response to its destination. The ORB is also the custodian of the Interface
Repository (abbreviated variously IR or IFR), an OMG-standardized distributed database
containing OMG IDL interface definitions.
On the client side, then, the ORB provides interface definitions from the IFR, and constructs
invocations for use with the Dynamic Invocation Interface (DII). It also converts Object
References between session and stringified format, and (for CORBA 2.4 and later ORBs)
converts URL-format corbaloc and corbaname object references to session references.
On the server side, the ORB de-activates inactive objects, and re-activates them whenever a
request comes in. CORBA supports a number of activation patterns, so that different object or
component types can activate and de-activate in the way that uses resources best.
Object Management Group (OMG)
The Object Management Group, Inc. (OMG) is an international organization supported by over
800 members, including information system vendors, software developers and users. Founded in
1989, the OMG promotes the theory and practice of object-oriented technology in software
development. The organization's charter includes the establishment of industry guidelines and
object management specifications to provide a common framework for application development.
Primary goals are the reusability, portability, and interoperability of object-based software in
distributed, heterogeneous environments. Conformance to these specifications will make it
possible to develop a heterogeneous applications environment across all major hardware
platforms and operating systems.
10.Expalin about CORBA?
CORBA is the acronym for Common Object Request Broker Architecture. It was developed under
the auspices of the Object Management Group (OMG). It is middleware. A CORBA-based
program from any vendor, on almost any computer, operating system, programming language,
and network, can interoperate with a CORBA-based program from the same or another vendor,
on almost any other computer, operating system, programming language, and network.
The first service-oriented architecture for many people in the past was with the use of Object
Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is
responsible for really increasing the awareness of service-oriented architectures.
11.what are the Requirements for an IDL-to-programming-language mapping?

All language mappings have approximately the same structure. They must define the means of
expressing in the language:
• All IDL basic data types

• All IDL constructed data types
• Constants defined in IDL
• References to objects defined in IDL
• Invocations of operations, including passing parameters and receiving results
• Exceptions, including what happens when an operation raises an exception and how the
exception parameters are accessed
• Access to attributes
• Signatures for the operations defined by the ORB, such as the dynamic invocation
interface, the object adapters, and so on.
A complete language mapping will allow a programmer to have access to all ORB functionality in
a way that is convenient for the particular programming language. To support source portability,
all ORB implementations must support the same mapping for a particular language.
MotherIDL
Throughout this article we will use a file I call MotherIDL -- motheridl.idl. The IDL file can do it all
and its purpose is just to look at and examine parts of the mapping. It may be a good idea to take
a quick look at it so you can be familiar with it as we move through it.
In order to examine the mapping you will need an IDL-to-Java compiler. Every CORBA ORB
comes with one or more IDL-to-some-language compiler. Most are for either C++ or Java
programming language but you can find others as well. New additions can be found for Python
and Delphi. For this column I will be using the JIDL that comes with the Orbacus ORB from
Object Oriented Concepts, Inc. (see Resources) but you could use any IDL-to-Java compiler. Just
make sure it is CORBA 2.3-compliant because your results could be substantially different if the
compiler is working from an earlier version.
So the first task is to run the IDL-to-Java compiler against motheridl.idl.
jidl --output-dir . . \. . \. . MotherIDL.idl
This step magically gives you a whole host of Java files that reflect the IDL file as well as provide
support and general CORBA plumbing.
12 .Write a note on Interface Definition Language (IDL), usage and implementation ?

Interface Definition Language (IDL), usage and implementation
The interface to a class of objects contains the information that a caller must know to use an
object, specifically, the names of its attributes and the signatures of its methods. In the CORBA
programming model, the Object Management Group (OMG) Interface Definition Language (IDL)
is the formal language used to define object interfaces independent of the programming language
used to implement those methods.
IDL, usage and implementation is an overview of the relationship between IDL and application
development languages. Object providers use IDL to define the interfaces to their objects. The
IDL can be directly defined by the object provider or can be produced transparently to the user in
application development tools. Code emitters and generators produce the following elements: A
usage binding that provides a native, client language rendering of the IDL, for example as a C++
class or Java interface. The usage binding is also used to generate a client stub object that
through delegation maps the interface onto the server object providing the implementation. An
implementation template that provides a native, server language class template into which
method behavior can be inserted, for example, by editing the file and adding source code. The
implementation of a class of objects (that is, the procedures that implement operations and the
variables used to store an object's state) is written in the implementer’s preferred programming
language (for example, C++ or Java).Implementation objects such as skeletons and stubs may
also be emitted and compiled if the client and server are in different processes or in different
languages. These implementation objects provide the functions needed to make interface
language calls and remote method execution.
The IDL compiler takes as input an IDL file and produces the usage binding files that make it
convenient to implement and use objects that support the defined interface within a particular
programming language.
For an Enterprise JavaBeans, you can create the IDL files from the bean's interface and home
classes.
13.Write a note on C++ CORBA client, locating a servant object?
To be able to locate a servant object somewhere in a CORBA environment, a client needs to
know the object reference that uniquely identifies the target object.
When an object is created, it is assigned an object reference, which can be bound with a name in
the naming service. Any client (or any other object) with access to the naming service can use the
associated name to retrieve the object reference.
Object references are bound into the naming service relative to the root naming context. After a
client has located the root naming context, it can use the standard CosNaming interface to
navigate the name space and retrieve the object reference associated with any name; for
example: // Create a new ::CosNaming::Name to pass to resolve().
// Construct it as the full three-part complex name.
::CosNaming::Name *loggerName = new ::CosNaming::Name;
loggerName->length( 3 );
(*loggerName)[0].id = ::CORBA::string_dup( "domain" );
(*loggerName)[0].kind = "";
(*loggerName)[1].id = ::CORBA::string_dup( "WSLoggerContext" );
(*loggerName)[1].kind = ::CORBA::string_dup( "" );
(*loggerName)[2].id = ::CORBA::string_dup( "WSLoggerObject1" );
(*loggerName)[2].kind = ::CORBA::string_dup( "" );
::CORBA::Object_ptr objPtr = rootNameContext->resolve( *loggerName );
liptr = WSLogger::_narrow( objPtr);
If the client bootstrapping operation does not establish contact with a remote naming service, you
can use the alternative strategies to retrieve the IOR of a remote object, as outlined in Strategies
for retrieving the IOR of a remote object
14.What Is an Enterprise Bean?

Written in the Java programming language, an enterprise bean is a server-side component that
encapsulates the business logic of an application. The business logic is the code that fulfills the
purpose of the application. In an inventory control application, for example, the enterprise beans
might implement the business logic in methods called checkInventoryLevel and order Product. By
invoking these methods, remote clients can access the inventory services provided by the
application. Benefits of Enterprise Beans
For several reasons, enterprise beans simplify the development of large, distributed applications.
First, because the EJB container provides system-level services to enterprise beans, the bean
developer can concentrate on solving business problems. The EJB container--not the bean
developer--is responsible for system-level services such as transaction management and security
authorization.
Second, because the beans--and not the clients--contain the application's business logic, the
client developer can focus on the presentation of the client. The client developer does not have to
code the routines that implement business rules or access databases. As a result, the clients are
thinner, a benefit that is particularly important for clients that run on small devices.
Third, because enterprise beans are portable components, the application assembler can build
new applications from existing beans. These applications can run on any compliant J2EE server.
When to Use Enterprise Beans
You should consider using enterprise beans if your application has any of the following
requirements: The application must be scalable. To accommodate a growing number of users,
you may need to distribute an application's components across multiple machines. Not only can
the enterprise beans of an application run on different machines, but their location will remain
transparent to the clients. Transactions are required to ensure data integrity. Enterprise beans
support transactions, the mechanisms that manage the concurrent access of shared objects. The
application will have a variety of clients. With just a few lines of code, remote clients can easily
locate enterprise beans. These clients can be thin, various, and numerous.
Session Bean
A session bean represents a single client inside the J2EE server. To access an application that
is deployed on the server, the client invokes the session bean's methods. The session bean
performs work for its client, shielding the client from complexity by executing business tasks
inside the server.
As its name suggests, a session bean is similar to an interactive session. A session bean is not
shared--it may have just one client, in the same way that an interactive session may have just
one user. Like an interactive session, a session bean is not persistent. (That is, its data is not
saved to a database.) When the client terminates, its session bean appears to terminate and is
no longer associated with the client.
There are two types of session beans: stateful and stateless. Stateful Session Beans
The state of an object consists of the values of its instance variables. In a stateful session bean,
the instance variables represent the state of a unique client-bean session. Because the client
interacts ("talks") with its bean, this state is often called the conversational state.
The state is retained for the duration of the client-bean session. If the client removes the bean or
terminates, the session ends and the state disappears. This transient nature of the state is not a
problem, however, because when the conversation between the client and the bean ends there is
no need to retain the state. Stateless Session Beans
A stateless session bean does not maintain a conversational state for a particular client. When a
client invokes the method of a stateless bean, the bean's instance variables may contain a state,
but only for the duration of the invocation. When the method is finished, the state is no longer
retained. Except during method invocation, all instances of a stateless bean are equivalent,
allowing the EJB container to assign an instance to any client.
Because stateless session beans can support multiple clients, they can offer better scalability for
applications that require large numbers of clients. Typically, an application requires fewer
stateless session beans than stateful session beans to support the same number of clients.
At times, the EJB container may write a stateful session bean to secondary storage. However,
stateless session beans are never written to secondary storage. Therefore, stateless beans may
offer better performance than stateful beans. When to Use Session Beans
In general, you should use a session bean if the following circumstances hold: At any given time,
only one client has access to the bean instance. The state of the bean is not persistent, existing
only for a short period of time (perhaps a few hours).
Stateful session beans are appropriate if any of the following conditions are true: The bean's
state represents the interaction between the bean and a specific client. The bean needs to hold
information about the client across method invocations. The bean mediates between the client
and the other components of the application, presenting a simplified view to the client. Behind
the scenes, the bean manages the work flow of several enterprise beans.
To improve performance, you might choose a stateless session bean if it has any of these traits:
The bean's state has no data for a specific client. In a single method invocation, the bean
performs a generic task for all clients. For example, you might use a stateless session bean to
send an e-mail that confirms an online order. The bean fetches from a database a set of read-
only data that is often used by clients. Such a bean, for example, could retrieve the table rows
that represent the products that are on sale this month.
15.explain about Summary of the CORBA Development Process?
The examples presented in this chapter follow roughly the same steps:
• Write some IDL that describes the interfaces to the object or objects that will be used or
implemented.
• Compile the IDL file. This produces the stub and skeleton code that provides location
transparency. That is, it will cooperate with the ORB library to convert an object reference
into a network connection to a remote server and then marshal the arguments we provide
to an operation on the object reference, convey them to the correct method in the object
denoted by our object reference, execute the method, and return the results.
• Identify the IDL compiler-generated interfaces and classes that we need to use or
specialize in order to invoke or implement operations.
• Write code to initialize the ORB and inform it of any CORBA objects that we have
created.
• Compile all the generated code and our application code with a Java compiler.
• Run the distributed application.
Figure 4.2 shows the use of IDL and the IDL compiler when building the application.
Figure 4.2 Building the Hello World application.
When you execute the IDL compiler for the Java ORB you have installed, it will generate two sets
of Java code files: stub code to create proxy objects that a client can use for making invocations
on object references of the interface types defined in the IDL file, and skeleton code for access to
objects that support those interfaces.
16.explain about Environment Setup of CORBA?
Before we can start with the examples we have to set up a working environment. We
implemented the examples with Visibroker for Java 4.1, and Sun Microsystems' Java
Development Kit (JDK) version 1.2. Because our example code relies on only standardized
interfaces and does not use any proprietary ORB extensions it will run unchanged on any
CORBA 2.3 compliant Java ORB. Code portability was verified by also running all code on
JacORB 1.2. For setups in different environments, the reader is referred to the installation
manuals for the particular products and platforms.
We use JDK 1.2, assuming that the path is set appropriately and that the Java compiler javac and
that the Java run-time system java isare installed. We also use Inprise Corp.'s Visibroker for
Java version 4.10, assuming that the path and classpath are set appropriately. Visibroker’s IDL
compiler is called idl2java. Note that we need to overcome applet sandbox and firewall
restrictions unless the server is running on the Wweb server from which the applet is downloaded
from. To do this, we run the gatekeeper, Visibroker’s IIOP gateway, and HTTP tunneling
mechanisms:
prompt> gatekeeper &

Many Java ORBs provide a similar IIOP gateway as part of their applet support.
OrbixWeb’s, for example, is called Wonderwall. In JacORB, it would be started as
appligator. The interface between the ORB and this gateway is not standardized, so using a
different ORB with applets also requires using this ORB's IIOP gateway mechanism. The code
itself remains unchanged, however.
17.Write about Interface Specification of CORBA?
Our first example provides the same functionality as the one introduced in Chapter 3. A client
invokes an operation hello() on the interface of a potentially remote object of type GoodDay. The
result of the invocation is a message that is printed by the client.
For any CORBA application we must write an IDL specification that defines data types and
interfaces, including attributes and operations. For our example, we defined an IDL interface
called HelloWorld which resembles the Java interface of the Hello World example from Chapter 3.
We place the IDL file HelloWorld.idl, containing this definition, in a directory which represents its
location in the book: com/wiley/compbooks/brose/chapter4/simple.
//HelloWorld.idl
module com {
module wiley {
module compbooks {
module brose {
module chapter4 {
module simple {
module helloWorld {
interface GoodDay {
string hello();
};
};};};};};};};
The file contains the specification of a hierarchy of modules. It is good specification style to use
modules to create a separate name space for an application or its major components, and to
follow the same naming conventions that have been introduced for Java packages. To align with
Java coding conventions, we recommend using module names that begin with lower case letters
and interface names beginning with capital letters.
Within the module helloWorld we define one interface: GoodDay. The interface is not in any
inheritance relationship. It provides one operation hello(). This operation does not have any
parameters and returns a result of type string.
As we will see in the implementation, the object returns a string describing its locality as part of
the result of the operation, hello(). The operation returns a message saying: "Hello World, from
location."

CBT

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CBT

Încărcat de

Drepturi de autor:

Formate disponibile

IF362- COMPONENT BASED TECHNOLOGY

1. What is mean by COM?

2.Where COM is applicable?

3.what is mean byCORBA?

4.What is the purpose of CORBA?

5.How CORBA was developed?

6.what is mean by OMG?

7.What is mean by ORB?

8.What is mean by components?

9.what is mean by component test?

10.what is mean by container?

11.what is mean by javabean?

12.what is mean by enterprise java bean?

13.what is mean by proxy?

14.what is mean by proxyserver?

15.what is mean by request & response?

16.what is the use of COM?

17. What is mean by marshalling?

18.What is mean by objects?

19.what is mean by distributed objects?

20.what is the use of java bean?

• It is a usable software. so by which we can utilize software at more than times.

• It is a platform neutral so we can use this language in platform.

21.what is the use of RMI?

22.what are the CORBA features?

23.what is mean by ORB?

24.what is mean by IDL?

25.what are the parts of IDL?

An IDL interface body contains the following kinds of declarations:

types Type definitions.

26.What is mean by software component?

27.what are the features of javabeans?

Allows a builder tool to analyze how a bean works

29.what is mean by customization?

The appearance and behavior of a bean can be customized

30.what is mean by event?

Which is Used to connect beans together.

31.what is the use of properties?

Properties are used for customization and for programmatic use.

32.what is mean by persistence?

Allows the customized state to be saved and reloaded later.

33.what is mean by class library?

34.what are the CORBA services?

OLE defines the Component Object Model, which specifies a programming-language-

37.what is mean by binding?

Binding", meaning the choice of a method to be executed in response to a request, is handled by

38.write about OMG object model?

39.what are the system management?

40.what are the COM libraries?

CoCreateInstance(Ex) Creates an interface pointer to an uninitialized instance of

41. How IDL working?

42.what are the software components?

44. where RPC using?

BIG QUESTIONS AND ANSWER

1.what is DCOM& advantages of DCOM?

2.what are the advantages of DCOM?

Advantages of distributed component computing

• Speeding up development processes: Since applications can be built from existing

3.explain about DCOM architecture?

Locating Objects: Activation

Creating Objects, Local or Remote

CoCreateInstance(Ex) Creates an interface pointer to an uninitialized instance of