Middleware Notes 1,2

MIDDLEWARE
TECHNOLOGIES
i
Anna University of Technology Trichy
Middleware Technologies
SYLLABUS
UNIT I CLIENT / SERVER CONCEPTS 9
Client server – File server – Database server – Group server – Object server – Web server
– Middleware – General Middleware – Service specific middleware – Client / server
building blocks – RPC – Messaging – Peer-to-peer.
UNIT II EJB ARCHITECTURE 9
EJB – EJB architecture – Overview of EJB software architecture – View of EJB

–
Conversation – Building and deploying EJB – Roles in
EJB.
UNIT III EJB APPLICATIONS 9
EJB session beans – EJB entity beans – EJB clients – EJB deployment – Building an
application with EJB.
UNIT IV CORBA 9
CORBA – Distributed systems – Purpose – Exploring CORBA alternatives – Architecture

overview – CORBA and networking model – CORBA object model – IDL – ORB –
Building an application with CORBA.
UNIT V COM 9
COM – Data types – Interfaces – Proxy and stub – Marshalling – Implementing server /
client – Interface pointers – Object creation – Invocation – Destruction – Comparison
COM and CORBA – Introduction to .NET – Overview of .NET architecture –
Marshalling – Remoting.
ii
LIST OF ABBREVIATION IN MIDDLEWARE TECHNOLOGY
RMI - Remote Method Invocation

RPC -Remote Procedure Call
JRMP - Java Remote Method Protocol
CORBA -Common Object Request Broker
ORB - Object Request Broker Architecture
NETBIOS - Network Basic Input/Output System
NETBEUI - NETBIOS Extended User Interface
IPX - Internetwork Packet Exchange
SPX - Sequenced Packet Exchange
RMI -IIOP - Remote Method Invocation Internet InterORB Protocol
IIOP - Internet InterORB Protocol
DSI - Dynamic Skeleton Interface
DII - Dynamic Invocation Interface
SSI - Static Skeleton Interface
SII - Static Invocation Interface
IDL -Interface Definition Language
IDLJ - Interface Definition Language to Java
CCM -CORBA Component Module
CLS -Common Language Specification
EJB -Enterprise Java Beans
J2EE -Java 2 Enterprise Edition
J2SE - Java 2 Standard Edition
iii
J2ME -Java 2 Micro Edition
SOAP -Simple Object Access Protocol
SOM -System Object model
JVM -Java Virtual Machine
JMS -Java Message Service
OMA -Object Management Architecture
OMG - Object Management Group
DLL -Dynamic Linked Library
OMG IDÌ -Object Management Group Interface Definition Language
SMTP - Simple Mail Transfer Protocol
CDMA -Code Division Multiple Access
WORA - Write Once Read Anywhere
JNDI - Java Naming Directory Interface
UTF - Universal Text Format
OWL - Web Ontology Language
JIT - Just In time
CLR - Common Language Runtime
MSIL - Microsoft Intermediate Language
WSDL - Web Service Description Language
SET - Service Endpoint Interface
JAX RPC - Java XML RPC
XML - Extended Markup Language
RPC - Remote Procedure Call
XSD - XML Schema Definition
SOAP - Simple Object Access Protocol
iv
RDF - Resource Description Framework
IIS - Internet Information Server
JMS - Java Message Service
JSP - Java Server Page
ASP - Active Serve page
VTBL - Virtual Table Pointer
COM - Component Object model
DCOM - Distributed Component Object Model
OLE - Object Linking & Embedding
v
UNIT I CLIENT / SERVER CONCEPTS 1.11 – 1.32
1.1 INTRODUCTION 1.1

1.2 CLIENT–SERVER MODEL
1.2.1 Advantage of Client/Server Model 1.3
1.2.2 Disadvantages of Client/Server Model 1.3
1.2.3 Characteristics of Client/Server Model 1.4
1.3 TYPES OF SERVERS

1.3.1 File Servers 1.5
1.3.2 Database Server 1.5
1. 3.3 Transaction Servers 1.6
1.3.4 Groupware Servers 1.7
1.3.5 Object Application Servers 1.7
1.3.6 Web Servers 1.8
1.4 MIDDLEWARE DEFINITION 1.17

1.4.1 General Middleware 1.17
1.4.2 Service-Specific Middleware 1.18
1.5 CLIENT SERVER BUILDING BLOCKS

1.5.1 Client/Server : A one size fit s all model 1.18
1.5.2 Client/Server for Tiny Shops and Nomadic Tribes 1.19
1.5.3 Client/Server for small shops and departments 1.20
1.5.4 Client/Server for Intergalactic Enterprises 1.20
1.5.5 Client/Server for a Post-Scarcity World 1.21
1.5.6 Intergalact ic Client/Server 1.22
1.6 INSIDE THE BUILDING BLOCKS 1.23

1.6.1 The Client Building Block 1.23
1.6.2 The Server Building Block 1.23
1.6.3 The Middleware Building Block 1.24
1.6.4 DSM – Distributed System Management 1.24
1.6.5 Server-to-server Middleware 1.24
vi
1.7 RPC – MESSAGING – PEER-TO-PEER 1.25
1.7.1 Peer – to – Peer Communicat ions 1.26
1.7.2 Sockets 1.27
1.7.3 Datagrams Vs Sessio ns 1.39
1.8 MESSAGING AND QUEUING : THE MOM MIDDLEWARE 1.32
UNIT II EJB ARCHITECTURE 2.1 – 2.23
2. ENTERPRISE JAVA BEAN
2. 1 EJB LOGICAL ARCHITECTURE 2.1
2.2 OVERVIEW OF EJB’S SOFTWARE ARCHITECTURE
2.2.1 EJB Servers 2.3

2.2.2 EJB Containers 2.4
2.3 ENTERPRISE BEANS
2.3.1 Sessio n Beans 2.11

2.3.2 Entit y Beans 2.17
2.4 A HIGH LEVEL VIEW OF AN EJB CONVERSATION 2.19
2.4.1 Finding the bean 2.20

2.4.2 Getting access to a bean 2.21
2.4.3 Calling the bean‘s methods 2.21
2.4.4 Getting rid of the bean 2.21
2.5 EJB CLINET 2.21
2.5.1 RMI client 2.21

2.5.2 CORBA clients 2.22
2.6 BUILDING AND DEPLOYING EJBS 2.22
2.6.1 Writing the EJB 2.22

2.6.2 Roles in EJB 2.24
vii
UNIT III EJB APPLICATIONS 3.1 – 3.34
3. ENTERPRISE JAVA BEAN 3.1
3.1 SESSION BEAN 3.2
3.1. 1 The Life Cycle of a Stateful Session Bean 3.4

3.1.2 The Life Cycle of a Stateless Session Bean 3.5
3.2 WHAT IS AN ENTITY BEAN 3.5
3.2.1 The Life Cycle of an Entity Bean 3.9
3.3 TRANSACTION AND EJB 3.12
3.3.1 Container-Managed Transactions 3.13

3.3.2 Bean-Managed Transactions 3.19
3.4 WHAT IS A MESSAGE-DRIVEN BEAN? 3.25
3.4.1 The Life Cycle of a Message-Driven Bean 3.26
3.5 EJB CLIENT 3.27
3.5.1 Defining Client Access with Interfaces 3.27
3.6 DEPLOYMENT DESCRIPTORS 3.31
3.7 BUILDING AN APPLICATION WITH EJB 3.33

3.7.1 Deploying the J2EE Application 3.42
UNIT IV CORBA 4.1 – 4.41
4.1 HISTORY OF DISTRIBUTED SYSTEMS 4.1

4.1.1 The Beginning: Monolithic Systems and Mainframes 4.1
4.1.2 Why CORBA? 4.1
4.2 EXPLORING CORBA ALTERNATIVES 4.2
viii
4.2.1 Socket Programming 4.2
4.2.2 Remote Procedure Call (RPC) 4.3
4.2.3 OSF Distributed Computing Environment (DCE) 4.3
4.2.4 Microsoft Distributed Component Object Model (DCOM) 4.3
4.2.5 Java Remote Method Invocation (RMI) 4.4
4.2.6 Introducing the Object Management Group (OMG) 4.4
4.3 CORBA 1.0 4.4

4.3.1 CORBA 2.0 and IIOP 4.4
4.3.2 CORBA Architecture Overview 4.5
4.3.3 The Object Request Broker (ORB) 4.6
4.3.4 Interface Definition Language (IDL) 4.6
4.4 The CORBA Communications Model 4.6

4.4.1 Inter-ORB Protocols 4.6
4.4.2 CORBA Clients and Servers 4.7
4.4.3 Stubs and Skeletons 4.7
4.4.4 The Object Request Broker (ORB) 4.8
4.5 MARSHALING 4.9

4.5.1 Platform Independence 4.10
4.5.2 Interface Definition Language (IDL) 4.10
4.5.3 Language Independence 4.10
4.6 CORBA and the Networking Model 4.11

