Object and component based middleware for distributed system development

INTRODUCTION
Traditionally computer software ran in stand-alone systems, where application processing, user
interface and persistent data resided in one computer. Whereas the objects and locally distributed
components are located on the computers utilizing them, distributed components are typically
located on machines other than those making call to them [1]. With the growth of technology and
certain challenges of software development in stand-alone systems, most computer software
today runs in distributed systems, where the data resources, interactive presentation, application
business processing, and data resources reside in loosely-coupled nodes and service tiers
connected together by networks. Some challenges faced by stand alone systems are described as
under:

LOAD-SHARING
The use of distributed software development facilitates the interaction across machine
boundaries, and this allows system to harness the resources of multiple computers.
Consequently, a number of systems may be involved in processing the request, potentially
removing the bottlenecks in performance.

INCREASED AVAILABITLITY
Distribution of components may result in increased system availability, with multiple instances
of each object residing on machine in network. If the instances are sharing load then the loss of
one host will result in the load being distributed through the remaining machines.

HETEROGENITY
Different hardware and software platforms store data in different ways. Distributed systems
overcome this problem by utilizing a middleware layer that resolves the heterogeneity issues.
The middleware enables distributed components to exist on multiple different platforms, and still
interact with one another.

CHAPTER 1

MIDDLEWARE

Middleware is the layer of software that mediates between the application and the software. It is
responsible for managing the interaction between components distributed over heterogeneous
computing platforms.

There are four categories of middleware technologies identified by Wolfgang Emmerich. They
exhibit different properties, and these classifications are as follows:

1.1 TRANSACTION ORIENTED
Transactional middleware enables distributed components to ensure that an atomic operation
either occurs completely or not at all. This is achieved by the use of a two-phase commit
protocol. A transactional middleware does create some overhead, so if transactions are not
required for an operation this is an unnecessary additional cost. Transaction-oriented middleware
is commonly used in distributed databases.

1.2 MESSAGE ORIENTED
This form of middleware provides message transmission, receipt and queuing services to
distributed components. Messages are used to transmit service requests, updates and responses to
requests. Messages are held in queues until they are de-queued by receiving component and this
ensures messages are not lost when a host is busy or unavailable.

Message oriented middleware provides asynchronous communication between components,
reducing the coupling between the components. This leads to systems that are more scalable,
with less tightly coupled components.

1.3 PROCEDURAL
The most common form of procedure oriented middleware is Sun Microsystems’ remote
procedure call technologies. This enables the components on one computer to invoke procedure
or method located on other computers. The invocation or any associated parameters are
marshaled into messages and these are sent from one machine to another. The invocation
semantics with procedural middleware are commonly synchronous- with invoker being blocked
until the response is received.

1.4 OBJECT ORIENTED
Object oriented middleware is based on object oriented paradigm, and extends the functionality
of procedural middleware to provide additional facilities required for use in an object oriented
environment.

There are a number of object oriented middleware technologies used in IT industries, report has
detailed study of CORBA and J2EE middleware.

CHAPTER2

OBJECTS AND COMPONENTS

2.1OBJECTS
An object can be defined as a concept, abstraction or thing with crisp boundaries and meaning
for problem at the hand. The features often associated with objects are

An object has
State
Operations
Attributes
Provides an abstraction
Represents something real
Is self-contained
Is clearly defined

2.2 COMPONENTS
A component can be thought of as a collection of objects that provide a set of services to other
systems. They have many features in common with objects, but are less fine grained. Examples
of components include code that provides graphing facilities; provide network communication
services; or perhaps a search and browsing service around a set of tables in a database.

A component is ―A self- contained entity that exports functionality to its environment and may
also import functionality from its environment using well-defined and open interfaces‖. This
definition highlights a number of differences from objects:

Components are self–contained.

Provide services to other systems
Use stated interfaces to interact with other systems

Components may run either locally or in a distributed fashion. Many examples of locally run
components exist and are commonly used to provide specific functionality to external programs.
The Object Linking and Embedding (OLE) architecture was one of the first component
frameworks in common use, and this enabled the use of specialized functionality from one
program to be used in another program. An example of this is the use of Microsoft Excel
spreadsheets in Microsoft Word [2].

