Top Banner
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
101
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 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?

Page 2: cbt

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.

Page 3: cbt

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?

Page 4: cbt

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?

Page 5: cbt

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) (<CLSID>…)

Creates an interface pointer to an uninitialized instance of 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

Page 6: cbt

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.

Page 7: cbt

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.

Page 8: cbt

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."

Page 9: cbt

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) (<CLSID>…)

Creates an interface pointer to an uninitialized instance of 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):

Page 10: cbt

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.

Page 11: cbt

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.

Page 12: cbt

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.

Page 13: cbt

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.

Page 14: cbt

← 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.

Page 15: cbt

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.

Page 16: cbt

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

Page 17: cbt

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.

Page 18: cbt

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?

Page 19: cbt

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 deliveryWhen 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

Page 20: cbt

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 deliveryIn 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?TransactionsTransaction 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 noconstraint 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 belocated on separate nodes. A server (process) can contain implementation of several objects or a singleobject, or even provide an implementation of one particular method only. However, typically, amultithreaded 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 objectthat 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 constructsrelated to object implementation (object state definitions have been proposed recently by OMG).29.what is mean by local representative?Proxy: local representativeUsing the Broker Pattern terminology, the client-side proxy code is called IDL stub; the server-side proxy

Page 21: cbt

code is referred to as IDL skeleton. However, in CORBA, the concept "proxy" is used to denote an objectcreated on the client side which contains the IDL stub plus provides some other functionality, e.g. supportfor dynamic invocation.30.waht is mean by Transmitting request and response?Marshalling: transmitting request & responseBoth request and response are delivered in the canonical format defined by the IIOP protocol which is thebase 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 donein the IDL Skeletons (or in the Dynamic Skeleton Interface, DSI) and partially in the Object Adapter. Ina request (response), Object References can be provided as parameters; remote objects can be passes byreference. 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 acorresponding 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 theJava RMI (Remote Method Invocation) service together with the Java Object Serialization service, or (2)employing the CORBA IIOP protocol34.how to employ CORBA IIOP protocol? (a) in a Java-written client code via stubs which speakthe 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 thestandard 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?

Page 22: cbt

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 BrokerPattern is mapped as the ORB Core; it is employed for establishing the connection between a client anda 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 & responseUnder 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.

Page 23: cbt

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 referenceOne 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 aparticular remote method call reside.IDL InterfaceIn 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.Proxy: local representativeTo 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 formand to transform the result of the call to a form suitable for transmitting to the client-proxy. Thus, a serversideproxy can be considered as the representative of all potential clients of the remote object.

Page 24: cbt

Marshalling: transmitting request & responseBoth 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 patternThe 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 Bridgeobject is used to communicate with other Brokers.Proxy patternThe 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 patternIn 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 tocreation of products of specific types.3.How to Provide and employing a service?Registering a service with brokerIn 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

Page 25: cbt

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.NamingBecause 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, tradingFor 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.BindingAs 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).Static invocation and deliveryWhen 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 deliveryIn 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

Page 26: cbt

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 problemThe 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 cooperativegarbage 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 referencesLifecycles 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).TransactionsTransaction 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 dealingwith this problem.Concurrency in server objectsIn 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

Page 27: cbt

