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 ModifiabilitySince 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 ProductivityWe 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 PerformanceSince 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 SecuritySince 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 intentOMG 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 ArchitectureTo 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.1ModelIt 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.2ViewView 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