CHAPTER 3
CORBA
The Object Management group’s (OMG) Common Object Request Broker Architecture
(CORBA) is an important and popular technology that supports the development of object based
distributed applications.‖ORB is a middleware that establishes the client server relationships
between the objects. Using an ORB the client can inherently invoke a method on the server
object, which can be on the same machine or across a network”. CORBA is intended to provide
a standardized platform for which to construct distributed components. A CORBA application
consists of a number of objects that store data and export functionality to other objects. CORBA
enables separate pieces of software written in different languages and running on different
computers to work with each other like a single application or set of services. CORBA uses an
interface definition language (IDL) to specify the interfaces of objects present to the outer world.
CORBA is language independent and has language bindings to Java, C, C++ and many other
common programming languages [3].

The CORBA specification dictates there shall be an ORB through which an application would
interact with other objects. In practice, the application simply initializes the ORB, and accesses
an internal Object Adapter, which maintains things like reference counting, object (and
reference) instantiation policies, and object lifetime policies. The Object Adapter is used to
register instances of generated code classes, which are a result of compiling the user IDL code,
which translates the high-level interface definition into an OS- and language specific class base
for use by the user application. This step is necessary in order to enforce CORBA semantics and
provide a clean user process for interfacing with the CORBA infrastructure. ORB is an abstract
entity that acts as a middleman in all remote method invocations. The ORB finds a server can
handle a method invocation, passes the request to the server, receives the response and forwards
it to the client. The functions handled by ORB are actually implemented by both client and
server.

3.1 PURPOSE OF CORBA

3.1.1VENDOR INDEPENDENT INTEROPERATIBILTY

Middleware that’s everywhere - is the main purpose of CORBA, which try to provide perfect
interoperability among any OS, hardware, and system. We might see the immediate benefit by integrating
legacy systems on mainframe computers and/or traditional client-server models with relatively new
component based systems on web technologies. Not only the interoperability among the variety of system
(architecture) styles but also interoperability among different vendors produces significant benefit for
users. ―Open system‖ was the first step for vendor independent interoperability but still had a limitation in
architecture point of views. CORBA could be rephrased to ―the road to the perfect open system‖.

3.1.2 Implement ORB functions (narrow definition in OMA)

The purpose of CORBA in OMA is to implement ORB functions. OMA has CORBA-related
objects: CORBAservices [OMG 1998b], CORBAfacilities, and CORBAdomains.

o CORBAservices provide low-level, base-type services such as transactions, security, life-
cycle, and naming.

o CORBAfacilities provide a higher-level set of services such as printing management.

o CORBAdomains represent vertical domain-related standards such as manufacturing,
telecommunication, healthcare, financial and so on.

o Application objects, other than these CORBA related objects, are not standardized as part
of OMG activities.

3.2 ARCHITECTURAL DESCRIPTION:
Any relationship between distributed objects has two sides: the client and server. The server
provides a remote interface, and client calls a remote interface. These relationships are common
to most distributed object standards, including RMI and CORBA. Note that in this context, the
terms client and server define object-level rather than application-level interaction any
application could be a server for some objects and clients for others [4].

On the client side, the application has a reference for the remote object. The object reference has
a stub method, which is a stand-in for the method being called remotely. The stub is actually
wired into the ORB, so that calling it invokes the ORB’s connection capabilities, which forwards
the invocation to the server.
On the server side, the ORB uses skeleton code to translate the remote invocation into a method
call on the local object. The skeleton translates the call and any parameters to their
implementation-specific format and calls the method being invoked. When the method returns,
the skeleton code transforms results or errors, and sends them back to the client via ORB’s.
Between the ORBs, communication proceeds by means of a shared protocol, IIOP-the Internet
Inter-ORB Protocol. IIOP, which is based on the standard TCP/IP internet protocol and works
across the internet, defines the procedure how CORBA-compliant ORBs pass information back
and forth [5].
Like CORBA and IDL, the IIOP standard is defined by OMG, the Object Management Group.
IIOP allows clients using a CORBA product from one vendor to communicate with objects using
a CORBA product from another vendor thus permitting interoperability, which is one of the
goals of the CORBA standard.
CORBA-compliant ORBs provides a number of services like maintaining persistent objects,
supporting transaction processing, enabling messaging and many other abilities useful in today’s
distributed, multi-tiered computing environments .

3.3Architectural description of CORBA with layered an
sequential diagram on physical view basis

Figure. 1

3.4 DESCRIPTION OF ELEMENTS OF DIAGRAM