multithreaded Broker.Applying client-server relation transitivelyIt 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 programmingThe 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 thePublisher). One of the key benefits of this approach is that the Publisher does not have to know itslisteners at compile time; listeners subscribe dynamically.5.Explain about Distributed objects in CORBA?Basic principles Request & responseIn CORBA, a client issues a request to execute a method of an object implementation. There is noconstraint 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 belocated on separate nodes. A server (process) can contain implementation of several objects or a singleobject, or even provide an implementation of one particular method only. However, typically, amultithreaded server encapsulates implementations of multiple objects.Remote referenceRemote references are called Object References and the target of an Object Reference must be an objectthat supports the CORBA::Object IDL interface (such objects are called CORBA objects).IDL InterfaceCORBA 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 constructsrelated to object implementation (object state definitions have been proposed recently by OMG).Proxy: local representativeUsing the Broker Pattern terminology, the client-side proxy code is called IDL stub; the server-side proxycode is referred to as IDL skeleton. However, in CORBA, the concept "proxy" is used to denote an objectcreated on the client side which contains the IDL stub plus provides some other functionality, e.g. supportfor dynamic invocation.Marshalling: transmitting request & responseBoth request and response are delivered in the canonical format defined by the IIOP protocol which is thebase 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 thefunctionality of the dynamic invocation interface (Section 3.2). On the server side, unmarshalling is donein the IDL Skeletons (or in the Dynamic Skeleton Interface, DSI) and partially in the Object Adapter. Ina request (response), Object References can be provided as parameters; remote objects can be passes byreference. 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 BrokerPattern is mapped as the ORB Core; it is employed for establishing the connection between a client anda 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 (Sect. 3.3.1,

Page 28: cbt

IDL skeleton, and DSI skeleton serving for dynamic delivery. More specifically, the direct communicationvariant of the Broker pattern is employed in many of the CORBA implementation (e.g., in Orbix), wherethe 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 isused 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 factoryable to create object of a given type) and generic factory (which encapsulates the functionality of multiplefactories).Providing and employing a serviceRegistering a service with brokerRegistering the object which represents the service is the task of the Object Adapter. Its currentlymandatory version, POA, provides, e.g., the activate_object(), activate() methods to supportregistration. In principle, activate_object() registers the object with POA and assigns a new ObjectReference, which will serve for referencing the newly created object; activate() signals that a particularserver (or a particular POA, to be precise) is ready to accept requests. Finally, calling ORB::run() tellsthe ORB to enter the main request processing loop.NamingOfficially there is the CORBA Naming Service which should provide for name spaces and for mappingsamong Object References and names. However, in addition to the standard Naming Service, most of theCORBA implementations provide a vendor specific way to locate objects associated directly withregistering of a service at the server side and a "binding" operation on the client side.Finding a service, tradingFor 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, askingthe 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 andVisiBroker), provide a proprietary location service. In a sense, this service is a hybrid between namingand 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 locationservice does not cover the functionality of the CORBA Naming Service or CORBA Trading Service.BindingThe client is bound to the requested server after it receives one of its Object References (and acorresponding proxy is created.Static invocation and deliveryWhen the client was compiled with knowledge of the requested service IDL specification, the proxyimplements the mapped IDL interface methods. The corresponding code of the proxy is encapsulated inthe IDL stub (Sect. 3.2). Similarly, the corresponding IDL skeleton is the code of the server-side proxywhich implements static delivery.Dynamic invocation and deliveryFor dynamic invocations, the proxy contains the create_request() method which returns a Requestobject. There is also a way to submit arguments with the request. When creating a request, the InterfaceRepository can be consulted for details about the target interface. The actual dynamic invocation isinitiated 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 whichdelivers the request via the invoke() method supported by the PortableServer::DynamicImplementationinterface. CORBA allows for combining static invocation at the client side with dynamic delivery at theserver side and vice versa. At the server side, the choice between static and dynamic delivery is made bythe server object itself (it can be determined, e.g., as a part of the registration with POA), regardless ofthe 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 appliedin CORBA clients implemented in Java. In this case, the client code can be compiled without employingthe IDL compiler (just the knowledge about the interface form will do).7. Explain about CORBA’S Inherent issues?Server objects garbage collection problemCORBA addresses the garbage collection problem via the third method (with assistance of the clients’

Page 29: cbt

code, the server is supposed to keep track of the number of references to a given object provided to theoutside of the server). It is assumed that if the client to which the reference was provided does not needit any more, it lets the server know. For this purpose, every CORBA::Object (proxy and the implementationobject are considered as separate entities - both are CORBA::Objects) possesses the duplicate() methodto be called if new reference to this object is to be created. If the reference is not needed any more, therelease() method of ORB is to be called. However, most of the CORBA implementations employslightly 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.Persistent remote referencesObject references themselves should be persistent in principle. In its IIOP format, an Object Referencecontains, 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 serverdeletes the target object of R. However, especially for effectivity reasons, the run of a server S which hasnot been answering any request for a time-out period is usually terminated. More specifically, the server’sloop inherently contained in this operation is terminated after the timeout period expires. Just before beingactually 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 istypically reactivated, the target of R is recreated, and its state is internalized again. Currently, thereactivation of servers is done in a vendor-dependent way (e.g., Orbix uses loaders for this purpose). Withintroduction of POA, the reactivation of server has been standardized: a servant manager supplied withthe server assumes the role of reactivating all necessary server objects.TransactionsThere is no implicit support for transactions upon remote objects. On the other hand, the CORBATransaction Service (OTS), closely cooperating with the CORBA Concurrency Control Service, has beenspecified. The CORBA implementations supporting OTS include Orbix and VisiBroker. The OTSspecification [11] addresses the problem of respecting the partial ordering of resources in the prepare phaseby introducing synchronization objects which are given a chance to store themselves before the very firstprepare action starts.Concurrency in server objectsIn 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 ControlService is used at different level of granularity - it provides locking only and was designed in particularto support locking in nested transaction. The other important point is that the implementation of ORB andPOA has to reflect the multithreading in servers. As multithreading inherently complicates theimplementation, some vendors offer their ORB alternatively in single and multithreaded versions (e.g.,ORBIX).Applying client-server relation transitively, callbacksApplying client-server relation transitively is straightforward in CORBA. Implementing a callback froma server S to its client C (via the approach mentioned in Section 2.4.5) typically requires the code of Cto include also the library code supporting servers. To avoid deadlock when a callback takes place whileresponding a request from C, the client C has to be of multithreaded implementation, or the callback isto be a one-way (asynchronous) call.Reactive programmingReactive programming in CORBA is supported by the CORBA Event Service [10]. This service providesthe event channel abstraction. To an event channel, an object can subscribe as an event supplier or eventlistener. A supplier generates an event which can be associated with event data. Both push and pull modelsof delivering events to consumers are provided. Thus the CORBA Event Service fully implements theObserver 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 principlesCurrently, there are two ways to handle distributed objects in the Java environment: (1) Employing the

Page 30: cbt

Java RMI (Remote Method Invocation) service together with the Java Object Serialization service, or (2)employing the CORBA IIOP protocol, alternatively: (a) in a Java-written client code via stubs which speakthe CORBA IIOP protocol, or (b) directly in a CORBA ORB fully implemented in the Java environment(e.g., OrbixWeb, VisiBroker)). In this section we limit ourselves to RMI (JDK1.2, [22]).Request & responseThe Java RMI architecture is based on the Broker pattern (Section 2.2.1). In addition to the classicalscenario of a client request targeting a particular interface of a single server object, the RMI architectureis open to support also, e.g., replication of server objects (transparent to the client request). At present, theSun Java RMI implementation includes only simple point-to-point requests and responses based upon theunderlying 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 (ingeneral) to the client’s JVM.Remote referenceRemote references are handles to remote objects (those implementing the Remote interface). Remotereferences are not directly accessible; they are encapsulated in proxies (stubs and skeletons, Sect. 4.2). Akey RMI feature is that, from a client’s point of view, a remote reference can always be employed onlyvia an interface (derived from Remote). This conceptually separates the interfaces and implementations ofobjects.IDL InterfaceRMI uses the Java language constructs for interface specification (instead of employing a separate IDLlanguage). The rmic compiler generates client stub and server skeleton classes to a particular remote objectclass from the bytecode.Proxy: local representativeAnytime a remote reference is provided to a client, a proxy is automatically created (if it does not alreadyexist). In compliance with the Broker pattern, the proxy supports the same remote interface as the targetinterface. The client always works with a local reference to the proxy. As for proxy creating, the basicstrategy (at least in the current Sun Java RMI implementation) is that anytime a remote reference isbrought into a Java address space, a new proxy is created; thus more proxies can coexist in one addressspace even though they embed the same remote reference.Marshalling: transmitting request & responseRMI uses a proprietary internal format for request and response marshalling. As far as parameter passingin remote calls is concerned, local objects are passed by copy using the Java object serialization (theobjects have to support the Serializable interface). When a remote object is passed as a parameter (areference to a proxy is indicated as the parameter) the proxy itself is passed (serialized); this complies withthe idea of multiple proxies in one address space (Section 4.1.4). As the proxy contains the remotereference, the RMI specification [22] also says "a remote object is passed by reference".Combining basic principles: basic patternsThe RMI architecture is organized in three cooperating layers (bottom-up): transport layer, remotereference layer, and stub/skeleton layer. This very much follows the Broker pattern - in RMI, the Brokerobject is implemented by the transport and remote reference layers.9.Explain about Providing and employing a service in java?Registering a service with brokerA server object can implement multiple Remote interfaces (those inheriting from Remote). Not very muchreflecting the key RMI policy to strictly separate interfaces and their implementations (Section 4.1.2), aserver 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 theUnicastRemoteObject class (e.g., it can be inherited into the Remote object implementation). The resultof the registration is a proxy supporting all of the Remote interfaces the object implements.NamingAt every node supporting RMI, there is the daemon process called RMI Registry. In principle, an RMIRegistry is a name server which supports a flat name space and registers pairs <name, proxy> associatedwith the Remote objects existing in this node. A Remote object is registered under a chosen name bycalling the operation bind() (or rebind()) of the RMI Registry at a particular node. The RMI Registryis accessible form the outside of the node via its Internet address.Finding a service, trading