4.7 The CORBA Object Model 4.12
4.7.1 Object Distribution 4.13
4.7.2 Object References 4.13
4.7.3 Basic Object Adapters (BOAs) 4.16
4.7.4 Server Activation Policies 4.16
4.7.5 Stubs and Skeletons 4.16
4.8 MASTERING THE INTERFACE DEFINITION LANGUAGE `4.17

4.8.1 IDL Overview 4.17
4.8.2 IDL Ground Rules 4.17
4.8.3 Case Sensitivity 4.18
4.8.4 IDL Definition Syntax 4.18
ix
4.8.5 Use of the C Preprocessor 4.18
4.8.6 The Module 4.18
4.8.7. Primitive Types 4.19
4.8.8 Constructed Types 4.21
4.8.9 Other IDL Constructs 4.28
4.9 BUILDING AN APPLICATION WITH CORBA 4.32

4.10 EXPLORING CORBA SERVICES AND CORBA FACILITIES 4.36
4.10.1 CORBA services 4.37
4.10.2 CORBA facilities 4.41
4.10.3 Enhancing the Bank Example with CORBA services 4.44
4.10.4 Choosing CORBA services 4.44
UNIT V COM 5.1 – 5.29
5.1 COM 5.1

5.1.1 COM: The· Dominant Component Architecture 5.1
5.1.2 The Evolution of Component Technology 5.3
5.1.3 Custom Controls 5.3
5.1.4 Visual Basic Extensions 5.3
5.1.5 OLE 1.0 5.4
5.1.6 OLE 2.0 5.4
5.2 COM DATA TYPES 5.7
5.2.1 COM Data Type Mapping 5.9

5.3 INTERFACES 5.10
5.4 PROXIES, STUBS, AND SKELETONS 5.10
5.5 MARSHALLING 5.11
5.6 IMPLEMENTING SERVER/CLIENT 5.12
5.6.1 Client/Server Beginnings 5.12
5.6.2 2-Tler, 3-Tier, and N-Tier Architecture 5.13
5.7 SIMILARITIES AND DIFFERENCE OF COM AND CORBA 5.16

5.8 INTRODUCTION TO .NET 5.17
5.8.1 .NET Framework 5.17
5.8.2 Design features 5.18
x
5.9 OVERVIEW OF .NET ARCHITECTURE 5.19
5.9.1 Common Language Infrastructure (CLI) 5.19
5.9.2 Assemblies 5.20
5.9.3 Security 5.21
5.9.4 Class library 5.21
5.9.5 Memory management 5.22
5.9.6 Standardization and licensing 5.23
5.9.7 Versions 5.24
5.9.8 Criticism 5.25
5.9.9 Alternative implementations 5.26
5.10 MARSHALLING 5.27
5.10.1 Usage 5.28
5.10.2 Comparison with serialization 5.28
5.11 .NET Framework Remoting Overview 5.28
5.11.1. Operations of Remoting in .Net Framework 5.29
5.11.2 References of Remoting in .Net Framework 5.30
5.11.3 Architecture of Remoting 5.32
5.11.4 Example 5.33
xi
xii
Client/Server Computing 1.1
UNIT I
CLIENT/SERVER COMPUTING
Client – Server – File Server, Data Base Server, Group Server, Object
Server, Web Server Middleware – General Middleware – Service Specific
Middleware Client
– Client Server Building blocks – RPC – Messaging – Peer-to-Peer
1.1 INTRODUCTION
Client/ server computing is an irresistible movement that is reshaping the
way computers are being used. Although the computing movement is relatively
young it is already in full and is not leaving any fact of the computer industry untouched.
In addition, the Internet is like tsunami; it is introducing a new form of client/server
computing- intergalactic client/server. It is revolution within the revolution.
Client-server is a co mputing architecture which separates a client from a server,
and is almost always implemented over a computer network. Each client or server
connected to a network can also be referred to as a node. The most basic type of client-
server architecture employs only two types of nodes: clients and servers. This type of
architecture is somet imes referred to as two-tier. It allows devices to share files and
resources.
Each instance of the client software can send data requests to one or more connected
servers. In turn, the servers can accept these requests, process them, and return the
requested information to the client. Although this concept can be applied for a variety of
reasons to many different kinds of applicat ions, the architecture remains fundamentally the
same.
These days, clients are most often web browsers, although that has not always
been the case. Servers typically include web servers, database servers and mail servers.
Online gaming is usually client-server too. In the specific case of MMORPG, the
servers are typically operated by the company selling the game; for other games one of the
players will act as the host by setting his game in server mode.
The interaction between client and server is often described using sequence
diagrams. Sequence diagrams are standardized in the Unified Modeling Language.
1.2 CLIENT–SERVER MODEL

According to MIS terminology, Client/Server computing is new technology
that yields solutions to many data management problems faced by modern organizations.
The term Client/Server is used to describe a computing model for the
development of
1.2 Client/Server Computing
computerized systems. This model is based on distribution of functions between two types
of independent and autonomous processes: Server and Client. A Client is any process
that requests specific services from the server process. A Server is a process that
provides requested services for the Client. Client and Server processes can reside in same
computer or in different computers linked by a network.
When Client and Server processes reside on two or more independent computers on
a network, the Server can provide services for more than one Client. In addition, a client
can request services from several servers on the network without regard to the location
or the physical characteristics of the computer in which the Server process resides. The
network ties the server and client together, providing the medium through which the clients
and the server communicate. The Fig. 1.1 given below shows a basic Client/Server
computing model.
Figure 1.1 Client/Server Computing

The client–server model of computing is a distributed applicat ion structure that
partitions tasks or workloads between the providers of a resource or service, called
servers, and service requesters, called clients. Often clients and servers communicate over a
computer network on separate hardware, but both client and server may reside in the same
system. A server machine is a host that is running one or more server programs which
share their resources with clients. A client does not share any of its resources, but
requests a server's content or service function. Clients therefore initiate communication
sessions with servers which await incoming requests. The client–server characteristic
describes the relationship of cooperating programs in an application. The server component
provides a function or service to one or many clients, which initiate requests for such
services.
Functions such as email exchange, web access and database access, are built on
the client–server model. Users accessing banking services from their computer use a
web browser client to send a request to a web server at a bank. That program may in turn
forwar d the request to its own database client program that sends a request to a database
server at another bank computer to retrieve the account information. The balance is
returned to the bank database client, which in turn serves it back to the web browser
client displaying the results to the user. The client–server model has become one of the
central ideas of network comput ing. Many business applications being written today use
the client–server model. So do the Internet's main application protocols, such as HTTP,
SMTP, Telnet, and DNS.
The interaction between client and server is often described using sequence
diagrams. Sequence diagrams are standardized in the Unified Modeling Language.
Specific types of clients include web browsers, email clients, and online chat clients.
Specific types of servers include web servers, ftp servers, applicat ion
servers, database servers, name servers, mail servers, file servers, print servers, and
terminal servers. Most web services are also types of servers.
1.2.1 Advantages of Client/Server Model

In most cases, a client–server architecture enables the roles and responsibilities of
a computing system to be distributed among several independent computers that are known
to each other only through a network. This creates an addit ional advantage to this
architecture: greater ease of maintenance. For example, it is possible to replace, repair,
upgrade, or even relocate a server while its clients remain both unaware and unaffected by
that change.
All data is stored on the servers, which generally have far greater security controls
than most clients. Servers can better control access and resources, to guarantee that only
those clients with the appropriate permissions may access and change data.
Since data storage is centralized, updates to that data are far easier to administer
in comparison to a P2P paradigm. In the latter, data updates may need to be distributed
and applied to each peer in the network, which is both time-consuming and error-prone as
there can be thousands or even millions of peers.
Many mature client–server technologies are already available which were designed
to ensure security, friendliness of the user interface, and ease of use. It functions with
multiple different clients of different capabilities.
1.2.2 Disadvantages of Client/Server Model

As the number of simultaneous client requests to a given server increases, the
server can become overloaded. Contrast that to a P2P network, where its aggregated
bandwidth actually increases as nodes are added, since the P2P network's overall
bandwidth can be roughly computed as the sum of the bandwidths of every node in that
network.
The client–server paradigm lacks the robustness of a good P2P network. Under
client–server, should a critical server fail, clients‘ requests cannot be fulfilled. In
P2P networks, resources are usually distributed among many nodes. Even if one or more
nodes depart and abandon a downloading file, for example, the remaining nodes should
still have the data needed to complete the download.
In software engineering, multi-tier architecture (often referred to as n-tier
architecture) is a client –server architecture in which the presentation, the
application
processing, and the data management are logically separate processes. For example,
an application that uses middleware to service data requests between a user and a
database employs multi-tier architecture.
1.2.3 Characteristics of Client/Server Model

All client/server systems have the following distinguishing characteristics.
Service : client/server is primarily a relationship between process running on
separate machine. The server process is a provider of service. The client is a consumer of
service. In essence , client/server provides a clean separation of function based on the idea
of service.
Shared resources : A server can service many clients at the same time and
regulate their access to shared resources.
Asymmetrical protocols : There is a many-to-one relationship between clients and

server. Clients always initiate the dialog by requesting a service. Servers are
passively awaiting for requests from clients.
Mix-and-match: The ideal Client/Server software is independent of hardware and

Operating System software platform. It should be able to mix-and-match client and
server platforms.
Scalability
Two types of scaling
1. Horizontal scaling means adding or removing client workstations with only a
slight performance impact.
2. Vertical scaling means migrating to a larger and faster server machine or
multi servers
Transparency Of Location: The server is a process that can reside on the same
machine as the client or on a different machine across a network. Client/server software
usually masks the location of the server from the clients by redirecting service calls
when needed. This is referred as
Mix and match: The ideal client/server software is independent of hardware or

operating system software platform. We should be able to mix and match client and
server platform.
Message – Based Exchanges: client and server are loosely coupled systems that
interact through a message passing mechanism. The message is the delivery mechanism
for the service requests and replies.
Encapsulation of services: The server is a ―specialist‖. A message tells a server

what service is requested, it is then up to the server to determine how to get the job done.
Servers can be upgraded without affecting the client as long as the published message is not
changed.
Integrity: The server code and server data is centrally managed, which results in
cheaper maintenance and guarding of shared data integrity. At the same time, the clients
remain personal and independent.
ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee that
database transact ions are processed reliably. In the context of databases, a single logical
operation on the data is called a transaction. For example, a transfer of funds from one
bank account to another, even though that might involve multiple changes (such as
debiting one account and crediting another), is a single transaction.
ATOMICITY
Atomicit y requires that each transaction is "all or nothing": if one part of the transaction
fails, the entire transaction fails, and the database state is left unchanged. An atomic
system must guarantee atomicity in each and every situation, including power failures,
errors, and crashes.
CONSISTENCY
The consistency property ensures that any transaction will bring the database from one
valid state to another. Any data written to the database must be valid according to all
defined rules, including but not limited to constraints, cascades, triggers, and any
combination thereof.
ISOLATION
Isolat ion refers to the requirement that no transaction should be able to interfere with
another transaction. One way of achieving this is to ensure that no transactions that affect
the same rows can run concurrently, since their sequence, and hence the outcome,
might be unpredictable. This property of ACID is often partly relaxed due to the huge
speed decrease this type of concurrency management entails.
DURABILITY
Durabilit y means that once a transaction has been committed, it will remain so, even in
the event of power loss, crashes, or errors. In a relational database, for instance, once a
group of SQL statements execute, the results need to be stored permanently. If the
database crashes
immediately thereafter, it should be possible to restore the database to the state after the
last transaction committed.
EXAMPLES
The following examples are used to further explain the ACID properties. In these
examples, the database has two fields, A and B, in two records. An integrity constraint
requires that the value in A and the value in B must sum to 100. The following SQL code
creates a table as described above:
CREATE TABLE acidtest (A INTEGER, B INTEGER CHECK (A + B =

100));
ATOMICITY FAILURE
The transaction subtracts 10 from A and adds 10 to B. This is a valid transaction, since
the data continue to satisfy the constraint after it has executed. However, assume that
after removing 10 from A, the transaction is unable to modify B. If the database retained
A's new value, atomicity and the constraint would both be violated. Atomicity requires that
both parts of this transaction, or neither, be complete.
CONSISTENCY FAILURE
Consistency is a very general term that demands the data meets all validation rules. In
the previous example, the validation is a requirement that A + B = 100. Also, it may be
implied that both A and B must be integers. A valid range for A and B may also be
implied. All validation rules must be checked to ensure consistency.
Assume that a transaction attempts to subtract 10 from A without altering B.

Because consistency is checked after each transaction, it is known that A + B = 100
before the transaction begins. If the transaction remo ves 10 from A successfully,
atomicity will be achieved. However, a validation check will show that A + B = 90.
That is not consistent according to the rules of the database. The entire transaction must
be cancelled and the affected rows rolled back to their pre-transaction state.
In reality, this goes much further than simply A and B, as it implies every single cascade
or trigger chain related to the events in the transaction, and thus every check on all of
the indirectly impacted values as well. If there had been other constraints, triggers or
cascades, every single change operation would have been checked in the same way as the
above before the transaction was committed.
ISOLATION FAILURE
To demonstrate isolation, we assume two transactions execute at the same time,

each attempting to modify the same data. One of the two must wait until the other
completes in order to maintain isolation.
Consider two transactions. T 1 transfers 10 from A to B. T2 transfers 10 from B to

A. Combined, there are four actions:
subtract 10 from A
add 10 to B.
subtract 10 from B
add 10 to A.
If these operations are performed in order, isolation is maintained, although T 2 must

wait. Consider what happens, if T1 fails half-way through. The database eliminates T 1's
effects, and T2 sees only valid data.
By interleaving the transactions, the actual order of actions might be:A-10, B-

10,B+10,A+10. Again consider what happens, if T 1 fails. T1 still subtracts 10 from A.
Now, T2 adds 10 to A restoring it to its initial value. Now T 1 fails. What should A's
value be? T2 has already changed it. Also, T1 never changed B. T2 subtracts 10 from it.
If T2 is allowed to complete, B's value will be 10 too low, and A's value will be
unchanged, leaving an invalid database. This is known as a write-write failure, because
two transactions attempted to write to the same data field.
DURABILITY FAILURE
Assume that a transaction transfers 10 from A to B. It removes 10 from A. It then

adds 10 to B. At this point, a "success" message is sent to the user. However, t he changes
are still queued in the disk buffer waiting to be committed to the disk. Power fails and
the changes are lost. The user assumes (validly) that the changes have been made.
1.3 TYPES OF SERVERS

1.3.1 File Servers
The client passes requests for file records over a network to the file server. This is
a very primitive form of data service that necessitates many message exchanges over
the network to find the requested data. File Servers are useful for sharing files across a
network. These are necessary for creating shared repository of documents, images,
engineering drawings and other large data objects. i.e. shared storage of computer
files (such as documents, sound files, photographs, movies, images, databases, etc.)
File server is a computer attached to a network that has the primary purpose of
providing a location for shared disk access that can be accessed by the workstations that
are attached to the computer network. The term server highlights the role of the machine
in the client–server scheme, where the clients are the workstations using the storage. A file
server is not intended to perform computational tasks, and does not run programs on
behalf of its clients. It is designed primarily to enable the storage and retrieval of
data while the computation is carried out by the workstations.
Network-attached storage (NAS) is file-level computer data storage connected to

a computer network providing data access to heterogeneous clients. NAS not only operates
as a file server, but is specialized for this task either by its hardware, software, or
configuration of those elements. NAS is often made as a co mputer appliance – a
specialized computer built from the ground up for storing and serving files – rather than
simply a general purpose computer being used for the role.NAS systems are networked
appliances which contain one or more hard drives, often arranged into logical,
redundant storage containers or RAID arrays. Network-attached storage removes the
responsibility of file serving from other servers on the network. They typically provide
access to files using network file sharing protocols such as NFS, SMB/CIFS, or AFP.
Figure 1.2 File Server
1.3.2 Database Server

The client passes SQL requests as messages to the database server. The result of
each SQL command is returned over the network to the client. The code in the server
process will processes the SQL request and the data reside in the same machine. The server
uses its own processing power to find the requested data instead of passing all records back
to a client and then letting it find its own data, as was the case for the file server. D
istributed database servers may increase the efficiency of the processing power. These
servers provide the foundation for decision-support systems that require adhoc queries and
flexible reports. They also play a key role in data warehousing.
Database server is the term used to refer to the back-end system of a database
application using client/server architecture. The back-end, sometimes called a
database server, performs tasks such as data analysis, storage, data manipulation, archiving,
and other
non-user specific tasks. 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
rely exclusively on the client–server model for database access.
It also performs tasks such as data analysis, storage, data manipulation, archiving,
and other tasks using client/server architecture. Such a server is accessed either through a
"front end" running on the user‘s computer which displays requested data or the "back
end" which runs on the server and handles tasks such as data analysis and storage. In a
master-slave model, database master servers are central and primary locations of data while
database slave servers are synchronized backups of the master acting as proxies.
Some examples of Database servers are Oracle, DB2, Informix, Ingres, SQL Server,
MySQL. Every server uses its own query logic and structure. The SQL query language is
more or less the same in all the database servers.
Figure 1.3 Database Server
1. 3.3 Transaction Servers

The client invokes remote procedures (or service) that resides 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. The
SQL statements either all succeed or fail as a unit. These grouped SQL statements are
called Transactions. The server component usually consists of SQL transactions against a
database These are called Online Transaction Processing or OLTP.OLTP applications
also require tight controls over the security and integrity of the database. Two forms of
OLTP:
TP Lite based on the stored procedures provided by database vendors.
TP Heavy based on the TP Monitors provided by the OLTP Vendors.
A transaction server is a software component that is used in implementing

transactions. A transaction involves multiple steps which must be completed atomically,
as though it is a single operation which cannot be interrupted, even though it may
require multiple steps. For example, bank moving money from account A to account B
must remove it from A and also add it to B; it would be unacceptable to do only one of
these steps. If the server is unable to accomplish all of the steps it must be sure to perform
none of the m. This will mean ensuring that transactions are guaranteed, or that if a
transaction fails the system can tell this has happened.
In case of transaction failure, it can be "backed out" (or "rolled back"), which will
mean that the system reverses all the actions that happened during the partial completion
of the transaction. This is sometimes referred to as the ACID property. A transaction server
will consist of a system providing the safety described above, and an environment
where programs can be written to make use of these features. It will also have various
connection protocols to allow it to connect to the databases involved, and to the front end
software (for example the computer of a telesales person or the web interface of an online
bank).
Figure 1.4 Transaction Server
1.3.4. Groupware Servers

Groupware addresses the management of semi-structured information such as text, 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 Example of such system,
although a number of other application including document management, imaging, military
applications and workflow are addressing some of the same needs. In most cases,
applications are created using a scripting language and form-based interfaces
provided by the vendor. The communication middleware between the client and the
server is vendor-specific.
However, many groupware products now use e-mail as their standard messaging.
In addition, the internet is quickly becoming the middleware platform of choice for
groupware. Both netscape and IBM/lotus are moving their products in their direction.
Groupware refers to programs that help people work together collectively while located
remotely from each other. Programs that enable real time collaboration are called
synchronous groupware. Groupware services can include the sharing of calendars,
collective writing, e-mail handling, shared database access, electronic meetings with each
person able to see and display information to others, and other activities. Sometimes called
collaborative software, groupware is an integral component of a field of study known
as Computer- Supported Cooperative Work or CSCW.
Groupware is often broken down into categories describing whether or not work group
members collaborate in real time (synchronous groupware and asynchronous groupware).
Some product examples of groupware include Lotus Notes and Microsoft Exchange, both
of which facilitate calendar sharing, e-mail handling, and the replication of files
across a distributed system so that all users can view the same information. Electronic
"face-to-face" meetings are facilitated by CU-SeeMe and Microsoft NetMeeting.
Figure 1.5 Groupware Servers
1.3.5 Object Application Servers

The client/server application is written as a set of communicating objects. Client
objects communicate with server objects using an Object 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.
Examples: Digital’s Object Broker, IBM’s SOM 3.0, Sun’s NEO, HP’s ORB Plus,
Expersoft’s Power Broker, Microsoft’s DCOM or Network OLE.
CORBA is also the foundation technology for the Enterprise Java Beans
component model. A new generation of CORBA application servers- also called Object
Transaction Monitors(OTMs) provide server side component coordination services.
Example of CORBA application servers are BEA‘s IBM component Borker,

Oralce Application server4.0. Microsoft has it own ORB called the distributed
component object model (DCOM). DCOM is the foundation technology for
Microsoft Transaction Server(MTS) is the application server for ActiveX components.
Figure 1.6 Object Server
1.3.6 Web Servers

WWW is the first truly intergalactic client/server application. This model of
client/server consists of thin, portable, ―universal‖ clients that talk to Superfast Servers.
The clients 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 client/server model is evolving. Java applets and CORBA enabled
browsers are the first manifestation of this new object web. Web application servers are a
new class of internet software. They argument standard HTTP servers side component
frameworks. Functionally, they are very similar to object servers. The collection of HTML
documents are stored in the Web Server.
Specification by which a Web server passes data between itself and an application
program. Typically, a Web user will make a request of the Web server, which in turn
passes the request to a CGI application program.
The program processes the request and passes the answer to the server, which in
turn sends it to the user. The entire interchange follows the rules of the CGI specification,
which is actually part of the HTTP protocol. CGI application programs can be written
in such programming languages as C++ and Visual Basic, but are usually written in Perl.
Figure 1.7 Web Server
Fat Servers (or) Fat Clients
Client/Server applications can also be differentiated by how the
distributed application is split between the client and the server. The fat server model
places more function on the server. The fat client does the reverse. Groupware,
transaction and the web servers are examples of fat servers; database and file servers are
examples of fat clients. Distributed objects can be either.
Figure 1.8 Fat Server with Fat Client

Fat Client
Fat clients are the more traditional form of client/server. The bulk of the
application runs on the client side of the equation. In both the file server and database
server models, the clients know how the data is organized and stored on the server side. Fat
clients are used for decision support and personal software. They provide flexibility
and opportunities for creating front-end tools that let end-users create their own
applications.
Fat Server
Fat Server applications are easier to manage and deploy on the network because
most of the code runs on the servers. Fat servers try to minimize network interchanges by
creating more abstract levels of service. Transaction and object servers, for example,
encapsulate the database. The client in the fat server model provides the GUI and interacts
with the server through remote procedure calls (or method invocations).These are used for
mission-critical applications; represent the new growth area fro PC-based client/server
computing.
1.3.6.1 Tiered architectures

The term 'Client/Server' has traditionally been associated with a desktop PC
connected over the network to some sort of SQL-database server. In fact, the
term Client/Server formally refers to a logical model that provides for a division of
tasks into
'client' and 'server' layers or 'tiers'. The two-tier physical representation that we have
become accustomed to is actually just one possible implementation of the
Client/Server logical model. Mainframe programmers have employed the Client/Server
model for years and most mainframe applications have a client /Server architecture.
There are no limitations to the number of tiers an application may have. The 'three'
in three-tier represents the most common number of logical separations for an
application. These logical separations are broken down into Presentation, Application, and
Data services, as described further below.
Two-tier architecture
Two tier Client/Server provides a basic separation of tasks. The client, or first tier, is
primarily responsible for the presentation of data to the user and the 'server,' or second tier,
is primarily responsible for supplying data services to the client. So far, so good.
Figure 1.9 Two-tier Client/Server architecture

Presentation services
Presentation services' refers to the portion of the application which presents data
to the user. In addition, it also provides for the mechanisms in which the user will interact
with the data. More simply put, presentation logic defines and interacts with the user
interface. The presentation of the data should generally not contain any validation
rules. Delphi Client/Server Suite's Rapid Application Development (RAD) approach
to application development and component architecture allows the developer to
easily assemble the presentation layer and move quickly from prototype to production.
Business services/objects
Business services' are a category of application services. Business services
encapsulate or componentized an organizations business processes and requirements.
These rules are derived from the steps necessary to carry out day-today business in an
organization. These rules can be validation rules, used to be sure that the incoming
information is of a valid type and format, or they can be process rules, which ensure that
the proper business process is followed in order to complete an operation. Through
Delphi Client/Server Suite these services can be encapsulated in Delphi components
which can then be shares amongst development teams providing for easier maintenance
and component/code reuse.
Application services -Application services' provide other functions necessary for
the application.
Data services
Data services' provide access to data independent of their location. The data can
come from legacy mainframe systems, SQL RDBMS systems, or proprietary data access
systems. Once again, the data services provide a standard interface for accessing data.
Delphi Client/Server Suite includes connectivity to Informix, InterBase, Microsoft
SQL Server, Oracle, Sybase and any other data source which supports ODBC.
Where do application logic and business rules reside in two-tier Client/Server?
As Figure 1 depicts, both business rules and application logic can reside on either the
client or the server. The Client/Server divisio n doesn't apply to them. The resulting lack
of clarity raises several critical issues: reuse, scalability, and maintenance. Delphi
Client/Server offers a number of features which ameliorate these issues, and an n-tier
architecture provides further resolution.
Delphi for two-tier development
Delphi Client/Server Suite addresses the issues mentioned above, smoothing
the transition from existing two-tier to three-tier solutions.
Delphi Client/Server Suite outpaces the competition such as PowerBuilder, SQL
Windows and Visual Basic for two-tier application development. Delphi Client/Server
Suite employs a true object-oriented language, to support a component-based RAD model
offering greater re-use and scalability. Unlike competing products, Delphi allows
developers to create custom components (VCLs) in Delphi to extend the Delphi
development environment
without having to resort to using another tool or language. Delphi Client/Server Suite's 32-
bit optimized native-code compiler delivers high performance native-code applications.
1.3.6.2 Two Tier Architecture Pros and Cons
Advantages Disadvantages
• Simple structure • Complex application rules difficult to

implement in database server – requires
• Easy to setup and maintain more code for the client
• Complex application rules difficult to

implement in client and have poor
performance
• Changes to business logic not

automatically enforced by a server – changes
require new client side software to be
distributed and installed
• Not portable to other database server platforms
• Adequate performance for low to • Inadequate performance for medium to high

medium volume environments volume environments, since database server
is required to perform business logic. This
• Business logic and database are slows down database operations on database
physically close, which provides server.
higher performance.
Three-tier architecture
In order to address the above-mentioned issues in an effective way,
software developers community came with an evolutionary but effective and efficient
solution referred to as "three-tier architecture". That is, an application can be separated
into three logical layers, each with a well-defined set of interfaces. The first tier is called
as the presentation layer and it normally consists of a graphical user interface. The
middle tier consists of the application logic and the third tier is the data layer. The three
logical layers can lie in the same machine also through smart software configuration.
Thus three-tier client/server applications employ an intermediary or middle-
tier application server, which operates between client applications and the back-end
databases. The middle tier composes business application logic code, which the user calls
upon through
the front-end graphical user interface to retrieve the desired data. The presentation layer
on getting the data from the middle tier formats the data for displaying it to the user. This
kind of separations brings a number of unique advantages such as flexibility and
performance increment. Also multiple user interfaces can be built and deployed with out
bringing any change to the application logic.
There are a variety of ways of implementing this middle tier, such as
using transaction processing (TP) monitors, message servers, object request brokers
(ORBs) or application servers. The middle tier can perform queuing, application execution,
locating and connecting application objects and database staging. If the middle tier
provides queuing, the client can deliver its request to the middle layer and disengage
because the middle tier will access the data and return the answer to the client.
The third tier contains the data that is needed for the application.. The data can be
from any source of information such an enterprise database like Oracle, MS SQL Server,
a set of XML documents, a directory service like an LDAP server, or even any legacy
and proprietary systems.
This approach heavily improves those lacking points found in two-tier application.
There are two fundamental motivations for using a three-tier architecture over a two-tier
model:
Improved Scalability, availability, and performance
Improved flexibility, and extensibility of business systems
These features are being achieved through managing back-end resources in a
more effective and smart manner. There are some good resource management techniques
such as pooling and clustering middle-tier servers. Pooling makes three-tier systems more
effective by allowing more clients to share scarce resources like database connections,
which reduces the workload on back-end servers. Clustering makes three-tier systems
more available and scalable because multiple servers and resources can support fail-over
and balance the word loads of a growing client population.
Three-tier systems are more flexible and extensible than their two-tier systems as the
business logic and services such as security, persistence, transactions etc reside on
the middle-tier and transparent to the client applications. This tends to make t hese services
being applied automatically to client requests and any changes made in the business logic
code do not reflect on the clients in any way.
Still it has been found that three-tier methodology lacks some critical features such as
reusability of application logic code and scalability. That is, there may arise a situation
whereby a collection of application logic code results and they cannot be reused and also
they do not communicate with one another. Thus there came a need for a viable
architecture that mainly facilitates reusability of business logic as reusability phenomena
has been found to reduce the cost of software development and the time to market and its
quality is assured.
Transaction Processing (TP) monitor technology - The most basic type of three-
tier architecture has a middle layer consisting of Transaction Processing (TP)
monitor technology. The TP monitor technology is a type of message queuing,
transaction scheduling, and prioritization service where the client connects to the TP
monitor in the middle layer instead of database server on the back-end. The transaction is
accepted by the monitor, which queues it and then takes responsibility for managing it to
completion, thus freeing up the client. A typical TP monitor technology provides the
ability to update multiple different DBMSs in a single transaction connectivity of data
sources including flat files, non
-relational DBMS‘s and even mainframe systems the ability to attach priority to
transactions and to give robust security For systems with thousands of users, TP monitor
technology has been one of the most effective solutions.
The main limitation of this technology is that the implementation code has to be
written in a low-level language such as COBOL and there is no visual toolsets to
interoperate with the middle tier.
Message Server - This is another viable technology to implement three-tier
architecture applications. Messages from clients are being prioritized and
processed asynchronously. A typical message consists of a header that
contains priority information, and the address and identification number. The
message server connects to the backend RDBMS and other data sources. The
main difference between TP monitor technology and message server paradigm
is that the message server architecture focuses on intelligent messages, whereas
the TP monitor environment has the intelligence in the monitor, and treats
transactions as dumb data packets. Click here for an overview of Java Message
Service (JMS).
Application Server - This helps the application logic code to be deployed in a
shared host machine rather than in the user system interface.
.
Figure 1.10. Three-tier Client/Server architecture
Through standard tiered interfaces, services are made available to the application.
A single application can employ many different services which may reside on
dissimilar platforms or are developed and maintained with different tools. This
approach allows a developer to leverage investments in existing systems while creating
new application which can utilize existing resources.
Multi-tier architectures
A multi-tier, three-tier, or N-tier implementation employs a three-tier logical

architecture superimposed on a distributed physical model. Application Servers can
access other application servers in order to supply services to the client application as well
as supply services for other application servers.
Thus the notion of n-tier architecture. To turn three-tier architecture into an n-tier
system, the middle tier can be allowed to have multiple application objects rather than a
single application. Each of these application objects must have a well-defined
interface which allows them to contact and communication with one another. An interface
is actually brings an idea of contract. That is, each object states through its interface that it
will accept certain parameters and return a specific set of results. Application objects use
their interfaces to do business processing.
With n-tier architecture, one can have multiple applications using a common set
of business objects across an organization. This promotes the standardization of
business practices by creating a single set of business functions for the entire organization to
access. If a particular business rule changes, then changes have to be made to only the
business object and if need, to its interface also.
For example, in the diagram below the client application looks to Application Server
#1 to supply data from a mainframe based application. Application Server #1 has no
direct
access to the mainframe application but, it does know, through the development of
application services, that Application Server #2 provides a service to access the data from
the mainframe application which satisfies the client request. Application Server #1 then
invokes the appropriate service on Application Server #2 and receives the requested data
which is then passed on to the client.
Application servers can take many forms. An application server may be anything
from custom application services, Transaction Processing Monitors, Database
Middleware, Message Queue to a CORBA/COM based solution.
Application server vendors such as Open Environment Corporation (Entera),
BEA Systems (Tuxedo), IBM (CICS, MQSeries), IBM/Transarc (Encina), Iona
Technologies (ORBix), NCR (TopEnd) in combination with their partners offer
connectivity solutions for Delphi Client/Server Suite.
Figure 1.11. Multi-tier Client/Server architecture
2-Tier Vs 3-Tier
Instead of Fat clients and fat servers these terms can be used. It is all about how
We split the client/server applications into functional units. These functional units
can be assigned to either the client or to one or more servers. The most typical functional
units are:
User Interface
Business Logic and
the Shared Data
In 2-tier, the application logic is either buried inside the User Interface on the client
or within the database on the server (or both) 2-tier system examples: File Servers and
Database Servers with stored procedure. In 3-tier, the application logic (or) process lives in
the middle- tier, it is separated from the data and the user interface. 3-tier systems are
more scalable, robust and flexible. In addition, they can integrate data from multiple
sources.
Examples: TP Monitors, Distributed Objects and the Web.
Figure 1.12. 2 Tier Vs 3-Tier Architecture
Table1.1
2-tier 3-tier
System Complex Less complex
administration (more logic on the client to (the application can be centrally,
manage) managed on the server-
application programs are made
visible to standard system
management tools)
Security Low( data level security) High (fine tuned at the service,
method, or object type level)
Encapsulation of Low( data tables are exposed) High(the client invokes service
data or method)
Performance Poor(many SQL statement sent Good(only service requests and
over the network, selected data responses are sent between the
must be down loaded for analysis client and server)
on the client)
Scale Poor(limited management of Excellent (concentrates incoming
client communications sessions; can distribute loads
links)
across multiple)
Application reuse Poor(monolithic application Excellent (can reuse service and
on client) objects)
Ease of High Getting better(standard tools can
development be used to create the client and
server sides of the application)
Server to Server No Yes(via server –side middleware)
infrastructure
Legacy application No Yes(via gateways encapsulated
integration by service or objects)
Internet support Poor(internet bandwidth Excellent (thin clients are easier
limitations make it harder to to download as applets or beans;
download clients and exacerbate remote service invocations
the already noted limitations) distribute the application load to
the server)
Heterogeneous No Yes(3-tier application can use
database support multiple database within the
same business transaction)
No(only synchronous, connection Yes(supports RPC-like calls, but
oriented RPC like calls) can also support connectionless
messaging, queued delivery,
public and subscribe and broad
cast)
Architecture Limited(We have a client and a Excellent(all three tiers may
flexibility server) reside on different computers, or
the second and third tires may
both reside on the same computer
with component based
environment We can distribute
the second tier across mulitple
servers as well)
1.3.7 Different Meanings for 3-tier

Table 1.2
First Then Now
tier 1 – Application in PC tier 1 – Partitions across tier 1 – Client

client
tier 2 – Departmental Servers tier 2 – local database tier 2 – Application Server
tier 3 – Enterprise Servers tier 3 – enterprise database tier 3 – Database Server
System administration Complex
1.3.8 Comparison with the MVC architecture

At first glance, the three tiers may seem similar to the model-view-controller
(MVC) concept; however, topologically they are different. A fundamental rule in a
three tier architecture is the client tier never communicates directly with the data tier; in
a three-tier model all communication must pass through the middle tier. Conceptually
the three-tier architecture is linear. However, the MVC architecture is triangular: the view
sends updates to the controller, the controller updates the model, and the view gets updated
directly from the model.
From a historical perspective the three-tier architecture concept emerged in the
1990s from observations of distributed systems (e.g., web applications) where the
client, middleware and data tiers ran on physically separate platforms. Whereas MVC
comes from the previous decade and is based on observations of applications that ran
on a single graphical workstation; MVC was applied to distributed applications later in its
history.
Presentation Layer Get sales Total Get sales Total &
The top-most level of the application is the Total Sales
user
interface. The main function of the interface is to translate
tasks and results to something the user can understand.
Logic Tier
This layer coordinates the application, processes
Get list of all sales Add all sales
commands, makes logical decisions and made last year together
evaluations
and performs calculations. It also moves and Sale1
processes data between the two surrounding layers. Query Sale2
Sale3
Sale4
Data Tier
Here information is stored and retrieved from
a database or file system. The information is Database
Storage
then
passed back to the logic tier for processing,
and then eventually back to the user.
Figure 1.13 Three Tier Architecture

1.4 MIDDLEWARE DEFINITION

Middleware does not include the software that provides the set of actual service.
It does however, include the software that is used to coordinate inter server interactions.
It also does not include the user interface or the application‘s logic t hat‘s in the
client‘s domain. It starts with the API set on the client side that is used to invoke a
service, and it covers the transmission of the request over the network and the resulting
response.
Middleware divided into two broad classes:
1. General Middleware
2. Service-Specific Middleware
1.4.1 General Middleware

It is the substrate for most client/server interactions. It includes the
communication stacks, distributed directories, authentication stacks, distributed
directories, authentication services, network time, remote procedure calls, and queuing
services.
Products that fall into the general middleware category include DCE,
ONC+, NetWare, Named Pipes, LAN Server, LAN Manager, Vines, TCP/IP, APPC and
NetBIOS. Message Oriented Middleware (MOM) products from Peer logic, Covia,
Message Express, System Strategies and IBM.They depend on message queue system and
increases portability, interoperability, flexibility.
1.4.2 Service-Specific Middleware

It is need to accomplish a particular client/server type of
service. These includes
Database-specific middleware such as ODBC, DRDA, EDA/SQL, SAG/CLI and
Oracle Glue.
OLTP-specific middleware such as Tuxedo‘s ATMI and /WS, Encina‘s
Transactional RPC, and X/Open‘s TxRPC and XATMI
Groupware-specific middleware such as MAPI, VIM, VIC, SMTP and Lotus Notes
Calls
Object-specific middleware such as OMG‘s CORBA and Microsoft‘s Network OLE
(or DCOM)
Internet-specific middleware such as HTTP, S-HTTP and SSL
System Management-specific middleware such as SNMP, CMIP and ORBs.
1.5 CLIENT SERVER BUILDING BLOCKS

1.5.1 Client/Server : A one size fits all model
The wide spectrum of client / server needs from the tiny to the intergalactic- with
just three basic building blocks: a client, a server, and the slash(/) that ties the client to the
server.
Figure 1.14. Client/Server Model

These building blocks can be rearranged to use them in the following situations:
Client/Server for tiny shops and nomadic tribes – This is a building-block
implementation
that runs the client, the middleware software, and most of the business services on the
same machine. It is the suggested implementation for the one-person shops, home
offices, and mobile users with well-endowed laptops.
Client/Server for small shops and departments - This is the classic Ethernet
client/single- server, building block implementation. It is used in small shops,
departments, and branch offices. This is the predominant form of client/server today.
Client/Server for intergalactic enterprises – This is the multi server building-
block implementation of client/server. The servers present a single system image to the
client. They can be spread out throughout the enterprise, but they can be made to look like
they are part of the local desktop. This implementation meets the initial needs of
intergalactic client/server computing.
Client/Server for a post-scarcity world – This model transforms every machine in the
world into both a client and a server. Personal agents on every machine will handle all
the negotiations with their peer agents anywhere in the universe. This dream is almost
within reach.
1.5.2 Client/Server for Tiny Shops and Nomadic Tribes

It is easy to run the client and server portion of an application on the same
machine. Vendors can easily package single-user versions of a client/server application.
The business critical client/server application runs on one machine and does some
occasional communications with outside servers to exchange data, refresh a database and
send or receive mail and faxes. Ex: Internet.
Figure 1.15. Client/Server Model for tiny Shops
1.5.3 Client/Server for small shops and departments

The client/server architecture is particularly well-suited for the LAN-based single
server establishments.
1. It consists of multiple clients talking to a local server.
2. This is the model used in small businesses.
3. The single-server nature of the model tends to keep the middleware simple.
4. The client only needs to look into a configuration file to find its server‘s name.
5. Security is implemented at the machine level and kept quite simple.
6. The network is usually relatively easy to administer; it‘s a part-time job for a
member of the group.
There are no complex interactions between servers, so it is easy to identify failures-
they‘re either on the client or on the local server.
Figure 1.16. Client/Server Model for Small Shops and Departments

1.5.4 Client/Server for Intergalactic Enterprises

The client/server enterprise model addresses the needs of establishments with a
mix of heterogeneous servers. These models are upwardly scalable. When more processing
power is needed for various intergalactic functions, more servers can be added, or the
existing server machine can be traded up for the latest generation of super server
machine. The servers can be partitioned based on the function they provide, the resource
they control, or the database they own. The servers can be replicated to provide a fault
-tolerant service or to boost an application‘s performance.
Multi server capability, when properly used, can provide an awesome amount of
compute power and flexibility, in many cases rivaling that of mainframes. To exploit the
full power of multi servers, we need low-cost, high-speed bandwidth and an awesome
amount of middleware features -including network directory services ,network
security ,remote procedure calls and network time services.
Middleware creates a common view of all the services on the network called a
single system image. Good software architecturefor
intergalactic enterprise client/server implementations is all about creating
system ―ensembles‖ out of modular building blocks. Intergalactic client/server is the
driving force behind middleware standards as distributed objects and the Internet.
Figure 1.17. Client/Server Model for Intergalactic Enterprises
1.5.5 Client/Server for a Post-Scarcity World

Every machine is both a client and a full-function server. Because every machine is a
full- function server, it will run, at a minimum, a file server, database server, workflow
agent, TP Monitor, and Web server – all connected via an ORB. This is in addition to all
the client software and middleware. In next few years, a hundred million machines or
more may be running almost all the forms of client/server software .In this model instead of
mobile agents, personal agents will be used.
Figure 1.18. Client/Server Model for Post-Scarcity World
1.5.6 Intergalactic Client/Server

Intergalactic client/server is a new threshold of client/server applications and this
is because of the exponential increase of low-cost bandwidth on Wide Area Networks –
for example, the Internet and CompuServe a new generation of network-enabled, multi-
threaded desktop operating systems – for example, OS/2 Warp Connect and Windows 95.
This new threshold marks the beginning of a transition from Ethernet client/server
to intergalactic client/server that will result in the irrelevance of proximity. The center
of gravity is shifting from single-server, 2-tier, LAN-based departmental client/server to a
post- scarcity form of client/server where every machine on the global ―information
highway‖ can be both a client and a server.
1.6 INSIDE THE BUILDING BLOCKS
Fig 1.19. Client/Server Software Infrastructure.

1.6.1 The Client Building Block

Runs the client side of the application.
It runs on the OS that provides a GUI or an OOUI and that can access
distribute services.
The client also runs a component of the Distributed System Management
(DSM) element.
1.6.2 The Server Building Block

Runs the server side of the application.
The server application typically runs on top of some shrink-wrapped server
software package.
The five contending server platforms for creating the next generation
of client/server applications are SQL database servers, TP Monitors,
groupware servers, Object servers and the Web server.
The server side depends on the OS to interface with the middleware
building block.
The server also runs DSM component .It may be a simple agent or a
shared object database etc.
1.6.3 The Middleware Building Block

Runs on both the client and server sides of an application
This broken into three categories
Transport Stacks
NOS
Service-specific middleware
Middleware is the nervous system of the client/server infrastructure. This also has the DSM
component.
1.6.4 DSM – Distributed System Management

Runs on every node in the client/server network. A managing workstation collects
information from all its agents on the network and displays it graphically. The
managing workstation can also instruct its agents to perform actions on its behalf.
1.6.5 Server-to-server Middleware

Server-to-server interactions are usually client/server in nature – servers are clients
to other servers. However, some server-to-server interactions require specialized
server middleware. For example, Two-Phase commit protocol may be used to
coordinate a transaction that executes on multiple servers. Servers on mail backbone
will use special server-to-server middleware for doing store-and-forward type messaging.
But most modern software follows the client/server paradigm.
Figure 1.20. The Server-to-Server Middleware Infrastructure.
1.7 RPC – MESSAGING – PEER-TO-PEER

Client/Server applications are split across address spaces, physical machines,
networks and operating systems. All NOSs offer peer-to-peer interfaces that let
applications communicate using close to the wire send/receive semantics. Most NOSs
provide some form of RPC middleware that hides the wire.
An alternative type of model – message queueing or simple MOM – incredibly
helpful in situations when the tight synchronization is not needed between the clients
and servers.
Each layer has a well-defined set of APIs and Protocols. With these mix-and-
match can be done. Practically, an entire stack of from a single vendor. The lowest layer
of the communication software belongs to the device drivers that provide an interface to
several types of communication hardware adapters. Real products don‘t have any
notion of architectural boundaries or reference models – they just get a job done.
Communication Stacks
At the lower layers, they interface to the hardware using MAC protocols defined
by IEEE. The LLC provides a common interface to the MACs and a reliable link service
for transmitting communication packets between two nodes. The transport layer provides
end-to- end delivery service.
1.7.1 Peer – to – Peer Communications

Most early client/server applications were implemented using low-level,
conversational, peer-to-peer protocols – such as sockets, TLI, CPIC/APPC, NetBIOS and
Named Pipes. These low-level protocols are hard to code and maintain. Instead now, the
programmers are using RPCs, MOMs, and ORBs, which provide high level abstraction.
The term, ―peer-to-peer‖ indicates that the two sides of a communication link use
the same protocol interface to conduct a networked conversation. The protocol is
symmetrical, and it is sometimes called ―program-to-program‖. The peer-to-peer interface
not fully mask the underlying network from the programmer. Programmers have to handle
the transmission timeouts, race conditions, and other network errors. The peer-to-peer
protocols started as stack-specific APIs.
1.7.2 Sockets
Sockets were introduced in 1981 as the UNIX BSD 4.2 generic interface that
would provide Unix-to-Unix communications over network. In 1985, SUN OS introduced
NFS and RPC over sockets. Sockets are supported on virtually every OS. The windows
socket API, known as WinSock, is a multivendor specification that standardizes the use of
TCP/IP under windows. In BSD UNIX System, sockets are part of the Kernel and
provide both a standalone and networked IPC service.
The three most popular socket types are,

Stream, Datagram, Raw Stream and datagram sockets interface to the TCP and
UDP protocols, and raw sockets interface to the IP protocol. The type of socket is specified
at creation time. In theory, the socket interface can be extended, and define a new socket
types to provide additional services. A socket address on the TCP/IP internet consists of
two parts: an IP address and a port number.
Figure 1.21. Socket Address of TCP/IP

Socket = Net_ID . Host_ID . Port_ID = IP Address + Port
Address.
A port is an entry point to an application that resides on the host. It is represented by a
16-bit integer. Ports are commonly used to define the entry points for services provided by
the server applications.
TLI
In 1986, AT&T introduced the Transport Layer Interface that provides
functionality similar to sockets but in a more network-independent fashion. Sockets and
TLI are very similar from a programmer‘s perspective. TLI is just cleaner version of the
sockets. It should run on IPX/SPX (or) TCP/IP with very few modifications. The TLI API
consists of 25 API calls. Later standardized as XTI, X/Open Transport Interface.
NetBIOS and NetBEUI

It is the premier protocol for LAN-based, program-to-program
communications. Introduced by IBM and Sytek in 1984 for the IBM PC network. It is used
as an interface to a variety of stacks – including NetBEUI, TCP/IP, XNS, Vines, OSI and
IPX/SPX.
NetBEUI is the protocol stack that comes with IBM and Microsoft LAN products
including windows for workgroup,NT,LAN manager, windows 95/98, and OS/2 warp.
This can be misleading. Netware, for example, has nothing do with netBEUI, yet it uses
NetBIOs as an interface to both IPX/SPX and TCP/IP.NetBEUI offers powerful
datagram and connection oriented service. It also offers a dynamic naming service
based on discovery protocols. NetBEUI main weakness is the lack of a network layer. Its
other weakness is the lack of security.
The NetBIOS services are provided through a set of commands, specified in
a structure called the Network Control Block (NCB). The structures also contains
the parameter associated with the command and the fields in which NetBIOS will
return
information to the program. A command can be issued in either wait or no-wait mode. In
the wait mode, the requesting thread is blocked until the command completes. In the no
-wait mode , control is returned to the calling thread at the earliest time possible, usually
before the command completes. When the command complete, the NetBIOS DLL places a
return code in the client.
Named Pipes
Named pipes Provide highly reliable, two-way communications between clients and
a server. They provide a file-like programming API that abstracts a session-based two-
way exchange of data. Using named pipes, processes can exchange data as if they were
writing to, or reading from, a sequential file. These are suitable for implementing server
programs that require many-to-one pipelines.
Important benefit of named pipes are part of the base interprocess communications
service. Named pipes interface is identical, whether the processes are running on
an individual machine or distributed across the network. Named pipes run on
NetBIOS, IPX/SPX, and TCP/IP stacks. Named pipes are built-in networking features in
Windows NT, Windows for Workgroups, Windows 95 and Warp Server. Unix support for
Named Pipes is provided by LAN Manager/X.
CPI-C/APPC
Common Programming Interface for Communications (CPI-C) build on top of
APPC and marks its complexities and irregularities. Writing to the CPI-C API allows We to
port our programs to all SNA platforms.
The CPI-C API consists of about 40 calls; APPC consists of over 60 calls. Most
of these calls deals with configuration and services.
Advanced program-to-program communication is a protocol which computer
programs can use to communicate over a network. APPC was developed as a
component of IBM‘s Systems Network Architecture (SNA). APPC is linked with the
term LU6.2. LU6.2. (Logic Unit Version 6.2) is a device independent SNA Protocol.
It was developed to allow computers in IBM environments to setup their
own communications sessions, rather than rely on a hos computer to do so. Contrary to
TCP/IP, in which both communication partners always possess a clear role, the
communication partners in APPC are equal, i.e., everyone can be both servers and clients
equally. With the wide success of TCP/IP, APPC has declined.
CPI-C on Top of APPC
Figure 1.22. CPI-C/APPC
1.7.3 Datagrams Vs Sessions
Connection-oriented protocols also known as session-based protocols, virtual

circuits or sequenced packet exchanges – provide a reliable two-way connection service
over a session. Each packet of information gets exchanged over a session. Duplicate
packets are detected and discarded by the session services. Overhead associated with
creating and managing the session. If a session is lost, one of the parties must reestablish
it. This can be a problem for fault-tolerant servers that require automatic switchovers to a
backup server if the primary server fails. The backup server needs to reestablish all the
outstanding sessions with clients.
Datagrams also known as connectionless protocols or transmits and pray protocols
provide a simple but unreliable form of exchange. The more powerful datagram protocols
such as NetBIOS provide broadcast capabilities. NetBIOS allows us to send datagram to
a named entity, to a select group of entities (multicast), or to all entities on a
network (broadcast). Datagrams are unreliable in the sense that they are not acknowledged
or tracked through a sequence number. Some stacks (ex: LAN Server‘s MailSlots)
provide an acknowledged datagram service.
Datagrams are very useful to have in ―discovery‖ types of situations. These are
situations to discover things about our network environment by broadcasting queries and
learning that is out there from the response. Broadcast can be used to obtain bids for
services or to advertise the availability of new services. Broadcast datagrams provide the
capabilit y of creating electronic ―bazaars‖ The alternative to broadcast is to use a
network directory service.
Datagrams are also very useful in situations where there is a need to send a quick
message (or) important message. Ex: All the systems have to send the ―I am alive‖
message periodically to the network manager. The ordinary method may need 500
sessions for each
computer in the network and not possible. Instead the system can broadcast the datagram
to the manager.
1.7.4 Remote Procedure Call

―RPCs are not procedure calls at all, they are truly process invocations. The invoked
program runs across the wire in a different resource domain‖
A client process calls a function on a remote server and suspends itself until it
gets back the results. Parameters are passed like in any ordinary procedure. The RPC,
like an ordinary procedure is synchronous. The process (or threads) that issue the call
waits until it gets the results. Under the covers, the RPC run-time software collects
values for the parameters, forms a message, and sends it to the remote server. The
server receives the request, unpacks the parameters, calls the procedure, and sends the
reply back to the client. While RPCs make life easier for the programmer, they pose a
challenge for the NOS designers who supply the development tools and run-time
environments.
1.7.4.1 COMMON ISSUES

The Common issues are:
How are the Server functions located and started?
Server starts the process, when a remote invocation is received with
necessary parameters and returns the response to the client. What happens when multiple
clients invoke the same function? Now an environment is needed to start and stop
servers, prioritize requests, perform security checks, and provide some form of load-
balancing. Each incoming requests invokes a thread in the server side. A server loop is
created to manage the pool of threads waiting for work rather than create a thread for each
incoming request. TP Monitors are really needed on the server side, which provides more
functions than a NOS.
How are parameters defined and passed between the client and the server?
The better NOSs provide an Interface Definition Language (IDL) for describing
the functions and parameters that a server exports to its clients. An IDL compiler takes
these descriptions and produces source code stubs (and header files) for both the client and
server. These stubs can then be linked with the client and server code. The client stubs
packages the parameters in an RPC packet, converts the data, calls the RPC run-time
library and waits for the server‘s reply. On the server side, the server stubs unpacks the
parameters, calls the remote procedure, packages the results, and sends the reply to the
client.
Figure 1.23. The Mechanics f an RPC Stub Compiler

How are failures handled?
Both the sides of the RPC can fail separately, it is important for the software to
be able to handle all the possible failure combinations. If the server does not respond, the
client side will normally block, timeout, and retry the call. The server side must
guarantee only once semantics to make sure that a duplicate request is not re-
executed. If the client unexpectedly dies after issuing a request, the server must be able
to undo the effects of that transition.
How is security handled by the RPC?
Modern NOSs, like DCE – make it easy to automatically incorporate their security
features into the RPC. All We need to specify is the level of security required; then the
RPC and security feature will cooperate to make it happen.
How does the client find its server?
The association of a client with a server is called binding. The binding
information may be hardcoded in the client. The client can find its server by consulting a
configuration file or an environment parameter. A client can also find its server at run
time through the network directory services. The server must, of course, advertise
their services in the directory. The process of using the directory to find a server at
runtime is called dynamic binding. RPC can be used to find a server. The RPC client
stub will locate a server from a list of servers that support the interface. This is called
automatic binding.
How is data representation across systems handled?
The problem here is that different CPUs represent data structures differently (Ex:
big- endian Vs little endian) To maintain machine independence, the RPC must provide
some level of data format translation across systems. Example: Sun RPC requires that
clients
convert their data to a neutral canonical format using the External Data Representation
(XDR) APIs.
In contrast, DCE‘s Network Data Representation (NDR) service is multi
canonical, meaning that it supports multiple data format representations. The client chooses
one of these formats, tags the data with chosen format, and then leaves it up to the server to
transform the data into a format it understands. In other words, the server makes it right. It
lets the client to do translation, which makes the life easy for the server. With Sun, all
clients look the same to the server: The Client makes it right.
Figure 1.2.4 shows how the RPC mechanism all comes together. The scenario
shows a simple seat reservation application. The seating server first starts up, advertises its
location and service in the network directory, and begins its continuous cycle of
receiving and servicing requests. A ticket client keeps in its cache the location of the
server. When a customer is ready to buy a ticket for a madonna concert, an RPC is issued
to reserve a seat. Notice how the client and server stubs cooperate to make that happen.
Figure 1.24. Seating Reservation using RPCs.

1.8 MESSAGING AND QUEUING: THE MOM MIDDLEWARE

MOM is a key piece of middleware that is absolutely essential for a class
of client/server products. If the application can tolerate a certain level of time-
independent responses, MOM provides the easiest path for creating enterprise and
inter-enterprise client/server systems. This accumulates outgoing transactions in queue and
do a bulk upload when a connection can be established with an office server.
MOM allows general purpose messages to be exchanged in a client/server system
using message queues. Applications communicate over networks by simply putting
messages in queues and getting messages from queues. MOM hides all the nasty
communications from applications and typically provides a very simple high-level of API
to its services. A MOM consortium was formed in mid-1993 with the goal of creating
standards for messaging middleware.
Members are product providers including
IBM – MQSeries
Covia – Communications Integrator
Peerlogic – PIPES
Horizon Strategies – Message Express
System Strategies – ezBridge
MOM‘s messaging and queuing allows clients and servers to communicate across
a network without being linked by a private, dedicated, logical connection. The clients
and servers can run at different times. Everybody communicates by putting messages on
queues and by taking messages from queues.
Figure 1.25. MOM: Two way message Queuing

MOM products provide their own NOS services – including hierarchical naming,
security, and a layer that isolates applications from the network. They use virtual memory
on
the local OS to create their queues. Most messaging products allow the sender to specify
the name of the reply queue. The products also include some type of format field that
tells the recipient how to interpret the message data. MOM enabled programs do not talk to
each other directly, so either program can be busy, unavailable, or simply not running at
the same time. The target program can even be started several hours later.
Figure 1.26. MOM: Save our message until We get to a server

Many clients are sending requests to one server queue. The messages are picked
off the queue by multiple instances of the server program that are concurrently servicing
the clients. The server instances can take messages off the queue either on a FIFO
basis or accounting to some priority to load-balancing scheme. The message queue
can be concurrently accessed. The servers can also use messaging filters to throw
away the messages they don‘t want to process, or they can pass them on to other servers.
The MOM messaging products provide persistent (logged on disk) and non-persistent
(in memory) message queues. Persistent messages are slower, that they can be recovered in
case of power failures after a system restart. A message queue can be local to the
machine or remote. System administrators can usually specify the number of messages a
queue can hold and the maximum message size.
Figure 1.27. MOM: Many-to-Many Messaging via Queues.

Table 1.3 Comparison of MOM and RPC
Feature MOM: Messaging and Remote Procedure Call

Queuing (RPC)
Metaphor Post office likes Telephone like
Client/server time Asynchronous. client and Synchronous. Clients and
relationship servers may operate at different servers must run
times and speeds concurrently. Server must
keep up with clients.
Client/server sequencing No fixed sequence Server must first come up
before clients can talk to
them
Style Queued Call- return
Partner needs to be No Yes
available
Load balancing Single queue can be used to Requires a separate TP
implement FIFO or priority monitor
based policy
Transactional support Yes(some proucts)messsage No. requires a transactional
queue can participate in the RPC
commit synchronization.
Message filtering Yes No
Performance Slow. An intermediate hop is Fast
required.
Asynchronous Processing Yes. Queues and triggers are Limited. Requires threads
required. and tricky code for managing
threads.
PART – A
1. What is Client?
2. What is Server?
3. What are the characteristics of Client/Server?
4. What are the different types of Servers?
5. Define RPC
6. What is meant by peer-to-peer communication?
7. Define Socket
8. What is meant by middleware?

9. What are the two types of pipes?
10. What is meant by platforms?
PART – B
1. Explain the characteristics of client/server?
2. Explain the different types of server?
3. Explain the building blocks of client/server?
4. Discuss briefly about RPC
5. Discuss briefly about peer-to-peer communication
6. Explain briefly about messaging?
7. Explain briefly about pipes?
8. Explain the concept of platforms?
Enterprise Java Bean 2.1
UNIT II
ENTERPRISE JAVA BEAN
EJB – EJB Architecture – Overview of EJB Software Architecture – View of
EJB Conversation – Building and Deploying EJBs – Roles in EJB
2.1 ENTERPRISE JAVA BEAN

An enterprise bean is a server-side component that encapsulates the business logic
of an application using Java Language. The business logic is the code that fulfills the
purpose of the application. In an inventory control application, for example, the enterprise
beans might implement the business logic in methods called checkInventoryLevel and
orderPro duct. By invoking these methods, remote clients can access the inventory
services provided by the application.
2.1.1 Benefits of Enterprise Java Beans
Enterprise beans simplify the development of large, distributed applications

because of several reasons. First, because the EJB container provides system-level
services to enterprise beans, the bean developer can concentrate on solving business
problems. The EJB container is not the bean developer but it is responsible for system-
level services such as transaction management and security authorization.
Second, because the beans and not the clients it contain the application's business
logic, the client developer can focus on the presentation of the client. The client
developer does not have to code the routines that implement business rules or access
databases. As a result, the clients are thinner, a benefit that is particularly important for
clients that run on small devices also.
Third, because enterprise beans are portable components, the application assembler
can build new applications from existing beans. These applications can run on any
compliant J2EE server.
2. 2 EJB LOGICAL ARCHITECTURE
An EJB system is logically a three-tier system. The three tiers are as follows:
1. The Client
2. The EJB Server
2.2 Enterprise Java Bean
3. The Database (or other persistent store)

All tiers are not reside on the same machine. So it is called Logical Architecture.
For example,
a) The EJB server and the database might reside on the same machine, when the EJB
server includes built-in functionalities for persistent
storage.
b) The client and the EJB server might reside on the same machine, when an EJB
bean makes a call to another bean in the same container. The caller bean is acting
as a client here.
c) These two cases can be combined to have all the tiers in a single machine.
Figure 2.1 shows a typical physical architecture for an EJB system. Most commonly,
the client, the EJB server, and the database will reside on separate machines-though
not necessarily. For example, if We‘re using an application server that supports servlets, We
may put our servlet clients on the same physical box as our EJB objects.
Figure2.1 A typical physical architecture for an EJB system
EJB’s roles in each of these tiers are :

a) A program on the client side makes call to remote EJBs. The client needs to
know how to find the EJB server and how to interact with the objects that reside
on the EJB server.
b) The EJB components live in the middle tier. The EJB objects reside inside an EJB
container. EJB Container in turn resides in an EJB server.
c) EJB can access the database themselves, typically via Java Database connecting
(JDBC), or they can allow the container to handle their data storage needs for them.
2.3 OVERVIEW OF EJB’S SOFTWARE ARCHITECTURE

The following Figure 2.2 presents a high-level view of the EJB architecture, showing the
various relationships between the various components. It specifies several Key Features
of the EJB Architecture.
Figure 2.2 A high-level sketch of the EJB architecture
EJB bean exists within the container.

Client never communicates directly with the EJB bean; rather it talks to the bean
through its home interface and its remote interface, both of which are provided by
the container.
EJB server does not take part in the logical conversation between client and EJB
bean. Actually, the server is doing a lot of work behind the scenes.
Remembers the server must handle requests for the container, and feed the
container incoming client requests. And the bean and the client not directly access
the server – all access is performed against the container.
2.3.1 EJB Servers

The EJB server is a ―Container Container‖. The Server contains the EJB
container. This server is responsible for providing the container with lower-level
services such as network connectivity. The 1.0 version of the EJB Specification did not
outline the exact interface between the EJB container and the EJB server. So, interface is
currently based on the individual vendor.
At an abstract level, though, the relationship between the container and server is such
that the server will provide the container with low-level implementation of the services
required
by the container. This layered architecture is used in many areas in the computer field. Figure
2.3 draws an analogy between EJB, and both the TCP/IP and an Operating system.
The internet protocol (IP) layer provides services to the transmission

control protocol (TCP) layer in the network, which in turn provide services to
the socket layer.
In operating system, the basic input/output system (BIOS) provides services to
the operating system, which in turn provides services to the applications.
The server provides services to the container in the Enterprise Java Beans,
which in turn provides service to the bean.
Layering in EJB Layering in TCP/IP Layering in a Typical OS
EJB Bean Socket Layer Application Program
Transmission Control Operating System

EJB Container Protocol(TCP)
EJB Server Internet Protocol(IP) BIOS
Physical Network Hardware

Operating System Connection
Figure 2.3 The layered division of services employed by EJB can also be found in
other areas of computing.
2.3.2 EJB Containers

EJB container is an environment in which EJB execute. Its primary role is to
serve as a buffer between an EJB and the outside world. Clients do not directly connect to
the EJB bean itself; rather they connect to a representation of the bean provided by the
container, which then forwards the client‘s requests to the bean. This scheme provides
the container with a high degree of flexibility in servicing client requests.
The container services:
Support for transactions

Support for management of multiple instances
Support for persistence
Support for security
The container generally provides support for managing and monitoring EJBs as well as
for version management.
Support for transactions
EJB container provides the beans with ACID properties. EJB supports transaction
by having the transaction manager for ‗begin‘ and ‗commit‘ operations. It also provides
another approach, called declarative transaction management. In declarative transaction
management, the author of the bean can specify what type of transaction support for that
bean requires for the server.
When the bean is deployed, the container reads the deployment descriptor
associated with that particular EJB Bean. Then it provides necessary transaction support
automatically. EJB provides six modes of transaction management.
 TX_NOT_SUPPORTED
 TX_BEAN_MANAGED
 TX_REQUIRED
 TX_SUPPORTS
 TX_REQUIRES_NEW
 TX_MANDATORY
 TX_NOT_SUPPORTED means that the bean does not support any

transactions, and can‘t be used from within a transaction. If the client attempts
to use the bean from within a transaction, the client‘s transaction will remain
suspended until the bean completes its operation; the client‘s transaction will
then resume.
 In TX_BEAN_MANAGED, the bean manages its own transaction. This
option is the only type of transaction support in which the bean can directly
manipulate the transaction.
 For TX_REQUIRED mode, if the client has a transaction open when it
invokes the bean‘s method, the bean runs within the client‘s transaction
context. Otherwise, the container starts a new transaction.
 TX_SUPPORTS means that if the client has a transaction in progress when it

invokes the bean‘s methods, the client‘s transaction is used. Otherwise no new
transaction is created.
 In TX_REQUIRES_NEW, the bean always starts a new transaction (even if a
transaction is already in progress). If a transaction is underway, the container
temporarily suspends it until the bean‘s transaction finishes.
 For TX_MANDATORY, the bean requires that the client have a transaction
open before the client attempts to use the bean. If no transaction is available,
an error occurs.
Support for Management of Multiple

Instances
EJB classes are written as if they were simple single threaded classes being accessed
by only one client. Other types of beans may be used concurrently by multiple clients
The EJB container must ensure that each client‘s requests are serviced in a timely
manner.To accomplish this goal, the server performs several tasks behind the screen.
 Instance Passivation
 Instance Pooling
 Database connection pooling
 Preached Instances
 Optimized method invocation
Instance Passivation is the temporary swapping of an EJB bean out to storage. If a

container needs resources, it may choose to temporarily swapout a bean. Both session &
entity beans can be passivated. Passivations on session beans are performed only to free up
space. But on the entity beans, also used to synchronize its state with the underlying data
store.
Instance Pooling means that the container shares instances of EJB beans among
multiple clients. This task is typically undertaken for purposes of efficiency; to increase the
efficiency the container instantiate fewer copies of a given bean to service requests. This not
possible in all cases. The container must provide one session bean per client otherwise
conversational state can‘t be tracked by the containers.
Database Connection Pooling is a strategy commonly employed in middleware

applications. In this approach when a component wishes to access a database, it does not
create a new database connection; instead, it simply grabs a connection from a pool of
available connections.
Database connection pooling is beneficial for two

reasons
It avoids the overhead of establishing a new database connection. In EJB‘s the

duration of a database connection will typically be relatively brief, but database access
will occur frequently.
Maintaining an open database connection consumes resources on the database. This
overhead is not significant for a small number of users, but can become substantial as
the number of concurrent connection grows. Connection pooling allows to limit the
no. of simultaneous connections and reduces the overhead on performance.
Precached instances may be used when an EJB needs to load some state information from
a database when it is created. To speed up the loading process, it is possible to keep a cache
of EJB state information in some readily accessible place to a accelerate the initial
creation of EJB‘s
Optimized method invocations are employed to combat overhead costs associated

with remote invocation. Whether the client of an EJB is a remote client or another EJB in
the same container, the APIs used to gain access to it are always the same. A typical EJB
interaction is as follows:
Use a naming service to locate the EJB’s home interface

Make a call on the EJB’s home interface to gain access to its remote interface.
Make calls to the business methods against the remote interface.
If two EJBs exist in the same container, using a full blown remote protocol for
communication adds needless overhead. Contain short circuit the remote protocol, when
both the beans live in the same container.
Support for persistence
EJB container provides Support for persistent to beans. EJBs (Entity Beans) are
not mandatory in the 1.x version of the EJB specification, but it will become mandatory,
but it will become mandatory in the 2.0 version. Persistence means that the state of an
object is saved to some sort of persistent storage (typically a file or a database) allowing
the object to be read in and used at some later time, instead of being recreated each time.
The container will then take responsibility for saving and restoring these fields.
The shifting of responsibility for transaction management, concurrency, security

and persistence to the container means that the bean developer can concentrate on the
business rules of his/her application for the specific services.
Support for security
EJB security is the main mechanism and it can be provided through access control list
(ACL). An ACL is a list of persons or groups that are allowed to access particular
pieces of functionality. Only those users who are included in the ACL will be able to
access the ACL protected beans others are not allowed.
2.4 ENTERPRISE BEANS
Figure 2.4 The Different types of EJB beans
The EJB Home Interface
All home interfaces must extend the EJBHome
Interface. public interface javax.ejb.EJBHome extends
java.rmi.Remote
public abstract EJBMetaData getEJBMetaData();
public abstract void remove (Handle handle);

public abstract void remove (Object primaryKey);
The home interface serves as the initial point of contact for a client. When the client uses
a naming service to lookup an EJB bean, the naming service returns a reference to an
object that implements the bean‘s home interface.
The home interface requires implementation of three methods namely,

getEJBMetaData(), remove(Handle handle) and remove(Object primarykey).
getEJBMetaData()
This call returns a reference to an object that implements the EJBMetaData
interface. public interface javax.ejb.EJBMetaData
{ public abstract EJBHome getEJBHome();
public abstract Class getHomeInterfaceClass();
public abstract Class getPrimaryKeyClass();
public abstract Class
getRemoteInterfaceClass(); public abstract
boolean isSession();
Builder tools can use the information in the EJBMetaData class to generate
wrapper classes to invoke methods on the bean.
remove(Handle handle)
This method removes an EJB object using a Handle, which is a serializable

reference to a particular bean.
remove(Object primaryKey)
This method removes an EJB object by its primary key. (Only an Entity bean can
have a primary key)
The EJBHome interface does not provide any methods by which a client can
create new beans or look up existing ones. Instead, the EJB bean developer must write the
method signatures for these tasks in their own interfaces.
A client uses a naming service to look up an EJB, getting a reference to an object that
implements its home interface to get a reference to the bean‘s remote interface.
The EJBObject Interface
All remote interfaces extend the EJBObject interface:
public interface javax.ejb.EJBObject extends java.rmi.Remote
public abstract EJBHome getEJBHome();
public abstract Handle getHandle();
public abstract Object getPrimaryKey();
public abstract boolean isIdentical (EJBObject obj);
public abstract void remove();
getEJBHome()
This method returns a reference to an object implementing the EJB object‘s home interface.
getHandle()
This method returns a handle, which is a serializable reference to the object.The

Handle interface specifies one method, getEJBObject(), which can be used to recreate a
remote reference from the handle.
getPrimaryKey()
This method returns the primary key used by the EJB object. Although it exists on
the interfaces for both session and entity beans, it really makes sense to use this method
only on an entity bean; session beans do not expose a primary key to the outside world,
and indeed need not have a primary key at all.
isIdentical()
This method provides a way to test whether two EJB object references refer to an
identical object. It is mainly useful for Entity Beans. Two Entity beans that are from the
same home interface and have the same primary key are considered identical.The two
references in this method do not necessarily point to the same object in memory, but all of
these instances are considered to have the same identity.
remove()
This method allows the caller to remove the remote EJB object.To create a remote
interface, simply create an interface that inherits from EJBObject and add the
method signatures of the methods. And there is no need to implement this remote
interface. Instead the container generates a proxy object that interacts with remote clients
and passes their method calls to the bean
The EnterpriseBean Interface
The top-level type in the EJB Class hierarchy is the EnterpriseBean
interface. public interface javax.ejb.EnterpriseBean extends
java.io.Serializable
This merely serves as a common point of ancestry for the Session and Entity
beans, and requires that its subinterfaces be serializable. The transaction attribute
logically belong with the Enterprise Bean interface, even though they‘re not associated
directly with it. Either a Session or an Entity Bean can be assigned any of the six available
transaction attributes.2.3
2.4.1 Session Beans

Session bean is another type of EJB. They are relatively short-lived. The stateful
session objects are created in response to a single client‘s request, communicate
exclusively with a single client and die when the client no longer needs them. A session
bean is required to implement the javax.ejb.SessionBean interface.
public interface javax.ejb.SessionBean extends javax.ejb.EnterpriseBean

{
public abstract void ejbActivate();
public abstract void ejbPassivate();

public abstract void ejbRemove();
public abstract void setSessionContext(SessionContext ctx);
}
All of the methods declared in this interface are callback methods; that is they are
invoked by the container to notify the Session EJB that some event has occurred.
ejbPassivate()
The Container calls this method to swap the EJB class out to ―semi-persistent‖
storage.The storage is ―semi-persistent‖ because Session EJBs do not carry the same sort
of guarantee of long life as Entity EJBs do. If the EJB container crashes or restarts, the
session beans that existed before the crash or restart are destroyed. Session bean also
have an associated timeout value; after the timeout expires, they are destroyed. If none of
these events happens the session bean can be sapped back in at some later time.
ejbActivate()
The ejbActivate() method is essentially the inverse of the ejbPassivate() call. The
container calls this method after a session bean‘s state has been restored from
―semi- persistent‖ storage, but before it becomes available to the outside world. A bean
can use the ejbActivate() call to restore any resources that is closed before being passivated.
ejbRemove()
This callback method in invoked by the container as a result of a client calling the
remove() method of a bean‘s home or remote interface. The client‘s invocation of
the remove() method notifies the container that this particular session bean instance
should be destroyed.
setSessionContext(SessionContext ctx)
This method is called at the very beginning of a session bean‘s life. The container
passes the session bean an object that implements the SessionContext interface. The
bean stores this object in an object variable, and can then use the SessionContext to
interact with container-provided services such as security and transaction management.
The EJBContext Interface
The SessionContext interface inherits from the EJBContext interface. The EJBContext
interface is the parent interface of both the SessionContext and EntityContext
interfaces.
public interface javax.ejb.EJBContext

{
public abstract Identity getCallerIdentity();
public abstract EJBHome getEJBHome();
public abstract Properties
getEnvironment(); public abstract boolean
getRollbackOnly();
public abstract UserTransaction
getUserTransaction(); public abstract boolean
isCallerInRole(Identity role); public abstract void
setRollbackOnly();
}
getCallerIdentity()
This method is used to get a java.security. Identity object that represents the
identity of the client.It can be used in concert with isCallerInRole() to allow the EJB
object to perform authorization checks before performing an operation.
getEJBHome()
This method is used to get a reference to its own home interface.This interface can
be used to create or find other instances of the bean class, or to do several other things.
getEnvironment()
This call returns the EJB‘s environment properties.These properties can be adjusted at
deployment time.
getRollbackOnly()
EJB supports distributed transactions. If any of the players in a distributed

transaction cannot continue for some reason, it can mark the transaction as ―rollback only‖.
A ―rollback only‖ transaction can never complete; it must be rolled back. A bean can use
this to check the status of a transaction before attempting to participate in it.
getUserTransaction()
The TX_BEAN_MANAGED transaction type, the bean is responsible for

beginning, committing and possibly rolling back its own transactions. If a bean has a
transaction
attribute of TX_BEAN_MANAGED, it can use getUserTransaction() to gain access to the

transaction.
The UserTransaction Interface
public interface javax.jtx.UserTransaction

{
public final static int STATUS_ACTIVE;
public final static int STATUS_COMMITTED;
public final static int STATUS_COMMITTING;
public final static int
STATUS_MARKED_ROLLBACK; public final static
int STATUS_NO_TRANSACTION; public final static
int STATUS_PREPARING;
public final static int STATUS_PREPARED;
public final static int STATUS_ROLLEDBACK;
public final static int
STATUS_ROLLING_BACK; public final static int
STATUS_UNKNOWN;
public abstract void begin();
public abstract void commit();
public abstract int getStatus();
public abstract void rollback();
public abstract void setRollbackOnly();
public abstract void setTransactionTimeout(int seconds);
}
The User transaction interface provides the classic ―begin‖, ―commit‖, and
―rollback‖ operations. , as well as getStatus() operation, which allows the caller to see the
status of the transaction. Also allows the caller to set a transaction timeout, enabling the
caller to set some upper bound on the execution time of the transaction.
isCallerInRole()
This boolean method can be used to test whether the caller has assumed a given
role. An EJB developer might specify several different roles that can be played by the users
of the class.
setRollbackOnly()
Calling this method sets the current transaction to ―rollback only‖.
The SessionContext Interface
public interface javax.ejb.SessionContext extends javax.ejb.EJBContext
public abstract EJBObject getEJBObject();
This contains only one method namely getEJBObject(). This method returns
a reference to an EJBObject. This remote reference to an object implements the bean‘s
remo te interface, and can be used if the bean wants to pass a reference to itself to some
other entity. EJB Container is responsible for creating objects that implement the remote
interface; these objects act as proxies, forwarding the business method calls to the object.
Session bean‘s home interface provides one or more ―create‖ methods.

―create‖ methods are invoked by clients to create new instances of a particular EJB
object. When a client invokes a create() method on the bean‘s home interface, the container
creates an object of the appropriate type, calls its setSessionContext() method, and then
calls a method in EJB class called ejbCreate().
The Rules for an ejbCreate() method in Session Beans are as follows:
The method must have a void return type. The container will pass the
remote interface back to the client.
The number and type of arguments to the ejbCreate() method must exactly match
the number and type of arguments in the corresponding create() method declared
in the home interface.
The following steps are involved in the creation of a new Session Bean:
The client calls a create() method in the bean‘s home interface.

The container sets aside storage for the object and instantiates
it. The container calls the object‘s setSessionContext() method.
The container calls the ejbCreate() method whose signature matches the create()
method invoked by the client.
Stateful and Stateless Session Beans Comparison
A stateless session bean is one that doesn’t keep track of any information from
one method call to another. It is essentially, a bean with no instance variables.
(Ex: CalculateInterest Bean). Any two instances of a stateless bean are equivalent. A
container can easily handle a stateless Session bean, because instances of a stateless
bean can be created and destroyed at will, without worrying about their state at the
time of their destruction.
A stateful session bean, is a bean that changes state during a conversation – that is,
a bean that has instance variables. (Ex: Shopping Cart Bean). The life cycle of a stateful
bean is more complex for the container than the stateless bean. Because, the container
have to maintain the state of the stateful session bean during swap out and swap in
process. According to the EJB specification, EJB Objects are not allowed to have static
variables.
The SessionSynchronization Interface
public interface javax.ejb.SessionSynchronization
public abstract void afterBegin();
public abstract void afterCompletion(boolean committed);
public abstract void beforeCompletion();
A session bean can implement the SessionSynchronization interface if it wishes to

be notified by the container about the state of any transaction in which it may be involved.
Even if a Session bean does not manage its own transactions via the UserTransaction
interface, it may still implement the SessionSynchronization interface. All of the
methods in the SessionSynchronization interface are callbacks.
afterBegin()
This method notifies the bean that a transaction has begun.
beforeCompletion()
This method indicates that a transaction is nearly complete. If the bean wishes to
roll back the transaction for some reason, it can call the setRollbackOnly() method
of the SessionContext interface.
afterCompletion()
The container calls this method after a transaction has been completed. Its
boolean argument will be set to true if the transaction was committed successfully, and
false if the transaction was rolled back. This interface must be implemented in the stateful
session bean because, the state of instance variables is not transactional. That is, if the
instance variables in a session bean are modified during the course of a transaction and
the transaction is then rolled back, the instance variables will not be automatically reset to
their original state prior to the transaction.
To reset the instance variables, the SessionSynchronization interface is needed and

use the afterCompletion() callback to read the state variables back out of the database.
Note that, a stateless session bean cannot implement this interface, because, it has no state,
there‘s no point in trying to synchronize its state with the database.
2.4.2 Entity Beans

Compared to Session Beans, the Entity Beans are long-lived; they exist across
client sessions, are shared by multiple clients, and remain alive even after a restart of the
server or other failure. Typically, an Entity EJB object represents a set of data in persistent
storage.
The EntityBean Interface
public interface javax.ejb.EntityBean

{
public abstract void ejbActivate();
public abstract void ejbLoad();
public abstract void ejbPassivate();
public abstract void ejbRemove();
public abstract void ejbStore();
public abstract void setEntityContext(EntityContext ctx);
public abstract void unsetEntityContext();
}
ejbActivate() and ejbPassivate()
These methods analogous to the methods of the same name in the SessionBean
Interface. ejbPassivate() is called before an Entity object is swapped out and ejbActivate()
is called after the Entity Object is swapped in.
ejbLoad() and ejbStore()
These operations allow the Entity bean to synchronize its state with an
underlying database. Under bean managed persistence the developer has to write the
coding in these methods. Under container managed persistence no coding is needed for
these methods.
setEntityContext() and unsetEntityContext()
setEntityContext() passes an object that inherits from EJBContext() to the EJB
instance. public interface javax.ejb.EntityContext extends
javax.ejb.EJBContext
{
public abstract EJBObject getEJBObject();
public abstract Object getPrimaryKey();
}
The getEJBObject() method in this interface is analogous to the method of the

same name in the SessionContext interface. The getPrimaryKey() method returns primary
key for this object. In the context of entity EJBs, a primary key is an object of some user
-defined type that can be used to look up a reference to a particular Entity EJB.
Because Entity EJBs can exist across many client invocations, the Entity
Bean interface includes an unsetEntityContext() method that allows the bean to discard its
previous context when it is destroyed.
ejbRemove()
The container invokes the ejbRemove() method when a client has called the
remove() method of the bean‘s home interface. The bean then has one last chance to put
affairs in order before being destroyed.
ejbFindByPrimaryKey()
This is implemented only if using bean-managed persistence; in container-

managed persistence, the container will generate automatically. The container invokes this
method
when a client invokes the findByPrimaryKey() method on an EJB‘s home

interface with a particular primary key. This key is passed to the container, which uses it to
look up the object and return a reference to its remote interface to the client.
Bean-Managed and Container-Managed Persistence
Entity beans are classified based on how they maintain synchronization. Entity beans
are intrinsically tied to an underlying database representation. The internal state of an
active Entity EJB should always be synchronized with its underlying data after a
transaction concludes. The EJB specification permits two
approaches to maintaining this
synchronization:
Bean-Managed persistence
Container-Managed persistence
In bean-managed persistence, the author of the bean must write necessary

database calls to send the object out to persistent storage and read it back in again. The
container calls ejbLoad() to notify the object that it should load its state in from a
database; so, here the developer has to write the code to read the state from the database.
Similarly, the ejbStore() notifies the object that it should write its state out to the database;
the developer has to write the code to write the state in the database.
In container-managed persistence, the developer has to do anything to

synchronize with the database. At runtime, container will invoke ejbLoad() and
ejbStore(), but the developer need not provide any implementations to these methods.
Reentrant and Non-reentrant Entity Beans
Entity EJBs are non reentrant defaultly. That is, if a call is being processed and
another call to the same object comes in with the same transaction context, the program
will throw a RemoteException and the call will not be allowed. It is possible to specify
in a deployment descriptor that an Entity EJB is reentrant that is, it will accept more than
one call in the same transaction context.
The developer might choose this approach so as to allow a remote object invoked by a
client to perform callbacks to the client. If possible, always avoid reentrant entity beans.
2.5 A HIGH LEVEL VIEW OF AN EJB CONVERSATION

In the EJB architecture, the client undertakes the following
tasks: Finding the bean

Getting access to a bean
Calling the bean‘s methods
Getting rid of the bean
2.5.1 Finding the bean

EJB specification mentions two ways in which a client can find a
bean.
1. Using the Java Naming and Directory Interface

2. Using the CORBA‘s Common Object Service (COS)
1. Using the Java Naming and Directory

Interface
JNDI API provides a uniform interface to naming and directory services. A naming service
is a service that associates a Symbolic Name with an object. Domain Name Service is
a commonly used naming service that is used to transfer symbolic machine names into
numeric IP addresses. Previous model of DNS, needed to maintain a file containing a list of
symbolic host names along with the numeric IP addresses that they should resolve to.
This approach was problematic for several reasons:
If the /etc/hosts/file developed errors, couldn‘t resolve symbolic names.

Needed to maintain the change of addresses when new machines were added.
If a machine did not appear in the /etc/hosts file, need to know its numeric IP
address to connect to it.
Using DNS approach allows us to avoid many of these annoyances. It works as

follows:
1. A client makes a query to a DNS server

2. If the DNS server knows how to resolve the address, it returns the address.
3. If the DNS server does not know how to resolve the address, it provides the query
to another DNS server
4. Once the server is able to resolve the name, it returns the address to the client.
Typically, it also caches the result so that, if the request is made again, it can be
handled immediately.
Where does JNDI fit in? JNDI provides a uniform interface to naming services. JNDI
client uses the Server‘s SPI (Server Provider Interface) to access its
services.
A Java client can use JNDI to lookup an EJB component. The JNDI call returns a
reference to an object implementing the EJB component‘s ―home‖ interface, which can
then be used to gain access to the EJB object itself.
2. Using the CORBA’s Common Object Service (COS)

The other way to find an EJB component is to use CORBA‘s Common Object
Services (COS) naming service. COS refers to a group of Services, including naming, that
is provided as part of the CORBA services specification. In addition to suing COS
naming directly, can make use it via JNDI.
2.5.2 Getting access to a bean

The result of the naming lookup is a reference to an object implementing the
EJB components home interface. A client uses the home interface to look up
existing EJB instances, or to create new ones. This lookup result in a reference to
an object that implements the EJB object‘s remote interface. The client uses the
remote interface to interact with the EJB objects on the server.
2.5.3 Calling the bean’s methods

After the client has a reference to an object implementing the object‘s
remote interface, it can then invoke the methods that the EJB object makes public in the
remote interface.
2.5.4 Getting rid of the bean

Finally, When the client has finished with an EJB object, it can call the remove()
method on the home interface or on the object‘s remote interface. In some cases, the
client may leave the object in existence. Usually remove() is called on a stateful session
bean when it is no longer needed, so that the container can discard it and use the space
for other beans. remove() method on the stateless bean can be invoked, but generally has
no effect; the server simply returns the instance to a pool. remove() on entity beans, would
remove the underlying object from persistent storage. (Ex: when the customer bean is
removed, the data will be deleted from the underlying database.)
2.6 EJB CLINET

Clients can interact with EJB either through CORBA or through RMI.
2.6.1 RMI client

Remote method invocation (RMI) has been included as part of the standard Java
API distribution since the release of java development kit(JDK) 1.1. It can be found
in the java.rmi package. This API allows a java program to find use java classes that
reside on remote machines. RMI client interact with objects on server thorough the
server object‘s remote interface. To the client, the object on a server represented b the
remote interface
appears to be an ordinary java class. When a method of a remote class is invoked,

however, the invocation is passed on to a class called a stub. One very cool aspect of EJB
is the fact that the EJB container automatically generates these stub classes.
EJB client that uses RMI will use the JNDI API to locate the home interface of
the desired bean. The client will then invoke a find () or create () method contained in the
bean‘s home interfaces; this call results in a reference to the beans remote interface.
2.6.2 CORBA clients

The EJB specification includes a mapping that allows us to use CORBA to
communicate with EJB objects. In CORBA, the developer specifies the interface for an
object in an IDL file, which defines the method and variables that will be made available in
a platform – and language –independent way. The IDL description is then run through
a language specific complier, which generates the classes necessary to converse over
th network.
The INDI to locate a bean‘s home interface, however, We use CORBA‘s COS naming
service. The pattern is
followed:
1. We use a naming service to find the bean‘s home interface

2. We use one of the find() or create() method of the bean‘s home interface to
create a new bean or obtain a reference to an existing bean.
3. We use the bean in our application.
2.7 BUILDING AND DEPLOYING EJBS

2.7.1 Writing the EJB
EJB Contains Three classes:
EJB implementation Class

Home Interface
Remote Interface
Each EJB must provide with a deployment descriptor. The deployment descriptor
is serialized instance of a Java class that contains information about how to deploy the
bean. Two flavors of deployment descriptors:
Session Descriptors – apply to Session EJBs

Entity Descriptors – apply to Entity EJBs
A Deployment Descriptor contains information such as the following
The name of the EJB Class

The name of the EJB Home Interface
The name of the EJB Remote Interface
ACLs of entities authorized to use each class or
method. For Entity Beans, a list of container – managed
fields.
For Session Beans, a value denoting whether the bean is stateful or stateless.
Properties File may be generated, which contains environment properties that will
be activated during runtime.
Manifest File is needed to create the ejb-jar file, which is the medium used to distribute
EJBs.
Name : <filename>
Enterprise-Bean: True
Deploying the EJBs
At the time of deployment, the EJB container must read the ejb-jar file, create
implementations for the home and remote interfaces. Reads the deployment-descriptor
and ensures that the bean has what it wants and the bean‘s property settings to the
environment so that they‘re available to the bean at runtime.
Connecting to the EJB
The final step is to access the bean from a client. The client can use either RMI or
CORBA to connect to the EJB. The client looks up the EJB‘s home interface using a
naming service (JNDI or COS). Invokes a find() or create() method on the home interface
to get a reference to an EJB object. And then uses the EJB object as if it were an ordinary
object.
2.7.2 Roles in EJB

EJB specification gives a clear description of each of these roles and their
associated responsibilities of its components.
Enterprise Bean Provider
The Enterprise bean provider is the person or group that writes and packages EJBs.
It might be a third-party vendor of EJB components, or it might be an information
systems programmer who writes EJBs to implement their company‘s business logic.
Because the container must provide transaction and network communication support, the
enterprise bean provider does not need to be an expert at low-level system programming,
networking or transaction processing.
The bean provider needs to be concerned only with business logic to be

implemented. The end product is an ejb-jar file, which contains the Enterprise bean, its
supporting classes, and information that describes how to deploy the bean.
Deployer
The deployer takes an ejb-jar file and installs it into an EJB container. The
deployer‘s task begins with the receipt of an ejb-jar file, and ends with the installation of
the ejb-jar file in the container. In the management information system(MIS)world, this
task is typically handled by the System Administrator in MIS world.
Application Assembler
An application assembler builds applications using EJBs classes. An MIS

programmer may purchase a prepackaged set of EJBs that implement an accounting
system. Then the programmer might use tools to customize the beans. The application
assembler might also need to provide a user-interface client program. This role is roughly
analogous to that of a Systems Integrator in the MIS world.
EJB Server Provider
An EJB Server Provider(Figure2.5) provides a server that can contain EJB

containers. The EJB 1.0 specification does not describe the interface between the
server and the container, so the EJB server provider and the EJB container provider will
likely be one and the same for any given product. The diagram shows the relationships
among the EJB server, the EJB container, and the EJB bean. An EJB server provides
services to an EJB container and an EJB container provides services to an Enterprise Java
Bean.
The role of the EJB server provider is similar to that of a database system vendor.
The server provider offers the container whatever services it needs to do it job. The
server provider will typically have a great deal of expertise in area such as concurrent
programming, transaction programming, and network communication.
Figure 2.5 The relationship among the EJB server, container, and bean
EJB Container Provider
An EJB container is the world in which an EJB bean lives. The container
services requests from the EJB, forwards requests from the client to the EJB, and
interacts with the EJB server. The container provider must provide transaction
support, security and persistence to beans. It is also responsible for running the beans
and for ensuring that the beans are protected from the outside world.
System Administrator
System Administrators are responsible for the day-to-day operation of the EJB
server. Their responsibilities include keeping security information up-to-date and
monitoring the performance of the server. The role of the system administrator will likely
be understand by a company‘s current system administration.

Middleware Notes 1,2

Uploaded by

Document Information

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

Middleware Notes 1,2

Uploaded by

Copyright:

Available Formats

MIDDLEWARE

UNIT I CLIENT / SERVER CONCEPTS 9

UNIT II EJB ARCHITECTURE 9

EJB – EJB architecture – Overview of EJB software architecture – View of EJB

UNIT III EJB APPLICATIONS 9

CORBA – Distributed systems – Purpose – Exploring CORBA alternatives – Architecture

RMI - Remote Method Invocation

1.1 INTRODUCTION 1.1

1.3 TYPES OF SERVERS

1.4 MIDDLEWARE DEFINITION 1.17

1.5 CLIENT SERVER BUILDING BLOCKS

1.6 INSIDE THE BUILDING BLOCKS 1.23

1.8 MESSAGING AND QUEUING : THE MOM MIDDLEWARE 1.32

UNIT II EJB ARCHITECTURE 2.1 – 2.23

2. ENTERPRISE JAVA BEAN

2. 1 EJB LOGICAL ARCHITECTURE 2.1

2.2 OVERVIEW OF EJB’S SOFTWARE ARCHITECTURE

2.2.1 EJB Servers 2.3

2.3 ENTERPRISE BEANS

2.3.1 Sessio n Beans 2.11

2.4 A HIGH LEVEL VIEW OF AN EJB CONVERSATION 2.19

2.4.1 Finding the bean 2.20

2.5 EJB CLINET 2.21

2.5.1 RMI client 2.21

2.6 BUILDING AND DEPLOYING EJBS 2.22

2.6.1 Writing the EJB 2.22

3. ENTERPRISE JAVA BEAN 3.1

3.1 SESSION BEAN 3.2

3.1. 1 The Life Cycle of a Stateful Session Bean 3.4

3.2 WHAT IS AN ENTITY BEAN 3.5

3.2.1 The Life Cycle of an Entity Bean 3.9

3.3 TRANSACTION AND EJB 3.12

3.3.1 Container-Managed Transactions 3.13

3.4 WHAT IS A MESSAGE-DRIVEN BEAN? 3.25

3.4.1 The Life Cycle of a Message-Driven Bean 3.26

3.5 EJB CLIENT 3.27

3.5.1 Defining Client Access with Interfaces 3.27

3.6 DEPLOYMENT DESCRIPTORS 3.31

3.7 BUILDING AN APPLICATION WITH EJB 3.33

UNIT IV CORBA 4.1 – 4.41

4.1 HISTORY OF DISTRIBUTED SYSTEMS 4.1

4.2 EXPLORING CORBA ALTERNATIVES 4.2

4.3 CORBA 1.0 4.4

4.4 The CORBA Communications Model 4.6

4.5 MARSHALING 4.9

4.6 CORBA and the Networking Model 4.11

4.8 MASTERING THE INTERFACE DEFINITION LANGUAGE `4.17

4.9 BUILDING AN APPLICATION WITH CORBA 4.32

UNIT V COM 5.1 – 5.29

5.1 COM 5.1

5.2 COM DATA TYPES 5.7

5.2.1 COM Data Type Mapping 5.9

5.7 SIMILARITIES AND DIFFERENCE OF COM AND CORBA 5.16

1.2 CLIENT–SERVER MODEL

Figure 1.1 Client/Server Computing

1.2.1 Advantages of Client/Server Model

1.2.2 Disadvantages of Client/Server Model

1.2.3 Characteristics of Client/Server Model

Asymmetrical protocols : There is a many-to-one relationship between clients and

Mix-and-match: The ideal Client/Server software is independent of hardware and

Mix and match: The ideal client/server software is independent of hardware or

Encapsulation of services: The server is a ―specialist‖. A message tells a server

CREATE TABLE acidtest (A INTEGER, B INTEGER CHECK (A + B =

Assume that a transaction attempts to subtract 10 from A without altering B.