IT1402 MWT Notes - CSE TUBE PDF

www.csetube.
in
UNIT-I
CLIENT/SERVER CONCEPTS
The Client Server Architecture
The Internet revolves around the client-server architecture. The computer runs
software called the client and it interacts with software known as the server located at a
remote computer. The client is usually a browser such as Internet Explorer or Netscape
Navigator. Browsers interact with the server using a set of instructions called protocols.
These protocols help in the accurate transfer of data requests made through requests from a
browser and responses from the server. There are many protocols available on the Internet.
The World Wide Web, which is a part of the Internet, brings all these protocols under one
roof. The protocols like HTTP, FTP, Telnet, email etc. through browser.
.in
A computer or device on a network that manages network resources. For example, a
file server is a computer and storage device dedicated to storing files. Any user on the
network can store files on the server. A print server is a computer that manages one or more
be
printers, and a network server is a computer that manages network traffic. A database server
is a computer system that processes database queries.
Servers are often dedicated, meaning that they perform no other tasks besides their
tu
server tasks. On multiprocessing operating systems, however, a single computer can execute
several programs at once. A server in this case could refer to the program that is managing
resources rather than the entire computer.
se
A network architecture in which each computer or process on the network is either a

client or a server.
.c
Servers are powerful computers or processes dedicated to managing disk drives (file
servers), printers (print servers), or network traffic (network servers ).
w
w
w
Clients are PCs or workstations on which users run applications. Clients rely on
servers for resources, such as files, devices, and even processing power.
Another type of network architecture is known as a peer-to-peer architecture because

each node has equivalent responsibilities. Both client/server and peer-to-peer architectures
are widely used, and each has unique advantages and disadvantages.
Two Tier Architecture
www.csetube.in
www.csetube.in
On a logical level the typical client/server architecture is best described as two tier,
simply because it only consists of two parts working together. In other words: The client
directly talks to the server.
.in
The division point between the client and the server within the application can vary
be
depending on the capabilities of the tools used. At one extreme, the workstation is used only
to perform the display portion of the presentation component, and the server performs most
of the presentation logic and all of the business and data access logic. This leads to a fat
server and can be found e.g. in typical web-applications where the browser has to cope with
tu
HTML. At the other extreme, most of the application resides on the workstation, and the
server only performs the actual data access services. This leads to a fat client. In net-
technologies this is being realized by the use of Java-applets.
se
The two-tiered client/server approach provides some significant advantages over the
one-tiered approach. The GUI development tools allow faster development and deployment
of applications. By offloading much of the application processing to the desktop
.c
workstations, the server systems do not need to be as large. The hardware-independent

database systems allow easy portability between systems, effectively breaking the hold of
hardware lock-in.
w
But in exchange for these advantages, the two-tiered approach loses a lot of the security,
reliability, scalability, and control associated with the one-tiered approach. The two-tiered
w
model works effectively as long as simple applications are developed, exactly one relational
database is accessed, and a small user base is supported. But as applications become more
w
complex, in terms of business algorithms processed, number of databases accessed, or