3.4.1.CLIENT
This is the program entity that invokes an operation on an object implementation. Accessing
the services of a remote object should be transparent to the caller. Ideally, it should be as
simple as calling a method on an object i.e. obj ->op (args).

3.4.2.OBJECTS/SERVANTS
An object is an identifiable, encapsulated entity that provides one or more services that can
be requested by a client [6]. Rambaugh adds that an object is ―a concept, abstraction or thing
with crisp boundaries and meaning for the problem at hand‖ [3].An implementation
programming language entity for operations corresponding to the IDL interface. Servants can
be written in a variety of languages, including C, C++, Java, Smalltalk and Ada.

3.4.3.Object Request Broker
The ORB simplifies distributed programming by decoupling the client from the details of
method invocations. This makes client requests appear to be local procedure calls). ORB is
responsible for finding the object implementation, transparently activating it if necessary,
delivering request to the object, and returning any response to the caller.

Figure .2 ORB Client Request

3.4.4 ORB Interface
CORBA specifies an abstract interface for the ORB that can be implemented in various ways
(such as one or more processes or a set of libraries). This interface provides various helper
functions such as converting object references to strings and vice versa, and creating
argument lists for requests made through DII (Dynamic Invocation Interface) [7].

Figure .3 Structure of Object Request Interfaces

3.4.5 IDL STUBS AND SKELETONS
CORBA IDL Stubs and skeleton serve as the ―glue‖ between the client, server and ORB. The
transformation between IDL definitions and target programming language is done by IDL
compiler. The use of a compiler reduces the potential for inconsistencies between client stubs
and server skeletons.

3.5 MAJOR COMPONENTS OF CORBA
3.5.1 Interface Definition Language (IDL)
The interface is the syntax part of the contract that the server object offers to the clients that
invoke it. Client access objects only through their advertised interface, invoking only those
operations that the object exposes through its IDL interface, with only those parameters (input
and output) that are included in the invocation. A cornerstone of the CORBA standards is the

Interface Definition Language. IDL is OMG defining language-neutral API’s and provides the
platform-independent delineation of the interfaces of distributed objects. The ability of the
CORBA environments to provide consistency between clients and servers in heterogeneous
environments begins with a standardized definition of the data and operations constituting the
client/server interface. This standardized mechanism is the IDL, and is used by CORBA to
describe the interfaces of objects. It has following features:

The services that an object provides are given by its interface. Interfaces are defined in
OMG’s Interface Definition Language (IDL). IDL is independent of any programming
language.
Mappings from IDL to specific programming languages are defined as part of the
CORBA specification. Mappings for C, C++, Smalltalk, Ada, COBOL and Java have
been approved by OMG.
The syntax of both Java and IDL were modeled to some extent on C++, so there are a lot
of similarities between the two in terms of syntax. However, there are differences
between IDL and Java.

Figure.4 IDL Implementations

3.5.2 IIOP
The CORBA standard includes specifications for inter-ORB communication protocols
that transmit object requests between various ORBs running on the network. The
protocols are independent of the particular ORB implementations running at either end.
An ORB implemented in Java can talk to an ORB implemented in C, as long as they are
both compliant with the CORBA standard[8]. The inter-ORB protocol delivers messages
between two ORBs. These messages might be method requests, return values, error
messages etc. The inter-ORB protocol (IIOP) also deals with differences between two
ORB implementations, like machine-level byte ordering etc. As a CORBA developer,
you don’t have to be concerned with the low-level communication protocol between
ORBs. If you want two ORBs to talk, just make sure they both speak the same inter-ORB
protocol (IIOP).

The Inter-ORB Protocol (IIOP) is an inter-ORB protocol based on TCP/IP and so is
extensively used on the Internet.

3.5.3 PORTABLE OBJECT ADAPTER

CORBA Server Object

POA

ORB

The POA connects the server object implementation to the ORB. It extends the
functionality of the ORB and some its services include: activation and deactivation of the
object implementations, generation and management of object references, mapping of
object references to their implementations, and dispatching of client requests to server
objects through a skeleton.

3.6 COMMON OBJECT SERVICES(COS)

. They are defined on the top of the ORB, as standard CORBA objects with IDL interfaces.

Figure.5 Common Object Services

3.6.1 POPULAR SERVICES

Naming Services

Defines how CORBA objects can be looked up by a name. It is a Common Object
Service (COS) and allows an object to be published using a symbolic name and allows
clients to obtain references to the object using a standard API.
The CORBA naming service provides a naming structure for remote objects.