Page 31: cbt

There is no trading or location service in RMI at present.BindingTo establish a connection from a client C to a server object SO located on a node N and registered thereunder the name name_SO, C contacts the RMI Registry at N and via its operation lookup() resolvesname_SO into the registered proxy of SO; a copy of this proxy is delivered to C as the result of thelookup() operation. Moreover, via introspection C can get from the proxy the information on all of theRemote interfaces SO (and thus also the proxy) supports. The client can of course receive a proxy as aresult of another remote call not targeting a RMI registry. The client is bound to a server object at themoment it receives the proxy.Static invocation and deliveryIf the client was compiled with knowledge of the requested service interface, it can use the methods ofthe corresponding proxy via statically encoded calls. Similarly, the corresponding skeleton at the serversideimplements static delivery.Dynamic invocation and deliveryThere is no support for dynamic delivery on the server side. On the client side, however, dynamicinvocation is always possible via the implicit opportunity to use the introspection features provided for anyobject to dynamically set up a call of a particular method in one of the proxy’s interfaces. The key benefitof the Java code mobility is that a proxy code can be always dynamically downloaded into a runningapplication (no recompilation is necessary).10.Explain about Inherent issues of java?Server objects garbage collection problemThe RMI system uses the second approach mentioned in Section 2.4.1: it keeps track of the live TCP/IPconnections. Basically, each registration of a remote reference in the RMI Registry implies also one liveconnection. If the number of live connections reaches zero, the server object is handled as if it was a localobject in the server’s JVM and thus being a subject of the standard local garbage collection process.Persistent remote referencesRemote references can be persistent in the RMI system in the following sense. If a client uses a remotereference and the connection from its proxy to the target skeleton does not exist any more, thecorresponding 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 AOcan register with the RMID (RMI Daemon) running at its node, and, consequently, a remote referenceto AO will contain also an information on the RMID. In case the remote reference is used and thecorresponding connection to the target skeleton does not exist any more, the RMID indicated in thereference is contacted instead; the RMID reactivates the server object and provides the client proxy withan updated remote reference.TransactionsRecently, the Java Transaction Service (JTS) has been announced. Essentially, JTS is a mapping of theCORBA Transaction Service (Sect. 3.4.3) to the Java environment.Concurrency in server objectsFollowing the Reactor pattern [15] in principle, the RMI system can deliver multiple calls at the same timeto a particular server object and they will executed in separate threads. (Nothing can be assumed about theactual dispatching strategy.) The standard Java synchronization tools are to be employed to handleconcurrent access/modification to the server object’s state. For this purpose, Java provides, e.g. thesynchronized clauses, and the wait, resp. notify methods.Applying client-server relation transitivelyApplying a client/server relation transitively is straightforward in Java RMI by providing the server witha remote reference to another server as described in Section 2.4.5. When a callback from a server S to itsclient C is implemented this way, deadlock should be avoided by creating a dedicated thread to accept thecallback in the client (there is no guarantee as for the number of the threads available for deliveringrequests, Sect. 4.4.4). As an aside, the Java Beans event model (Sect. 4.5) can also be also employed forcallbacks (with a significant comfort).Reactive programming

Page 32: cbt