number of users supported, the two-tiered approach starts to fall short.
Without the tight security controls provided by a centralized environment, each client
application must enforce its own security process. Since the relational databases can be
accessed from a number of different clients, each database must also enforce its own security
process. Therefore application users may need to repeatedly login to various systems in the
course of running the application. Since each database provides its own proprietary network
protocol, the client application has to maintain different sessions with each database being
accessed.
Due to more complex client applications, the size of the application increases; the
client hardware platform has to increase in terms of processing power and memory. In
www.csetube.in
www.csetube.in
addition, as the number of users accessing the database increases, the server hardware
platform requires higher capacity.
Two tier software architectures were developed in the 1980s from the file server
software architecture design. The two tier architecture is intended to improve usability by
supporting a forms-based, user-friendly interface. Finally this type of distributed architecture
requires minimal operator intervention, and is frequently used in non-complex, non-time
critical information processing systems.
Three Tier Architecture
Three-tier architecture introduces a server (or an "agent") between the client and the
server. The role of the agent is manifold. It can provide translation services (as in adapting a
legacy application on a mainframe to a client/server environment), metering services (as
inacting as a transaction monitor to limit the number of simultaneous requests to a given
.in
server), or intelligent agent services (as in mapping a request to a number of different servers,
collating the results, and returning a single response to the client. A three tier distributed
client/server architecture includes a user system interface top tier where user services (such as
be
session, text input, dialog, and display management) reside.
The third tier provides database management functionality and is dedicated to data
tu
and file services that can be optimized without using any proprietary database management
system languages. The data management component ensures that the data is consistent
throughout the distributed environment through the use of features such as data locking,
se
consistency, and replication. It should be noted that connectivity between tiers can be
dynamically changed depending upon the user's request for data and services.
.c
w
w
w
The middle tier provides process management services (such as process development,
process enactment, process monitoring, and process resourcing) that are shared by multiple
applications. The middle tier server (also referred to as the application server) improves
performance, flexibility, maintainability, reusability, and scalability by centralizing process
logic. Centralized process logic makes administration and change management easier by
localizing system functionality so that changes must only be written once and placed on the
middle tier server to be available throughout the systems.
File server
In telecommunication, the term file server has the following meanings:
www.csetube.in
www.csetube.in
 A form of disk storage that hosts files within a network; file servers do not need to be
high-end but must have enough disk space to incorporate a large amount of data.
Many people mistake file servers for a high-end storage system, but in reality, file
servers do not need to possess great power or superfast computer specifications.
 A computer program, that allows different programs, running on other computers, to

access the files of that computer
 In common parlance, the term file server refers specifically to a computer on which a
user can map or mount a drive or directory so that the directory appears to be on the
machine at which the user is sitting. Additionally, on this type of file server, the user
can read or write a file as though it were part of the file system of the user's computer.
Files and directories on the remote computer are usually accessed using a particular protocol,
such as SMB, CIFS, NFS (Network file system), Appletalk or their mutations.
.in
 Although files can be sent to and received from most other computers unless their
primary function is access by the above means, they are generally not considered file
be
servers as such.
Memory Requirements
tu
File servers have historically been instrumental in pushing up the demand for RAM.
The Novell NetWarefile server [operating system], which dominated the market for file
servers at the time of greatest growth in demand, read the entire FAT table into RAM on
se
boot, enabling rapid access to files. Whilst this guaranteed maximum performance, it also
required large quantities of memory.
This in turn drove demand for UPS devices (also known as the "Uninterruptible
.c
Power Supply" devices) as it became more and more apparent that power outages could cause
loss of data. This has become less of an issue in recent years with faster disk access times.
However, these, too, have in part been driven by file serving requirements.
w
File and Print

w
Traditionally, file and print services have been combined on the same computers due
to similar computing requirements for both functions. Usually, such computers are distinct
w
from application and database servers, which have different, usually more processor-
intensive, requirements. However, as computing power increases and file serving
requirements remain relatively constant, it is more common to see these functions combined
on the same machine.
Security
File servers generally offer some form of system security to limit access to files to
specific users or groups. In large organisations, this is a task usually delegated to what is
known as directory services such as Novell's NDS or Microsoft's Active Directory.
These servers work within the hierarchical computing environment which treat users,
directories, computers, applications and files as distinct but related entities on the network
www.csetube.in
www.csetube.in
and grant access based on user or group credentials. In many cases, the directory service
spans many file servers, potentially hundreds for large organisations. In the past, and in
smaller organisations, authentication can take place directly to the server itself.
Database Server
A database server is a computer program that provides database services to other

computer programs or computers, as defined by the client-server model. The term may also
refer to a computer dedicated to running such a program. Database management systems
frequently provide database server functionality, and some DBMS's (e.g., MySQL) rely
exclusively on the client-server model for database access. Database Master servers are
central and main locations of data while Database Slave servers are synchronized backups of
the master acting as proxies
Server Types
.in
There are several kinds of database servers which include:
be
 Flat file database servers
 Relational database servers
 Object database servers
 Object relational database servers
tu
The most popular today are Relational Database Management Systems (RDBMS). However,
object database servers may someday overtake the relational database servers.
se
Object Server
An object server is a process that provides an address space, contact points and
.c
runtime services to the local representatives that it hosts. The object server also manages a
local representative's access to local resources such as local disks and networking resources.
Besides simply hosting LRs, a Globe object server also has a remotely accessible interface
w
that allows other local representatives, other Globe object servers, or administrators to request
services from it. These services include the creation and destruction of GlobeDoc objects and
their replicas.
w
Up until the mid 90s, the basis for network-capable applications had been mostly provided by
w
client/server architectures. Over the past few years these have been increasingly replaced by
three-layer architectures (three-tier) consisting of a presentation logic for displaying and
acceptance of entries on the client (layer 1), a business logic (layer 2) and data storage,
usually in the form of a relational database (layer 3).
Object servers are used to make the business logik available to different kinds of clients in a
disrtributed environment. Such clients can be a native GUI, a web client, another server, etc.
Spellcaster is an object server that serves objects to clients in a platform and programming
language neutral way. Thus it is ideal for occupying the middle layer of a modern three-tier
software architecture.
Web Server
www.csetube.in
www.csetube.in
A computer, including software package, that provides a specific kind of service to

client software running on other computers. More specifically, a server is a computer that
manages and shares web based applications accessible anytime from any computer connected
to the Internet.
Transaction Servers:
With a transaction server, the client invokes remote procedures that reside on the
server with an SQL database engine. These remote procedures on the server execute a group
of SQL statements. The network exchange consists of a single request/reply message (as
apposed to the database server’s approach of one request/reply message for each SQL
statement in a transaction). The SQL statement either all succeeds or fail as a unit. These
grouped SQL statement are called transaction.
With a transaction server, you create the client/server application by writing the code
for both the client and server component. The client component usually includes a graphical
.in
user Interface (GUI). The server component usually consists of SQL transaction against a
database. These applications are called online transaction processing, or OLTP. They tend to
be mission-critical applications that require a 1-3 second response time 100% of the time.
be
OLTP applications also require tight controls over the security and integrity of the database.
Two forms of OLTP will be discussed in this book. TP lite, based on the stored procedures
provided by database vendors, and TP Heavy, based on the TP monitors provided by OLTP
vendors.
tu
Groupware Servers:
Groupware address the management of semi-structured information such as text,
se
image, mail, bulletin boards, and the flow of work. These client/server systems place people
in direct contact with other people. Lotus notes is the leading examples of such a system,
although a number of other applications—including document management, imaging,
multiparty applications, and workflow—are addressing some of the same needs. Specialized
.c
groupware software can be built on top of a vendor’s canned set of client/server APIs. In
most cases, applications are created using a scripting language and form-based interfaces
provided by the vendors. The communication middleware between the client and the server is
w
vendor-specific. Eventually, the internet will become the middleware of choice of groupware.
Object servers:
w
With an object server the client/server application is written as a set of

communicating objects. Client objects communicate with server objects using an Object
w
Request Broker (ORB). The client invokes a method on a remote object. The ORB locates an
instance of that object server class, invokes the requested method, and returns the results to
the client object. Server objects must provide support for concurrency and sharing. The ORB
brings it all together. After years of incubation, some “Real Life” commercial ORBs are now
in production. Examples of commercial ORBs that comply with the Object Management
Group’s CORBA standard include Digital’s Object Broker, IBM’s SOM 3.0, Sun’s NEO,
HP’s ORB plus, Expersoft’s Powerbroker, Iona’s Orbix, and Post Modern’s Black Window.
However, CORBA is not the only game in town. As we go to press, Microsoft is getting
ready to ship its own ORB, which it calls Distributed COM (DCOM) or network OLE.
Web Servers:
The World Wide Web is the first truly intergalactic client/server application. This new
model of client/server consists of thin, portable, “Universal” clients that talk of super fat
www.csetube.in
www.csetube.in
servers. In its simplest incarnation, a web server returns documents when clients ask for them
by name. The client and servers communicate using an RPC-like protocol called HTTP. This
protocol defines a simple set of commands; parameters are passed as strings, with no
provision for typed data. The Web is being extended to provide more interactive forms of
client/server computing. In addition, the Web and distributed objects are starting to come
together. Java is the first manifestation of this new Object Web.
FAT Client
A Fat Client model places more functions on the client side. For example, database
and file servers. In both the file server and database server models, the clients know how the
data is organised and stored in the server side. It is used to decision support and personal
software.
FAT Server
.in
The Fat server model places more functions on the server side. For example, web
server, transaction server and groupware server. It tries to minimize network interchanges by
be
create more abstract level of service Fat server, used of mission-critical applications.
Fat Client Fat Server

tu
GUI Applications DATA
se
Client Server
MIDDLEWARE
.c
In the computer industry, middleware is a general term for any programming that
serves to "glue together" or mediate between two separate and often already existing
w
programs. A common application of middleware is to allow programs written for access to a

particular database to access other databases.
w
Typically, middleware programs provide messaging services so that different

applications can communicate. The systematic tying together of disparate applications, often
w
through the use of middleware, is known as enterprise application integration.
Software that connects two otherwise separate applications. For example, there are a
number of middleware products that link a database system to a Web server. This allows
users to request data from the database using forms displayed on a Web browser, and it
enables the Web server to return dynamic Web pages based on the user's requests and profile.
The term middleware is used to describe separate products that serve as the glue
between two applications. It is, therefore, distinct from import and export features that may
be built into one of the applications. Middleware is sometimes called plumbing because it
connects two sides of an application and passes data between them. Common middleware
categories include:
www.csetube.in
www.csetube.in
 ESBs
 TP monitors
 DCE environments
 RPC systems
 Object Request Brokers (ORBs)
 Database access systems
 Message Passing
Middleware, on the other hand, is defined as the software layer that lies between the
operating system and the applications on each site of the system in a distributed computing
system (ObjectWeb consortium). More generally, the term is used to describe Web servers,
application servers, content management systems, and similar tools that support the
.in
application development and delivery process. Middleware is the enabling technology of
Enterprise Application Integration (EAI) and consequently integral to service-oriented
computing.
be
Current middleware in general is challenged to support adaptivity and dependability
while maintaining scalability and mastering complexity. Of course dependability and
adaptivity can not simply be added to a system like a plug-in module. Rather, middleware
needs architectural principles and sound methodologies, as well as appropriate container
tu
services, service coordination and composition standards, and possibly consideration of
software aspects to help application developers to integrate their services with a configurable
distributed middleware instead of reinventing the wheel each time.
se
While the immediate need of middleware support for Service-Oriented Architectures

(SOA) is evident, current approaches and solutions mostly fall short by primarily providing
support for the EAI aspect of SOC only and do not sufficiently address composition support,
.c
service management and monitoring.
Moreover, non-functional properties (like dependability and security) and Quality of

w
Service (QoS) need to be addressed not only by interfacing and communication standards, but
also in terms of integrated middleware support. But what makes these issues so different in a
w
SOA setting? Why - for instance - is traditional middleware support for transaction
processing different to transaction processing in SOA, reflecting different types of atomicity
needs? One answer lies in the loose coupling, high dynamicity and flexibility during run-
w
time, enabled by a significant increase of meta-data, like explicit requirement- and constraint-
negotiation during run-time.
Middleware is connectivity software that consists of a set of enabling services that

allow multiple processes running on one or more machines to interact across a network.
Middleware is essential to migrating mainframe applications to client/server applications and
to providing for communication across heterogeneous platforms.
This technology has evolved during the 1990s to provide for interoperability in
support of the move to client/server architectures (see Client/Server Software Architectures).
The most widely-publicized middleware initiatives are the Open Software Foundation's
Distributed Computing Environment (DCE) , Object Management Group's Common Object
www.csetube.in
www.csetube.in
Request Broker Architecture (CORBA), and Microsoft's COM/DCOM (see Component

Object Model (COM), DCOM, and Related Capabilities) [Eckerson 95].
As outlined in Figure, middleware services are sets of distributed software that exist
between the application and the operating system and network services on a system node in
the network.
.in
be
tu
se
Figure: Use of Middleware
Middleware services provide a more functional set of Application Programming

.c
Interfaces (API) than the operating system and network services to allow an application to
w
 locate transparently across the network, providing interaction with another application
or service
 be independent from network services
w
 be reliable and available

 scale up in capacity without losing function
w
Middleware can take on the following different forms:
 Transaction processing (TP) monitors, which provide tools and an environment for
developing and deploying distributed applications.
 Remote Procedure Call (RPCs), which enable the logic of an application to be
distributed across the network. Program logic on remote systems can be executed as
simply as calling a local routine.
 Message-Oriented Middleware (MOM), which provides program-to-program data
exchange, enabling the creation of distributed applications. MOM is analogous to
email in the sense it is asynchronous and requires the recipients of messages to
interpret their meaning and to take appropriate action.
www.csetube.in
www.csetube.in
 Object Request Brokers (ORBs) , which enable the objects that comprise an
application to be distributed and shared across heterogeneous networks.
Classes of Middleware
General Middleware
It includes communication stacks, distributed directories, authentication services,

network time, remote procedure calls and queuing services. It also includes distributed file
and print services.
Service-specific middleware
 Database-specific middleware
 OLTP- (On Line Transaction Processing) middleware
.in
 Groupware-specific middleware
 Object-specific middleware
 Internet-specific middleware
be
 System management-specific middleware
CLIENT/SERVER BUILDING BLOCKS

tu
Building blocks are
1. Client
2. Middleware
se
3. Server
Different types of arrangement of building blocks are
1. Client/server for tiny shops and nomadic tribes
.c
Single
w
Client Middleware Server machine

w
This building block implementation that runs the client, the middleware software, and
w
most of the business services on the same machine.
2. Client/server for small shops and departments
Client Middleware Server
www.csetube.in
www.csetube.in
A classic Ethernet client/single-server building block implementation. It is used in small

shops, departments, and branch offices.
3. Client/server for intergalactic enterprises
Client
Ser
ver
Middleware 1
Server 2
.in
Heterogeneous Server
be
It is a multi server building-block implementation of client/server. The servers are
heterogeneous with different types of services.
tu
4. Client/server for a post-scarcity world
se
Middleware
Middleware Client Server
Client Server
.c
Middleware
w
w
Middleware
w
Client Server Middleware

Client Server
It transforms every machine to both client and server.
REMOTE PROCEDURE CALL
What Is RPC
www.csetube.in
www.csetube.in
RPC is a powerful technique for constructing distributed, client-server based

applications. It is based on extending the notion of conventional or local procedure calling, so
that the called procedure need not exist in the same address space as the calling procedure.
The two processes may be on the same system, or they may be on different systems
with a network connecting them. By using RPC, programmers of distributed applications
avoid the details of the interface with the network.
The transport independence of RPC isolates the application from the physical and
logical elements of the data communications mechanism and allows the application to use a
variety of transports.
RPC spans the Transport layer and the Application layer in the Open Systems
Interconnection (OSI) model of network communication. RPC makes it easier to develop an
application that includes multiple programs distributed in a network.
.in
be
How RPC Works?
An RPC is analogous to a function call. Like a function call, when an RPC is made,
the calling arguments are passed to the remote procedure and the caller waits for a response
tu
to be returned from the remote procedure.
Figure shows the flow of activity that takes place during an RPC call between two
se
networked systems. The client makes a procedure call that sends a request to the server and
waits. The thread is blocked from processing until either a reply is received, or it times out.
When the request arrives, the server calls a dispatch routine that performs the requested
service, and sends the reply to the client. After the RPC call is completed, the client program
.c
continues. RPC specifically supports network applications.
A remote procedure is uniquely identified by the triple: (program number, version

w
number, procedure number) the program number identifies a group of related remote
procedures, each of which has a unique procedure number.
w
A program may consist of one or more versions. Each version consists of a collection
of procedures which are available to be called remotely. Version numbers enable multiple
w
versions of an RPC protocol to be available simultaneously. Each version contains a a

number of procedures that can be called remotely. Each procedure has a procedure number.
Messaging
RPC is an easy and popular paradigm for implementing the client-server model of
distributed computing. An RPC is initiated by the client sending a request message to a
known remote server in order to execute a specified procedure using supplied parameters.
A response is returned to the client where the application continues along with its
process. There are many variations and subtleties in various implementations, resulting in a
variety of different (incompatible) RPC protocols.
www.csetube.in
www.csetube.in
The key concept to understand is the blocking of the client, or waiting time, while the
server application responds with the required information. It is a communication requiring a
specific identity or address of the server and specific knowledge of the server's application -
including known parameters necessary for invoking the procedure and of the output to be
returned.
.in
be
tu
se
.c
Fig. Remote Procedure Calling Mechanism

w
PEER TO PEER
A peer-to-peer (or P2P) computer network is a network that relies primarily on the
w
computing power and bandwidth of the participants in the network rather than concentrating
it in a relatively low number of servers. P2P networks are typically used for connecting nodes
w
via largely ad hoc connections. Such networks are useful for many purposes.
Sharing content files containing audio, video, data or anything in digital format is
very common, and real-time data, such as telephony traffic, is also passed using P2P
technology.
A pure peer-to-peer network does not have the notion of clients or servers, but only
equal peer nodes that simultaneously function as both "clients" and "servers" to the other
nodes on the network. This model of network arrangement differs from the client-server
model where communication is usually to and from a central server.
A typical example for a non peer-to-peer file transfer is an FTP server where the
client and server programs are quite distinct, and the clients initiate the download/uploads and
www.csetube.in
www.csetube.in
the servers react to and satisfy these requests. Peer-to-peer networks are generally simpler,
but they usually do not offer same performance during heavy loads.
Peer-to-peer is a communications model in which each party has the same capabilities
and either party can initiate a communication session. Other models with which it might be
contrasted include the client/server model and the master/slave model.
On the Internet, peer-to-peer (referred to as P2P) is a type of transient Internet

network that allows a group of computer users with the same networking program to connect
with each other and directly access files from one another's hard drives.
Napster and Gnutella are examples of this kind of peer-to-peer software. Major
producers of content, including record companies, have shown their concern about what they
consider illegal sharing of copyrighted content by suing some P2P users.
.in
Meanwhile, corporations are looking at the advantages of using P2P as a way for
employees to share files without the expense involved in maintaining a centralized server and
as a way for businesses to exchange information with each other directly.
be
The earliest peer-to-peer network in widespread use were the Usenet news servers,
which communicated with one another as peers, propagating Usenet news articles over the
entire Usenet network, which particularly in the earlier days of Usenet also used UUCP to
tu
extend even beyond the Internet. However, these news servers also acted as client-server
when the individual users accessed the local news server to read and post articles.
se
Some networks and channels, such as Napster, OpenNAP, or IRC use a client-server
structure for some tasks (e.g., searching) and a peer-to-peer structure for others. Networks
such as Gnutella or Freenet use a peer-to-peer structure for all purposes, and are sometimes
referred to as true peer-to-peer networks, although Gnutella is greatly facilitated by directory
.c
servers that inform peers of the network addresses of other peers.
Peer-to-peer Architecture
w
Peer-to-peer architecture is a type of network in which each workstation has

w
equivalent capabilities and responsibilities. This differs from client/server architectures where
some computers are dedicated to serving the others.
w
Peer-to-peer networks are generally simpler but they usually do not offer the same
performance under heavy loads. The P2P network itself relies on computing power at the
ends of a connection rather than from within the network itself. The concept of peer to peer is
increasingly evolving to an expanded usage as the relational dynamic active in distributed
networks, i.e. not just computer to computer, but human to human.
P2P is often mistakenly used as as a term to describe one user linking with another
user to transfer information and files through the use of a common P2P client to download
MP3s, videos, images, games and other software. This, however, is only one type of P2P
networking. Generally, P2P networks are used for sharing files, but a P2P network can also
mean Grid Computing or Instant messaging.
Users can choose how many member connections to seek at one time and determine
www.csetube.in
www.csetube.in
which files they wish to share or password protect.
Types of P2P Networks
Peer-to-peer networks come in three flavors. The category classification is based on

the network and application.
(I)Collaborative Computing
Also referred to as distributed computing, it combines the idle or unused CPU

processing power and/or free disk space of many computers in the network.
Collaborative computing is most popular with science and biotech organizations where
intense computer processing is required.
Examples of distributed computing can be found at GRID.ORG where United
.in
Devices is hosting virtual screening for cancer research on the Grid MP platform. This
project has evolved into the largest computational chemistry project in history. United
Devices has harnessed the power of more than 2,000,000 PCs around the world to
be
generate more than 100 teraflops of power. Most distributed computing networks are
created by users volunteering their unused computing resources to contribute to public
interest research projects.
tu
(II)Instant Messaging
One very common form of P2P networking is Instant Messaging (IM) where
se
software applications, such as MSN Messenger or AOL Instant Messenger, for

example, allow users to chat via text messages in real-time. While most vendors offer a
free version of their IM software others have begun to focus on enterprise versions of
IM software as business and corporations have moved towards implementing IM as a
.c
standard communications tool for business.
(III)Affinity Communities
w
Affinity communities is the group of P2P networks that is based around file-
w
sharing and became widely known and talked about due to the public legal issues
surrounding the direct file sharing group, Napster. Affinity Communities are based on
users collaborating and searching other user's computers for information and files.
w
Operation of peer-to-peer networks

One possible classification of peer-to-peer networks is according to their degree of
centralisation:
Pure peer-to-peer:
 Peers act as equals, merging the roles of clients and server

 There is no central server managing the network
 There is no central router
Hybrid peer-to-peer:
www.csetube.in
www.csetube.in
 Has a central server that keeps information on peers and responds to requests for that
information.
 Peers are responsible for hosting available resources (as the central server does not
have them), for letting the central server know what resources they want to share, and
for making its shareable resources available to peers that request it.
 Route terminals are used addresses, which are referenced by a set of indices to obtain
an absolute address.
Some examples of "pure" peer-to-peer application layer networks designed for file sharing
are Gnutella and Freenet.
Unstructured and structured P2P networks

The P2P overlay network consists of all the participating peers as network nodes.
There are links between any two nodes that know each other: i.e. if a participating peer
.in
knows the location of another peer in the P2P network, then there is a directed edge from the
former node to the latter in the overlay network. Based on how the nodes in the overlay
network are linked to each other, we can classify the P2P networks as unstructured or
structured.
be
An unstructured P2P network is formed when the overlay links are established
arbitrarily. Such networks can be easily constructed as a new peer that wants to join the
network can copy existing links of another node and then form its own links over time.
tu
In an unstructured P2P network, if a peer wants to find a desired piece of data in the
network, the query has to be flooded through the network in order to find as many peers as
se
possible that share the data. The main disadvantage with such networks is that the queries
may not always be resolved. Flooding also causes a high amount of signalling traffic in the
network and hence such networks typically have a very poor search efficiency. Most of the
popular P2P networks such as Napster, Gnutella and KaZaA are unstructured.
.c
Structured P2P networks overcome the limitations of unstructured networks by

maintaining a Distributed Hash Table (DHT) and by allowing each peer to be responsible for
w
a specific part of the content in the network. These networks use hash functions and assign
values to every content and every peer in the network and then follow a global protocol in
w
determining which peer is responsible for which content. This way, whenever a peer wants to
search for some data, it uses the global protocol to determine the peer(s) responsible for the
data and then directs the search towards the responsible peer(s).
w
Some well known structured P2P networks are:
 Chord
 Pastry
 Tapestry
 CAN.
 Tulip
How Peer-to-peer File-sharing Clients Work
Once you have downloaded and installed a P2P client, if you are connected to the
www.csetube.in
www.csetube.in
Internet you can launch the utility and you are then logged into a central indexing server. This
central server indexes all users who are currently online connected to the server. This server
does not host any files for downloading.
The P2P client will contain an area where you can search for a specific file. The
utility queries the index server to find other connected users with the file you are looking for.
When a match is found the central server will tell you where to find the requested file. You
can then choose a result from the search query and your utility when then attempt to establish
a connection with the computer hosting the file you have requested. If a successful
connection is made, you will begin downloading the file. Once the file download is complete
the connection will be broken.
A second model of P2P clients works in the same way but without a central indexing
server. In this scenario the P2P software simply seeks out other Internet users using the same
program and informs them of your presence online, building a large network of computers as
.in
more users install and use the software.
P2P Security Concerns
be
One major concern of using P2P architecture in the workplace is, of course, network
security. Security concerns stem from the architecture itself. Today we find most blocking
and routing handles by a specific server within network, but the P2P architecture has no
tu
single fixed server responsible for routing and requests. The first step in securing your P2P
network is to adopt a strict usage policy within the workplace. In securing your network
against attacks and viruses there are two main strategies where focus is on controlling the
se
network access or the focus is put on controlling the files. A protocol-based approach is
where system administrators use a software or hardware solution to watch for and block
intrusive network traffic being received through the P2P clients. A second method of
protection is a software solution which would provide file surveillance to actively search for
.c
files based on their type, their name, their signature or even their content.
P2P at Work
w
P2P is not only popular with home users but many small business have come to rely
w
on this cost-effective solution for sharing files with co-workers and clients. P2P promotes the
ease of working together when you're not physically located in the same office. In just
seconds updated files and data can be shared with peers and confidential files can be blocked
w
for security.
Additionally, companies can also block access to Internet music and video files to
assist in maintaining a work-oriented P2P network. Not only does this keep the company free
and clear from legal issues regarding music downloading and sharing but it also keeps the
corporate bandwidth usage down.
Advantages of peer-to-peer networks

An important goal in peer-to-peer networks is that all clients provide resources,
including bandwidth, storage space, and computing power. Thus, as nodes arrive and demand
on the system increases, the total capacity of the system also increases. This is not true of a
client-server architecture with a fixed set of servers, in which adding more clients could mean
slower data transfer for all users.
www.csetube.in
www.csetube.in
The distributed nature of peer-to-peer networks also increases robustness in case of

failures by replicating data over multiple peers, and -- in pure P2P systems -- by enabling
peers to find the data without relying on a centralized index server. In the latter case, there is
no single point of failure in the system.
.in
be
tu
se
.c
w
w
w
www.csetube.in
www.csetube.in
UNIT II
EJB ARCHITECTURE
EJB
Enterprise JavaBeans (EJB) are reusable Java components that implement business
logic and enable you to develop component-based distributed business applications.
EJBs reside in an EJB container, which provides a standard set of services such as
Persistence,
Security,
Transactions, and
Concurrency.
.in
Enterprise JavaBeans are the standard for defining server-side components. WebLogic
Server's implementation of the Enterprise JavaBeans component architecture is based on Sun
be
Microsystems EJB specification.
The EJB specification defines the following four types of Enterprise JavaBeans:
tu
 Stateless session. These non-persistent EJBs provide a service without storing an
interaction or conversation state between methods.
se
 Stateful session. These non-persistent EJBs maintain state across methods and
transactions. Each instance is associated with a particular client.
.c
w
 Entity. These persistent EJBs represent an object view of the data, usually rows in a
database. An entity bean has a primary key as a unique identifier.
w
 Message-driven. These EJBs are integrated with the Java Message Service (JMS) to
w
enable message-driven beans to act as a standard JMS message consumer and perform
asynchronous processing between the server and the JMS message producer. The
WebLogic Server container directly interacts with a message-driven bean by creating
bean instances and passing JMS messages to those instances as necessary.
From the EJB sub-node, of the Deployments node of the Administration Console, you
can update or configure EJBs deployed on WebLogic Server or monitor the their
performance.
1
www.csetube.in
www.csetube.in
Configuring EJBs
To configure an EJB for deployment to the WebLogic Server Administration Console:
Start the WebLogic Server Administration Console.
Select the Domain in which you will be working.
In the left pane of the Console, click Deployments.
In the left pane of the Console, click EJB. A table is displayed in the right pane of the
Console showing all the deployed EJBs.
Select the Configure a new EJB option.
Locate the EAR, WAR or JAR file you would like to configure. You can also
.in
configure an exploded application or component directory. Note that WebLogic Server will
deploy all components it finds in and below the specified directory.
be
Click [select] to the left of a directory or file to choose it and proceed to the next step.
Select a Target Server from among Available Servers.

tu
Enter a name for the EJB or application in the provided field.
se
Click Configure and Deploy. The Console will display the Deploy panel, which lists
deployment status and deployment activities for the EJB.
Using the available tabs, enter the following information:

.c
Configuration—Edit the staging mode and enter the deployment order.

Targets—Indicate the Targets-Server for this configured EJB or application by moving the
w
server from the Available list to the Chosen list.

w
Deploy—Deploy the EJB or application to all or selected targets or undeploy it from all or
selected targets.
w
Monitoring—Enable session monitoring for the EJB or application.

Notes—Enter notes related to the EJB or application.
2
www.csetube.in
www.csetube.in
EJB Architecture
.in
be
tu
Enterprise beans provide several benefits for application developers:
They allow you to build distributed applications by combining components developed
using tools from different vendors.
se
They make it easy to write applications. You do not have to deal with low-level
details of transaction and state management, multithreading, resource pooling, and other
.c
complex low-level APIs. However, if necessary, expert programmers can still gain direct
access to the low-level APIs.
w
They can be developed once and then deployed on multiple platforms without
recompilation or source code modification.
w
The EJB specification that governs the use of enterprise beans is compatible with
other Java™ APIs and CORBA. It also provides for interoperability between enterprise beans
w
and non-Java applications.
Enterprise beans
An enterprise bean is a non-visual component of a distributed, transaction-oriented
enterprise application. Enterprise beans are typically deployed in EJB containers and run on
EJB servers. You can customize them by changing their deployment descriptors and you can
assemble them with other beans to create new applications.
3
www.csetube.in
www.csetube.in
There are three types of enterprise beans:

session beans,
entity beans, and
message-driven beans.
Session beans: Session beans are non-persistent enterprise beans. They can be stateful or
stateless. A stateful session bean acts on behalf of a single client and maintains client-specific
session information (called conversational state) across multiple method calls and
transactions. It exists for the duration of a single client/server session. A stateless session
bean, by comparison, does not maintain any conversational state. Stateless session beans are
pooled by their container to handle multiple requests from multiple clients.
.in
Entity beans: Entity beans are enterprise beans that contain persistent data and that can be
saved in various persistent data stores. Each entity bean carries its own identity. Entity beans
be
that manage their own persistence are called bean-managed persistence (BMP) entity beans.
Entity beans that delegate their persistence to their EJB container are called container-
managed persistence (CMP) entity beans.
tu
Message-driven beans: Message-driven beans are enterprise beans that receive and process
se
JMS messages. Unlike session or entity beans, message-driven beans have no interfaces.
They can be accessed only through messaging and they do not maintain any conversational
.c
state. Message-driven beans allow asynchronous communication between the queue and the
listener, and provide separation between message processing and business logic.
w
Remote client view

w
The remote client view specification became available beginning with EJB 1.1. The
remote client view of an enterprise bean is location independent. A client running in the same
w
JVM as a bean instance uses the same API to access the bean as a client running in a different
JVM on the same or different machine.
Remote interface: The remote interface specifies the remote business methods that a client
can call on an enterprise bean.
Remote home interface: The remote home interface specifies the methods used by remote
clients for locating, creating, and removing instances of enterprise bean classes.
4
www.csetube.in
www.csetube.in
Local client view

The local client view specification is available in EJB 2.0 or later. Unlike the remote
client view, the local client view of a bean is location dependent. Local client view access to
an enterprise bean requires both the local client and the enterprise bean that provides the local
client view to be in the same JVM. The local client view therefore does not provide the
location transparency provided by the remote client view. Local interfaces and local home
interfaces provide support for lightweight access from enterprise bean that are local clients.
Session and entity beans can be tightly couple with their clients, allowing access without the
overhead typically associated with remote method calls.
.in
Local interface: The local interface is a lightweight version of the remote interface, but for
local clients. It includes business logic methods that can be called by a local client.
Local home interface: The local home interface specifies the methods used by local clients
be
for locating, creating, and removing instances of enterprise bean classes.
tu
Web service client view
In the EJB 2.1 specification, the EJB architecture introduced the support for Web services. A
se
client for a session bean can be a Web service client. A Web service client can make use of
the Web service client view of a stateless session bean, which has a corresponding service
endpoint interface..
.c
Service endpoint interface

w
The service endpoint interface for a stateless session bean exposes the functionality of
the session bean as a Web service endpoint. The Web Service Description Language (WSDL)
w
document for a Web service describes the Web service as a set of endpoints operating on
w
messages. A WSDL document can include the service endpoint interface of a stateless
session bean as one of its endpoints. An existing stateless session bean can be modified to
include a Web service client view, or a service endpoint interface can be mapped from an
existing WSDL to provide the correct interface.
A Web service client view is independent of location and can be accessed through
remote calls.
5
www.csetube.in
www.csetube.in
EJB client JAR file

An EJB client JAR file is an optional JAR file that can contain the client interfaces
that a client program needs to use the client views of the enterprise beans that are contained
in the EJB JAR file. If you decide not to create an EJB client JAR file for an EJB module, all
of the client interface classes will be in the EJB JAR file. By default, the workbench creates
EJB client JAR projects for each corresponding EJB project.
EJB container
An EJB container is a runtime environment that manages one or more enterprise
beans. The EJB container manages the life cycles of enterprise bean objects, coordinates
.in
distributed transactions, and implements object security. Generally, each EJB container is
provided by an EJB server and contains a set of enterprise beans that run on the server.
Deployment descriptor
be
A deployment descriptor is an XML file packaged with the enterprise beans in an EJB
tu
JAR file or an EAR file. It contains metadata describing the contents and structure of the
enterprise beans, and runtime transaction and security information for the EJB container.
se
EJB server
An EJB server is a high-level process or application that provides a runtime
environment to support the execution of server applications that use enterprise beans. An EJB
.c
server provides a JNDI-accessible naming service, manages and coordinates the allocation of
resources to client applications, provides access to system resources, and provides a
w
transaction service. An EJB server could be provided by, for example, a database or
w
application server.
w
6
www.csetube.in
www.csetube.in
Types of EJB
Version 1.1 of the EJB Specification [EJB1.1 4.3] defined two types of EJB: the
session EJB and the entity EJB. Version 2.0 introduces a third type, the message-driven EJB
[EJB2.0 4.3]. It is possible to envisage EJB applications where the EJBs don’t fit neatly into
any of these categories, but in practice one of these types can be adapted to suit most jobs.
(i)Session EJBs
A session EJB is a nonpersistent object: Its lifetime is the duration of a particular
interaction between the client and the EJB. The client normally creates an EJB, calls methods
on it, and then removes it. If the client fails to remove it, the EJB container will remove it
after a certain period of inactivity. Session EJBs are subdivided into ‘stateful’ and ‘stateless’
.in
types. A stateless session EJB is shared amongst a number of clients, while a stateful session
EJB is created for a specific client and not used by any others. The use of stateless EJBs
be
offers efficiency advantages but, of course, it is not always possible to use them.
(ii) Entity EJBs
Entity EJBs represent persistent objects: Their lifetimes are not related to the duration
tu
of interaction with clients. In nearly all cases, entity EJBs are synchronized with relational
databases. This is how persistence is achieved. Entity EJBs are always shared amongst
se
clients: A client cannot get an entity EJB to itself. Thus, entity EJBs are nearly always used
as a scheme for mapping relational databases into object-oriented applications.
.c
Whereas a client normally creates a session EJB and removes it after use, clients
w
normally look up an existing entity EJB. Creation of an entity EJB corresponds to adding new
data items to the application (e.g., adding rows to database tables).
w
An important feature of entity EJBs is that they have identity—that is, one can be
distinguished from another. This is implemented by assigning a primary key to each instance
w
of the EJB, where ‘primary key’ has the same meaning as it does for database management.
Primary keys that identify EJBs can be of any type, including programmer-defined classes.
(iii)Message-driven EJBs
A message-driven bean acts as a consumer of asynchronous messages: It cannot be
called directly by clients, but is activated by the container when a message arrives. Clients
interact with these EJBs by sending messages to the queues or topics to which they are
listening. Although a message-driven EJB cannot be called directly by clients, it can call
7
www.csetube.in
www.csetube.in
other EJBs itself. Message-driven EJBs are the only type that do not follow a strict request-
response interaction with clients.
Why use EJBs?

It is possible to write applications that support distribution, transaction management,
and security without using EJBs. There are many such applications in use already.
So what advantages do EJBs have to offer over other techniques?
The EJB developer works within the EJB framework to take advantage of its built-in
support for features like transaction management and security; once understood, little
.in
developer effort is required to make effective use of these features. With suitable servers, EJB
applications can even make use of features as sophisticated as distributed transaction
management with no coding whatsoever.
be
EJB 2.0 introduces a very powerful persistence management scheme, which supports
tu
not only persistent data, but persistent relationships between objects. It takes a while to get
used to, but once mastered; this revolutionizes the development of persistent application
se
objects. Again, very little coding is required to implement such objects.
The EJB framework presents the EJB with a managed operating environment. For
.c
example, the framework ensures that an EJB instance is never executing in more than one
concurrent thread,3so the developer does not have to be concerned about the effects of
w
concurrency on data integrity. The container is also responsible for memory and resource
w
management, so EJB developers don't have to be concerned with these issues.

w
EJBs can make use of the full range of Java APIs and class libraries. It is relatively
straightforward to code an EJB that parses XML, sends email, and communicates with
directory and database servers via standard APIs like JDBC and JNDI.
EJBs isolate database implementation from the application's business logic. If we use
entity EJBs, for example, as models of the underlying data, then theuse of that data is
decoupled from its internal representation. This leads to increased ease of maintenance and
portability of code. We can also use EJBs as interfaces to legacy systems, with similar
advantages.
8
www.csetube.in
www.csetube.in
EJBs are very accessible to Web components such as servlets and JSPs. There are a
number of products available that support these components in the same application
framework (typically called application servers). This makes it straightforward to provide
EJB applications with a Web-based user interface and, perhaps, provide Internet access to the
application.
Overview of the EJB Building and Deploying Process

Building and deploying EJBs in the WebLogic Enterprise environment requires
.in
careful planning to define how to locate these EJBs in the WLE distributed environment.
After the Bean Provider has implemented an EJB's business logic and has produced
be
an initial deployment descriptor, the process for building and deploying that EJB in the WLE
environment includes the following steps:
Step 1: Obtain the EJB JAR file from the bean provider.
tu
Step 2: Modify the deployment descriptor.
Step 3: Create the WebLogic EJB extensions to the deployment descriptor DTD.
se
Step 4: Produce the deployable EJB JAR file.

Step 5: Configure the EJB application.
Step 6: Specify the module initializer object in the WebLogic EJB extensions to the
.c
deployment descriptor DTD.

w
When you build the EJB that has been produced by the Bean Provider, the end result is an
EJB JAR file. The WLE system allows you to build two kinds of EJB JAR files:
w
Standard EJB An EJB that has been built, but lacks the specific deployment information
JAR file on any specific system. You typically build a standard EJB with the goal of
w
being able to distribute that EJB to a variety of deployment environments. If

you are only creating a standard EJB JAR file, you only need to perform
steps 1 and 2 in this topic.
Deployable An EJB that has been built with deployment descriptor information specific
EJB JAR file to a particular deployment environment. The steps described in this chapter
for building a deployable EJB JAR file specifically create an EJB that can
be deployed on a WLE system, and require you to perform steps 1 through
4 in this topic.
The remainder of this topic discusses each of these steps in detail.
9
www.csetube.in
www.csetube.in
Steps for Building and Deploying EJBs

This section describes the steps for building and deploying EJBs in the WLE
environment and also provides the following sections:
Scaling an EJB Application
For More Information
Step 1: Obtain the EJB JAR file from the bean provider.
The first step in deploying an EJB is to obtain the EJB JAR file from the Bean
Provider. In addition to the class files contained in the EJB JAR file, the EJB JAR file also
has a deployment descriptor for each bean in that file. The steps for producing the Bean
Provider's EJB JAR file are described in the section Development Steps.
.in
Because multiple EJBs can be joined together in a single, deployable unit, part of the
assembly process is joining the EJB JAR files for each of the beans.
be
Step 2: Modify the deployment descriptor.
As stated in Designing and Developing Enterprise JavaBeans for the WLE System,
tu
the deployment descriptor ties together the different classes and interfaces, and is used to
build the code-generated class files. It also allows you to specify some aspects of the EJB's
se
deployment at run time.

The Bean Provider specifies some initial deployment information in the deployment
descriptor. The deployer typically needs to add to or modify that information, such as shown
.c
in the following table:
The EJB's name You may change the enterprise bean's name defined in the ejb-name
w
element.
Values of You may change existing values or define new values for the
w
environment environment properties.

entries
w
Description fields You may change existing or create new description elements.
Binding of You may link an enterprise bean reference to another enterprise bean
enterprise bean in the EJB JAR file. You create the link by adding the ejb-link element
references to the referencing bean.
Security roles You may define one or more security roles. The security roles define
the recommended security roles for the clients of the enterprise beans.
You define the security roles using the security-role elements. For
more information about EJB security, see Using Security in the
WebLogic Enterprise online documentation.
Method You may define method permissions, which are binary relationships
permissions between the security roles and the methods of the remote and home
10
www.csetube.in
www.csetube.in
interfaces of the EJBs. You define method permissions using the

method-permission elements.
Linking of If you define security roles in the deployment descriptor, you must
security role link the security role references declared by the Bean Provider to the
references security roles. You define these links using the role-link element. For
more information about EJB security, see Using Security in the
Changing persistent
The deployer can change the type of persistent storage used by a bean.
storage If the persistentStoreType is file , the serialized files are created in this
information, directory. The default file is / pstore/ bean_name .dat , where the
if
necessary directory pstore represents the directory from which the WLE
application was started, and bean_name is the fully qualified name of
the EJB with underscores (_ ) replacing the periods (. ) in the name.
If the persistentStoreType is jdbc , the container looks for additional
.in
values to determine the appropriate values for the JDBC connection.
Note that if the bean's persistence is stored in a database via a JDBC
connection, the system administrator needs to add this information to
be
the UBBCONFIG file as well. For more information, see Using the
JDBC Drivers in the WebLogic Enterprise online documentation.
Note that persistence information is specified in the WebLogic EJB
extensions to the deployment descriptor DTD file, as described in the
tu
section Specifying Persistence Information.
To modify a deployment descriptor, you can use either of the following two methods:
se
The WebLogic EJB Deployer

The manual modification of the deployment descriptor in a text editor .The type of
deployment descriptor you produce depends on whether you are creating a standard EJB JAR
.c
file or a deployable EJB JAR file.

w
Creating a Standard EJB JAR File

If you are creating a standard EJB JAR file, you only need to modify the single
w
deployment descriptor contained in the EJB JAR file produced by the Bean Provider. When
modifying this deployment descriptor, use the syntax described in the EJB 1.1 Specification
w
produced by Sun Microsystems, Inc.
If you are creating a standard EJB JAR file:

Make the appropriate modifications to the bean's deployment descriptor file.
Run the ejbc command, specifying the -nodeploy option.
For more information about the ejbc command, see the Command Reference in the -
-WebLogic Enterprise online documentation.
Creating a Deployable EJB JAR File

If you are creating a deployable EJB JAR file, you need to do the following:
11
www.csetube.in
www.csetube.in
Modify the deployment descriptor, as described in the section Creating a Standard EJB JAR
File.
Create a WebLogic Enterprise extended deployment descriptor file, which is also
created as an XML file, and which specifies the information described in the section Step 3:
Create the WebLogic EJB extensions to the deployment descriptor DTD..
Step 3: Create the WebLogic EJB extensions to the deployment descriptor DTD.
For an EJB application to be deployable in the WLE environment, you need to create
a file containing the WebLogic EJB extensions to the deployment descriptor DTD. This file
specifies the following run time and configuration information for the EJB application:
.in
1. Custom application startup and shutdown properties
2. Registration of the application's home interfaces
be
3. Persistence information
Specifying the WebLogic EJB Extensions DTD
The file that includes the WebLogic EJB extensions to the deployment descriptor DTD must
tu
specify the following DTD reference at the beginning:
<!DOCTYPE weblogic-ejb-extensions SYSTEM "weblogic-ejb-extensions.dtd" >
se
Specifying the Module Initializer Class
Server application startup and shutdown can be handled automatically by the EJB
.c
container. However, if you have special server initialization or shutdown requirements, use
the module-initializer-class-name element in the WebLogic EJB extensions to the
w
deployment descriptor DTD to specify the name of the module initializer object.
w
The syntax for specifying a module initializer object for handling the initialize and
w
release methods is similar to that for CORBA and RMI. However, with the CORBA and RMI
models, the startup and shutdown information is specified in an XML file and is serialized by
the buildjavaserver command. For EJB deployment, XML elements for startup and shutdown
procedures are specified together with the other elements in the WebLogic EJB extensions to
the deployment descriptor DTD, and you process them using the ejbc command. The WLE
EJB container parses the XML at run time and performs the startup and shutdown processing.
See the section Step 5: Configure the EJB application. for a complete description of startup
and shutdown handling in WLE.
12
www.csetube.in
www.csetube.in
XML DTD Syntax

<!ELEMENT module-initializer-class (module-initializer-class-name*))>
<!ELEMENT module-initializer-class-name (#PCDATA)>
Example
<weblogic-ejb-extensions>
. . .
<module-initializer-class>
<moduleinitializer-class-name>ServerImpl
</moduleinitializer-class-name>
</module-initializer-class>
</weblogic-ejb-extensions>
Registering Names for the EJB Home Classes

A name for the EJB home class must be registered in the global WLE JNDI
.in
namespace. This allows Java clients to perform a lookup on the JNDI name for the EJB home
and gain access to the object. The name for the EJB home class can be different than the
be
<ejb-name> element specified in the standard EJB XML. The <ejb-name> in the standard
deployment descriptor must be unique only among the names of the EJBs in the same EJB
JAR file. However, the JNDI name must be unique among all global home or factory names
tu
in a WLE domain; this includes EJB homes, CORBA factories, and RMI named objects.
se
XML DTD Syntax

<!ELEMENT jndi-name (#PCDATA)>
Example
.c
<weblogic-version>
WebLogic Enterprise Server 5.0
w
</weblogic-version>
<weblogic-enterprise-bean>
<ejb-name>
w
oracle
</ejb-name>
w
<weblogic-deployment-params>
<max-beans-in-free-pool>
20
</max-beans-in-free-pool>
<max-beans-in-cache>
1000
</max-beans-in-cache>
<idle-timeout-seconds>
5
</idle-timeout-seconds>

13
www.csetube.in
www.csetube.in
<jndi-name>
oracle.OracleHome
</jndi-name>
.
.
.
Specifying Persistence Information

The WLE EJB container provides container-managed persistence. The code for
implementing the persistence is generated by the ejbc command based on the deployment
descriptors. The persistence store can be a flat file or it can be a database managed with a
JDBC connection pool. For the EJB state to fully cooperate in a WLE global transaction,
.in
configure the EJB to use the JDBC-managed database store provided in WLE. Use file-based
persistence only during development and prototyping.
be
The standard deployment descriptor created by the Bean Provider normally specifies:
The fields in the EJB that are to be persistent, via the cmp-field element
tu
Information about the primary key
However, you, as the deployer, need to specify additional information for mapping an EJB to
se
its persistent store via the WebLogic EJB extensions to the deployment descriptor DTD.
File-based Persistence
.c
The following code shows the WebLogic EJB extensions to the deployment descriptor DTD
for specifying file-based persistence:
w

<!ELEMENT persistence-store-descriptor (description?,
w
(persistence-store-file |
persistence-store-jdbc)?)>

<!ELEMENT persistence-store-file (description?,
persistence-store-directory-root
?)>

<!ELEMENT persistence-store-directory-root (#PCDATA)>
14
www.csetube.in
www.csetube.in
The information supplied for the persistence-store-directory-root element is used by the EJB
container to store all instances of the EJB, with the ejb-name element converted to a directory
name.
Database-stored Persistence
The following code shows the WebLogic EJB extensions to the deployment descriptor DTD
for specifying a JDBC connection for database-stored persistence:

<!ELEMENT persistence-store-jdbc (description?, pool-name, user?, password?,
driver-url?, driver-class-name?, table-name, attribute-map,
finder-descriptor*)>

.in
<!ELEMENT pool-name (#PCDATA)>

<!ELEMENT user (#PCDATA)>
tu
pool
se
<!ELEMENT password (#PCDATA)>

pool
.c

<!ELEMENT driver-url (#PCDATA)>
w

pool
w
<!ELEMENT driver-class-name (#PCDATA)>

w

<!ELEMENT table-name (#PCDATA)>

<!ELEMENT attribute-map (description?, attribute-map-entry+)>

<!ELEMENT attribute-map-entry (bean-field-name, table-column-name)>

<!ELEMENT bean-field-name (#PCDATA)>
15
www.csetube.in
www.csetube.in
<!ELEMENT table-column-name (#PCDATA)>

<!ELEMENT finder-descriptor (description?, method?, query-grammar?)>

<!ELEMENT query-grammar (#PCDATA)>
The EJB instances are stored in a database that has been previously set up with a
JDBC connection pool, which is identified by the pool-name element. The table-name and
attribute-map elements map the EJB fields to the appropriate table columns in the database.
Finder descriptors are the WLE implementation of the EJB find methods. The finder-
descriptor elements are pairs of method signatures and expressions. You specify a method
.in
signature in the EJBHome interface, and you specify the method's expression in the
deployment descriptor via the query-grammar element. The finder methods return an
be
enumeration of EJBs. For more information about specifying finder descriptors, see the EJB
XML Reference in the WebLogic Enterprise online documentation.
tu
Example
The following WebLogic EJB extensions to the deployment descriptor DTD fragment
se
specify automatic saving using JDBC persistence of two fields of an entity bean (accountId
and salary ) to a database table (emp ) using a connection pool (pool1 ), shown in boldface
.c
type:
<weblogic-version>
w
WebLogic Enterprise Server 5.0

</weblogic-version>
w
<weblogic-enterprise-bean>
<ejb-name>
oracle
w
</ejb-name>
<weblogic-deployment-params>
<max-beans-in-free-pool>
20
</max-beans-in-free-pool>
<max-beans-in-cache>
1000
</max-beans-in-cache>
<idle-timeout-seconds>
5
</idle-timeout-seconds>

16
www.csetube.in
www.csetube.in
<jndi-name>
oracle.OracleHome
</jndi-name>


<persistence-store-descriptor>
<persistence-store-jdbc>

<pool-name>
jdbc/pool1
</pool-name>


<user>
.in
scott
</user>
be

<password>
tiger
</password>
tu

se
<driver-url>
jdbc:weblogic:oracle:Beq-Local
</driver-url>
<table-name>
.c
emp
</table-name>
w


<attribute-map>
<attribute-map-entry>
w
<bean-field-name>
accountId
w
</bean-field-name>
<table-column-name>
empno
</table-column-name>
</attribute-map-entry>
<attribute-map-entry>
<bean-field-name>
salary
</bean-field-name>
<table-column-name>
sal
</table-column-name>
</attribute-map-entry>
17
www.csetube.in
www.csetube.in
</attribute-map>


<finder-descriptor>
<method>
<ejb-name>
oracle
</ejb-name>
<method-name>
findAccount(double salaryEqual)
</method-name>
</method>
<query-grammar>
(= salary $salaryEqual)
</query-grammar>
.in
</finder-descriptor>
</persistence-store-jdbc>
</persistence-store-descriptor>
be
</weblogic-deployment-params>
</weblogic-enterprise-bean>
For more information about JDBC connections, see Using the JDBC Drivers in the
tu
Step 4: Produce the deployable EJB JAR file.

se
In this step, you package the deployment descriptor, the compiled files for the EJB
classes, the WLE extensions to the deployment descriptor DTD, and any additional required
classes into a deployable EJB JAR file. You can do this using the ejbc command, as in the
.c
following example:
java com.beasys.ejb.utils.ejbc -validate -i DDfile -x WLEXfile archive-file
w
The ejbc command performs the following steps:

Parses the standard EJB deployment descriptor and WebLogic Enterprise extended
w
deployment descriptor XML files, which are represented, respectively, as DDfile and
w
WLEXfile in the preceding command.

Checks the deployment descriptors for semantic consistency, and writes any
inconsistencies to standard output.
Generates the wrapper Java classes and compiles them. This is performed for each
EJB in the deployment descriptor.
Packages the XML deployment descriptors and the generated class files into a
deployable EJB JAR file. The command-line argument archive-files specifies the files that
are archived into the EJB JAR file.
18
www.csetube.in
www.csetube.in
If you have multiple bean packages meant to be assembled as a deployable unit, the
bean packages must be specified in a single deployment descriptor. For more information
about the ejbc command, see the Command Reference in the WebLogic Enterprise online
documentation.
Step 5: Configure the EJB application.

In the SERVERS section of the UBBCONFIG file, the administrator uses the
MODULES keyword to identify the deployed EJB JAR files. Optionally, a related set of
startup arguments can be specified for each EJB JAR file. For information about configuring
the EJB container, configuring the WLE EJB server process, and specifying values in the
UBBCONFIG file, see Creating a Configuration File in the WebLogic Enterprise online
.in
documentation.
be
Step 6: Specify the module initializer object in the WebLogic EJB extensions to the
deployment descriptor DTD.
Server application startup and shutdown can be handled automatically by the EJB
container. However, if you have special server initialization or shutdown requirements, you
tu
need to implement an application entity called the module initializer object.
The module initializer object implements operations that execute the following tasks:
se
Performing basic module initialization (or EJB JAR file deployment) operations, which may
include allocating resources needed by the EJB JAR file.
.c
Performing basic server application initialization operations, which may include

registering homes or factories managed by the server application and allocating resources
w
needed by the server application.

Performing server process shutdown and cleanup procedures when the server
w
application has finished servicing requests.

Note: For EJBs, the scope of the module initializer object is at the EJB JAR file level and not
w
of the entire server application, as with the Server object and WLE CORBA applications.
19
www.csetube.in
www.csetube.in
EJB Roles
An interesting feature of the EJB Specification is that its requirements are largely
divided into different 'roles.' When reading the Specification, it is therefore quite clear to
whom the various requirements correspond.
Component provider
The component provider [EJB2.0 25.1] is a software developer who authors EJBs.
These EJBs may be destined for a particular application, or they may be general-purpose or
part of a software library. The EJB author may not know the names of the EJBs with which it
is to interact although, of course, their method specifications must be known. Similarly, the
EJB author may not know the names of external resources like databases.
The Specification indicates how the component provider uses the XML deployment
.in
descriptor to indicate that these EJBs and resources are required, and the names by which it
has referenced them.
be
tu
se
.c
w
w
Application assembler
w
The application assembler [EJB2.0 25.2] is someone who builds an application out of
component EJBs. The same person or people may be operating in this role as are fulfilling the
component provider role, but the Specification is quite clear that the two are distinct jobs.
The application assembler resolves references between EJBs, unifies the references to
external resources, and packages the components into a single file ready for deployment.
It is slightly confusing for the newcomer to EJB development that most of the
graphical tools used for building EJB applications don't distinguish between what they are
doing in the provider role versus in the assembler role. It often appears that the developer is
20
www.csetube.in
www.csetube.in
supplying redundant information or information that is duplicated; this is because the

deployment descriptor being built does support the notion of a separate provider and
assembler, even if they are in practice the same person.
Deployer
The deployer [EJB2.0 25.3] takes a file from the application assembler that contains
the EJBs and other components required for the application and installs it on the server,
making appropriate customizations for the site.
These customizations include replacing database references with real database
information, mapping the security roles in the application onto real users and groups in the
organization, and supplying values for other configuration parameters.
.in
Server vendor
The server vendor supplies EJB server products. An EJB developer should not assume
be
that the sections in the EJB Specification that deal with the responsibilities of the server
vendor are not of interest. On the contrary: The server sets the operating environment of the
tu
EJB, and this section of the EJB Specification gives the developer an insight into what
environment the EJB can expect.
se
Administrator
An administrator [EJB2.0 25.4] is a person responsible for the maintenance and performance
.c
tuning of an application.
Tool provider
w
A tool provider authors EJB packaging and deployment tools.

w
w
21
www.csetube.in
www.csetube.in
UNIT-4
CORBA
The Common Object Request Broker Architecture (CORBA) is an emerging open distributed
object computing infrastructure being standardized by the Object Management Group
(OMG). CORBA automates many common network programming tasks such as object
registration, location, and activation; request demultiplexing; framing and error-handling;
parameter marshalling and demarshalling; and operation dispatching.
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 .
.in
be
tu
se
.c
Figure 1. OMG Reference Model Architecture

w
 Object Services -- These are domain-independent interfaces that are used by many
w
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:
w
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 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.
1
www.csetube.in
www.csetube.in
 Domain Interfaces -- These interfaces fill roles similar to Object Services and
Common Facilities but are oriented towards specific application domains. For
example, one of the first OMG RFPs issued for Domain Interfaces is for Product Data
Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will
soon be issued in the telecommunications, medical, and financial domains.
 Application Interfaces - These are interfaces developed specifically for a given
application. Because they are application-specific, and because the OMG does not
develop applications (only specifications), these interfaces are not standardized.
However, if over time it appears that certain broadly useful services emerge out of a
particular application domain, they might become candidates for future OMG
standardization.
CORBA ORB Architecture
.in
The following figure illustrates the primary components in the CORBA ORB architecture.
Descriptions of these components are available below the figure.
be
tu
se
.c
w
w
w
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.
2
www.csetube.in
www.csetube.in
 Client -- This is the program entity that invokes an operation on an object

implementation. Accessing the services of a remote object should be transparent to
the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj-
>op(args). The remaining components in Figure 2 help to support this level of
transparency.
 Object Request Broker (ORB) -- The ORB provides a mechanism for transparently
communicating client requests to target object implementations. The ORB simplifies
distributed programming by decoupling the client from the details of the method
invocations. This makes client requests appear to be local procedure calls. When a
client invokes an operation, the ORB is responsible for finding the object
implementation, transparently activating it if necessary, delivering the request to the
object, and returning any response to the caller.
 ORB Interface -- An ORB is a logical entity that may be implemented in various
ways (such as one or more processes or a set of libraries). To decouple applications
from implementation details, the CORBA specification defines an abstract interface
.in
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
be

``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
tu
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
se
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
.c
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
w
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.
w
 Object Adapter -- This assists the ORB with delivering requests to the object and
with activating the object. More importantly, an object adapter associates object
w
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).
3
www.csetube.in
www.csetube.in
Distributed Systems
Organizing the interaction between each computer is of prime importance. In order to be able
to use the widest possible range and types of computers, the protocol or communication
channel should not contain or use any information that may not be understood by certain
machines. Special care must also be taken that messages are indeed delivered correctly and
that invalid messages are rejected which would otherwise bring down the system and perhaps
the rest of the network.
Another important factor is the ability to send software to another computer in a portable way
so that it may execute and interact with the existing network. This may not always be
possible or practical when using differing hardware and resources, in which case other
methods must be used such as cross-compiling or manually porting this software.
Goals and advantages
.in
There are many different types of distributed computing systems and many challenges to
overcome in successfully designing one. The main goal of a distributed computing system is
be
to connect users and resources in a transparent, open, and scalable way. Ideally this
arrangement is drastically more fault tolerant and more powerful than many combinations of
stand-alone computer systems.
tu
Openness
Openness is the property of distributed systems such that each subsystem is continually open
se
to interaction with other systems (see references). Web Services protocols are standards
which enable distributed systems to be extended and scaled. In general, an open system that
scales has an advantage over a perfectly closed and self-contained system.
.c
Consequently, open distributed systems are required to meet the following challenges:
Monotonicity
w
Once something is published in an open system, it cannot be taken back.

Pluralism
Different subsystems of an open distributed system include heterogeneous,
w
overlapping and possibly conflicting information. There is no central arbiter of truth

in open distributed systems.
w
Unbounded no determinism
Asynchronously, different subsystems can come up and go down and communication
links can come in and go out between subsystems of an open distributed system.
Therefore the time that it will take to complete an operation cannot be bounded in
advance (see unbounded nondeterminism).
Scalability
A scalable system is one that can easily be altered to accommodate changes in the
number of users, resources and computing entities affected to it. Scalability can be measured
in three different dimensions:
Load scalability
A distributed system should make it easy for us to expand and contract its resource
pool to accommodate heavier or lighter loads.
4
www.csetube.in
www.csetube.in
Geographic scalability
A geographically scalable system is one that maintains its usefulness and usability,
regardless of how far apart its users or resources are.
Administrative scalability
No matter how many different organizations need to share a single distributed system,
it should still be easy to use and manage.
Some loss of performance may occur in a system that allows itself to scale in one or more of
these dimensions. There is a limit up to which we can scale/add processors to the system, and
above that the performance of the system degrades.
Drawbacks and disadvantages
If not planned properly, a distributed system can decrease the overall reliability of
computations if the unavailability of a node can cause a disruption of the other nodes. Leslie
.in
Lamport describes this type of distributed system fragility like this: "You know you have one
when the crash of a computer you've never heard of stops you from getting any work done
be
Troubleshooting and diagnosing problems in a distributed system can also become more
difficult, because the analysis may now require connecting to remote nodes or inspecting
communications being sent between nodes.
tu
Not many types of computation are well-suited for distributed environments, due typically to
the amount of network communication or synchronization that would be required between
nodes. If bandwidth, latency, or communication requirements are too significant, then the
se
benefits of distributed computing may be negated and the performance may be worse than a
non-distributed environment.
Architecture
.c
Various hardware and software architectures are used for distributed computing. At a lower
level, it is necessary to interconnect multiple CPUs with some sort of network, regardless of
w
whether that network is printed onto a circuit board or made up of loosely-coupled devices
and cables. At a higher level, it is necessary to interconnect processes running on those CPUs
with some sort of communication system.
w
Distributed programming typically falls into one of several basic architectures or categories:
w
Client-server, 3-tier architecture, N-tier architecture, Distributed objects, loose coupling, or

tight coupling.
 Client-server — Smart client code contacts the server for data, then formats and
displays it to the user. Input at the client is committed back to the server when it
represents a permanent change.
 3-tier architecture — Three tier systems move the client intelligence to a middle tier
so that stateless clients can be used. This simplifies application deployment. Most web
applications are 3-Tier.
 N-tier architecture — N-Tier refers typically to web applications which further
forward their requests to other enterprise services. This type of application is the one
most responsible for the success of application servers.
5
www.csetube.in
www.csetube.in
 Tightly coupled (clustered) — refers typically to a set of highly integrated machines

that run the same process in parallel, subdividing the task in parts that are made
individually by each one, and then put back together to make the final result.
 Peer-to-peer — an architecture where there is no special machine or machines that
provide a service or manage the network resources. Instead all responsibilities are
uniformly divided among all machines, known as peers.
Concurrency
Distributed computing implements a kind of concurrency. It interrelates tightly with

concurrent programming so much that they are sometimes not taught as distinct subjects
Multiprocessor systems
A multiprocessor system is simply a computer that has more than one CPU on its
.in
motherboard. If the operating system is built to take advantage of this, it can run different
processes (or different threads belonging to the same process) on different CPUs.
be
Over the years, many different multiprocessing options have been explored for use in
distributed computing. Intel CPUs from the late Pentium 4 era (Northwood and Prescott
cores) employed a technology called Hyper threading that allowed more than one thread
(usually two) to run on the same CPU. The most recent Sun UltraSPARC T1, AMD Athlon
tu
64 X2, AMD Athlon FX, Intel Pentium D and Intel Core 2 processors feature multiple
processor cores to also increase the number of concurrent threads they can run.
se
Multicomputer systems
A multicomputer system is a system made up of several independent computers

interconnected by a telecommunications network.
.c
Multicomputer systems can be homogeneous or heterogeneous: A homogeneous distributed

system is one where all CPUs are similar and are connected by a single type of network. They
w
are often used for parallel computing.
A heterogeneous distributed system is made up of different kinds of computers, possibly with

w
vastly differing memory sizes, processing power and even basic underlying architecture.
They are in widespread use today, with many companies adopting this architecture due to the
w
speed with which hardware goes obsolete and the cost of upgrading a whole system
simultaneously.
Computing taxonomies
The types of distributed computers are based on Flynn's taxonomy of systems; single
instruction, single data (SISD), single instruction, multiple data (SIMD), and multiple
instruction, multiple data (MIMD). Other taxonomies and architectures available at Computer
architecture and in Category: Computer architecture.
6
www.csetube.in
www.csetube.in
Computer clusters
A cluster consists of multiple stand-alone machines acting in parallel across a local high
speed network. Distributed computing differs from cluster computing in that computers in a
distributed computing environment are typically not exclusively running "group" tasks,
whereas clustered computers are usually much more tightly coupled. Distributed computing
also often consists of machines which are widely separated geographically.
Grid computing
A grid uses the resources of many separate computers connected by a network (usually the
Internet) to solve large-scale computation problems. Most use idle time on many thousands of
computers throughout the world. Such arrangements permit handling of data that would
otherwise require the power of expensive supercomputers or would have been impossible to
analyze.
.in
Languages
be
Nearly any programming language that has access to the full hardware of the system could
handle distributed programming given enough time and code. Remote procedure calls
distribute operating system commands over a network connection. Systems like CORBA,
Microsoft D/COM, Java RMI and others, try to map object oriented design to the network.
tu
Loosely coupled systems that communicate through intermediate documents that are typically
human readable are XML, HTML, SGML, X.500, and EDI.
se
Languages specifically tailored for distributed programming are:
 Ada programming language [2]

 Alef programming language
.c
 E programming language
 Erlang programming language
 Limbo programming language
w
 Oz programming language
Common Object Request Broker Architecture

w
CORBA defines a model that specifies interoperability between distributed objects on a

network in a way that is transparent to the programmer It achieves this by defining ways for
w
specifying the externally visible characteristics of a distributed object in a way that is

implementation-independent.
This model is based on clients requesting the services from distributed objects or servers
through a well-defined interface, by issuing requests to the objects in the form of events. An
event carries information about an operation that needs to be performed including the object
name (called an object reference) of the service provider and the actual parameters if any.
CORBA automatically handles a lot of network programming tasks such as object

registration, object location, object activation, request demultiplexing, frame and error-
handling, marshalling and operation dispatching.
7
www.csetube.in
www.csetube.in
CORBA objects are accessed through the use of an interface. OMG's Interface Definition
Language (IDL for short) is used to define interfaces, their attributes, methods and
parameters to those methods within the interface.
The central component of CORBA is the Object Request Broker (ORB for short). This
component provides all the communication infrastructure needed to identify and locate
objects, handle connection management and deliver data and request communication. One
CORBA object never talks directly with another. Instead, the object requests for an interface
to the ORB running on the local machine. The local ORB then passes the request to an ORB
on the other machine. The remote ORB then locates the appropriate object and passes back an
object reference to the requester.
The functions of the ORB are as follows:
.in
Lookup and instantiate objects on remote machines
Marshal parameters from one application object to the other
Handle security issues across machine boundaries
Retrieve and publish data on objects on local machine for another ORB to use
be
Invoke methods on a remote object using static method invocation
Invoke methods on a remote object using dynamic method invocation
Automatically instantiate objects that are'nt currently running
tu
Route callback methods to the appropriate local object being managed
Communicate with other ORBs using Internet Inter-ORB Protocol ( IIOP )
se
CORBA and networking model
CORBA is a specification for creating distributed object-based applications. The CORBA

.c
architecture and specification were developed by the Object Management Group (OMG).
The OMG is a consortium of several hundred information systems vendors. The goal of
w
CORBA is to promote an object-oriented approach to building and integrating distributed

software applications.
w
The CORBA specification provides a broad and consistent model for building distributed
applications by defining:
w
 An object model for building distributed applications.

 A common set of application programming objects to be used by the client and server
applications.
 A syntax for describing the interfaces of objects used in the development of
distributed applications.
 Support for use by applications written in multiple programming languages.
The CORBA specification describes how to develop an implementation of CORBA. It

also describes programming language bindings that developers use to develop
applications.
To illustrate the advantages of using the CORBA architecture, this section compares early
client/server application development techniques to CORBA development techniques.
8
www.csetube.in
www.csetube.in
Pre-CORBA Approach to Client/Server Development

Client/server computing is an application development methodology that allows
programmers to distribute processing among networked machine systems, thus enabling
more efficient use of machine resources. In client/server computing, an application
consists of two parts: the client application and the server application. These two
applications typically run on different machines, connected by a network, as shown in the
following figure.
.in
The client application makes requests for information or services and typically provides
users with a means to display results. The server application fulfills the requests of one or
be
more client applications and usually performs compute-intensive functions.
The key advantages of the client/server model are:
tu
 Computing functions run on the most appropriate machine system.
 Developers can balance the load of application processing among several servers.
 Server applications can be shared among numerous client applications.
se
For example, desktop systems provide many business users with an easy-to-use graphical
environment for displaying information. However, desktop systems may have restricted
disk space and memory and are typically single-user systems. Larger, more powerful
.c
machine systems are better suited to perform compute-intensive functions and provide
multiple user access and shared database access.
w
Therefore, larger systems usually run the server portion of the application. In this way,
distributed desktop systems and networked servers provide a perfect computing
environment for deploying distributed client/server applications.
w
Although the non-CORBA client/server approach provides the means to distribute

processing in a heterogeneous network, it has the following disadvantages:
w
 For communications, the client application must know how to access the server
application, including any necessary network protocol information.
Client/server applications might use the same, single network protocol or different
protocols. If they use multiple protocols, the applications must logically repeat the
protocol-specific code for each network.
 Applications must handle data format conversions when they are integrated with
machines that use different data formats.
For example, some machines read an integer value from the lowest byte address to the
highest (little endian), while others read the highest byte address to the lowest (big
9
www.csetube.in
www.csetube.in
endian). Some machine systems might also use different formats for floating-point
numbers or text strings. If an application sends data to a machine that uses a different
data format, but the application does not convert the data, the data is misinterpreted.
Transporting data over the network and converting it to its proper representation on
the target system is called data marshaling. In many non-CORBA client/server
models, applications must perform all data marshaling. Data marshaling requires that
the application use features of the network and operating system to move data from
one machine to another. It also requires that the application perform all data format
translations to ensure that the data is read in the same way it was sent.
 There is less flexibility for extension of the application.
The non-CORBA client/server approach ties the client and server applications
together. Therefore, if either the client or server application changes, the programmer
.in
must change the interface, network address, and network transport. Additionally, if
the programmer ports the client and server applications to a machine that supports a
different network interface, the programmer must create a new network interface for
those applications.
CORBA Approach to Client/Server Development

be
tu
The CORBA model provides a more flexible approach to developing distributed
applications. The CORBA model:
se
 Formally separates the client and server portions of the application
A CORBA client application knows only how to ask for something to be done, and a
CORBA server application knows only how to accomplish a task that a client
.c
application has requested it to do. Because of this separation, developers can change
the way a server accomplishes a task without affecting how the client application asks
w
for the server application to accomplish the task.
 Logically separates an application into objects that can perform certain tasks, called
w
operations
CORBA is based on the distributed object computing model, which combines the
w
concepts of distributed computing (client and server) and object-oriented computing

(based on objects and operations).
In object-oriented computing, objects are the entities that make up the application, and
operations are the tasks that a server can perform on those objects. For example, a
banking application could have objects for customer accounts, and operations for
depositing, withdrawing, and viewing the balance in the accounts.
 Provides data marshaling to send and receive data with remote or local machine
applications
For example, the CORBA model automatically formats for big or little endian as
needed. (Refer to the preceding section for a description of data marshaling.)
10
www.csetube.in
www.csetube.in
 Hides network protocol interfaces from the applications
The CORBA model handles all network interfaces. The applications see only objects.
The applications can run on different machines and, because all the network interface
code is handled by the ORB, the application does not require any network-related
changes if it is later deployed on a machine that supports a different network protocol.
The CORBA model allows client applications to make requests to server applications, and
to receive responses from them without direct knowledge of the information source or its
location. In a CORBA environment, applications do not need to include network and
operating system information to communicate; instead, client and server applications
communicate with the Object Request Broker (ORB). The following figure shows the
ORB in a client/server environment.
.in
be
tu
se
CORBA defines the ORB as an intermediary between client and server applications. The
.c
ORB delivers client requests to the appropriate server applications and returns the server
responses to the requesting client application. Using an ORB, a client application can
request a service without knowing the location of the server application or how the server
w
application will fulfill the request.

In the CORBA model, client applications need to know only what requests they can make
w
and how to make the requests; they do not need to be coded with any implementation
details of the server or of the data formats. Server applications need only know how to
w
fulfill the requests, not how to return data to the client application.
This means that programmers can change the way a server application accomplishes a task
without affecting how the client application asks for the server application to accomplish
that task. For example, as long as the interfaces between the client and the server
applications do not change, programmers can evolve and create new implementations of a
server application without changing the client application; in addition, they can create new
client applications without changing the server applications.
CORBA object model
With the availability of high bandwidth wide area networks, it is nowadays feasible to couple
several computing resources --- supercomputers or PC clusters --- together to obtain a high
performance distributed system. The question is to determine a suitable programming model
11
www.csetube.in
www.csetube.in
that provides transparency, interoperability, reliability, scalability and performance. Since

such distributed systems appear as a combination of distributed and parallel systems, it is
very tempting to extend programming models that were associated to distributed or to parallel
systems. Another choice is to combine the two different worlds into a single coherent one. A
parallelism oriented model appears more adequate to program parallel codes while a
distributed oriented model is more suitable to handle inter-code communications. We have
designed the concept of parallel CORBA object to address this issue. It extends the CORBA
specification with the notion of parallel object. A parallel CORBA object is a collection of
CORBA object with a Single Program Multiple Data (SPMD) execution model. This paper
deals with PACO++ , a portable implementation of the concept of parallel CORBA object. It
examines how the different design issues have been tackled with. For example, scalability is
achieved between two parallel CORBA objects by involving all members of both collections
in the communication. Early experiments with a 1 Gbit/s WAN show scalable performance:
an aggregated bandwidth of 874 Mbit/s has been obtained between two parallel CORBA
objects made of twelve nodes each. Such a performance has been obtained while preserving
.in
the semantics of CORBA. For example, parallel CORBA objects are interoperable with
standard CORBA objects via a proxy mechanism. Only the implementer of a parallel
CORBA object and parallel-aware clients have to deal with parallel issues. PACO++ is
be
currently used as the high performance object platform for several multiphysics applications
like hydrology and aircraft simulations.
CORBA IDL
tu
The CORBA Interface Definition Language (IDL) is used to define interfaces to objects in
your network. This chapter introduces the features of CORBA IDL and illustrates the syntax
se
used to describe interfaces.
The first step in developing a CORBA application is to define the interfaces to the objects
required in your distributed system. To define these interfaces, you use CORBA IDL.
.c
IDL allows you to define interfaces to objects without specifying the implementation of those
interfaces. To implement an IDL interface, you define a C++ class that can be accessed
w
through that interface and then you create objects of that class within an Orbix server
application.
w
In fact, you can implement IDL interfaces using any programming language for which an
IDL mapping is available. An IDL mapping specifies how an interface defined in IDL
w
corresponds to an implementation defined in a programming language. CORBA applications

written in different programming languages are fully interoperable.
CORBA defines standard mappings from IDL to several programming languages, including
C++, Java, and Smalltalk. The Orbix IDL compiler converts IDL definitions to corresponding
C++ definitions, in accordance with the standard IDL to C++ mapping.
IDL Modules and Scoping
An IDL module defines a naming scope for a set of IDL definitions. Modules allow you to
group interface and other IDL type definitions in logical name spaces. When writing IDL
definitions, always use modules to avoid possible name clashes.
12
www.csetube.in
www.csetube.in
The following example illustrates the use of modules in IDL:
// IDL
module BankSimple {
interface Bank {
...
};
interface Account {
...
};
};
The interfaces Bank and Account are scoped within the module BankSimple. IDL definitions
.in
are available directly within the scope in which you define them. In other naming scopes, you
must use the scoping operator (::) to access these definitions. For example, the fully scoped
name of interfaces Bank and Account are BankSimple::Bank and BankSimple::Account
be
respectively.
IDL modules can be reopened. For example, a module declaration can appear several times in
a single IDL specification if each declaration contains different data types. In most IDL
tu
specifications, this feature of modules is not required.
Defining IDL Interfaces

se
An IDL interface describes the functions that an object supports in a distributed application.
Interface definitions provide all of the information that clients need to access the object
across a network.
.c
Consider the example of an interface that describes objects which implement bank accounts
in a distributed application. The IDL interface definition is as follows:
w
//IDL
module BankSimple {
w
// Define a named type to represent money.

w
typedef float CashAmount;

// Forward declaration of interface Account.
interface Account;
interface Bank {
...
};
interface Account {
// The account owner and balance.
readonly attribute string name;
readonly attribute CashAmount balance;
13
www.csetube.in
www.csetube.in
// Operations available on the account.

void deposit (in CashAmount amount);
void withdraw (in CashAmount amount);
};
};
The definition of interface Account includes both attributes and operations. These are the
main elements of any IDL interface definition.
Attributes in IDL Interface Definitions
Conceptually, attributes correspond to variables that an object implements. Attributes indicate

that these variables are available in an object and that clients can read or write their values.
In general, attributes map to a pair of functions in the programming language used to
.in
implement the object. These functions allow client applications to read or write the attribute
values. However, if an attribute is preceded by the keyword readonly, then clients can only
read the attribute value.
be
For example, the Account interface defines the attributes name and balance. These attributes
represent information about the account which the object implementation can set, but which
client applications can only read.
tu
Operations in IDL Interface Definitions
se
IDL operations define the format of functions, methods, or operations that clients use to
access the functionality of an object. An IDL operation can take parameters and return a
value, using any of the available IDL data types.
.c
For example, the Account interface defines the operations deposit() and withdraw() as
follows:
w
//IDL
module BankSimple {
w
...
w
interface Account {
// Operations available on the account.
void deposit(in CashAmount amount);
void withdraw(in CashAmount amount);
...
};
};
Each operation takes a parameter and has a void return type.
Each parameter definition must specify the direction in which the parameter value is passed.
The possible parameter passing modes are as follows:
14
www.csetube.in
www.csetube.in
In The parameter is passed from the caller of the operation to the object.
out The parameter is passed from the object to the caller.
inout The parameter is passed in both directions.
Parameter passing modes clarify operation definitions and allow an IDL compiler to map
operations accurately to a target programming language.
Raising Exceptions in IDL Operations
IDL operations can raise exceptions to indicate the occurrence of an error. CORBA defines
two types of exceptions:
System exceptions are a set of standard exceptions defined by CORBA.
.in

 User-defined exceptions are exceptions that you define in your IDL specification.
Implicitly, all IDL operations can raise any of the CORBA system exceptions. No reference
be
to system exceptions appears in an IDL specification.
To specify that an operation can raise a user-defined exception, first define the exception
structure and then add an IDL raises clause to the operation definition. For example, the
tu
operation withdraw() in interface Account could raise an exception to indicate that the
withdrawal has failed, as follows:
se
// IDL
module BankExceptions {
...
.c
interface Account {
exception InsufficientFunds {
w
string reason;
};
w
void withdraw(in CashAmount amount)

raises(InsufficientFunds);
w
...
};
};
An IDL exception is a data structure that contains member fields. In the preceding example,
the exception InsufficientFunds includes a single member of type string.
The raises clause follows the definition of operation withdraw() to indicate that this operation
can raise exception InsufficientFunds. If an operation can raise more then one type of user-
defined exception, include each exception identifier in the raises clause and separate the
identifiers using commas.
15
www.csetube.in
www.csetube.in
Invocation Semantics for IDL Operations
By default, IDL operations calls are synchronous, that is a client calls an operation and blocks
until the object has processed the operation call and returned a value. The IDL keyword
oneway allows you to modify these invocation semantics.
If you precede an operation definition with the keyword oneway, a client that calls the
operation will not block while the object processes the call. For example, you could add a
oneway operation to interface Account that sends a notice to an Account object, as follows:
module BankSimple {
...
interface Account {
oneway void notice(in string text);
.in
...
};
};
be
Orbix does not guarantee that a oneway operation call will succeed; so if a oneway operation
fails, a client may never know. There is only one circumstance in which Orbix indicates
failure of a oneway operation. If a oneway operation call fails before Orbix transmits the call
tu
from the client address space, then Orbix raises a system exception.
A oneway operation can not have any out or inout parameters and can not return a value. In
se
addition, a oneway operation can not have an associated raises clause.
Passing Context Information to IDL Operations

.c
CORBA context objects allow a client to map a set of identifiers to a set of string values.
When defining an IDL operation, you can specify that the operation should receive the client
mapping for particular identifiers as an implicit part of the operation call. To do this, add a
w
context clause to the operation definition.
Consider the example of an Account object, where each client maintains a set of identifiers,
w
such as sys_time and sys_location that map to information that the operation deposit() logs
for each deposit received. To ensure that this information is passed with every operation call,
w
extend the definition of deposit() as follows:
// IDL
module BankSimple {
...
interface Account {
void deposit(in CashAmount amount)
context("sys_time", "sys_location");
...
};
};
16
www.csetube.in
www.csetube.in
A context clause includes the identifiers for which the operation expects to receive mappings.
Note that IDL contexts are rarely used in practice.
Inheritance of IDL Interfaces
IDL supports inheritance of interfaces. An IDL interface can inherit all the elements of one or
more other interfaces.
For example, the following IDL definition illustrates two interfaces, called CheckingAccount
and SavingsAccount, that inherit from interface Account:
// IDL
module BankSimple{
interface Account {
.in
...
};
be
interface CheckingAccount : Account {
readonly attribute overdraftLimit;
boolean orderChequeBook ();
};
tu
interface SavingsAccount : Account {
float calculateInterest ();
se
};
};
Interfaces CheckingAccount and SavingsAccount implicitly include all elements of interface

.c
Account.
An object that implements CheckingAccount can accept invocations on any of the attributes
w
and operations of this interface, and on any of the elements of interface Account. However, a
CheckingAccount object may provide different implementations of the elements of interface
Account to an object that implements Account only.
w
The following IDL definition shows how to define an interface that inherits both
w
CheckingAccount and SavingsAccount:
// IDL
module BankSimple {
interface Account {
...
};
interface CheckingAccount : Account {

...
};
interface SavingsAccount : Account {
17
www.csetube.in
www.csetube.in
...
};
interface PremiumAccount :
CheckingAccount, SavingsAccount {
...
};
};
Interface PremiumAccount is an example of multiple inheritance in IDL. Figure 3.1 on

page 59 illustrates the inheritance hierarchy for this interface.
If you define an interface that inherits from two interfaces which contain a constant, type, or
exception definition of the same name, you must fully scope that name when using that
constant, type, or exception. An interface can not inherit from two interfaces that include
.in
operations or attributes that have the same name.
be
tu
se
.c
Figure 3.1: Multiple Inheritance of IDL Interfaces

w
The Object Interface Type
IDL includes the pre-defined interface Object, which all user-defined interfaces inherit
w
implicitly. The operations defined in this interface are described in the Orbix C++ Edition
Programmer's Reference.
w
While interface Object is never defined explicitly in your IDL specification, the operations of
this interface are available through all your interface types. In addition, you can use Object as
an attribute or operation parameter type to indicate that the attribute or operation accepts any
interface type, for example:
// IDL
interface ObjectLocator
{
void getAnyObject (out Object obj);
};
Note that it is not legal IDL syntax to inherit interface Object explicitly.
18
www.csetube.in
www.csetube.in
Forward Declaration of IDL Interfaces
In an IDL definition, you must declare an IDL interface before you reference it. A forward
declaration declares the name of an interface without defining it. This feature of IDL allows
you to define interfaces that mutually reference each other.
For example, IDL interface Bank includes an operation of IDL interface type Account, to
indicate that Bank stores a reference to an Account object. If the definition of interface
Account follows the definition of interface Bank, you must forward declare Account as
follows:
// IDL
module BankSimple {
// Forward declaration of Account.
interface Account;
.in
interface Bank {
Account create_account (in string name);
be
Account find_account (in string name);
};
// Full definition of Account.
interface Account {
tu
...
};
};
se
The syntax for a forward declaration is the keyword interface followed by the interface
identifier.
.c
Overview of the IDL Data Types
In addition to IDL module, interface, and exception types, there are three general categories
w
of data type in IDL:
Basic types.
w

 Complex types.
 Pseudo object types.
w
This section examines each category of IDL types in turn and also describes how you can
define new data type names in IDL.
IDL Basic Types
The following table lists the basic types supported in IDL.
IDL Type Range of Values

short -2 15...2 15-1 (16-bit)
unsigned short 0...2 16-1 (16-bit)
long -2 31...2 31-1 (32-bit)
19
www.csetube.in
www.csetube.in
unsigned long 0...2 32-1 (32-bit)

long long -2 63...2 63-1 (64-bit)
unsigned long 0...-2 64 (64-bit)
long
float IEEE single-precision floating point numbers.
double IEEE double-precision floating point numbers.
char An 8-bit value.
boolean TRUE or FALSE.
octet An 8-bit value that is guaranteed not to undergo any conversion during
transmission.
any The any type allows the specification of values that can express an
arbitrary IDL type.
.in
The any data type allows you to specify that an attribute value, an operation parameter, or an
operation return value can contain an arbitrary type of value to be determined at runtime.
be
Type any is described in detail in Chapter 12, "The Any Data Type" on page 239.
IDL Complex Types

tu
This section describes the IDL data types enum, struct, union, string, sequence, array, and
fixed.
se
Enum
An enumerated type allows you to assign identifiers to the members of a set of values, for
example:
.c
// IDL
module BankSimple {
w
enum Currency {pound, dollar, yen, franc};

w
interface Account {
readonly attribute CashAmount balance;
readonly attribute Currency balanceCurrency;
w
...
};
};
In this example, attribute balanceCurrency in interface Account can take any one of the
values pound, dollar, yen, or franc.
Struct
A struct data type allows you to package a set of named members of various types, for
example:
// IDL
20
www.csetube.in
www.csetube.in
module BankSimple{
struct CustomerDetails {
string name;
short age;
};
interface Bank {
CustomerDetails getCustomerDetails
(in string name);
...
};
};
In this example, the struct CustomerDetails has two members. The operation
getCustomerDetails() returns a struct of type CustomerDetails that includes values for the
.in
customer name and age.
Union
be
A union data type allows you to define a structure that can contain only one of several
alternative members at any given time. A union saves space in memory, as the amount of
storage required for a union is the amount necessary to store its largest member.
tu
All IDL unions are discriminated. A discriminated union associates a label value with each
member. The value of the label indicates which member of the union currently stores a value.
se
For example, consider the following IDL union definition:
// IDL
.c
struct DateStructure {
short Day;
short Month;
w
short Year;
};
w
union Date switch (short) {

case 1: string stringFormat;
w
case 2: long digitalFormat;

default: DateStructure structFormat;
};
The union type Date is discriminated by a short value. For example, if this short value is 1,
then the union member stringFormat stores a date value as an IDL string. The default label
associated with the member structFormat indicates that if the short value is not 1 or 2, then
the structFormat member stores a date value as an IDL struct.
Note that the type specified in parentheses after the switch keyword must be an integer, char,
boolean or enum type and the value of each case label must be compatible with this type.
21
www.csetube.in
www.csetube.in
String
An IDL string represents a character string, where each character can take any value of the
char basic type.
If the maximum length of an IDL string is specified in the string declaration, then the string is
bounded. Otherwise the string is unbounded.
The following example shows how to declare bounded and unbounded strings:
// IDL
module BankSimple {
interface Account {
// A bounded string with maximum length 10.
attribute string<10> sortCode;
.in
// An unbounded string.
readonly attribute string name;
be
...
}; };
Sequence
tu
In IDL, you can declare a sequence of any IDL data type. An IDL sequence is similar to a
one-dimensional array of elements.
se
An IDL sequence does not have a fixed length. If the sequence has a fixed maximum length,
then the sequence is bounded. Otherwise, the sequence is unbounded.
.c
For example, the following code shows how to declare bounded and unbounded sequences as
members of an IDL struct:
w
// IDL
module BankSimple {
interface Account {
w
...
};
w
struct LimitedAccounts {
string bankSortCode<10>;
// Maximum length of sequence is 50.
sequence<Account, 50> accounts;
};
struct UnlimitedAccounts {
string bankSortCode<10>;
// No maximum length of sequence.
sequence<Account> accounts;
};
};
22
www.csetube.in
www.csetube.in
A sequence must be named by an IDL typedef declaration before it can be used as the type of
an IDL attribute or operation parameter. The following code illustrates this:
// IDL
module BankSimple {
typedef sequence<string> CustomerSeq;
interface Account {
void getCustomerList(out CustomerSeq names);
...
};
};
Arrays
.in
In IDL, you can declare an array of any IDL data type. IDL arrays can be multi-dimensional
and always have a fixed size. For example, you can define an IDL struct with an array
member as follows:
be
// IDL
module BankSimple {
...
tu
interface Account {
...
};
se
struct CustomerAccountInfo {
string name;
.c
Account accounts[3];
};
w
interface Bank {
getCustomerAccountInfo (in string name,
out CustomerAccountInfo accounts);
w
...
};
w
};
In this example, struct CustomerAccountInfo provides access to an array of Account objects

for a bank customer, where each customer can have a maximum of three accounts.
An array must be named by an IDL typedef declaration before it can be used as the type of an
IDL attribute or operation parameter. The IDL typedef declaration allows you define an alias
for a data type, as described in "Defining Data Type Names and Constants" on page 68.
The following code illustrates this:
// IDL
module BankSimple {
23
www.csetube.in
www.csetube.in
interface Account {
...
};
typedef Account AccountArray[100];
interface Bank {
readonly attribute AccountArray accounts;
...
};
};
Note that an array is a less flexible data type than an IDL sequence, because an array always
has a fixed length. An IDL sequence always has a variable length, although it may have an
associated maximum length value.
.in
Fixed
be
The fixed data type allows you to represent number in two parts: a digit and a scale. The digit
represents the length of the number, and the scale is a non-negative integer that represents the
position of the decimal point in the number, relative to the rightmost digit.
tu
module BankSimple {
typedef fixed<10,4> ExchangeRate;
se
struct Rates {
ExchangeRate USRate;
ExchangeRate UKRate;
ExchangeRate IRRate;
.c
};
};
w
In this case, the ExchangeRate type has a digit of size 10, and a scale of 4. This means that it
can represent numbers up to (+/-)999999.9999.
w
The maximum value for the digits is 31, and scale cannot be greater than digits. The
maximum value that a fixed type can hold is equal to the maximum value of a double.
w
Scale can also be a negative number. This means that the decimal point is moved scale digits
in a rightward direction, causing trailing zeros to be added to the value of the fixed. For
example, fixed <3,-4> with a numeric value of 123 actually represents the number 1230000.
This provides a mechanism for storing numbers with trailing zeros in an efficient manner.
Note: Fixed <3, -4> can also be represented as fixed <7, 0>.
Constant fixed types can also be declared in IDL. The digits and scale are automatically
calculated from the constant value. For example:
24
www.csetube.in
www.csetube.in
module Circle {
const fixed pi = 3.142857;
};
This yields a fixed type with a digits value of 7, and a scale value of 6.
IDL Pseudo Object Types
CORBA defines a set of pseudo object types that ORB implementations use when mapping
IDL to some programming languages. These object types have interfaces defined in IDL but
do not have to follow the normal IDL mapping for interfaces and are not generally available
in your IDL specifications.
You can use only the following pseudo object types as attribute or operation parameter types
in an IDL specification:
.in
CORBA::NamedValue
CORBA::Principal
be
CORBA::TypeCode
To use any of these three types in an IDL specification, include the file orb.idl in the IDL file
as follows:
tu
// IDL
#include <orb.idl>
se
...
This statement indicates to the IDL compiler that types NamedValue, Principal, and
TypeCode may be used. The file orb.idl should not actually exist in your system. Do not
.c
name any of your IDL files orb.idl.
Defining Data Type Names and Constants

w
IDL allows you to define new data type names and constants. This section describes how to
use each of these features of IDL.
w
Data Type Names

w
The typedef keyword allows you define a meaningful or more simple name for an IDL type.
The following IDL provides a simple example of using this keyword:
// IDL
module BankSimple {
interface Account {
...
};
typedef Account StandardAccount;

};
25
www.csetube.in
www.csetube.in
The identifier StandardAccount can act as an alias for type Account in subsequent IDL
definitions. Note that CORBA does not specify whether the identifiers Account and
StandardAccount represent distinct IDL data types in this example.
Constants
IDL allows you to specify constant data values using one of several basic data types. To
declare a constant, use the IDL keyword const, for example:
// IDL
module BankSimple {
interface Bank {
const long MaxAccounts = 10000;
const float Factor = (10.0 - 6.5) * 3.91;
...
.in
};
};
be
The value of an IDL constant cannot change. You can define a constant at any level of scope
in your IDL specification. tu
A class providing APIs for the CORBA Object Request Broker features. The ORB class also
se
provides "pluggable ORB implementation" APIs that allow another vendor's ORB
implementation to be used.
An ORB makes it possible for CORBA objects to communicate with each other by
.c
connecting objects making requests (clients) with objects servicing requests (servers).
The ORB class, which encapsulates generic CORBA functionality, does the following: (Note
w
that items 5 and 6, which include most of the methods in the class ORB, are typically used
with the Dynamic Invocation Interface (DII) and the Dynamic Skeleton Interface (DSI).
These interfaces may be used by a developer directly, but most commonly they are used by
w
the ORB internally and are not seen by the general programmer.)
w
1. initializes the ORB implementation by supplying values for predefined properties and
environmental parameters
2. obtains initial object references to services such as the NameService using the method
resolve_initial_references
3. converts object references to strings and back
4. connects the ORB to a servant (an instance of a CORBA object implementation) and
disconnects the ORB from a servant
5. creates objects such as
o TypeCode
o Any
o NamedValue
o Context
o Environment
26
www.csetube.in
www.csetube.in
o lists (such as NVList) containing these objects

6. sends multiple messages in the DII
The ORB class can be used to obtain references to objects implemented anywhere on the
network.
An application or applet gains access to the CORBA environment by initializing itself into an
ORB using one of three init methods. Two of the three methods use the properties
(associations of a name with a value) shown in the table below.
Standard Java CORBA Properties:

Property Name Property Value
org.omg.CORBA.ORBClass class name of an ORB implementation
org.omg.CORBA.ORBSingletonClass class name of the ORB returned by init()
.in
These properties allow a different vendor's ORB implementation to be "plugged in."
be
When an ORB instance is being created, the class name of the ORB implementation is
located using the following standard search order:
1. check in Applet parameter or application string array, if any

tu
2. check in properties parameter, if any
3. check in the System properties
4. check in the orb.properties file located in the user.home directory (if any)
se
5. check in the orb.properties file located in the java.home/lib directory (if any)
6. fall back on a hardcoded default behavior (use the Java IDL implementation)
Note that Java IDL provides a default implementation for the fully-functional ORB and for
.c
the Singleton ORB. When the method init is given no parameters, the default Singleton ORB
is returned. When the method init is given parameters but no ORB class is specified, the
Java IDL ORB implementation is returned.
w
The following code fragment creates an ORB object initialized with the default ORB
w
Singleton. This ORB has a restricted implementation to prevent malicious applets from doing
anything beyond creating typecodes. It is called a singleton because there is only one instance
for an entire virtual machine.
w
ORB orb = ORB.init();
The following code fragment creates an ORB object for an application. The parameter args
represents the arguments supplied to the application's main method. Since the property
specifies the ORB class to be "SomeORBImplementation", the new ORB will be initialized
with that ORB implementation. If p had been null, and the arguments had not specified an
ORB class, the new ORB would have been initialized with the default Java IDL
implementation.
Properties p = new Properties();
27
www.csetube.in
www.csetube.in
p.put("org.omg.CORBA.ORBClass", "SomeORBImplementation");
ORB orb = ORB.init(args, p);
The following code fragment creates an ORB object for the applet supplied as the first
parameter. If the given applet does not specify an ORB class, the new ORB will be initialized
with the default Java IDL implementation.
ORB orb = ORB.init(myApplet, null);
An application or applet can be initialized in one or more ORBs. ORB initialization is a

bootstrap call into the CORBA world.
Since:
.in
JDK1.2
Constructor Summary
be
ORB() tu
Method Summary
se
void connect(Object obj)

Connects the given servant object (a Java object that is an instance of
the server implementation class) to the ORB.
.c
TypeCode create_abstract_interface_tc(String id, String name)

Create a TypeCode object for an IDL abstract interface.
w
abstract create_alias_tc(String id, String name, TypeCode original_type)

TypeCode Creates a TypeCode object representing an IDL alias (typedef).
abstract Any create_any()
w
Creates an IDL Any object initialized to contain a Typecode object

whose kind field is set to TCKind.tc_null.
w
abstract create_array_tc(int length, TypeCode element_type)

TypeCode Creates a TypeCode object representing an IDL array.
DynAny create_basic_dyn_any(TypeCode type)
Creates a basic DynAny object from the given TypeCode object.
abstract create_context_list()
ContextList Creates an empty ContextList object.
DynAny create_dyn_any(Any value)
Creates a new DynAny object from the given Any object.
DynArray create_dyn_array(TypeCode type)
Creates a new DynArray object from the given TypeCode object.
28
www.csetube.in
www.csetube.in
DynEnum create_dyn_enum(TypeCode type)

Creates a new DynEnum object from the given TypeCode object.
DynSequence create_dyn_sequence(TypeCode type)
Creates a new DynSequence object from the given TypeCode object.
DynStruct create_dyn_struct(TypeCode type)
Creates a new DynStruct object from the given TypeCode object.
DynUnion create_dyn_union(TypeCode type)
Creates a new DynUnion object from the given TypeCode object.
abstract create_enum_tc(String id, String name, String[] members)
TypeCode Creates a TypeCode object representing an IDL enum.
abstract create_environment()
Environment Creates an Environment object.
.in
abstract create_exception_list()
ExceptionList Creates an empty ExceptionList object.
abstract create_exception_tc(String id, String name, StructMember[] members)
be
TypeCode Creates a TypeCode object representing an IDL exception.
TypeCode create_fixed_tc(short digits, short scale)
Create a TypeCode object for an IDL fixed type.
tu
abstract create_interface_tc(String id, String name)
TypeCode Creates a TypeCode object representing an IDL interface.
abstract create_list(int count)
se
NVList Allocates an NVList with (probably) enough space for the specified
number of NamedValue objects.
abstract create_named_value(String s, Any any, int flags)
.c
NamedValue Creates a NamedValue object using the given name, value, and
argument mode flags.
TypeCode create_native_tc(String id, String name)
w
Create a TypeCode object for an IDL native type.

NVList create_operation_list(Object oper)
w
Creates an NVList initialized with argument descriptions for the

operation described in the given OperationDef object.
w
abstract create_output_stream()
OutputStream Creates a new org.omg.CORBA.portable.OutputStream into which IDL
method parameters can be marshalled during method invocation.
Policy create_policy(int type, Any val)
Can be invoked to create new instances of policy objects of a specific
type with specified initial state.
abstract create_recursive_sequence_tc(int bound, int offset)
TypeCode Deprecated. Use a combination of create_recursive_tc and
create_sequence_tc instead
TypeCode create_recursive_tc(String id)
Create a recursive TypeCode object which serves as a placeholder for a
29
www.csetube.in
www.csetube.in
concrete TypeCode during the process of creating TypeCodes which contain

recursion.
abstract create_sequence_tc(int bound, TypeCode element_type)
TypeCode Creates a TypeCode object representing an IDL sequence.
abstract create_string_tc(int bound)
TypeCode Creates a TypeCode object representing a bounded IDL string.
abstract create_struct_tc(String id, String name, StructMember[] members)
TypeCode Creates a TypeCode object representing an IDL struct.
abstract create_union_tc(String id, String name, TypeCode discriminator_type,
TypeCode UnionMember[] members)
Creates a TypeCode object representing an IDL union.
TypeCode create_value_box_tc(String id, String name, TypeCode boxed_type)
.in
Creates a TypeCode object for an IDL value box.
TypeCode create_value_tc(String id, String name, short type_modifier,
TypeCode concrete_base, ValueMember[] members)
Create a TypeCode object for an IDL value type.
abstract create_wstring_tc(int bound)
TypeCode
be
Creates a TypeCode object representing a bounded IDL wstring (wide
string).
tu
void destroy()
Destroys the ORB so that its resources can be reclaimed.
se
void disconnect(Object obj)

Disconnects the given servant object from the ORB.
Current get_current()
Deprecated. use resolve_initial_references.
.c
abstract get_default_context()
Context Gets the default Context object.
w
abstract get_next_response()
Request Gets the next Request instance for which a response has been received.
w
abstract get_primitive_tc(TCKind tcKind)

TypeCode Retrieves the TypeCode object that represents the given primitive IDL
w
type.
boolean get_service_information(short service_type,
ServiceInformationHolder service_info)
Used to obtain information about CORBA facilities and services that
are supported by this ORB.
static ORB init()
Returns the ORB singleton object.
static ORB init(Applet app, Properties props)
Creates a new ORB instance for an applet.
static ORB init(String[] args, Properties props)
Creates a new ORB instance for a standalone application.
30
www.csetube.in
www.csetube.in
abstract list_initial_services()
String[] Returns a list of the initially available CORBA object references, such
as "NameService" and "InterfaceRepository".
abstract object_to_string(Object obj)
String Converts the given CORBA object reference to a string.
void perform_work()
Performs an implementation-dependent unit of work if called by the
main thread.
abstract poll_next_response()
boolean Finds out if any of the deferred (asynchronous) invocations have a
response yet.
abstract resolve_initial_references(String object_name)
Object Resolves a specific object reference from the set of available initial
.in
service names.
void run()
This operation blocks the current thread until the ORB has completed
be
the shutdown process, initiated when some thread calls shutdown.
abstract void send_multiple_requests_deferred(Request[] req)
Sends multiple dynamic (DII) requests asynchronously.
tu
abstract void send_multiple_requests_oneway(Request[] req)
Sends multiple dynamic (DII) requests asynchronously without
expecting any responses.
se
protected set_parameters(Applet app, Properties props)

abstract void Allows the ORB implementation to be initialized with the given applet
and parameters.
.c
protected set_parameters(String[] args, Properties props)

abstract void Allows the ORB implementation to be initialized with the given
parameters and properties.
w
void shutdown(boolean wait_for_completion)

Instructs the ORB to shut down, which causes all object adapters to
w
shut down, in preparation for destruction.

If the wait_for_completion parameter is true, this operation blocks until all
ORB processing (including processing of currently executing requests, object
w
deactivation, and other object adapter operations) has completed.

abstract string_to_object(String str)
Object Converts a string produced by the method object_to_string back to a
CORBA object reference.
boolean work_pending()
Returns true if the ORB needs the main thread to perform some work,
and false if the ORB does not need the main thread.
Methods inherited from class java.lang.Object
31
www.csetube.in
www.csetube.in
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Constructor Detail
ORB
public ORB()
Method Detail
init
.in
public static ORB init()
Returns the ORB singleton object. This method always returns the same ORB
instance, which is an instance of the class described by the
org.omg.CORBA.ORBSingletonClass system property.
be
This no-argument version of the method init is used primarily as a factory for
TypeCode objects, which are used by Helper classes to implement the method type. It
is also used to create Any objects that are used to describe union labels (as part of
tu
creating a TypeCode object for a union).
This method is not intended to be used by applets, and in the event that it is called in
se
an applet environment, the ORB it returns is restricted so that it can be used only as a
factory for TypeCode objects. Any TypeCode objects it produces can be safely shared
among untrusted applets.
.c
If an ORB is created using this method from an applet, a system exception will be
thrown if methods other than those for creating TypeCode objects are invoked.
w
Returns:
the singleton ORB
w
w
init
public static ORB init(String[] args,

Properties props)
Creates a new ORB instance for a standalone application. This method may be called
from applications only and returns a new fully functional ORB object each time it is
called.
Parameters:
args - command-line arguments for the application's main method; may be null
props - application-specific properties; may be null
Returns:
the newly-created ORB instance
32
www.csetube.in
www.csetube.in
init
public static ORB init(Applet app,

Properties props)
Creates a new ORB instance for an applet. This method may be called from applets
only and returns a new fully-functional ORB object each time it is called.
Parameters:
app - the applet; may be null
props - applet-specific properties; may be null
Returns:
the newly-created ORB instance
set_parameters
.in
protected abstract void set_parameters(String[] args, Properties props)
Allows the ORB implementation to be initialized with the given parameters and
properties. This method, used in applications only, is implemented by subclass ORB
be
implementations and called by the appropriate init method to pass in its parameters.
Parameters:
args - command-line arguments for the application's main method; may be null
props - application-specific properties; may be null
tu
set_parameters
se
protected abstract void set_parameters(Applet app,

Properties props)
Allows the ORB implementation to be initialized with the given applet and
.c
parameters. This method, used in applets only, is implemented by subclass ORB

implementations and called by the appropriate init method to pass in its parameters.
Parameters:
w
app - the applet; may be null

props - applet-specific properties; may be null
w
connect
w
public void connect(Object obj)

Connects the given servant object (a Java object that is an instance of the server
implementation class) to the ORB. The servant class must extend the ImplBase class
corresponding to the interface that is supported by the server. The servant must thus
be a CORBA object reference, and inherit from org.omg.CORBA.Object. Servants
created by the user can start receiving remote invocations after the method connect
has been called. A servant may also be automatically and implicitly connected to the
ORB if it is passed as an IDL parameter in an IDL method invocation on a non-local
object, that is, if the servant object has to be marshalled and sent outside of the
process address space.
33
www.csetube.in
www.csetube.in
Calling the method connect has no effect when the servant object is already connected
to the ORB.
Deprecated by the OMG in favor of the Portable Object Adapter APIs.
Parameters:
obj - The servant object reference
destroy
public void destroy()

Destroys the ORB so that its resources can be reclaimed. Any operation invoked on a
destroyed ORB reference will throw the OBJECT_NOT_EXIST exception. Once an
ORB has been destroyed, another call to init with the same ORBid will return a
.in
reference to a newly constructed ORB.
If destroy is called on an ORB that has not been shut down, it will start the shut down
be
process and block until the ORB has shut down before it destroys the ORB.
If an application calls destroy in a thread that is currently servicing an invocation, the
BAD_INV_ORDER system exception will be thrown with the OMG minor code 3,
since blocking would result in a deadlock.
tu
For maximum portability and to avoid resource leaks, an application should always
call shutdown and destroy on all ORB instances before exiting.
se
Throws:
BAD_INV_ORDER - if the current thread is servicing an invocation
.c
disconnect
w
public void disconnect(Object obj)

Disconnects the given servant object from the ORB. After this method returns, the
ORB will reject incoming remote requests for the disconnected servant and will send
w
the exception org.omg.CORBA.OBJECT_NOT_EXIST back to the remote client.

Thus the object appears to be destroyed from the point of view of remote clients.
w
Note, however, that local requests issued using the servant directly do not pass
through the ORB; hence, they will continue to be processed by the servant.
Calling the method disconnect has no effect if the servant is not connected to the
ORB.
Deprecated by the OMG in favor of the Portable Object Adapter APIs.
Parameters:
obj - The servant object to be disconnected from the ORB
list_initial_services
34
www.csetube.in
www.csetube.in
public abstract String[] list_initial_services()

Returns a list of the initially available CORBA object references, such as
"NameService" and "InterfaceRepository".
Returns:
an array of String objects that represent the object references for CORBA services
that are initially available with this ORB
resolve_initial_references
public abstract Object resolve_initial_references(String object_name)

throws InvalidName
Resolves a specific object reference from the set of available initial service names.
Parameters:
object_name - the name of the initial service as a string
.in
Returns:
the object reference associated with the given name
Throws:
be
InvalidName - if the given name is not associated with a known service
object_to_string
tu
public abstract String object_to_string(Object obj)
Converts the given CORBA object reference to a string. Note that the format of this
se
string is predefined by IIOP, allowing strings generated by a different ORB to be
converted back into an object reference.
The resulting String object may be stored or communicated in any way that a String
.c
object can be manipulated.
Parameters:
w
obj - the object reference to stringify

Returns:
the string representing the object reference
w
w
string_to_object
public abstract Object string_to_object(String str)

Converts a string produced by the method object_to_string back to a CORBA object
reference.
Parameters:
str - the string to be converted back to an object reference. It must be the result of
converting an object reference to a string using the method object_to_string.
Returns:
the object reference
create_list
35
www.csetube.in
www.csetube.in
public abstract NVList create_list(int count)

Allocates an NVList with (probably) enough space for the specified number of
NamedValue objects. Note that the specified size is only a hint to help with storage
allocation and does not imply the maximum size of the list.
Parameters:
count - suggested number of NamedValue objects for which to allocate space
Returns:
the newly-created NVList
create_operation_list
public NVList create_operation_list(Object oper)

Creates an NVList initialized with argument descriptions for the operation described
in the given OperationDef object. This OperationDef object is obtained from an
.in
Interface Repository. The arguments in the returned NVList object are in the same
order as in the original IDL operation definition, which makes it possible for the list to
be used in dynamic invocation requests.
be
Parameters:
oper - the OperationDef object to use to create the list
Returns:
a newly-created NVList object containing descriptions of the arguments to the method
tu
described in the given OperationDef object
See Also:
NVList
se
create_named_value
.c
public abstract NamedValue create_named_value(String s,

Any any,
int flags)
w
Creates a NamedValue object using the given name, value, and argument mode flags.
A NamedValue object serves as (1) a parameter or return value or (2) a context

w
property. It may be used by itself or as an element in an NVList object.

w
Parameters:
s - the name of the NamedValue object
any - the Any value to be inserted into the NamedValue object
flags - the argument mode flags for the NamedValue: one of ARG_IN.value,
ARG_OUT.value, or ARG_INOUT.value.
Returns:
the newly-created NamedValue object
See Also:
NamedValue
create_exception_list
36
www.csetube.in
www.csetube.in
public abstract ExceptionList create_exception_list()

Creates an empty ExceptionList object.
Returns:
the newly-created ExceptionList object
create_context_list
public abstract ContextList create_context_list()

Creates an empty ContextList object.
Returns:
the newly-created ContextList object
See Also:
ContextList, Context
.in
get_default_context
be
public abstract Context get_default_context()
Gets the default Context object.
Returns:
the default Context object
tu
See Also:
Context
se
create_environment
public abstract Environment create_environment()

.c
Creates an Environment object.

Returns:
the newly-created Environment object
w
See Also:
Environment
w
create_output_stream
w
public abstract OutputStream create_output_stream()

Creates a new org.omg.CORBA.portable.OutputStream into which IDL method
parameters can be marshalled during method invocation.
Returns:
the newly-created org.omg.CORBA.portable.OutputStream object
send_multiple_requests_oneway
public abstract void send_multiple_requests_oneway(Request[] req)

Sends multiple dynamic (DII) requests asynchronously without expecting any
responses. Note that oneway invocations are not guaranteed to reach the server.
37
www.csetube.in
www.csetube.in
Parameters:
req - an array of request objects
send_multiple_requests_deferred
public abstract void send_multiple_requests_deferred(Request[] req)

Sends multiple dynamic (DII) requests asynchronously.
Parameters:
req - an array of Request objects
poll_next_response
public abstract boolean poll_next_response()
.in
Finds out if any of the deferred (asynchronous) invocations have a response yet.
Returns:
true if there is a response available; false otherwise
get_next_response
be
tu
public abstract Request get_next_response()
throws WrongTransaction
Gets the next Request instance for which a response has been received.
se
Returns:
the next Request object ready with a response
Throws:
WrongTransaction - if the method get_next_response is called from a transaction
.c
scope different from the one from which the original request was sent. See the OMG
Transaction Service specification for details.
w
get_primitive_tc
w
public abstract TypeCode get_primitive_tc(TCKind tcKind)

Retrieves the TypeCode object that represents the given primitive IDL type.
w
Parameters:
tcKind - the TCKind instance corresponding to the desired primitive type
Returns:
the requested TypeCode object
create_struct_tc
public abstract TypeCode create_struct_tc(String id,

String name,
StructMember[] members)
Creates a TypeCode object representing an IDL struct. The TypeCode object is
initialized with the given id, name, and members.
38
www.csetube.in
www.csetube.in
Parameters:
id - the repository id for the struct
name - the name of the struct
members - an array describing the members of the struct
Returns:
a newly-created TypeCode object describing an IDL struct
create_union_tc
public abstract TypeCode create_union_tc(String id,

String name,
TypeCode discriminator_type,
UnionMember[] members)
Creates a TypeCode object representing an IDL union. The TypeCode object is
.in
initialized with the given id, name, discriminator type, and members.
Parameters:
id - the repository id of the union
be
name - the name of the union
discriminator_type - the type of the union discriminator
members - an array describing the members of the union
Returns:
tu
a newly-created TypeCode object describing an IDL union
se
create_enum_tc
public abstract TypeCode create_enum_tc(String id,

String name,
.c
String[] members)
Creates a TypeCode object representing an IDL enum. The TypeCode object is
w
Parameters:
id - the repository id for the enum
name - the name for the enum
w
members - an array describing the members of the enum

Returns:
w
a newly-created TypeCode object describing an IDL enum
create_alias_tc
public abstract TypeCode create_alias_tc(String id,

String name,
TypeCode original_type)
Creates a TypeCode object representing an IDL alias (typedef). The TypeCode object
is initialized with the given id, name, and original type.
Parameters:
39
www.csetube.in
www.csetube.in
id - the repository id for the alias

name - the name for the alias
original_type - the TypeCode object describing the original type for which this is an
alias
Returns:
a newly-created TypeCode object describing an IDL alias
create_exception_tc
public abstract TypeCode create_exception_tc(String id,

String name,
StructMember[] members)
Creates a TypeCode object representing an IDL exception. The TypeCode object is
.in
Parameters:
id - the repository id for the exception
name - the name for the exception
be
members - an array describing the members of the exception
Returns:
a newly-created TypeCode object describing an IDL exception
tu
create_interface_tc
se
public abstract TypeCode create_interface_tc(String id,
String name)
Creates a TypeCode object representing an IDL interface. The TypeCode object is
initialized with the given id and name.
.c
Parameters:
id - the repository id for the interface
name - the name for the interface
w
Returns:
a newly-created TypeCode object describing an IDL interface
w
create_string_tc
w
public abstract TypeCode create_string_tc(int bound)

Creates a TypeCode object representing a bounded IDL string. The TypeCode object
is initialized with the given bound, which represents the maximum length of the
string. Zero indicates that the string described by this type code is unbounded.
Parameters:
bound - the bound for the string; cannot be negative
Returns:
a newly-created TypeCode object describing a bounded IDL string
Throws:
BAD_PARAM - if bound is a negative value
40
www.csetube.in
www.csetube.in
create_wstring_tc
public abstract TypeCode create_wstring_tc(int bound)

Creates a TypeCode object representing a bounded IDL wstring (wide string). The
TypeCode object is initialized with the given bound, which represents the maximum
length of the wide string. Zero indicates that the string described by this type code is
unbounded.
Parameters:
bound - the bound for the wstring; cannot be negative
Returns:
a newly-created TypeCode object describing a bounded IDL wstring
Throws:
BAD_PARAM - if bound is a negative value
.in
create_sequence_tc
public abstract TypeCode create_sequence_tc(int bound,
be
TypeCode element_type)
Creates a TypeCode object representing an IDL sequence. The TypeCode object is
initialized with the given bound and element type.
Parameters:
tu
bound - the bound for the sequence, 0 if unbounded
element_type - the TypeCode object describing the elements contained in the
sequence
se
Returns:
a newly-created TypeCode object describing an IDL sequence
.c
create_recursive_sequence_tc
public abstract TypeCode create_recursive_sequence_tc(int bound,

w
int offset)
Deprecated. Use a combination of create_recursive_tc and create_sequence_tc
instead
w
Creates a TypeCode object representing a a recursive IDL sequence.

w
For the IDL struct Node in following code fragment, the offset parameter for creating
its sequence would be 1:
Struct Node {
long value;
Sequence <Node> subnodes;
};
Parameters:
bound - the bound for the sequence, 0 if unbounded
offset - the index to the enclosing TypeCode object that describes the elements of this
sequence
Returns:
41
www.csetube.in
www.csetube.in
a newly-created TypeCode object describing a recursive sequence

See Also:
create_recursive_tc, create_sequence_tc
create_array_tc
public abstract TypeCode create_array_tc(int length,

TypeCode element_type)
Creates a TypeCode object representing an IDL array. The TypeCode object is
initialized with the given length and element type.
Parameters:
length - the length of the array
element_type - a TypeCode object describing the type of element contained in the
array
.in
Returns:
a newly-created TypeCode object describing an IDL array
be
create_native_tc
public TypeCode create_native_tc(String id,

tu
String name)
Create a TypeCode object for an IDL native type.
Parameters:
se
id - the logical id for the native type.
name - the name of the native type.
Returns:
the requested TypeCode.
.c
create_abstract_interface_tc
w
public TypeCode create_abstract_interface_tc(String id,

String name)
w
Create a TypeCode object for an IDL abstract interface.

Parameters:
w
id - the logical id for the abstract interface type.

name - the name of the abstract interface type.
Returns:
create_fixed_tc
public TypeCode create_fixed_tc(short digits,

short scale)
Create a TypeCode object for an IDL fixed type.
Parameters:
42
www.csetube.in
www.csetube.in
digits - specifies the total number of decimal digits in the number and must be from 1
to 31 inclusive.
scale - specifies the position of the decimal point.
Returns:
create_value_tc
public TypeCode create_value_tc(String id,

String name,
short type_modifier,
TypeCode concrete_base,
ValueMember[] members)
Create a TypeCode object for an IDL value type. The concrete_base parameter is the
.in
TypeCode for the immediate concrete valuetype base of the valuetype for which the
TypeCode is being created. It may be null if the valuetype does not have a concrete
base.
be
Parameters:
id - the logical id for the value type.
name - the name of the value type.
type_modifier - one of the value type modifier constants: VM_NONE,
tu
VM_CUSTOM, VM_ABSTRACT or VM_TRUNCATABLE
concrete_base - a TypeCode object describing the concrete valuetype base
members - an array containing the members of the value type
se
Returns:
the requested TypeCode
.c
create_recursive_tc
public TypeCode create_recursive_tc(String id)

w
Create a recursive TypeCode object which serves as a placeholder for a concrete

TypeCode during the process of creating TypeCodes which contain recursion. The id
parameter specifies the repository id of the type for which the recursive TypeCode is
w
serving as a placeholder. Once the recursive TypeCode has been properly embedded
in the enclosing TypeCode which corresponds to the specified repository id, it will
w
function as a normal TypeCode. Invoking operations on the recursive TypeCode

before it has been embedded in the enclosing TypeCode will result in a
BAD_TYPECODE exception.
For example, the following IDL type declaration contains recursion:
Struct Node {
Sequence<Node> subnodes;
};
To create a TypeCode for struct Node, you would invoke the TypeCode creation
operations as shown below:
43
www.csetube.in
www.csetube.in
String nodeID = "IDL:Node:1.0";

TypeCode recursiveSeqTC = orb.create_sequence_tc(0,
orb.create_recursive_tc(nodeID));
StructMember[] members = { new StructMember("subnodes", recursiveSeqTC, null)
};
TypeCode structNodeTC = orb.create_struct_tc(nodeID, "Node", members);
Also note that the following is an illegal IDL type declaration:
Struct Node {
Node next;
};
.in
Recursive types can only appear within sequences which can be empty. That way
marshaling problems, when transmitting the struct in an Any, are avoided.
be
Parameters:
id - the logical id of the referenced type
Returns:
tu
create_value_box_tc
se
public TypeCode create_value_box_tc(String id,

String name,
TypeCode boxed_type)
.c
Creates a TypeCode object for an IDL value box.

Parameters:
id - the logical id for the value type
w
name - the name of the value type

boxed_type - the TypeCode for the type
Returns:
w

w
create_any
public abstract Any create_any()

Creates an IDL Any object initialized to contain a Typecode object whose kind field
is set to TCKind.tc_null.
Returns:
a newly-created Any object
get_current
public Current get_current()
44
www.csetube.in
www.csetube.in
Deprecated. use resolve_initial_references.

Retrieves a Current object. The Current interface is used to manage thread-specific
information for use by services such as transactions and security.
Returns:
a newly-created Current object
See Also:
CORBA package comments for unimplemented features
run
public void run()

This operation blocks the current thread until the ORB has completed the shutdown
process, initiated when some thread calls shutdown. It may be used by multiple
threads which get all notified when the ORB shuts down.
.in
shutdown
be
public void shutdown(boolean wait_for_completion)
Instructs the ORB to shut down, which causes all object adapters to shut down, in
preparation for destruction. If the wait_for_completion parameter is true, this
tu
operation blocks until all ORB processing (including processing of currently
executing requests, object deactivation, and other object adapter operations) has
completed. If an application does this in a thread that is currently servicing an
se
invocation, the BAD_INV_ORDER system exception will be thrown with the OMG
minor code 3, since blocking would result in a deadlock. If the wait_for_completion
parameter is FALSE, then shutdown may not have completed upon return.
.c
While the ORB is in the process of shutting down, the ORB operates as normal,
servicing incoming and outgoing requests until all requests have been completed.
Once an ORB has shutdown, only object reference management operations may be
w
invoked on the ORB or any object reference obtained from it. An application may
also invoke the destroy operation on the ORB itself. Invoking any other operation will
throw the BAD_INV_ORDER system exception with the OMG minor code 4.
w
The ORB.run method will return after shutdown has been called.
w
Parameters:
wait_for_completion - true if the call should block until the shutdown is complete;
false if it should return immediately
Throws:
BAD_INV_ORDER - if the current thread is servicing an invocation
work_pending
public boolean work_pending()

Returns true if the ORB needs the main thread to perform some work, and false if the
ORB does not need the main thread.
45
www.csetube.in
www.csetube.in
Returns:
true if there is work pending, meaning that the ORB needs the main thread to perform
some work; false if there is no work pending and thus the ORB does not need the
main thread
perform_work
public void perform_work()

Performs an implementation-dependent unit of work if called by the main thread.
Otherwise it does nothing. The methods work_pending and perform_work can be
used in conjunction to implement a simple polling loop that multiplexes the main
thread among the ORB and other activities.
.in
get_service_information
public boolean get_service_information(short service_type,
be
ServiceInformationHolder service_info)
Used to obtain information about CORBA facilities and services that are supported by
this ORB. The service type for which information is being requested is passed in as
the in parameter service_type, the values defined by constants in the CORBA module.
tu
If service information is available for that type, that is returned in the out parameter
service_info, and the operation returns the value true. If no information for the
requested services type is available, the operation returns false (i.e., the service is not
se
supported by this ORB).
Parameters:
service_type - a short indicating the service type for which information is being
requested
.c
service_info - a ServiceInformationHolder object that will hold the

ServiceInformation object produced by this method
Returns:
w
true if service information is available for the service_type; false if no information for
the requested services type is available
See Also:
w
CORBA package comments for unimplemented features

w
create_dyn_any
public DynAny create_dyn_any(Any value)

Creates a new DynAny object from the given Any object.
Parameters:
value - the Any object from which to create a new DynAny object
Returns:
the new DynAny object created from the given Any object
See Also:
CORBA package comments for unimplemented features, DynamicAny package
replaces these API
46
www.csetube.in
www.csetube.in
create_basic_dyn_any
public DynAny create_basic_dyn_any(TypeCode type)

throws InconsistentTypeCode
Creates a basic DynAny object from the given TypeCode object.
Parameters:
type - the TypeCode object from which to create a new DynAny object
Returns:
the new DynAny object created from the given TypeCode object
Throws:
InconsistentTypeCode - if the given TypeCode object is not consistent with the
operation.
See Also:
replaces these API
.in
create_dyn_struct
be
public DynStruct create_dyn_struct(TypeCode type)
Creates a new DynStruct object from the given TypeCode object.
tu
Parameters:
type - the TypeCode object from which to create a new DynStruct object
Returns:
se
the new DynStruct object created from the given TypeCode object
Throws:
operation.
.c
See Also:
replaces these API
w
create_dyn_sequence
w
public DynSequence create_dyn_sequence(TypeCode type)

w
Creates a new DynSequence object from the given TypeCode object.
Parameters:
type - the TypeCode object from which to create a new DynSequence object
Returns:
the new DynSequence object created from the given TypeCode object
Throws:
operation.
See Also:
replaces these API
47
www.csetube.in
www.csetube.in
create_dyn_array
public DynArray create_dyn_array(TypeCode type)

Creates a new DynArray object from the given TypeCode object.
Parameters:
type - the TypeCode object from which to create a new DynArray object
Returns:
the new DynArray object created from the given TypeCode object
Throws:
operation.
See Also:
replaces these API
.in
create_dyn_union
be
public DynUnion create_dyn_union(TypeCode type)
Creates a new DynUnion object from the given TypeCode object.
tu
Parameters:
type - the TypeCode object from which to create a new DynUnion object
Returns:
se
the new DynUnion object created from the given TypeCode object
Throws:
operation.
.c
See Also:
replaces these API
w
create_dyn_enum
w
public DynEnum create_dyn_enum(TypeCode type)

w
Creates a new DynEnum object from the given TypeCode object.
Parameters:
type - the TypeCode object from which to create a new DynEnum object
Returns:
the new DynEnum object created from the given TypeCode object
Throws:
operation.
See Also:
replaces these API
48
www.csetube.in
www.csetube.in
create_policy
public Policy create_policy(int type,

Any val)
throws PolicyError
Can be invoked to create new instances of policy objects of a specific type with
specified initial state. If create_policy fails to instantiate a new Policy object due to its
inability to interpret the requested type and content of the policy, it raises the
PolicyError exception with the appropriate reason.
Parameters:
type - the PolicyType of the policy object to be created
val - the value that will be used to set the initial state of the Policy object that is
created
Returns:
Reference to a newly created Policy object of type specified by the type parameter
.in
and initialized to a state specified by the val parameter
Throws:
org.omg.CORBA.PolicyError - when the requested policy is not supported or a
be
requested initial state for the policy is not supported.
PolicyError tu
se
.c
w
w
w
49
www.csetube.in
www.csetube.in
UNIT V
Component Object Model
Component Object Model (COM) is a Microsoft platform for software componentry introduced
by Microsoft in 1993. The Component Object Model (COM) is a software architecture that allows
applications to be built from binary software components. COM is the underlying architecture that
forms the foundation for higher-level software services, like those provided by OLE. OLE services
span various aspects of commonly needed system functionality, including compound documents,
custom controls, interapplication scripting, data transfer, and other software interactions.
.in
be
tu
se
.c
w
w
Figure . OLE technologies build on one another, with COM as the foundation.
The essence of COM is a language-neutral way of implementing objects such that they can be used
w
in environments different from the one they were created in, even across machine boundaries. For
well-authored components, COM allows reuse of objects with no knowledge of their internal
implementation because it forces component implementers to provide well-defined interfaces that
are separate from the implementation. The different allocation semantics of languages are
accommodated by making objects responsible for their own creation and destruction through
reference-counting. Casting between different interfaces of an object is achieved through the
QueryInterface() function. The preferred method of inheritance within COM is the creation of sub-
objects (called aggregation) to which method calls are delegated.
Although it has been implemented on several platforms, COM is primarily used with Microsoft
Windows. COM is expected to be replaced to at least some extent by the Microsoft .NET
framework, and support for Web Services through the Windows Communication Foundation
(WCF). Networked DCOM uses binary proprietary formats, while WCF uses XML-based SOAP
messaging. COM also competes with CORBA and Java Beans as component software systems.
1
www.csetube.in
www.csetube.in
COM Fundamentals
The Component Object Model defines several fundamental concepts that provide the model's
structural underpinnings. These include:
 A binary standard for function calling between components.

 A provision for strongly-typed groupings of functions into interfaces.
 A base interface providing:
 A way for components to dynamically discover the interfaces implemented by other

components.
 Reference counting to allow components to track their own lifetime and delete themselves
when appropriate.
 A mechanism to identify components and their interfaces uniquely, worldwide.

 A "component loader" to set up component interactions and, additionally (in the cross-
.in
process and cross-network cases), to help manage component interactions.
Advantages of COM
be
1. COM promotes component-based software development - before component-based
development came, software programs have been coded using procedural programming paradigm,
which supports linear form of program execution. But component-based program development
tu
comes with a number of advantages, such as the ability to use pre-packaged components and tools
from third party vendors into an application and support for code reusability in other parts of the
same application.
se
2. COM promotes code reusability - standard classes are normally reused in the same
application but not to be used easily in other applications. But COM components are designed to
separate themselves from single applications and hence can be accessed and used by several
.c
different applications without any hassle.
3. COM promotes Object-oriented programming (OOP) - The primary characteristics

w
of OOP are encapsulation, which allows the implementation details of an object to be hidden,
polymorphism, which is the ability to exhibit multiple behaviors, and inheritance, which allows for
the reuse of existing classes in order to design new and more specialized classes. Among these,
w
encapsulation is one of COM's most important characteristics. Encapsulation helps to hide how an
object has implemented a method internally. This ultimately helps to incorporate more vigorously
w
implemented or advanced implementation into an object at later time without affecting the client
which uses it.
4. COM comprises the necessary mechanisms for COM components to communicate

with each other - In the normal case, two components coded using two different programming
languages can not communicate with each other. But COM can make it possible for different
language components, which adhere to the COM specification, to interact with each other and
hence COM is language-independent.
5. COM helps to access components loaded in different machines on the network -

COM component can reside anywhere on our computer or even on another computer connected to a
network. That is, applications using COM can access and share COM components regardless of
their locations. Thus COM abstracts away the nitty-gritty of clients to locate COM components
2
www.csetube.in
www.csetube.in
anywhere in the network. Thus COM provides location transparency and COM components are
location independent.
COM Interfaces
Components, especially server-side ones, are bound to have their own interfaces. An interface is
simply a list of methods a COM component implements and makes them available to consumers.
COM interface are immutable. That is, once a COM component has been released with an
interface, this interface must never be manipulated. COM interfaces are the mechanisms by which a
client contacts, connects and use components. If the client component is using a different language
from the one a server component is coded, there will be language problem for interactions. In order
to remove this barrier, COM interfaces provide an universal way so that components coded in
different languages can communicate with each other. Thus every interface constitutes a binding
contract between a COM object (no interface is attached with this) and a COM component with an
interface. COM specification makes life easier by allowing a component to publish more than one
interface at a time. New interfaces can! be incorporated to support new features of the components
.in
while keeping the original interface intact. We have to increment a version number for the new
interface. A class module then would need to be implemented for both old and new interfaces in
order to support both old clients that rely on the old interface and new clients that can take
advantage of the new interface. Thus the immutability factor of COM interfaces can be overcome.
Interface Definition Language (IDL)

be
tu
To successfully make COM language-independent, the COM interfaces have to coded using IDL.
IDL is just a declaration language, not a programming language. The syntax for IDL is almost
similar to C++ language. But IDL goes beyond what C++ can offer by being able to define
se
functions that extend process boundaries. IDL provides many vital extensions that allow attributes
such as type libraries, co-classes, interfaces, and method parameters to be specified quite elegantly.
But if there is no language problem, it is not mandatory to use IDL for defining COM interfaces.
.c
Here comes an model interface definition for a COM component coded using Microsoft IDL.
[ object,
w
uuid (122323FAGAd098776)
]
interface IFindSum : IUnknown
w
{
import "unknown.idl"
w
HRESULT SumOfNumbers ( [in] long lnum1, [in] long lnum2, [out, retval] long* sum);
}
The interface definition begins with an object attribute. The object attribute is used to identify a
COM interface. Then a UUID (universally unique identifier), which provides an unique identifying
number ( a string of hexadecimal digits ) for each interface and this number is being generated by
an algorithm, which takes into account the unique value from the network card on the programmer's
PC and the current system date and time, follows that. The interface keyword is followed by the
name of the interface (IFindSum).
The letter I in the interface name helps to identify that this is an interface. Following IFindSum is a
colon and then the interface name IUnknown, the base interface and every COM object has to have
this interface. IUnknown has three methods that a client can invoke: QueryInterface, AddRef, and
Release.
3
www.csetube.in
www.csetube.in
The QueryInterface method is the mechanism that a client uses to discover and navigate the
interfaces of a component dynamically. It is the most significant method of all COM interfaces
available for a component since this method allows run-time checking of all of these interfaces.
When the QueryInterface method provides an interface pointer to a client, the QueryInterface calls
the method AddRef. The only way to access a COM object is through a pointer to an interface.
An interface pointer is actually a pointer to a pointer in a virtual table that is implemented in

memory. That is, for every class that contains public methods, a virtual table will be created and
placed in memory at run time. Virtual tables are generated for each class and not for objects of that
class. Each virtual table contains an array of function pointers whose elements contain the address
of each specific function that an object can implement. At the top of every virtual table array will
be three fundamental methods that make up this IUnknown interface.
The methods AddRef and Release manage reference counting. This reference count is an internal
count of the number of clients using a particular COM object . It is possible for several clients to
invoke the services available with a COM object at the same time. When a client begins a session
.in
with an object, it calls the AddRef method, which increments one to the existing count. Once the
session is over, the corresponding Release method gets invoked to decrement one from the existing
count.
be
The next line down is used to locate the definition for the base interface IUnknown The next line
identifies the interface method "SumofNumbers". This interface method is designed to return an
HRESULT value.
tu
An HRESULT is used with COM to indicate whether a method call is successfully accomplished or
not. Almost all COM interfaces return a special 32-bit code, called as HRESULT, from their
se
methods to return status information. It is actually the method COM utilizes to return errors to the
caller of the method. The reason for this mechanism is due to the inability of COM to transmit error
messages back to the client if there is anything wrong on the server side or on the way to the server.
As components are being written using different programming languages and each language
.c
follows its own exception mechanisms, COM can not correctly pass on the error messages and
hence HRESULT.
w
Following the HRESULT are three parameters for the interface method SumOfNumbers. The [in]
in the first two parameters specifies that these parameters are input values to be passed to the
interface method and the [out, retval] in the last parameter indicates that this parameter returns a
w
value that will be ultimately passed to back to the client.

w
Windows Registry and Components Environment
COM components may be loaded in different address spaces in the same machine or
machine connected with the network. Before an object can be created, the COM runtime must first
locate the COM components. The COM runtime is able to locate COM components through the use
of Windows registry.
COM components may be out-of-process or in-process. An out-of-process

component can effectively be a separate program containing objects. This type runs in its own
process space and will thus be largely independent from any client programs. These components
are often large applications themselves, and provide access to their objects to make it easy for other
programs to create macros or otherwise make use of existing functionality. This can be very
beneficial, because the component developer can choose his own threading models. The drawback
4
www.csetube.in
www.csetube.in
here is that the developer has to write the code for threading. This work can be handled by
automatically COM+ , the latest one from the COM family.
There is also a performance issue. Because the client application is communicating

with objects which are in an entirely different process there is quite a bit of overhead. COM steps in
between the client and the server and handles all the communication between them. Mainly out-of-
process components are useful if we are trying to make use of the objects in a pre-existing
application.
An in-process component is one where the objects run inside the client's process.
Each client gets its own private copy of the component and hence a copy of all the objects in that
component. An in-process component is often called COM DLLs or ActiveX DLLs. In-process
component does not have a process of its own and it always runs within the context of another
process. Often this other process is the client application itself but may be run within the context of
a different process entirely. In this case, we can get performance boost as the component is loaded
in the client application itself. There is almost no overhead when client interacts with an object that
.in
is running in the same process. The major advantages of having in-process components are stability
and increased manageability .
be
Creating a COM object
There is a lot of communication that must occur behind the scenes in order for a
COM object to be created. First of all, a client looking for an object has to make a call to an API
tu
function called CoCreateInstance with the CLSID for the class, which comprises the particular
object. The prefix Co in this function is a typical naming convention for COM runtime API
functions. CoCreateInstance in turn as a second step calls another API function called
se
CoGetClassObject. Basically the function CoCreateInstance asks the SCM to search the Windows
registry location, which is HKEY_CLASSES_ROOT\CLSID. The function of SCM is to locate the
requested class object by using the specified CLSID. The first place the SCM looks to locate the
class object is within its own internal database. If the class is not located inside its database, the
.c
SCM turns to the system registry as a third step. As soon as the class object is found, the SCM
immediately returns to COM an interface pointer referred to as IClassFactory.
w
Every COM class must have a factory object associated with it. The main purpose of
these class objects is to implement the IClassFactory interface. Once the client gets the
IClassFactory pointer, two things happen. One, by obtaining a pointer to the IClassFactory,
w
CoCreateInstance can call IClassFactory::CreateInstance in order to create the requested COM

object. Once the object is created, a second step occurs: the interface pointer to the IClassFactory
w
gets released.
The interface called IClassFactory's job is to talk to other class objects. Further,
CoGetClassObject is a COM class object whose sole purpose is to create a new instance of a
different class. Because this COM class creates class objects by implementing the IClassFactory
interface, CoGetClassObject is referred to as a class factory.
LockServer
When an object is created it resides in memory. It is the client's job to notify the
object when it is no longer needed. The Release method told above can decrement the reference
count for the interface. If there are several interfaces for an object, it is possible that the object is
still being accessed somewhere else. The idea is that the reference count has to reach zero before
the object is to be released from the memory. Releasing objects from memory usually improves
5
www.csetube.in
www.csetube.in
performance. Some special clients constantly create and destroy objects, which normally affects the
application's performance. The LockServer method allows components to remain in memory by
incrementing the reference count by one. Because LockServer keeps a count of one in the reference
counter, the object will stay in memory even if it is not being accessed currently. Having the
component reside in memory has the advantage of allowing the object to be called without having
to go through the process of recreating it. But on the other hand, if objects are not destroyed when
they are not in use, there will be reduction of system memory resources.
COM Data Types
The following table shows data types used in COM and their corresponding .NET Framework built-
in value types or classes. Any type not explicitly identified in this table is converted to an Int32
system type. For corresponding types in Visual Basic 2005, C#, and C++, see the Introduction to
the .NET Framework Class Library.
.in
COM value type COM reference type System type
be
bool bool * System.Int32
char, small char *, small * System.SByte
short short * System.Int16
tu
long, int long *, int * System.Int32
se
Hyper hyper * System.Int64

unsigned char, byte unsigned char *, byte * System.Byte
wchar_t, unsigned short wchar_t *, unsigned short * System.UInt16
.c
unsigned long, unsigned int unsigned long *, unsigned int System.UInt32

*
w
unsigned hyper unsigned hyper * System.UInt64

w
float float * System.Single

double double * System.Double
w
VARIANT_BOOL VARIANT_BOOL * System.Boolean

void * void ** System.IntPtr
HRESULT HRESULT * System.Int16 or
System.IntPtr
SCODE SCODE * System.Int32
BSTR BSTR * System.String
LPSTR or [string, …] char * LPSTR * System.String
LPWSTR or [string, …] LPWSTR * System.String
wchar_t *
6
www.csetube.in
www.csetube.in
COM value type COM reference type System type
VARIANT VARIANT * System.Object

DECIMAL DECIMAL * System.Decimal
DATE DATE * System.DateTime
GUID GUID * System.Guid
CURRENCY CURRENCY * System.Decimal
IUnknown * IUnknown ** System.Object
IDispatch * IDispatch ** System.Object
SAFEARRAY(type) SAFEARRAY(type) * type[]
.in
The following table lists COM value and reference types that convert to corresponding element
types. For example, a COM coclass automatically maps to a managed class with the same name.
be
COM value type COM reference type Element type
Typedef BaseType MyType ByRef BaseType BaseType

tu
MyStruct ByRef VALUETYPE<MyStruct> valuetype<MyStruct>
MyEnum ByRef VALUETYPE<MyEnum> valuetype<MyEnum>
se
MyInterface * ByRef CLASS <MyInterface> Class <MyInterface>

MyCoClass ByRef CLASS <_Class> Class <_Class>
.c
Proxy
w
A proxy resides in the address space of the calling process and acts as a surrogate for the remote
object. From the perspective of the calling object, the proxy is the object. Typically, the proxy's role
w
is to package the interface parameters for calls to methods in its object interfaces. The proxy
packages the parameters into a message buffer and passes the buffer onto the channel, which
w
handles the transport between processes. The proxy is implemented as an aggregate, or composite,
object. It contains a system-provided, manager piece called the proxy manager and one or more
interface-specific components called interface proxies. The number of interface proxies equals the
number of object interfaces that have been exposed to that particular client. To the client complying
with the component object model, the proxy appears to be the real object.
Each interface proxy is a component object that implements the marshaling code for one of the
object's interfaces. The proxy represents the object for which it provides marshaling code. Each
proxy also implements the IRpcProxyBuffer interface. Although the object interface represented by
the proxy is public, the IRpcProxyBuffer implementation is private and is used internally within
7
www.csetube.in
www.csetube.in
the proxy. The proxy manager keeps track of the interface proxies and also contains the public
implementation of the controlling IUnknown interface for the aggregate. Each interface proxy can
exist in a separate DLL that is loaded when the interface it supports is materialized to the client.
Structure of the Proxy
The following diagram shows the structure of a proxy that supports the standard marshaling of
parameters belonging to two interfaces: IA1 and IA2. Each interface proxy implements
IRpcProxyBuffer for internal communication between the aggregate pieces. When the proxy is
ready to pass its marshaled parameters across the process boundary, it calls methods in the
IRpcChannelBuffer interface, which is implemented by the channel. The channel in turn forwards
the call to the RPC run-time library so that it can reach its destination in the object.
.in
be
tu
se
Stub
.c
w
The stub, like the proxy, is made up of one or more interface pieces and a manager. Each interface
stub provides code to unmarshal the parameters and code that calls one of the object's supported
w
interfaces. Each stub also provides an interface for internal communication. The stub manager
keeps track of the available interface stubs.
w
There are, however, the following differences between the stub and the proxy:
 The most important difference is that the stub represents the client in the object's address
space.
 The stub is not implemented as an aggregate object because there is no requirement that
the client be viewed as a single unit; each piece in the stub is a separate component.
 The interface stubs are private rather than public.
 The interface stubs implement IRpcStubBuffer, not IRpcProxyBuffer.
8
www.csetube.in
www.csetube.in
 Instead of packaging parameters to be marshaled, the stub unpackages them after they
have been marshaled and then packages the reply.
Structure of the Stub
The following diagram shows the structure of the stub. Each interface stub is connected to an
interface on the object. The channel dispatches incoming messages to the appropriate interface stub.
All the components talk to the channel through IRpcChannelBuffer, the interface that provides
access to the RPC run-time library
.in
be
tu
Marshalling
se
COM handles all of the details described in this section for you. This section is provided for
those few programmers who need these details and for those interested in the underlying
.c
information. Marshaling is the process of packaging and unpackaging parameters so a remote

procedure call can take place.
w
Different parameter types are marshaled in different ways. For example, marshaling an
w
integer parameter involves simply copying the value into the message buffer. (Although even in
this simple case, there are issues such as byte ordering to deal with in cross-machine calls.)
w
Marshaling an array, however, is a more complex process. Array members are copied in a specific
order so that the other side can reconstruct the array exactly. When a pointer is marshaled, the data
that the pointer is pointing to is copied following rules and conventions for dealing with nested
pointers in structures. Unique functions exist to handle the marshaling of each parameter type.
With standard marshaling, the proxies and stubs are systemwide resources for the interface and
they interact with the channel through a standard protocol. Standard marshaling can be used both
by standard COM-defined interfaces and by custom interfaces, as follows:
9
www.csetube.in
www.csetube.in
 In the case of most COM interfaces, the proxies and stubs for standard marshaling are
in-process component objects which are loaded from a systemwide DLL provided by
COM in ole32.dll.
 In the case of custom interfaces, the proxies and stubs for standard marshaling are
generated by the interface designer, typically with MIDL. These proxies and stubs are
statically configured in the registry, so any potential client can use the custom interface
across process boundaries. These proxies and stubs are loaded from a DLL that is
located via the system registry, using the interface ID (IID) for the custom interface
they marshal.
 An alternative to using MIDL to generate proxies and stubs for custom interfaces, a
type library can be generated instead and the system provided, type-library–driven
.in
marshaling engine will marshal the interface.
As an alternative to standard marshaling, an interface (standard or custom) can use custom
be
marshaling. With custom marshaling, an object dynamically implements the proxies at run time for
each interface that it supports. For any given interface, the object can select COM-provided
standard marshaling or custom marshaling. This choice is made by the object on an interface-by-
tu
interface basis. Once the choice is made for a given interface, it remains in effect during the object's
lifetime. However, one interface on an object can use custom marshaling while another uses
se
standard marshaling.
Custom marshaling is inherently unique to the object that implements it. It uses proxies
implemented by the object and provided to the system on request at run time. Objects that
.c
implement custom marshaling must implement the IMarshal interface, whereas objects that support
standard marshaling do not.
w
If you decide to write a custom interface, you must provide marshaling support for it. Typically,
w
you will provide a standard marshaling DLL for the interface you design. You can use the tools
contained in the Platform SDK CD to create the proxy/stub code and the proxy/stub DLL.
w
Alternatively, you can use these tools to create a type library which COM will use to do data-driven
marshaling (using the data in the type library).
For a client to make a call to an interface method in an object in another process involves the
cooperation of several components. The standard proxy is a piece of interface-specific code that
resides in the client's process space and prepares the interface parameters for transmittal. It
packages, or marshals, them in such a way that they can be re-created and understood in the
receiving process. The standard stub, also a piece of interface-specific code, resides in the server's
process space and reverses the work of the proxy. The stub unpackages, or unmarshals, the sent
10
www.csetube.in
www.csetube.in
parameters and forwards them to the object application. It also packages reply information to send
back to the client.
Components of Interprocess communications
The following diagram shows the flow of communication between the components
involved. On the client side of the process boundary, the client's method call goes through the
proxy and then onto the channel, which is part of the COM library. The channel sends the buffer
containing the marshaled parameters to the RPC run-time library, which transmits it across the
process boundary. The RPC run time and the COM libraries exist on both sides of the process. The
distinction between the channel and the RPC run time is a characteristic of this implementation and
is not part of the programming model or the conceptual model for COM client/server objects. COM
.in
servers see only the proxy or stub and, indirectly, the channel. Future implementations may use
different layers below the channel or no layers.
be
tu
se
.c
w
w
w
Interface Pointers
An instance of an interface implementation is actually a pointer to an array of pointers to

methods—that is, a function table that refers to an implementation of all of the methods specified in
the interface. Objects with multiple interfaces can provide pointers to more than one function table.
Any code that has a pointer through which it can access the array can call the methods in that
interface.
11
www.csetube.in
www.csetube.in
Speaking precisely about this multiple indirection is inconvenient, so instead, the pointer to the
interface function table that another object must have to call its methods is called simply an
interface pointer. You can manually create function tables in a C application or almost
automatically by using Visual C++ (or other object-oriented languages that support COM).
With appropriate compiler support (which is inherent in C and C++), a client can call an interface
method through its name, not its position in the array. Because an interface is a type, the compiler,
given the names of methods, can check the types of parameters and return values of each interface
method call. In contrast, if a client uses a position-based calling scheme, such type-checking is not
available, even in C or C++.
Each interface—the immutable contract of a functional group of methods—is referred to at run

time with a globally unique interface identifier (IID). This IID, which is a specific instance of a
.in
globally unique identifier (GUID) supported by COM, allows a client to ask an object precisely
whether it supports the semantics of the interface, without unnecessary overhead and without the
be
confusion that could arise in a system from having multiple versions of the same interface with the
same name.
To summarize, it is important to understand what a COM interface is, and is not:

tu
 A COM interface is not the same as a C++ class—The pure virtual definition carries no
implementation. If you are a C++ programmer, you can define your implementation of an
se
interface as a class, but this falls under the heading of implementation details, which COM
does not specify. An instance of an object that implements an interface must be created for
.c
the interface actually to exist. Furthermore, different object classes may implement an
interface differently yet be used interchangeably in binary form, as long as the behavior
w
conforms to the interface definition.

 A COM interface is not an object—It is simply a related group of functions and is the
w
binary standard through which clients and objects communicate. As long as it can provide
pointers to interface methods, the object can be implemented in any language with any
w
internal state representation.

 COM interfaces are strongly typed—Every interface has its own interface identifier (a
GUID), which eliminates the possibility of duplication that could occur with any other
naming scheme.
 COM interfaces are immutable—You cannot define a new version of an old interface
and give it the same identifier. Adding or removing methods of an interface or changing
semantics creates a new interface, not a new version of an old interface. Therefore, a new
interface cannot conflict with an old interface. However, objects can support multiple
interfaces simultaneously and can expose interfaces that are successive revisions of an
12
www.csetube.in
www.csetube.in
interface, with different identifiers. Thus, each interface is a separate contract, and
systemwide objects need not be concerned about whether the version of the interface they
are calling is the one they expect. The interface ID (IID) defines the interface contract
explicitly and uniquely.
Object Creation and Destruction
Because exceptions are excluded from the kernel’s restricted form of C++, you cannot
implement “normal” C++ constructors and destructors without jeopardy. Constructors and
destructors are typed to return no value (such as an error code). Normally, if they encounter a
problem, they raise an exception. But because exceptions aren’t supported in the kernel’s C++
.in
runtime, there is no way for you to know when an allocation or deallocation error has occurred.
This situation prompted a design feature of the libkern’s C++ runtime system that uses
be
OSMetaClass macros to specify the structure of a class—that is, the metaclass data structures and
functional interfaces—for the runtime typing system. The macros also define the primary
constructor and a destructor for a class. These macro-created constructors are guaranteed not to fail
tu
because they do not themselves perform any allocations. Instead, the runtime system defers the
actual allocation of objects until their initialization (usually in the init member function). Because
se
the init function is typed to return a bool, it makes it possible to return an error upon any failure.
Comparison of COM and CORBA

.c
Distributed object computing extends an object-oriented programming system by allowing

w
objects to be distributed across a heterogeneous network, so that each of these distributed object
components interoperate as a unified whole. These objects may be distributed on different
w
computers throughout a network, living within their own address space outside of an application,
w
and yet appear as though they were local to an application.
Three of the most popular distributed object paradigms are Microsoft's Distributed
Component Object Model (DCOM), OMG's Common Object Request Broker Architecture
(CORBA) and JavaSoft's Java/Remote Method Invocation (Java/RMI). In this article, let us
examine the differences between these three models from a programmer's standpoint and an
architectural standpoint. At the end of this article, you will be able to better appreciate the merits
and innards of each of the distributed object paradigms.
13
www.csetube.in
www.csetube.in
CORBA relies on a protocol called the Internet Inter-ORB Protocol (IIOP) for remoting
objects. Everything in the CORBA architecture depends on an Object Request Broker (ORB).
The ORB acts as a central Object Bus over which each CORBA object interacts transparently with
other CORBA objects located either locally or remotely. Each CORBA server object has an
interface and exposes a set of methods. To request a service, a CORBA client acquires an object
reference to a CORBA server object. The client can now make method calls on the object reference
as if the CORBA server object resided in the client's address space. The ORB is responsible for
finding a CORBA object's implementation, preparing it to receive requests, communicate requests
to it and carry the reply back to the client. A CORBA object interacts with the ORB either through
the ORB interface or through an Object Adapter - either a Basic Object Adapter (BOA) or a
Portable Object Adapter (POA). Since CORBA is just a specification, it can be used on diverse
.in
operating system platforms from mainframes to UNIX boxes to Windows machines to handheld
devices as long as there is an ORB implementation for that platform. Major ORB vendors like
be
Inprise have CORBA ORB implementations through their VisiBroker product for Windows,
UNIX and mainframe platforms and Iona through their Orbix product.
tu
DCOM which is often called 'COM on the wire', supports remoting objects by running on a
protocol called the Object Remote Procedure Call (ORPC). This ORPC layer is built on top of
se
DCE's RPC and interacts with COM's run-time services. A DCOM server is a body of code that is
capable of serving up objects of a particular type at runtime. Each DCOM server object can support
multiple interfaces each representing a different behavior of the object. A DCOM client calls into
.c
the exposed methods of a DCOM server by acquiring a pointer to one of the server object's
interfaces. The client object then starts calling the server object's exposed methods through the
w
acquired interface pointer as if the server object resided in the client's address space. As specified
w
by COM, a server object's memory layout conforms to the C++ vtable layout. Since the COM
specification is at the binary level it allows DCOM server components to be written in diverse
w
programming languages like C++, Java, Object Pascal (Delphi), Visual Basic and even COBOL.
As long as a platform supports COM services, DCOM can be used on that platform. DCOM is now
heavily used on the Windows platform. Companies like Software AG provide COM service
implementations through their EntireX product for UNIX, Linux and mainframe platforms; Digital
for the Open VMS platform and Microsoft for Windows and Solaris platforms.
Java/RMI relies on a protocol called the Java Remote Method Protocol (JRMP). Java relies
heavily on Java Object Serialization, which allows objects to be marshaled (or transmitted) as a
stream. Since Java Object Serialization is specific to Java, both the Java/RMI server object and the
client object have to be written in Java. Each Java/RMI Server object defines an interface which
14
www.csetube.in
www.csetube.in
can be used to access the server object outside of the current Java Virtual Machine(JVM) and on
another machine's JVM. The interface exposes a set of methods which are indicative of the services
offered by the server object. For a client to locate a server object for the first time, RMI depends on
a naming mechanism called an RMIRegistry that runs on the Server machine and holds
information about available Server Objects. A Java/RMI client acquires an object reference to a
Java/RMI server object by doing a lookup for a Server Object reference and invokes methods on
the Server Object as if the Java/RMI server object resided in the client's address space. Java/RMI
server objects are named using URLs and for a client to acquire a server object reference, it should
specify the URL of the server object as you would with the URL to a HTML page. Since Java/RMI
relies on Java, it can be used on diverse operating system platforms from mainframes to UNIX
boxes to Windows machines to handheld devices as long as there is a Java Virtual Machine (JVM)
.in
implementation for that platform. In addition to Javasoft and Microsoft, a lot of other companies
have announced Java Virtual Machine ports
Introduction to .NET
What is .NET ? be
tu
Since quite some time each person is talking about .NET, but what actually is .NET ? In this Article
se
i will explain you the meaning and the advantages of .NET.

.c
The .NET Framework introduces a completely new model for the programming and deployment of
applications. .NET is Microsoft's vision of "software as a service", a development environment in
w
which you can build, create, and deploy your applications and the next generation of components,
the ability to use the Web rather than your own computer for various services.
w
w
Microsoft introduced great technologies like COM, DCOM, COM+ etc. to enable reuse of
Software. Although these technologies are very powerful to reuse Software, they required a huge
learning curve. According to this aspect, Microsoft realized that its time to come up with a new
Technology, a better one, an easier one, a new Framework, within which each Programming Task
is easy accomplished.
The .NET Framework was born:
Microsoft changed all complex tasks with the new .NET Framework. That was a huge advantage
for all developers. Most of the Win32 API was now accessible through a very simple Object
15
www.csetube.in
www.csetube.in
Model. Most of the features and functions of C++ were added to Visual Basic. A new Programming
Language C# was introduced, which offered flexibility and productivity. ASP.NET also called
ASP+ replaced ASP.
It provides the easiest and most scalable way to build, deploy and run web services. ASP.NET
server controls enable an HTML-like style of declarative programming that let you build great
pages with far less code than with classic ASP. VB, C++ and C# Code can be used in other
languages f.e. code written in VB can be easily used in C# or in VC++. Also an another benefit is
that the you can step between the languages in the debugger.
The .NET Compilation Stages:
.in
The Code written in .NET isn't compiled directly to the executable, instead .NET uses two steps
be
to compile the code. First, the code is compiled to an Intermediate Language called
Microsoft Intermediate Language (MSIL). Second, the compiled code will be recompiled with the
Common Language Runtime ( CLR ), which converts the code to the machine code. The basic Idea
tu
of this two stages was to make the code language independence.
se
The major Components ( Layers ) of the .NET framework:

.c
The top layer includes user and program interfaces. Windows Forms are a new way to create
standard Win32 desktop applications, based on the Windows Foundation Classes (WFC) produced
w
for J++.
w
Web Forms provide a powerful, forms-based UI for the web. Web Services, which are perhaps the
most revolutionary, provide a mechanism for programs to communicate over the Internet using
w
SOAP. Web Services provide an analog of COM and DCOM for object brokering and interfacing,
but based on Internet technologies so that allowance is made for integration even with non-
Microsoft platforms.
Web Forms and Web Services, comprise the Internet interface portion of .NET, and are
implemented through a section of the .NET Framework referred to as ASP.NET. The middle layer
includes the next generation of standard system services such as ADO.NET and XML. These
services are brought under the control of the framework, making them universally available and
standardizing their usage across languages.
16
www.csetube.in
www.csetube.in
The last layer includes system-level capability that a developer would need.
Overview of .Net Architecture
It seems the Redmond giant believes that the holy grail of Internet development has been found,
and its name is ".NET Framework."
As Microsoft explains in its FAQ, the .NET Framework is an "environment for building, deploying
and running Web services and other applications. It consists of three main parts: the Common
Language Runtime, the Framework classes, and ASP.NET."
.in
But I, a mere programmer, view things a little more simply: The .NET Framework is basically just
a single platform that anybody can develop for, using a system similar to Java/JVM. Only unlike
Java/JVM, there's no language barrier with .NET: The languages available to the developer upon
be
installation of the SDK (software development kit) are Managed C++, C#, Visual Basic and
JScript; even more are on the way.
tu
That said, like Java/JVM, .NET comes with its own set of pros and cons, something every
developer needs to consider when it comes to choosing one platform over another:
se
.NET Pros
.c
 It offers multiple language support.

 It has a rich set of libraries, a la JVM.
It's open-standard friendly (e.g., HTTP and XML) -- it may even become a standard itself.
w

 Its code is compiled natively, regardless of language or deployment (Web or desktop).
w
.NET Cons
 It's yet another platform to consider, which generally means rewriting and learning new
w
tricks.
 Microsoft tends to have good ideas, but mediocre implementation.
 Currently, it's only available on Windows.
 Microsoft claims C#, IL, and CLR/CLS will be submitted to ECMA, but there's still no
clear view on what will be standardized from the platform.
.NET Marshalling
Thus .NET runtime automatically generates code to translate calls between managed code and
unmanaged code. While transferring calls between these two codes, .NET handles the data type
conversion also. This technique of automatically binding with the server data type to the client data
type is known as marshalling. Marshaling occurs between managed heap and unmanaged heap. For
17
www.csetube.in
www.csetube.in
example, Fig.4 shows a call from the .NET client to a COM component. This sample call passes a
.NET string from the client. The RCW converts this .NET data type into the COM compatible data
type. In this case COM compatible data type is BSTR. Thus the RCW converts the .NET string into
COM compatible BSTR. This BSTR will be passed to the object and the required calls will be
made. The results will be returned to back to the RCW. The RCW converts this COM compatible
result to .NET native data type.
.in
be
tu
Fig. Sample diagram for marshalling
se
Logically the marshalling can be classified into 2 types.
1. Interop marshalling
2. COM marshalling
.c
If a call occurs between managed code and unmanaged code with in the same apartment, Interop
w
marshaller will play the role. It marshals data between managed code and unmanaged code.
w
In some scenarios COM component may be running in different apartment threads. In those cases
i.e., calling between managed code and unmanaged code in different apartments or process, both
w
Interop marshaler and COM marshaler are involved.
Interop marshaler
When the server object is created in the same apartment of client, all data marshaling is handled by
Interop marshaling.
18
www.csetube.in
www.csetube.in
Fig. Sample diagram for same apartment marshalling
COM marshaler
COM marshaling involved whenever the calls between managed code and unmanaged code are in
.in
different apartments. For eg., when a .NET client (with the default apartment settings)
communicates with a COM component (whichever developed in VB6.0), the communication
be
occurs through proxy and stub because both the objects will be running in different apartment
threads. (The default apartment settings of .NET objects are STA and the components which are
developed by VB6.0 are STA). Between these two different apartments COM marshaling will
tu
occurs and with in the apartment Interop marshaling will occurs. Fig.6 shows this kind of
marshaling.
se
This kind of different apartment communication will impact the performance. The apartment
settings of the managed client can be changed by changing the STAThreadAttribute /
.c
MTAThreadAttribute / Thread.ApartmentState property. Both the codes can run in a same

apartment, by making the managed code’s thread to STA. (If the COM component is set as MTA,
w
then cross marshaling will occurs.)

w
w
Fig Sample diagram for cross apartment marshalling
In the above scenario, the call with in different apartments will occur by COM marshaling and the
call between managed and unmanaged code will occur by Interop marshaling.
19
www.csetube.in
www.csetube.in
Remoting in .Net
Introduction:
Distributed computing is an integral part of almost every software development. Before .Net
Remoting, DCOM was the most used method of developing distributed application on Microsoft
platform. Because of object oriented architecture, .NET Remoting replaces DCOM as .Net
framework replaces COM.
Benefits of Distributed Application Development:
.in
Fault Tolerance: Fault tolerance means that a system should be resilient when failures within the
system occur.
be
Scalability: Scalability is the ability of a system to handle increased load with only an incremental
change in performance.
tu
Administration: Managing the system from one place.
se
In brief, .NET remoting is an architecture which enables communication between different
application domains or processes using different transportation protocols, serialization formats,
object lifetime schemes, and modes of object creation. Remote means any object which executes
outside the application domain. The two processes can exist on the same computer or on two
.c
computers connected by a LAN or the Internet. This is called marshalling (This is the process of
passing parameters from one context to another.), and there are two basic ways to marshal an
object:
w
Marshal by value: the server creates a copy of the object passes the copy to the client.
w
Marshal by reference: the client creates a proxy for the object and then uses the proxy to access the
object.
w
20
www.csetube.in
www.csetube.in
Comparison between .NET Remoting and Web services:
.in
For performance comparison between .Net Remoting and ASP.Net Web Services
Architecture:
be
Remote objects are accessed thro channels. Channels are Transport protocols for passing the
messages between Remote objects. A channel is an object that makes communication between a
client and a remote object, across app domain boundaries. The .NET Framework implements two
default channel classes, as follows:
tu
HttpChannel: Implements a channel that uses the HTTP protocol.
TcpChannel: Implements a channel that uses the TCP protocol (Transmission Control Protocol).
se
Channel take stream of data and creates package for a transport protocol and sends to other
machine. A simple architecture of .NET remoting is as in Fig 1.
.c
w
w
w
As Fig.1 shows, Remoting system creates a proxy for the server object and a reference to the proxy
will be returned to the client. When client calls a method, Remoting system sends request thro the
channel to the server. Then client receives the response sent by the server process thro the proxy.
21
www.csetube.in
www.csetube.in
Example:
Let us see a simple example which demonstrates .Net Remoting. In This example the Remoting
object will send us the maximum of the two integer numbers sent.
Creating Remote Server and the Service classes on Machine 1:

Please note for Remoting support your service (Remote object) should be derived from
MarshalByRefObject.
////////////////////////////////////////////////////////////////////////////////////////////////////////////
using System;
using System.Runtime.Remoting.Channels; //To support and handle Channel and channel sinks
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels.Http; //For HTTP channel
using System.IO;
.in
namespace ServerApp
{
be
public class RemotingServer
{
public RemotingServer()
{
tu
//
// TODO: Add constructor logic here
//
se
}
}
//Service class
.c
public class Service: MarshalByRefObject

{
public void WriteMessage (int num1,int num2)
w
{
Console.WriteLine (Math.Max(num1,num2));
}
w
}
//Server Class
w
public class Server

{
public static void Main ()
{
HttpChannel channel = new HttpChannel(8001); //Create a new channel
ChannelServices.RegisterChannel (channel); //Register channel
RemotingConfiguration.RegisterWellKnownServiceType(typeof(Service),"Service",WellKnownO
bjectMode.Singleton);
Console.WriteLine ("Server ON at port number:8001");
Console.WriteLine ("Please press enter to stop the server.");
Console.ReadLine ();
}
}
22
www.csetube.in
www.csetube.in
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
Save the above file as ServerApp.cs. Create an executable by using Visual Studio.Net command
prompt by,
csc /r:system.runtime.remoting.dll /r:system.dll ServerApp.cs
A ServerApp.Exe will be generated in the Class folder.
Run the ServerApp.Exe will give below message on the console
Server ON at port number:8001
Please press enter to stop the server.
.in
In order to check whether the HTTP channel is binded to the port, type
http://localhost:8001/Service?WSDL in the browser.
You should see a XML file describing the Service class.
be
Please note before running above URL on the browser your server (ServerApp.Exe should be
running) should be ON.
tu
Creating Proxy and the Client application on Machine 2
SoapSuds.exe is a utility which can be used for creating a proxy dll.

se
Type below command on Visual studio.Net command prompt.

.c
soapsuds -url:http://< Machine Name where service is running>:8001/Service?WSDL -

oa:Server.dll
w
This will generates a proxy dll by name Server.dll. This will be used to access remote object.
w
Client Code:
w
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
using System;
using System.Runtime.Remoting.Channels; //To support and handle Channel and channel sinks
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels.Http; //For HTTP channel
using System.IO;
using ServerApp;
namespace RemotingApp
{
public class ClientApp

{
public ClientApp()
23
www.csetube.in
www.csetube.in
public static void Main (string[] args)

{
HttpChannel channel = new HttpChannel (8002); //Create a new channel
ChannelServices.RegisterChannel (channel); //Register the channel
//Create Service class object
Service svc = (Service) Activator.GetObject (typeof (Service),"http://<Machine name where
Service running>:8001/Service"); //Localhost can be replaced by
//Pass Message
svc.WriteMessage (10,20);
}
}
}
.in
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
Save the above file as ClientApp.cs. Create an executable by using Visual Studio.Net command
prompt by,
csc /r:system.runtime.remoting.dll /r:system.dll ClientrApp.cs
be
A ClientApp.Exe will be generated in the Class folder. Run ClientApp.Exe , we can see the result
tu
on Running ServerApp.EXE command prompt.
In the same way we can implement it for TCP channel also.
se
.c
w
w
w
24
www.csetube.in

IT1402 MWT Notes - CSE TUBE PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IT1402 MWT Notes - CSE TUBE PDF

Uploaded by

Copyright:

Available Formats

www.csetube.

The Client Server Architecture

A network architecture in which each computer or process on the network is either a

Another type of network architecture is known as a peer-to-peer architecture because

Two Tier Architecture

workstations, the server systems do not need to be as large. The hardware-independent

complex, in terms of business algorithms processed, number of databases accessed, or

Three Tier Architecture

In telecommunication, the term file server has the following meanings:

 A computer program, that allows different programs, running on other computers, to

File and Print

A database server is a computer program that provides database services to other

A computer, including software package, that provides a specific kind of service to

With an object server the client/server application is written as a set of

Fat Client Fat Server

programs. A common application of middleware is to allow programs written for access to a

Typically, middleware programs provide messaging services so that different

through the use of middleware, is known as enterprise application integration.

While the immediate need of middleware support for Service-Oriented Architectures

service management and monitoring.

Moreover, non-functional properties (like dependability and security) and Quality of

Middleware is connectivity software that consists of a set of enabling services that

Request Broker Architecture (CORBA), and Microsoft's COM/DCOM (see Component

Figure: Use of Middleware

Middleware services provide a more functional set of Application Programming

 be reliable and available

Middleware can take on the following different forms:

It includes communication stacks, distributed directories, authentication services,

CLIENT/SERVER BUILDING BLOCKS

Client Middleware Server machine

most of the business services on the same machine.

2. Client/server for small shops and departments

Client Middleware Server

A classic Ethernet client/single-server building block implementation. It is used in small

3. Client/server for intergalactic enterprises

Client Server Middleware

It transforms every machine to both client and server.

REMOTE PROCEDURE CALL

RPC is a powerful technique for constructing distributed, client-server based

continues. RPC specifically supports network applications.

A remote procedure is uniquely identified by the triple: (program number, version

versions of an RPC protocol to be available simultaneously. Each version contains a a

Fig. Remote Procedure Calling Mechanism

On the Internet, peer-to-peer (referred to as P2P) is a type of transient Internet

servers that inform peers of the network addresses of other peers.

Peer-to-peer architecture is a type of network in which each workstation has

which files they wish to share or password protect.

Types of P2P Networks

Peer-to-peer networks come in three flavors. The category classification is based on

Also referred to as distributed computing, it combines the idle or unused CPU

Examples of distributed computing can be found at GRID.ORG where United

software applications, such as MSN Messenger or AOL Instant Messenger, for

standard communications tool for business.

Operation of peer-to-peer networks

 Peers act as equals, merging the roles of clients and server

Unstructured and structured P2P networks

Structured P2P networks overcome the limitations of unstructured networks by

Some well known structured P2P networks are:

How Peer-to-peer File-sharing Clients Work

P2P Security Concerns

Advantages of peer-to-peer networks

The distributed nature of peer-to-peer networks also increases robustness in case of

Select a Target Server from among Available Servers.