Event services

Another COS that provides a supplier-consumer communication model that creates
asynchronous communication between the objects via an Event Channel[9]. The flow of data
into the Event Channel is handled by supplier objects, while the flow of data out of the Event
Channel is handled by consumer objects. The Event service supports both the push and pull
model. In the push model the supplier objects control the flow of data by pushing it to the
consumers, and in the pull model the consumer objects control the flow of data by pulling the
data from the supplier. Instead of directly communicating with each other, the supplier and

consumer can obtain a proxy object from Event Channel and communicate it. Supplier objects
obtain a consumer proxy and consumer objects obtain a supplier proxy.

Security services

Provides a means to authenticate messages, authorize access to objects and provide secure
communications

Transaction services

Defines a means to control an action against a database or other subsystems.

3.7 SUPPORTED QUALITY ATTRIBUTES

3.7.1 Reusability (Interoperability)
A variety of systems, computer languages and vendors can be integrated into one total enterprise
system. This attribute goes into two ―well known‖ Quality attributes. The significant benefit of
CORBA could be the integration of huge legacy systems such as mainframe systems and new
systems. For example, it is too costly to reengineer the huge COBOL programs and systems in
order to integrate with new systems while they want a seamless integration for a total enterprise
system. CORBA allows these companies to reuse the most of legacy systems for the total
system with minor modification.

3.7.2 Modifiability
Since all implementation was hidden by IDL, the internal logic in a component can be easily
modified. And also the component location (server location) can be changed without affecting
calling components (clients) since Naming service provide the latest information of server side
components dynamically.

3.7.3 Extensibility
Since the number of vendors is growing, existing CORBA systems have a significant probability
to integrate more systems, devices and software into themselves. And also naming service
contributes extensibility by allowing the system to expand with more servers.

3.7.4 Productivity
We can integrate variety of software components written by different languages so developer
might be able to choose the best or most familiar language to develop each component, which
has favorable impact on productivity.

3.8 NON-SUPPORTED QUALITY ATTRIBUTES

3.8.1 Performance
Since all communication with remote components has to go through CORBA mechanism, the
response time could be an issue because of more layers among communication. So, platform
dependent own socket programs over TCP/IP with C language will produce much faster through
put than the combined CORBA components.

3.8.2 Security
Since the total system will be highly distributed with multiple vendor products, more security
holes are likely to be embedded into the system. Moreover the root cause of system troubles
could be difficult to be identified in highly integrated environment.

3.9 TRADE OFFS
3.9.1 Reusability (Interoperability) vs. Performance
To integrate a variety of systems in heterogeneous environment, developers had to add more
layers and steps for the communication mechanism and sacrifice performance due to additional
steps.

3.9.2 Extensibility vs. Security

The ability to extend system by adding new servers for load balanced or business needs might
increase the number of weak points (security holes) in the system. In theory, the more network
communications are executed, the more chances are raised for intrusion (Distribution systems
have weaker than centered systems).

3.9.3 Consistency and original intent
OMG provides ISO standards for some core specifications such as IDL and keeps consistency
among the products from a variety of vendor. In spite of the small number (11) of the original
organizations, the number of participants is growing up to 800 now. The original intent,
―middleware that’s everywhere‖ seems to meet. Even though one of the original organizations,
Sun Microsystems, has started own architecture, EJB, but Sun is positioning EJB to provide
seamless integration with CORBA environment by RMI-IIOP methods for communication.
Another big architecture, DCOM from Microsoft, can also be integrated with CORBA with
DCOM/CORBA bridges. Overall CORBA’s original intention is kept and the industry trend
seems to be going forward to support CORBA.

3.10 ADAVANTAGES OF CORBA

3.10.1 Maturity
The original version of the CORBA standard was defined in 1991. This first version of the
specification was deliberately limited in scope. The OMG’s philosophy was to define a small
standard, let implementors gain experience and then slowly expand the standard to incorporate
more and more capabilities. This ―slow but sure‖ approach has been remarkably successful. In

particular, there have been few backwards-incompatible changes to the CORBA specification.
Instead, new versions of the specification have tended to add new functionality rather than
modify existing functionality. Today, CORBA is extremely feature-rich, supporting numerous
programming languages, operating systems, and a diverse range of capabilities—such as
transactions, security, Naming and Trading services, messaging and publish-subscribe services—
that are essential for many enterprise-level applications. Many newer middleware technologies
claim to be superior to CORBA but actually have to do a lot of ―catching up‖ just to match some
of the capabilities that CORBA has had for a long time.