To support the Observer (Publisher-Subscriber) pattern, Java Beans event model is defined in the Javaenvironment. 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 themethod, which corresponds to the event being reported, of all these subscribers. The new version of JavaBeans, Glasgow, supports BeanContext services. One the proposed services is the Infobus [20]. The basicidea of the Infobus is that, a subscriber does not have to know the particular remote reference of the Beannotifying 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 principlesMicrosoft’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 similarfunctionality across node boundaries. We focus on COM interaction across separate address spaces andwill emphasize some of the key DCOM’s architectural enhancements to COM. An important part ofMicrosoft’s object technology is OLE (Object Linking and Embedding); originally designed to supportcompound documents, OLE is mainly a library of predefined interfaces and default implementation ofsome of them.In COM, the key concept is COM object. Here "object" is not a classical object, it is a componentcomposed of (classical) objects and providing a set of interfaces to the outside. Using the terminology ofSect. 2, a client residing in one address space calls a remote method of an interface of a COM Objectresiding in a server (in this paper: server COM object, or server object for short). Each interface of theserver COM object corresponds to one service provided by this object.Request & responseThe COM/DCOM architecture is based on the Broker pattern. In COM, a client issues a request targetinga 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 ProcedureCalls (LRPC); DCOM uses the Object-Oriented RPCs (ORPCs) developed upon the base of DCE remoteprocedure calls from OSF.Remote referenceRemote references are handles to server objects’ interfaces. Each of the separate interfaces of a serverobject is associated with its own remote reference. Remote references are stored in proxy objects. Whenused for remote calls, remote references are referred to as binding information, which can contain, forexample, information on the transport protocol, host address, and the port number. When transferred asa parameter of a remote call, a remote reference is referred to as an Object Reference (OBJREF). InDCOM. 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, IPIDidentifies the target interface, binding_info_on_OXID_resolver identifies the resolver process which canresolve the rest of the tuple into the corresponding binding information.IDL InterfaceThe IDL language used by COM/DCOM is called MIDL. Interface specifications are compiled by thestandard Microsoft IDL Compiler (also denoted as MIDL), which creates the code of sever stubs and clientproxies. 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 repositoryentries in CORBA).

Page 33: cbt

