You are on page 1of 34


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:

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.


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.

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 environment. There are a number of object oriented middleware technologies used in IT industries, report has detailed study of CORBA and J2EE middleware.

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

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

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.

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

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


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

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

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

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.


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.

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

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

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

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

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

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

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

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

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

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


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, resourceplanning 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 application. • Data layer. This layer is used by the business logic layer to persist state permanently. This layer normally consists of one or more databases where data is stored. However, other types of data store could also be used. For example, it is now very common to use XML documents as storage to keep data.

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

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

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

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

Advantages of Multi-tiers
• • • Tiers separate functionality: – Presentation Logic, Business Logic, Data Schema

Easier upgrade since one tier can be changed without changing the rest Lower deployment and maintenance cost

More flexible (can support changes), more extensible (can add functionality) J2EE is open standard n-tier architecture for developing, designing, deploying and assembling component based enterprise applications. It provides reusability, scalability, interoperatabilty, enhanceabilty. The reason for choosing J2EE is • • • Simplifies the complexity of a building n-tier application Standardizes an API between components and application server container J2EE Application Server and Containers provide the framework services

4.2 J2EE Components & Services
• Components • Java Servlets JavaServer Pages (JSP) Enterprise JavaBeans (EJB)

Standard services & supporting technologies Java database connectivity(JDBC) data access API Java Messaging Service (JMS)

(Remote Method Invocations (RMI)) Extensible Markup Languages(XML) JavaIDL (Interface Description Language) JavaMail Java Security

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

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

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

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.


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

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

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

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.

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.

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.

[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-29, OMG 1997 [10]- taken from [SUN] Sun Microsystems :J2EE Tutorial [11]-