3.10.2 Open standard

CORBA is an open standard rather than a proprietary technology. This is important for a variety
of reasons.

First, users can choose an implementation from a variety of CORBA vendors (or choose one of
the freeware implementations). You might think that switching from one CORBA product to
another would involve a lot of work. In contrast, if you use a proprietary middleware system then
switching to another proprietary middleware vendor is much more challenging.

Second, the competition between different CORBA vendors helps to keep software prices down.

Finally, many proprietary middleware technologies are designed with the assumption that
developers will build all their applications using that particular middleware technology, and so
they provide only limited support for integration with other technologies. In contrast, CORBA
was designed with the goal of making it easy to integrate with other technologies. Indeed, the
CORBA specification explicitly tackles integrations with TMN, SOAP, Microsoft’s (D)COM
and DCE (a middleware standard that was popular before CORBA). Furthermore, many parts of
J2EE borrow heavily from concepts in CORBA, which makes it relatively easy to integrate J2EE
and CORBA. Some vendors sell gateways between CORBA and J2EE that make such
integration even easier. Several CORBA vendors sell COM-to-CORBA and/or .NET-to-CORBA
gateways. This provides a very pragmatic solution to organizations that wish to write GUI
applications in, say, Visual Basic on Windows that act as clients to server applications on a

different type of computer, such as UNIX or a mainframe. The Visual Basic GUI can be written
as a COM/.NET client that thinks it is talking to a COM/.NET server, but in fact communicates
with a gateway that forwards on requests to a CORBA server.

3.10.3 Wide platform support

CORBA implementations are available for a wide variety of computers, including IBM OS/390
and Fujitsu Global Server mainframes, numerous variants of UNIX (including Linux), Windows,
AS/400, Open VMS, Apple’s OS X and several embedded operating systems. There are very few
other middleware technologies that are available on such a wide range of computers.

3.10.4 Wide language support
CORBA defines standardized language mappings for a wide variety of programming languages,
such as C, C++, Java, Smalltalk, Ada, COBOL, PL/I, LISP, Python and IDLScript. Some small
organizations might use a single programming language for all their projects, but as an
organization increases in size, it becomes increasingly likely that the organization will make use
of several programming languages. Likewise, the older an organization is, the higher the
likelihood becomes that some of its ―legacy‖ (older) applications are implemented in one
programming language and newer applications are implemented in a different programming
language. For these organizational reasons, it is important for a middleware system to support
many programming languages; unfortunately, not all middleware systems do so. One extreme
case of this is J2EE, which supports only Java. Another extreme case is the SOAP middleware
standard. SOAP applications can be built with a variety of programming languages but, at the
time of writing, the SOAP standard defines only one language mapping (for Java). There may be
several vendors who support, say, C++ development of SOAP applications, but each of those
vendors provides their own proprietary C++ APIs. This means that there is no source-code
portability of non-Java SOAP applications across different vendor products.

3.10.5 Efficiency
The on-the-wire protocol infrastructure of CORBA ensures that messages between clients and
servers are transmitted in a compact representation. Also, most CORBA implementations

marshal data (that is, convert data from programming-language types into a binary buffer that
can be transmitted) efficiently. Many other middleware technologies also use a similarly
compact format for transmitting data and have efficient marshaling infrastructure. However,
there are some notable exceptions, as I now discuss.

SOAP uses XML to represent data that is to be transmitted. The verbosity of XML results in
SOAP using much more network bandwidth than CORBA. SOAP-based applications also incur
considerable CPU overhead involved in formatting programming-language types into XML
format and later parsing the XML to extract the embedded programming-languages types.

Some other middleware technologies, such as IBM MQ Series, transmit only binary data, which
is efficient. However, this requires that developers write the marshaling code that copies
programming-language types into the binary buffers prior to transmission, and the unmarshalling
code to extract the programming-language types from a binary buffer. In contrast, a CORBA
IDL compiler generates the marshaling and unmarshalling code, so that developers do not need
to write (and maintain) such low-level code.