Proxy: local representativeAnytime a remote reference is provided to a client, a proxy object is automatically created (if it does notalready exist) in the client’s process. Naturally, in compliance with the Broker pattern, the proxy objectsupports the same interface as the target of the remote reference. The client always works with a localreference to the proxy object. The basic philosophy is that anytime a new remote reference is brought intoa process, a proxy object is created; in principle, there is a proxy object per each interface of a serverobject.Marshalling: transmitting request & responseCOM uses a proprietary internal format for request and response marshalling. As far as parameter passingof remote calls is concerned (with DCOM on mind), data are marshalled in a platform independent formatcalled 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, thenecessary 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 reflectedin a proxy object, and the server-side proxy in a stub object. More specifically, the direct communicationvariant of the Broker pattern is employed, as proxies directly communicate with corresponding stubs. TheAbstract Factory pattern plays a very important role in COM/DCOM: In servers, new objects areinstantiated 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 objectsbased on this particular class. (To follow the COM convention, we refer to "object factory" as classfactory.)Providing and employing a serviceRegistering a service with brokerCompared to CORBA and JAVA RMI, the basic philosophy of remote references in COM/DCOM isdifferent: they are not expected to persist; they are not intended to be directly used for reactivation ofservers (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 factoryresiding also in the server for a remote object creation and at the same time indicates the interface usedfor accessing the object. During this process the corresponding stub and proxy objects are created. Theproxy object contains the linking information to that particular interface of the server object. If the proxyobject’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 proxyobject’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 resolvedinto the linking information. Therefore, a server (object exporter) has to be registered with the OXIDResolver Process running at its node.NamingThere 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 identifyclasses 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 ofmonikers (persistent objects used to internalize and externalize the state of COM objects). The names ofmonikers are based on indication of the URL together with the logical path to data stored on a permanentstorage (e.g., a file of or an object in a COM structured storage).Finding a service, tradingThere is no trading service available in COM/DCOM. However, there is an option one could callemulation service: a class can emulate the functionality of a set of classes being generic or parametrizedvia an "emulation configuration".BindingA client can bind to remote service (an interface of a server COM object) in two ways. First, it can aska known class factory to create a server object and provide access to its particular interface, reflecting the

Page 34: cbt

basic strategy of work with remote objects. The creation is done by calling theCreateInstance(...,iid,...) method of the corresponding class factory; iid indicates the requiredinterfaces of the created COM object. Second, it can use the method BindToObject() of a Monikerassociated with externalized state of a remote object. This method either creates a new COM object andinternalizes its state, or recognizes that such a COM object already exists. In both cases, the final effectis that the client is provided with a reference to a proxy object supporting the required interface of theserver COM object.Static invocation and deliveryWhen the client code was compiled with knowledge of the requested service interface, the remote callscan be encoded statically as calls of the proxy object’s methods. Recall that in COM/DCOM thegranularity of proxies is such that there is a proxy object per each interface of a server object (Section5.1.4). Similarly, static delivery is done by statically encoded calls executed in the corresponding Stubobject..Dynamic invocation and deliveryAs far as dynamic invocation is concerned, COM/DCOM follows very much the approach described inSect. 2.3.6. A COM object can support an IDispatch interface (predefined in OLE), the implementationof which is associated with an "indirect interface" (our concept). As an aside, a description of thisinterface’s methods is available through a type library. IDispatch contains the Invoke() method; via itsparameter of type DISPID, a method of the indirect interface can be called (the call is delegated in theimplementation of invoke()). The DISPID value can be obtained from the type library. Similarly, anotherparameter of Invoke(), a variant record, supplies the parameters of the delegated call. The suppliedparameters are to be provided in an encoded form (there are rules for encoding both the simple andcomposite 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 theimplementation of which delegates calls to the "classical" interface. However, the server COM object doesnot have to support both interfaces at the same time. If it supports only the IDispatch interface, the clientis 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 dualinterface combines both the "classical" interface and the corresponding IDispatch interface. The dynamicinvocation is in OLE referred to as automation.13.Explain about Inherent issues of COM/DCOM?Server objects garbage collection problemThe cooperative garbage collection technique is employed in COM/DCOM (Section 2.4.1). The referencecounting may be, alternatively, applied on a COM object as one entity, or separately for each of itsinterfaces. The first variant is the usual approach. However, some of the COM object’s interfaceimplementation can be associated with large data structures - in a similar case separate reference countingmay be applied in order to dispose the interface implementation as soon as possible.Persistent remote referencesIn COM/DCOM remote references are not persistent. The way to approximate persistence of remotereferences and their target server objects is to associate a server COM object with a moniker object andrenew the reference via the moniker’s BindToObject() method as described in Sect. 5.3.4.TransactionsThrough the Microsoft Transaction Server (MTS), transparent addition of transactional capabilities to aCOM object is possible; references to other COM objects are automatically detected and the target COMobjects are made transactional components as well (transitive closures of related COM objects areevaluated). Nested transaction are supported. The hart of the MTS, the MTS Executive, maintains a poolof 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 storageoperations have been announced to be subject to simple transactions in Windows NT 5.0.Concurrency in server objectsIn COM, there are two basic models of threading related to access to the objects made externally availableby servers (to server objects): the apartment model and the free threading model. For a server object, beingin an apartment means that there is only one thread to call its methods in response to the requests

Page 35: cbt

incoming from clients; in other words, the methods of all its interfaces are implicitly mutually excludedand no synchronization is necessary. On the contrary, if the free threading model is applied to the addressspace a server object resides, the methods of all its interfaces can be called and executed simultaneouslyby any number of threads. Appropriate synchronization has to be applied in implementation of thesemethods to handle the concurrent access/modification to the server object’s state.Applying client-server relation transitivelyApplying client-server relation transitively is straightforward in COM/DCOM. To avoid deadlock whileemulating a callback from a server S to its client C (via the approach mentioned in Sect. 2.4.5), theclient C has to be of a multithreaded implementation (the free threading model has to be applied at theclient side).

14 .Explain about Distributed objects of RMI? Basic principles Request & responseUnder the term distributed objects, we usually understand objects which reside in separate address spacesand methods of which can be subject of remote method calls (a remote call is issued in an address spaceseparate to the address space where the target object resides). By convention, the code issuing the call isreferred to as the client; the target object is referred to as the server object (or simply remote object); theset of methods which implements one of the server object’s interfaces is sometimes designated as aservice that this object provides. Similarly, the process in which the server object is located is referred toas a server.An important goal of the client and server abstractions is to make it transparent how "far" the client andserver spaces actually are - whether they reside on the same machine, are on different nodes of a localnetwork, or even reside on different Internet URLs (thus being "intergalactic"); as a special case, clientand server may share the same address space.Because it is inherently delivered over a network communication infrastructure, a remote method call istypically 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 methodcall can be done as one atomic action (synchronous call), or they can be separated, where the client issuesthe 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, thecorresponding method is usually termed a one-way method. A one-way method can be calledasynchronously, where the client does not have to wait till the call is finished. In a distributed environmentthe exactly-once semantics of remote calls is practically impossible to achieve; real distributed platformsensure the at-most-once semantics of a synchronous and deferred-synchronous call (exactly-once semanticsin case of a successful call, at-most-once semantics otherwise); best-effort semantics is ensured for a onewaymethod.2.1.2 Remote referenceOne 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 ussuppose only one of the parameters, say pj, contains a reference. However, in a distributed environmentwe face the following issue: rro should identify a remote object over the network, and so should pj. Itis obvious that classical addresses will not do as the references, at least for the following reasons: inaddition to the data record of the target object, a reference has also to identify the node and the server inwhich 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

Page 36: cbt

to which m belongs. By convention, a reference that contains all this information is termed a remotereference. Hence, a remote reference identifies a service. In addition, representation of a remote referencehas to span the differences in the hardware architectures of the nodes where the objects involved in aparticular remote method call reside.2.1.3 IDL InterfaceIn principle, a client’s code and the server object that is subject to a remote call from the client can beimplemented in different languages and can run on heterogenous architectures. To span this kind ofdifference, the interfaces of a server object are specified in an architecture-neutral Interface DefinitionLanguage (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 amapping from IDL to standard programming languages, such as C++ and Java, is a part of an IDLdefinition. CORBA IDL and Microsoft MIDL are examples of IDL languages.2.1.4 Proxy: local representativeTo bridge the conceptual gap between the remote and local style of references, both in the client andserver code, the actual manipulation with remote references is typically encapsulated in wrapper-likeobjects known as client-side and server-side proxies. The client-side proxy and the corresponding serversideproxy communicate with each other to transmit requests and responses. Basically, the client-side proxysupports the same interface as the remote object does. The key idea behind proxies [17] is that the clientcalls a method m of the client-side proxy to achieve the effect of calling m of the remote object. Thus, theclient-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 formand to transform the result of the call to a form suitable for transmitting to the client-proxy. Thus, a serversideproxy can be considered as the representative of all potential clients of the remote object.2.1.5 Marshalling: transmitting request & responseBoth the request and response of a call are to be converted into a form suitable for transmitting over thenetwork communication infrastructure (a message, or a TCP socket connection for transmitting streamsmight be an example of the infrastructure). Typically, serialization into a byte stream is the technical baseof such conversion. By convention, this conversion is referred to as marshalling (the reverse process isunmarshalling). Some authors use these concepts in a narrower sense, where marshalling/unmarshallingrefers 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 twoapproaches indicate the basic options: passing remote references and passing objects by value. Supposerro.m(rp,lp) is a remote call issued by a client C. The rro reference identifies a proxy whichencapsulates 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 requestcorresponding 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 detailson design patterns (patterns for short) refer, e.g., to Buschmann et al. [1] or Pree [14], and particularly tothe classical catalog of design patterns by Gamma et al. [3]. We will use informally just a few of themin the following sections to explain the basic ideas behind the architectural concept of the distributed objectplatforms.2.2.1 Broker patternThe Broker pattern in Fig.1 reflects the classical client/server relationship implementation in distributedenvironment. The role of the Client, Client-side Proxy, Server-side Proxy and Server was explained in theprevious sections, so we can focus on the Broker object, which is in this pattern to capture thecommunication between Client-side Proxy and corresponding Server-side Proxy. In a loop, the Brokerforwards requests and responses to the corresponding proxies. These requests and responses are encoded

Page 37: cbt

in messages by which the Broker communicates with the proxies. Figure 2 demonstrates a typical scenarioof object interaction for delivering a request and receiving a response. Another scenario (Fig.3), illustrateshow a server registers the service it provides with the Broker object. The Broker pattern, as described sofar, is a Broker with indirect communication between proxies. In the typical modification of the Brokerpattern referred to as Broker with direct communication, the Client-side Proxy and the correspondingServer-side Proxy communicate directly after a communication channel was initially established. A Bridgeobject is used to communicate with other Brokers.2.2.2 Proxy patternThe essence of the proxy idea (Sect. 2.1.4, 2.2.1) is captured in Fig.4. Both the Proxy and Original classessupport the same interface defined by AbstractOriginal. A typical scenario of interaction among instancesof these objects is depicted in Fig. 5.2.2.3 Abstract Factory patternIn principle, a factory is an object which creates other object; usually a factory is specialized for creatingobjects 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 usingfactories 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 objectfactory returns a remote reference of the newly created object. Typically, the created object resides in thesame server as does the Object Factory involved in the request. The essence of the factory idea is capturedby the Abstract Factory pattern (Fig.6). In particular, it illustrates that a Concrete Factory is devoted tocreation of products of specific types.14.Explain about Providing and employing a service of RMI?2.3.1 Registering a service with brokerIn order to be remotely accessible, any service provided by a server has to be registered with a broker. Asa result of the registration operation, the broker a creates a remote reference to the service (i.e. to aparticular 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, followingthe Abstract Factory pattern, an object factory residing in the server would be used to create the newremote object implementing the service being registered.2.3.2 NamingBecause the remote references are supplied by brokers in scarcely legible form, and so to enable the useof 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. Classicaloperations for resolving a name into a remote reference and associating a name with a remote referenceare provided. Typical scenarios for a naming implementation include (a) providing a naming serviceaccessible via a well-known remote reference, (b) embodying naming in the Broker’s functionality.2.3.3 Finding a service, tradingFor 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 theproperties which the client indicated as the search key. The typical scenario for trading implementationincludes provision of a trading service accessible via a well-known remote reference.2.3.4 BindingAs mentioned in Sections 2.1.5, 2.3.2, and 2.3.3., the client can receive a remote reference via naming ortrading, or as a result of another remote method call (in fact if naming and trading are implemented asservices, the client always receives remote references as a result of other remote methods calls - exceptfor well-known remote references of, e.g., naming and trading services). It is a general rule of all thedistributed 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 theproxy. At the latest with the first remote call that the client issues via the proxy, the connection betweenthe 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

Page 38: cbt

When the client was compiled with the knowledge of the requested service interface (e.g., in the form ofan IDL specification), the remote methods’ calls can be encoded statically in the clients code as calls ofthe proxy methods (static invocation). This is done fully in compliance with the proxy pattern (Section2.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 (staticdelivery).2.3.6 Dynamic invocation and deliveryIn principle, the client and the server can be compiled separately; thus they might not always be currentwith respect to the static knowledge of available interfaces. Moreover, there are specific applications inwhich 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 withan interface (say IRemote) which allows issuing dynamically set-up calls (dynamic invocation). The nameof the corresponding method is typically invoke(). As an example, suppose the rop.m(p1, ..., pn) callis to be issued dynamically as the signature of m was not known at compile time (rop is a reference to theproxy 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 tomethod_name, and fill paramlist_array with the parameters p1, ..., pn. Usually some kind ofintrospection is necessary to obtain/check details on the target interface at run time (types and numbersof method’s parameters, etc.).Similarly, new objects can be created in a server with interfaces not known at compile time (e.g., in aviewer or a bridge). Calls to these objects can be delivered dynamically if these objects are equippedaccordingly. The usual technique employed is the following: Suppose the rop.m(p1,...,pn) call is tobe delivered to the object RO identified by the rop remote reference; however, the object is located in aserver which was compiled without any knowledge of RO’s interfaces - except for the IRemote interfacesupported by all remote objects. IRemote contains the invoke() method which accepts dynamicallycreated calls and forwards them to the actual methods of RO. Thus to be able to accept dynamic calls, ROhas to implement the Invoke method. The server-side proxy associated with RO is very simple - itsupports just the IRemote interface; therefore the code of the server-side-proxy can be very generic andcan 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 sidewith dynamic delivery at the server side and vice versa (combining dynamic invocation with staticdelivery).15Explain about Inherent issues of RMI? Server objects garbage collection problemThe server objects not targeted by any remote reference can be disposed and should be handled by agarbage collector. As opposed to the classical techniques used in single address space, garbage collectionin 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 distributedobjects: (1) Garbage collection is done in the underlaying platform, e.g. at a distributed operating systemlevel; this approach remains in an experimental stage [23]). (2) The broker evaluates the number of livereferences (e.g., derived from the number of live connections). (3) The server keeps track of the numberof references provided to the outside; each of its clients has to cooperate in the sense that if it does notneed a remote reference any more, it should report this to the server. This technique is called cooperativegarbage collection.The approaches (2) and (3) are based on reference counting: once the reference count drops to zero, thetarget object can be disposed of. Despite of its simplicity, reference counting suffers from a seriousproblem - cyclic referencing among otherwise unreachable object prevents zeroing of reference counts. Persistent remote referencesLifecycles of clients and servers are not synchronized. For example, a server can time-out or crash, andits client can still hold a remote reference to an object located in the server. Thus, remote references canpersist with respect to the server they target. In most of the distributed object platforms, using a remotereference to an inactive server is solved by an automatic reactivation of the server. Typically, before theserver 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

Page 39: cbt

reactivation process). TransactionsTransaction are an important tool in making distributed object applications robust. Three consequences ofworking with distributed objects with respect to transactions should be emphasized: (1) Because oftransitive 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. Thisimplies 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 ofresources) 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 dealingwith this problem. Concurrency in server objectsIn the basic variant of the Broker pattern (Section 2.2.1), the Server enters a loop and waits for incomingrequests. In this variant, the Server responds to the requests sequentially. However, many implementationsemploy multithreading; the following is an example of this approach: the Broker, sharing address spacewith 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 isnow 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 raceconditions, 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 amultithreaded Broker. Applying client-server relation transitivelyIt is very natural for a server S be become a client of another server S’. Simply an object O in S containsObject Reference to an object O" in S’. Thus any method of O can invoke a method of O’’. This verylikely happens when a remote reference is passed as a parameter in a request to S. In fact, we face atransitive application of the master/slave pattern [3]. Furthermore, this is also the underlying idea of n-tierarchitectures [13]. Similarly, we can also achieve callbacks from a server to its client by passing a remotereference of the interface, which is to be the subject of a callback from the client to the server (see alsoSection 2.5). Reactive programmingThe 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 thedistributed object platforms define some abstractions to support this style of programming with significantcomfort. In principle, all of them are based on the Observer (Publisher-Subscriber) pattern [3]. The basicidea here is that a listener object (Subscriber) can subscribe to an event source (Publisher) to be notifiedabout and event (asynchronous signal) occurrence. The Publisher announces what interfaces its listenershave to honor and what methods of these interfaces will be called to report on an event. This reportingcan be just a notification (one-way method will do), or a callback (some results can be delivered to thePublisher). One of the key benefits of this approach is that the Publisher does not have to know itslisteners at compile time; listeners subscribe dynamically.16. Distributed objects in CORBA3.1 Basic principles3.1.1 Request & responseIn CORBA, a client issues a request to execute a method of an object implementation. There is noconstraint 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

Page 40: cbt

located on separate nodes. A server (process) can contain implementation of several objects or a singleobject, or even provide an implementation of one particular method only. However, typically, amultithreaded server encapsulates implementations of multiple objects.3.1.2 Remote referenceRemote references are called Object References and the target of an Object Reference must be an objectthat supports the CORBA::Object IDL interface (such objects are called CORBA objects).3.1.3 IDL InterfaceCORBA 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 constructsrelated to object implementation (object state definitions have been proposed recently by OMG).3.1.4 Proxy: local representativeUsing the Broker Pattern terminology, the client-side proxy code is called IDL stub; the server-side proxycode is referred to as IDL skeleton. However, in CORBA, the concept "proxy" is used to denote an objectcreated on the client side which contains the IDL stub plus provides some other functionality, e.g. supportfor dynamic invocation.3.1.5 Marshalling: transmitting request & responseBoth request and response are delivered in the canonical format defined by the IIOP protocol which is thebase 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 thefunctionality of the dynamic invocation interface (Section 3.2). On the server side, unmarshalling is donein the IDL Skeletons (or in the Dynamic Skeleton Interface, DSI) and partially in the Object Adapter. Ina request (response), Object References can be provided as parameters; remote objects can be passes byreference. 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 BrokerPattern is mapped as the ORB Core; it is employed for establishing the connection between a client anda 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 (Sect. 3.3.1,IDL skeleton, and DSI skeleton serving for dynamic delivery. More specifically, the direct communicationvariant of the Broker pattern is employed in many of the CORBA implementation (e.g., in Orbix), wherethe 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 isused 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 factoryable to create object of a given type) and generic factory (which encapsulates the functionality of multiplefactories).3.3 Providing and employing a service3.3.1 Registering a service with brokerRegistering the object which represents the service is the task of the Object Adapter. Its currentlymandatory version, POA, provides, e.g., the activate_object(), activate() methods to supportregistration. In principle, activate_object() registers the object with POA and assigns a new ObjectReference, which will serve for referencing the newly created object; activate() signals that a particularserver (or a particular POA, to be precise) is ready to accept requests. Finally, calling ORB::run() tellsthe ORB to enter the main request processing loop.3.3.2 NamingOfficially there is the CORBA Naming Service which should provide for name spaces and for mappingsamong Object References and names. However, in addition to the standard Naming Service, most of theCORBA implementations provide a vendor specific way to locate objects associated directly withregistering of a service at the server side and a "binding" operation on the client side.3.3.3 Finding a service, tradingFor 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, askingthe CORBA trading service (in analogy to yellow pages) to provide a list of services (Object References)

Page 41: cbt

that possess the properties used as the search key. Some CORBA implementations (e.g. Orbix andVisiBroker), provide a proprietary location service. In a sense, this service is a hybrid between namingand 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 locationservice does not cover the functionality of the CORBA Naming Service or CORBA Trading Service.3.3.4 BindingThe client is bound to the requested server after it receives one of its Object References (and acorresponding proxy is created, Section 2.3.4).3.3.5 Static invocation and deliveryWhen the client was compiled with knowledge of the requested service IDL specification, the proxyimplements the mapped IDL interface methods. The corresponding code of the proxy is encapsulated inthe IDL stub (Sect. 3.2). Similarly, the corresponding IDL skeleton is the code of the server-side proxywhich implements static delivery.3.3.6 Dynamic invocation and deliveryFor dynamic invocations, the proxy contains the create_request() method which returns a Requestobject. There is also a way to submit arguments with the request. When creating a request, the InterfaceRepository can be consulted for details about the target interface. The actual dynamic invocation isinitiated 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 whichdelivers the request via the invoke() method supported by the PortableServer::DynamicImplementationinterface. CORBA allows for combining static invocation at the client side with dynamic delivery at theserver side and vice versa. At the server side, the choice between static and dynamic delivery is made bythe server object itself (it can be determined, e.g., as a part of the registration with POA), regardless ofthe 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 appliedin CORBA clients implemented in Java. In this case, the client code can be compiled without employingthe IDL compiler (just the knowledge about the interface form will do).16.Expalin about Distributed Objects in Java?4.1 Basic principlesCurrently, there are two ways to handle distributed objects in the Java environment: (1) Employing theJava RMI (Remote Method Invocation) service together with the Java Object Serialization service, or (2)employing the CORBA IIOP protocol, alternatively: (a) in a Java-written client code via stubs which speakthe CORBA IIOP protocol, or (b) directly in a CORBA ORB fully implemented in the Java environment(e.g., OrbixWeb, VisiBroker)). In this section we limit ourselves to RMI (JDK1.2, [22]).4.1.1 Request & responseThe Java RMI architecture is based on the Broker pattern (Section 2.2.1). In addition to the classicalscenario of a client request targeting a particular interface of a single server object, the RMI architectureis open to support also, e.g., replication of server objects (transparent to the client request). At present, theSun Java RMI implementation includes only simple point-to-point requests and responses based upon theunderlying 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 (ingeneral) to the client’s JVM.4.1.2 Remote referenceRemote references are handles to remote objects (those implementing the Remote interface). Remotereferences are not directly accessible; they are encapsulated in proxies (stubs and skeletons, Sect. 4.2). Akey RMI feature is that, from a client’s point of view, a remote reference can always be employed onlyvia an interface (derived from Remote). This conceptually separates the interfaces and implementations ofobjects.4.1.3 IDL InterfaceRMI uses the Java language constructs for interface specification (instead of employing a separate IDLlanguage). The rmic compiler generates client stub and server skeleton classes to a particular remote objectclass from the bytecode.

Page 42: cbt

4.1.4 Proxy: local representativeAnytime a remote reference is provided to a client, a proxy is automatically created (if it does not alreadyexist). In compliance with the Broker pattern, the proxy supports the same remote interface as the targetinterface. The client always works with a local reference to the proxy. As for proxy creating, the basicstrategy (at least in the current Sun Java RMI implementation) is that anytime a remote reference isbrought into a Java address space, a new proxy is created; thus more proxies can coexist in one addressspace even though they embed the same remote reference.4.1.5 Marshalling: transmitting request & responseRMI uses a proprietary internal format for request and response marshalling. As far as parameter passingin remote calls is concerned, local objects are passed by copy using the Java object serialization (theobjects have to support the Serializable interface). When a remote object is passed as a parameter (areference to a proxy is indicated as the parameter) the proxy itself is passed (serialized); this complies withthe idea of multiple proxies in one address space (Section 4.1.4). As the proxy contains the remotereference, the RMI specification [22] also says "a remote object is passed by reference".4.2 Combining basic principles: basic patternsThe RMI architecture is organized in three cooperating layers (bottom-up): transport layer, remotereference layer, and stub/skeleton layer. This very much follows the Broker pattern - in RMI, the Brokerobject is implemented by the transport and remote reference layers.4.3 Providing and employing a service4.3.1 Registering a service with brokerA server object can implement multiple Remote interfaces (those inheriting from Remote). Not very muchreflecting the key RMI policy to strictly separate interfaces and their implementations (Section 4.1.2), aserver 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 theUnicastRemoteObject class (e.g., it can be inherited into the Remote object implementation). The resultof the registration is a proxy supporting all of the Remote interfaces the object implements.4.3.2 NamingAt every node supporting RMI, there is the daemon process called RMI Registry. In principle, an RMIRegistry is a name server which supports a flat name space and registers pairs <name, proxy> associatedwith the Remote objects existing in this node. A Remote object is registered under a chosen name bycalling the operation bind() (or rebind()) of the RMI Registry at a particular node. The RMI Registryis accessible form the outside of the node via its Internet address.4.3.3 Finding a service, tradingThere is no trading or location service in RMI at present.4.3.4 BindingTo establish a connection from a client C to a server object SO located on a node N and registered thereunder the name name_SO, C contacts the RMI Registry at N and via its operation lookup() resolvesname_SO into the registered proxy of SO; a copy of this proxy is delivered to C as the result of thelookup() operation. Moreover, via introspection C can get from the proxy the information on all of theRemote interfaces SO (and thus also the proxy) supports. The client can of course receive a proxy as aresult of another remote call not targeting a RMI registry. The client is bound to a server object at themoment it receives the proxy.4.3.5 Static invocation and deliveryIf the client was compiled with knowledge of the requested service interface, it can use the methods ofthe corresponding proxy via statically encoded calls. Similarly, the corresponding skeleton at the serversideimplements static delivery.4.3.6 Dynamic invocation and deliveryThere is no support for dynamic delivery on the server side. On the client side, however, dynamicinvocation is always possible via the implicit opportunity to use the introspection features provided for anyobject to dynamically set up a call of a particular method in one of the proxy’s interfaces. The key benefitof the Java code mobility is that a proxy code can be always dynamically downloaded into a runningapplication (no recompilation is necessary).

Page 43: cbt

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

Page 44: cbt

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.

Page 45: cbt

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

Page 46: cbt

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.

Page 47: cbt

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 applications26.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?

Page 48: cbt

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.

Page 49: cbt

35.Draw OMG Reference model?

Figure 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.

Page 50: cbt

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.

Page 51: cbt

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.

Page 52: cbt

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.

Page 53: cbt

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

Page 54: cbt

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

Page 55: cbt

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;

Page 56: cbt

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].

Figure 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.

Page 57: cbt

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

Page 58: cbt

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

Page 59: cbt

IDL Type Java Type

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

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

constant (within an interface) fields in the Java signature interface for non-abstract, or the sole Java interface for abstract

exception class

Any org.omg.CORBA.Any

type declarations nested within interfaces

"scoped" package

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

Page 60: cbt

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.

Page 61: cbt

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

Page 62: cbt

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

Page 63: cbt

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

Page 64: cbt

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?

Page 65: cbt

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&rsquo;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?

Page 66: cbt

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."