Top Banner

of 34

seminar report on object and component based middleware for distributed system development

Apr 04, 2018



Ekta Bhalwara
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
  • 7/29/2019 seminar report on object and component based middleware for distributed system development



    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



    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.


    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.


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development




    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:


    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.


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development



    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.


    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


    There are a number of object oriented middleware technologies used in IT industries, report has

    detailed study of CORBA and J2EE middleware.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development





    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




    Provides an abstraction

    Represents something real

    Is self-contained

    Is clearly defined


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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development




    The Object Management groups (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


  • 7/29/2019 seminar report on object and component based middleware for distributed system development




    Middleware thats 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 CORBAservicesprovide 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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development



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

    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 todays

    distributed, multi-tiered computing environments .

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    3.3Architectural description of CORBA with layered an

    sequential diagram on physical view basis

    Figure. 1



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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development



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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    Figure .3 Structure of Object Request Interfaces


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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    Interface Definition Language. IDL is OMG defining language-neutral APIs 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

    OMGs Interface Definition Language (IDL). IDL is independent of any programming


    Mappings from IDL to specific programming languages are defined as part of the

    CORBA specification. Mappings for C, C++, Smalltalk, Ada, COBOL and Java havebeen 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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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 dont 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-ORBprotocol (IIOP).

    The Inter-ORB Protocol (IIOP) is an inter-ORB protocol based on TCP/IP and so is

    extensively used on the Internet.


    CORBA Server Object



    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development



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

    Figure.5 Common Object Services


    Naming Services

    Defines how CORBA objects can be looked up by a name. It is a Common Object

    Service (COS) andallows 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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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


    Transaction services

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


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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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


    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 thats 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 CORBAs original intention is kept and the industry trend

    seems to be going forward to support 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 OMGs 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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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 capabilitiessuch 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 varietyof 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, Microsofts (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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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, Apples 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.4Wide 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 programminglanguage. 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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    marshaldata (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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development



  • 7/29/2019 seminar report on object and component based middleware for distributed system development




    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


    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 containeran application

    that controls the execution of JavaBeans and provides services such as transaction management,

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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.


    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


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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

    serveeven 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 upinto 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


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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


    - 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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


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


    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


  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    Figure.7 MVC Architecture


    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:


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

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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.


    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.


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    Figure.10 A J2EE application architecture


    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.


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development


    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development



    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.

  • 7/29/2019 seminar report on object and component based middleware for distributed system development



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

    [2]- Objects and Components

    [3]Object Management Group; CORBA Basics

    [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

    [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