3.10.6 Scalability
The flexible, server-side infrastructure of CORBA makes it feasible to develop servers that can
scale from handling a small number of objects up to handling a virtually unlimited number of
objects. Obviously, scalability varies from one CORBA implementation to another but, time and
time again, real-world projects have demonstrated that a CORBA server can scale to handle not
just a huge amount of server-side data, but also high communication loads from thousands of
client applications. Most CORBA vendors will likely know of customers who have tried a
different middleware technology, found that it could not scale sufficiently well and then switched
to CORBA.

3.10.7 Transparency

Object location transparency

The client does not need to know where an object is physically located. An object can either be
linked into the client, run in a different process on the same machine, or run in a server on the
other side of the planet. A request invocation looks the same regardless, and the location of an
object can change over time without, breaking applications.

Server transparency

The client is, as far as the programming model is concerned, ignorant of the existence of servers.
The client does not know (and cannot find out) which server hosts a particular object, and does
not care whether the server is running at the time the client invokes a request.

Language transparency

Client and server can be written in different languages. This fact encapsulates the whole point of
CORBA; that is, the strengths of different languages can be utilized to develop different aspects
of a system, which can interoperate through IDL. A server can be implemented in a different
language without clients being aware of this.

Operating system transparency

Client and server are unaffected by each other's operating system. In addition, source code does
not change if you need to port the source from one operating system to another

Protocol transparency

Clients and servers do not care about the data link and transport layer. They can communicate
via token ring, Ethernet, wireless links, ATM (Asynchronous Transfer Mode), or any number of
other networking technologies.

3.11 EXAMPLES OF CORBA PRODUCTS

CHAPTER 4

J2EE AND EJB

The java 2 Enterprise edition provides a multiplatform distributed component platform. It
consists of a set of services and protocols that are used at each level of a multi-tier distributed
system. It provides services for all tiers of the J2EE distributed component architecture as shown
in fig.6[10].

Figure .6

The client-tier provides an interface for the user to interact with the system. This may be in one
of several forms: it could be a web browser (such as Netscape Navigator or Internet explorer), a
Java applet or Java-based client program.
The web-tier consists of Java server pages or servlets, which process and respond to requests
from client tier. The components of the web-tier obtain data and process information using the
business-tier.
The business-tier is implemented in Enterprise JavaBeans (EJBs) and is commonly referred to as
Business Logic of the application. The EJBs are executed in a bean container – an application
that controls the execution of JavaBeans and provides services such as transaction management,

database connection pooling, security and authorization facilities, remote machine connectivity,
component persistence and replication[11].

Behind the business-tier is the EIS-tier, which is comprised of the Enterprise Information
Systems (EIS). This category contains; databases, transaction processing systems, resource-
planning systems and other large-scale information systems and these will often be accessed by
many different n-tier systems. For example, a bank may have one J2EE application for its traders
to use, a system for external clients to trade, and another for reporting and monitoring functions
all utilizing the same transaction processing system.

4.1 MOTIVATION FOR J2EE
Due to the need for multi tier computing model in web environment. A well-designed software
application is partitioned into separate logical parts called layers. Each layer has a different
responsibility in the overall architecture. These layers are purely abstractions, and do not
correspond to physical distribution.
Typical layers in a software system are as follows:
• Presentation layer. In this layer are parts that handle the user interface and user interaction.
• Business logic layer. This layer contains components that handle the programming logic of the
application.
• Data layer. This layer is used by the business logic layer to persist state permanently. This
layer normally consists of one or more databases where data is stored. However, other types of
data store could also be used. For example, it is now very common to use XML documents as
storage to keep data.

4.1.1 The Two-Tier Architecture

A two-tiered application is a simple client-server application in which the processing workload
falls onto the client computer's shoulders and the server simply acts as a traffic controller
between the client and the data. The term "fat client" for this type of architecture is due to the
bulk of processing requirements at the client side. In this architecture, the presentation layer and
the business logic layer are hosted in one tier and the data layer is on another tier. The drawback
of this type of architecture is that it starts to pose problems as the number of clients increases.

The first problem is due to the fact that all processing happens at the client side. There is
increased network traffic because each client has to make multiple requests for data from the
serve—even before presenting anything to the user. Another problem is cost because each client
needs a machine with sufficient processing power. As the number of clients increase, the cost for
providing client machines alone could be astronomical. However, the most severe problem that
this type of architecture can cause is probably a maintenance problem. Even a tiny change to the
processing logic might require a complete rollout to the entire organization. Even though the
process can be automated, there are always problems with larger organizations because some
users may not be ready for an upgrade, whereas others insist it be performed immediately.

4.1.2 The Three-Tier Architecture
To overcome the problems in many client two-tiered applications, an application is broken up
into three separate tiers, instead of two. The first tier contains the presentation layer, the second
tier, or the middle tier, consists of the business logic layer, and the third tier contains the data
layer.

4.1.3 The n-Tier Architecture: Vision of J2EE

To achieve more flexibility, the three tiers in the three-tiered application can be segregated even
further. An application with this type of architecture is called an n-tiered application. In this
architecture, the business logic layer is divided by function instead of being physically divided. It
breaks down like the following:
• A user interface. This handles the user interaction with the application. In an Internet
application, this is usually a web browser used to render HTML tags.
• Presentation logic. This defines what the user interface displays and how user requests
are handled.
• Business logic. This models the application business logic.
• Infrastructure services. These provide additional functionality required by the
application components.
• The data layer. Hosts the application data.

Advantages of Multi-tiers
• Tiers separate functionality:
– Presentation Logic, Business Logic, Data Schema
• Easier upgrade since one tier can be changed without changing the rest
• Lower deployment and maintenance cost
More flexible (can support changes), more extensible (can add functionality)
J2EE is open standard n-tier architecture for developing, designing, deploying and assembling
component based enterprise applications. It provides reusability, scalability, interoperatabilty,
enhanceabilty. The reason for choosing J2EE is
• Simplifies the complexity of a building n-tier application
• Standardizes an API between components and application server container
• J2EE Application Server and Containers provide the framework services

4.2 J2EE Components & Services
• Components
- Java Servlets
- JavaServer Pages (JSP)
- Enterprise JavaBeans (EJB)
• Standard services & supporting technologies
- Java database connectivity(JDBC) data access API
- Java Messaging Service (JMS)
(Remote Method Invocations (RMI))
- Extensible Markup Languages(XML)
- JavaIDL (Interface Description Language)
- JavaMail
- Java Security

4.3 Basic Model-View-Controller(MVC) Architecture

MVC Architecture has implemented by Trygve Reenskaug at 1979 for the first time. It was
implemented on Smalltalk at Xerox labs. Then benefits and advantages of this architecture has
been accepted by most of the coders and software engineers.

4.3.1Model
It handles data processing and database works part. Model processes events sent by controller.
After processing these events then it sends processed data to controller (thus, controller may
reprocess it) or directly to view side.

4.3.2View
View prepares an interface to show to the user. Controller or model tells view what to show to
the user. Also view handles requests from user and informs controller.

4.3.3Controller
The controller is responsible for responding to user input and performs interactions on the data
model objects. The controller receives the input, it validates the input and then performs the
business operation that modifies the state of the data model.

Advantages of MVC

1. They are resuable : When the problems recurs, there is no need to invent a new solution,
we just have to follow the pattern and adapt it as necessary.
2. They are expressive: By using the MVC design pattern our application becomes more
expressive.

Figure.7 MVC Architecture

4.4 ENTERPRISE JAVA BEANS

Enterprise JavaBeans (EJBs) components are that are used to provide the business logic for a
J2EE application. They consist of a number of Java classes that have been packaged
appropriately and are deployed to an EJB container that creates and manages the components.
EJBs communicate using either Java Remote Method Invocation, or with Java Message Queues.
There are a number of different types of EJBs, and are examined below:

4.4.1 SESSION BEANS

A session bean is used to represent the state of a single interactive communication session
between a client and business-tier of the server. Session beans are transient; when a session is
completed the associated session bean is discarded. If an application server fails, any session
beans currently available to it are lost, as they are not stored in stable storage. There are two
categories of session beans.
STATEFUL session bean hold the conversational state and one of these is required for each of
the sessions that are currently open.

STATELESS session beans hold no state (outside of calls) and receive all of their required input
from the client-tier. These beans may be pooled and reused, thereby reducing the overheads of
many clients accessing one server.

4.4.2 ENTITY BEANS

Entity beans provide an in-memory copy of long-term data. They are persistent, and are saved to
stable storage to ensure they are preserved across machine crashes. Many clients may access an
individual entity bean, and can find them by searching for the desired bean with the appropriate
primary key.
An example of an entity bean is one that represents the historic prices of a stock. The data could
be loaded from a database, and this entity bean could then be cached in memory and referenced
by other entity bean.

4.4.3 MESSAGE-DRIVEN BEANS

Message beans were added to the Enterprise JavaBeans architecture later than session and entity
beans. Originally, EJBs communicated using Java Remote Method Invocation; however, with the
advent of the Java Message Service (JMS), message-driven beans were introduced. This form of
bean is an asynchronous JMS message consumer, and to avoid tying up servers it uses a non-
blocking primitive.

4.4.4 BEAN CONTAINERS

As briefly mentioned above, EJB containers are responsible for the management of Enterprise
JavaBeans. Before execution, an EJB component must be assembled into a J2EE application and
deployed into its container. Each J2EE component has a configuration file associated with it
(called a deployment descriptor), and this specifies the container settings for each of the EJBs
and for the application as a whole.

Figure.8 EJB-Containers

4.5 Developing Web Applications in Java
We normally adopt two main architectures when developing web applications in Java. The first
Architecture utilizes servlets and JSP in the middle tier to serve clients and process the business
logic.

Figure.9 A servlets/JSP application architecture.

Small to medium-size applications use this design model.
The second architecture includes the use of J2EE server and Enterprise JavaBeans (EJB) and this
is especially useful for large enterprise applications that need scalability.

Figure.10 A J2EE application architecture

4.6 FACILITIES PROVIDED
The container manages many aspects of the execution of each application. The configuration file
enables components to customize the support services provided by the J2EE application server.
These include transaction management, database connection management, security, remote host
connectivity and EJB persistence.

4.7ADVANTAGES

The use of application servers such as EJB containers greatly simplifies the process of
development and deployment of distributed components. It enables developers to concentrate on
the functional and business-oriented aspects of the components they are developing, rather than
having to consider concurrency controls, transactional behaviours, persistence, database
connectivity and other complex issues.

The EJB architecture extends the concept of reusability and takes it to a practical level, where
whole components may be reused, rather than the piecemeal reuse of individual classes that
occurs in class based object-oriented development.

CONCLUSION
The development of CORBA leads to vendor independent interoperatabilty irrespective of the
underlying hardware, software, operating system, languages etc. It leads to the component and
object abstraction in which the client or the implementer needs to know only essential details and
not the implementation details. Vendors can present their interface in any language on Object
Request Broker which will be converted into standard interface by Interface definition language.
Clients can download or use these interface and IDL compiler will convert them into language
format as required by the clients.
But due to excessive load on middleware server i.e. ORB server, and inefficient load
management CORBA was not able to meet the performance constraints and no standard protocol
format too was used.
Above Demerits lead Sun Microsystems to present a new open, scalable, heterogeneity based
technology J2EE. It divided the work of application development into n- tiers separating the
presentation, business, application, database logic and hence providing efficient load
management. It also provided a standard common format for purpose of interoperatabilty. It
extended the concept of CORBA using its positive aspects and added new features one of which
was its model ,view, controller architecture and use of Enterprise Java Beans, which are
components are that are used to provide the business logic for a J2EE application. They consist
of a number of Java classes that have been packaged appropriately and are deployed to an EJB
container that creates and manages the components. J2EE simplifies the concept of development
and deployment of applications and lets the developers to concentrate on the functional and
business-oriented aspects of the components.

REFERENCES
[1]- Engineering Distributed Objects; Wiley & Sons, 2000.

[2]- Objects and Components
http://www.cetus-links.org

[3] – Object Management Group; CORBA Basics
http://www.omg.org/gettingstarted/corbafaq.html

[4] – Research into the interoperability of enterprise information
technologies (Yoshi Hasegawa MSE May 2001)

[5] – Lecture slides of Architecture of Software Systems CMU-SCS Spring 2001

[6]- J2EE Tutorial
http://java.sun.com/j2ee/tutorial/

[7]- OMG: CORBA Components. Joint Initial Submission, OMG 97-11-24, OMG 1997

[8]- OMG: CORBA 2.2 Specification, OMG 98-2-33, OMG, 1998

[9]- OMG: CORBA services Specification, Event Management Service, OMG document FORMAL/97-2-
9, OMG 1997

[10]- taken from [SUN] Sun Microsystems :J2EE Tutorial

[11]- http://www.sun.com/developers/evangcentral/presentations/j2eeoverview.pdf

Object and component based middleware for distributed system development

More Related Content

What's hot

Viewers also liked

Similar to Object and component based middleware for distributed system development

In this document

Object and component based middleware for distributed system development