Object and component based middleware for distributed system development
INTRODUCTIONTraditionally computer software ran in stand-alone systems, where application processing, userinterface and persistent data resided in one computer. Whereas the objects and locally distributedcomponents are located on the computers utilizing them, distributed components are typicallylocated on machines other than those making call to them . With the growth of technology andcertain challenges of software development in stand-alone systems, most computer softwaretoday runs in distributed systems, where the data resources, interactive presentation, applicationbusiness processing, and data resources reside in loosely-coupled nodes and service tiersconnected together by networks. Some challenges faced by stand alone systems are described asunder:LOAD-SHARINGThe use of distributed software development facilitates the interaction across machineboundaries, and this allows system to harness the resources of multiple computers.Consequently, a number of systems may be involved in processing the request, potentiallyremoving the bottlenecks in performance.INCREASED AVAILABITLITYDistribution of components may result in increased system availability, with multiple instancesof each object residing on machine in network. If the instances are sharing load then the loss ofone host will result in the load being distributed through the remaining machines.HETEROGENITYDifferent hardware and software platforms store data in different ways. Distributed systemsovercome this problem by utilizing a middleware layer that resolves the heterogeneity issues.The middleware enables distributed components to exist on multiple different platforms, and stillinteract with one another.
CHAPTER 1 MIDDLEWAREMiddleware is the layer of software that mediates between the application and the software. It isresponsible for managing the interaction between components distributed over heterogeneouscomputing platforms.There are four categories of middleware technologies identified by Wolfgang Emmerich. Theyexhibit different properties, and these classifications are as follows:1.1 TRANSACTION ORIENTEDTransactional middleware enables distributed components to ensure that an atomic operationeither occurs completely or not at all. This is achieved by the use of a two-phase commitprotocol. A transactional middleware does create some overhead, so if transactions are notrequired for an operation this is an unnecessary additional cost. Transaction-oriented middlewareis commonly used in distributed databases.1.2 MESSAGE ORIENTEDThis form of middleware provides message transmission, receipt and queuing services todistributed components. Messages are used to transmit service requests, updates and responses torequests. Messages are held in queues until they are de-queued by receiving component and thisensures messages are not lost when a host is busy or unavailable.Message oriented middleware provides asynchronous communication between components,reducing the coupling between the components. This leads to systems that are more scalable,with less tightly coupled components.
1.3 PROCEDURALThe most common form of procedure oriented middleware is Sun Microsystems’ remoteprocedure call technologies. This enables the components on one computer to invoke procedureor method located on other computers. The invocation or any associated parameters aremarshaled into messages and these are sent from one machine to another. The invocationsemantics with procedural middleware are commonly synchronous- with invoker being blockeduntil the response is received.1.4 OBJECT ORIENTEDObject oriented middleware is based on object oriented paradigm, and extends the functionalityof procedural middleware to provide additional facilities required for use in an object orientedenvironment.There are a number of object oriented middleware technologies used in IT industries, report hasdetailed study of CORBA and J2EE middleware.
CHAPTER2 OBJECTS AND COMPONENTS2.1OBJECTSAn object can be defined as a concept, abstraction or thing with crisp boundaries and meaningfor 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 defined2.2 COMPONENTSA component can be thought of as a collection of objects that provide a set of services to othersystems. They have many features in common with objects, but are less fine grained. Examplesof components include code that provides graphing facilities; provide network communicationservices; 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 mayalso import functionality from its environment using well-defined and open interfaces‖. Thisdefinition highlights a number of differences from objects: Components are self–contained.
Provide services to other systems Use stated interfaces to interact with other systemsComponents may run either locally or in a distributed fashion. Many examples of locally runcomponents exist and are commonly used to provide specific functionality to external programs.The Object Linking and Embedding (OLE) architecture was one of the first componentframeworks in common use, and this enabled the use of specialized functionality from oneprogram to be used in another program. An example of this is the use of Microsoft Excelspreadsheets in Microsoft Word .
CHAPTER 3 CORBAThe Object Management group’s (OMG) Common Object Request Broker Architecture(CORBA) is an important and popular technology that supports the development of object baseddistributed applications.‖ORB is a middleware that establishes the client server relationshipsbetween the objects. Using an ORB the client can inherently invoke a method on the serverobject, which can be on the same machine or across a network”. CORBA is intended to providea standardized platform for which to construct distributed components. A CORBA applicationconsists of a number of objects that store data and export functionality to other objects. CORBAenables separate pieces of software written in different languages and running on differentcomputers to work with each other like a single application or set of services. CORBA uses aninterface 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 othercommon programming languages .The CORBA specification dictates there shall be an ORB through which an application wouldinteract with other objects. In practice, the application simply initializes the ORB, and accessesan internal Object Adapter, which maintains things like reference counting, object (andreference) instantiation policies, and object lifetime policies. The Object Adapter is used toregister 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 basefor use by the user application. This step is necessary in order to enforce CORBA semantics andprovide a clean user process for interfacing with the CORBA infrastructure. ORB is an abstractentity that acts as a middleman in all remote method invocations. The ORB finds a server canhandle a method invocation, passes the request to the server, receives the response and forwardsit to the client. The functions handled by ORB are actually implemented by both client andserver.
3.1 PURPOSE OF CORBA3.1.1VENDOR INDEPENDENT INTEROPERATIBILTYMiddleware that’s everywhere - is the main purpose of CORBA, which try to provide perfectinteroperability among any OS, hardware, and system. We might see the immediate benefit by integratinglegacy systems on mainframe computers and/or traditional client-server models with relatively newcomponent 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 forusers. ―Open system‖ was the first step for vendor independent interoperability but still had a limitation inarchitecture 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-relatedobjects: CORBAservices [OMG 1998b], CORBAfacilities, and CORBAdomains. o CORBAservices provide low-level, base-type services such as transactions, security, life- cycle, and naming. o CORBAfacilities provide a higher-level set of services such as printing management. o CORBAdomains represent vertical domain-related standards such as manufacturing, telecommunication, healthcare, financial and so on. o Application objects, other than these CORBA related objects, are not standardized as part of OMG activities.
3.2 ARCHITECTURAL DESCRIPTION:Any relationship between distributed objects has two sides: the client and server. The serverprovides a remote interface, and client calls a remote interface. These relationships are commonto most distributed object standards, including RMI and CORBA. Note that in this context, theterms client and server define object-level rather than application-level interaction anyapplication could be a server for some objects and clients for others .On the client side, the application has a reference for the remote object. The object reference hasa stub method, which is a stand-in for the method being called remotely. The stub is actuallywired into the ORB, so that calling it invokes the ORB’s connection capabilities, which forwardsthe invocation to the server.On the server side, the ORB uses skeleton code to translate the remote invocation into a methodcall on the local object. The skeleton translates the call and any parameters to theirimplementation-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 InternetInter-ORB Protocol. IIOP, which is based on the standard TCP/IP internet protocol and worksacross the internet, defines the procedure how CORBA-compliant ORBs pass information backand forth .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 usinga CORBA product from another vendor thus permitting interoperability, which is one of thegoals 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’sdistributed, multi-tiered computing environments .
3.3Architectural description of CORBA with layered ansequential diagram on physical view basis Figure. 13.4 DESCRIPTION OF ELEMENTS OF DIAGRAM 3.4.1.CLIENT This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object i.e. obj ->op (args).
3.4.2.OBJECTS/SERVANTSAn object is an identifiable, encapsulated entity that provides one or more services that canbe requested by a client . Rambaugh adds that an object is ―a concept, abstraction or thingwith crisp boundaries and meaning for the problem at hand‖ .An implementationprogramming language entity for operations corresponding to the IDL interface. Servants canbe written in a variety of languages, including C, C++, Java, Smalltalk and Ada.3.4.3.Object Request BrokerThe ORB simplifies distributed programming by decoupling the client from the details ofmethod invocations. This makes client requests appear to be local procedure calls). ORB isresponsible 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 Request3.4.4 ORB InterfaceCORBA 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 helperfunctions such as converting object references to strings and vice versa, and creatingargument lists for requests made through DII (Dynamic Invocation Interface) .
Figure .3 Structure of Object Request Interfaces 3.4.5 IDL STUBS AND SKELETONS CORBA IDL Stubs and skeleton serve as the ―glue‖ between the client, server and ORB. The transformation between IDL definitions and target programming language is done by IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons.3.5 MAJOR COMPONENTS OF CORBA3.5.1 Interface Definition Language (IDL)The interface is the syntax part of the contract that the server object offers to the clients thatinvoke it. Client access objects only through their advertised interface, invoking only thoseoperations that the object exposes through its IDL interface, with only those parameters (inputand 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 theplatform-independent delineation of the interfaces of distributed objects. The ability of theCORBA environments to provide consistency between clients and servers in heterogeneousenvironments begins with a standardized definition of the data and operations constituting theclient/server interface. This standardized mechanism is the IDL, and is used by CORBA todescribe 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. The inter-ORB protocol delivers messages between two ORBs. These messages might be method requests, return values, error messages etc. The inter-ORB protocol (IIOP) also deals with differences between two ORB implementations, like machine-level byte ordering etc. As a CORBA developer, you don’t have to be concerned with the low-level communication protocol between ORBs. If you want two ORBs to talk, just make sure they both speak the same inter-ORB protocol (IIOP). The Inter-ORB Protocol (IIOP) is an inter-ORB protocol based on TCP/IP and so is extensively used on the Internet.3.5.3 PORTABLE OBJECT ADAPTER CORBA Server Object POA ORB The POA connects the server object implementation to the ORB. It extends the functionality of the ORB and some its services include: activation and deactivation of the object implementations, generation and management of object references, mapping of object references to their implementations, and dispatching of client requests to server objects through a skeleton.
3.6 COMMON OBJECT SERVICES(COS). They are defined on the top of the ORB, as standard CORBA objects with IDL interfaces. Figure.5 Common Object Services3.6.1 POPULAR SERVICESNaming 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 servicesAnother COS that provides a supplier-consumer communication model that createsasynchronous communication between the objects via an Event Channel. The flow of datainto the Event Channel is handled by supplier objects, while the flow of data out of the EventChannel is handled by consumer objects. The Event service supports both the push and pullmodel. In the push model the supplier objects control the flow of data by pushing it to theconsumers, and in the pull model the consumer objects control the flow of data by pulling thedata 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 objectsobtain a consumer proxy and consumer objects obtain a supplier proxy.Security servicesProvides a means to authenticate messages, authorize access to objects and provide securecommunicationsTransaction servicesDefines a means to control an action against a database or other subsystems.3.7 SUPPORTED QUALITY ATTRIBUTES3.7.1 Reusability (Interoperability)A variety of systems, computer languages and vendors can be integrated into one total enterprisesystem. This attribute goes into two ―well known‖ Quality attributes. The significant benefit ofCORBA could be the integration of huge legacy systems such as mainframe systems and newsystems. 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 enterprisesystem. CORBA allows these companies to reuse the most of legacy systems for the totalsystem with minor modification.3.7.2 ModifiabilitySince all implementation was hidden by IDL, the internal logic in a component can be easilymodified. And also the component location (server location) can be changed without affectingcalling components (clients) since Naming service provide the latest information of server sidecomponents dynamically.
3.7.3 ExtensibilitySince the number of vendors is growing, existing CORBA systems have a significant probabilityto integrate more systems, devices and software into themselves. And also naming servicecontributes 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 developermight be able to choose the best or most familiar language to develop each component, whichhas favorable impact on productivity.3.8 NON-SUPPORTED QUALITY ATTRIBUTES3.8.1 PerformanceSince all communication with remote components has to go through CORBA mechanism, theresponse time could be an issue because of more layers among communication. So, platformdependent own socket programs over TCP/IP with C language will produce much faster throughput than the combined CORBA components.3.8.2 SecuritySince the total system will be highly distributed with multiple vendor products, more securityholes are likely to be embedded into the system. Moreover the root cause of system troublescould be difficult to be identified in highly integrated environment.
3.9 TRADE OFFS3.9.1 Reusability (Interoperability) vs. PerformanceTo integrate a variety of systems in heterogeneous environment, developers had to add morelayers and steps for the communication mechanism and sacrifice performance due to additionalsteps.3.9.2 Extensibility vs. SecurityThe ability to extend system by adding new servers for load balanced or business needs mightincrease the number of weak points (security holes) in the system. In theory, the more networkcommunications are executed, the more chances are raised for intrusion (Distribution systemshave weaker than centered systems).3.9.3 Consistency and original intentOMG provides ISO standards for some core specifications such as IDL and keeps consistencyamong the products from a variety of vendor. In spite of the small number (11) of the originalorganizations, 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 provideseamless integration with CORBA environment by RMI-IIOP methods for communication.Another big architecture, DCOM from Microsoft, can also be integrated with CORBA withDCOM/CORBA bridges. Overall CORBA’s original intention is kept and the industry trendseems to be going forward to support CORBA.3.10 ADAVANTAGES OF CORBA3.10.1 MaturityThe original version of the CORBA standard was defined in 1991. This first version of thespecification was deliberately limited in scope. The OMG’s philosophy was to define a smallstandard, let implementors gain experience and then slowly expand the standard to incorporatemore 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 thanmodify existing functionality. Today, CORBA is extremely feature-rich, supporting numerousprogramming languages, operating systems, and a diverse range of capabilities—such astransactions, security, Naming and Trading services, messaging and publish-subscribe services—that are essential for many enterprise-level applications. Many newer middleware technologiesclaim to be superior to CORBA but actually have to do a lot of ―catching up‖ just to match someof the capabilities that CORBA has had for a long time.3.10.2 Open standardCORBA 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 ofthe freeware implementations). You might think that switching from one CORBA product toanother would involve a lot of work. In contrast, if you use a proprietary middleware system thenswitching 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 thatdevelopers will build all their applications using that particular middleware technology, and sothey provide only limited support for integration with other technologies. In contrast, CORBAwas designed with the goal of making it easy to integrate with other technologies. Indeed, theCORBA specification explicitly tackles integrations with TMN, SOAP, Microsoft’s (D)COMand DCE (a middleware standard that was popular before CORBA). Furthermore, many parts ofJ2EE borrow heavily from concepts in CORBA, which makes it relatively easy to integrate J2EEand CORBA. Some vendors sell gateways between CORBA and J2EE that make suchintegration even easier. Several CORBA vendors sell COM-to-CORBA and/or .NET-to-CORBAgateways. This provides a very pragmatic solution to organizations that wish to write GUIapplications 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 writtenas a COM/.NET client that thinks it is talking to a COM/.NET server, but in fact communicateswith a gateway that forwards on requests to a CORBA server.3.10.3 Wide platform supportCORBA implementations are available for a wide variety of computers, including IBM OS/390and 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 fewother middleware technologies that are available on such a wide range of computers.3.10.4 Wide language supportCORBA 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 smallorganizations might use a single programming language for all their projects, but as anorganization increases in size, it becomes increasingly likely that the organization will make useof several programming languages. Likewise, the older an organization is, the higher thelikelihood becomes that some of its ―legacy‖ (older) applications are implemented in oneprogramming language and newer applications are implemented in a different programminglanguage. For these organizational reasons, it is important for a middleware system to supportmany programming languages; unfortunately, not all middleware systems do so. One extremecase of this is J2EE, which supports only Java. Another extreme case is the SOAP middlewarestandard. SOAP applications can be built with a variety of programming languages but, at thetime of writing, the SOAP standard defines only one language mapping (for Java). There may beseveral vendors who support, say, C++ development of SOAP applications, but each of thosevendors provides their own proprietary C++ APIs. This means that there is no source-codeportability of non-Java SOAP applications across different vendor products.3.10.5 EfficiencyThe on-the-wire protocol infrastructure of CORBA ensures that messages between clients andservers are transmitted in a compact representation. Also, most CORBA implementations
marshal data (that is, convert data from programming-language types into a binary buffer thatcan be transmitted) efficiently. Many other middleware technologies also use a similarlycompact 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 inSOAP using much more network bandwidth than CORBA. SOAP-based applications also incurconsiderable CPU overhead involved in formatting programming-language types into XMLformat 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, whichis efficient. However, this requires that developers write the marshaling code that copiesprogramming-language types into the binary buffers prior to transmission, and the unmarshallingcode to extract the programming-language types from a binary buffer. In contrast, a CORBAIDL compiler generates the marshaling and unmarshalling code, so that developers do not needto write (and maintain) such low-level code.3.10.6 ScalabilityThe flexible, server-side infrastructure of CORBA makes it feasible to develop servers that canscale from handling a small number of objects up to handling a virtually unlimited number ofobjects. Obviously, scalability varies from one CORBA implementation to another but, time andtime again, real-world projects have demonstrated that a CORBA server can scale to handle notjust a huge amount of server-side data, but also high communication loads from thousands ofclient applications. Most CORBA vendors will likely know of customers who have tried adifferent middleware technology, found that it could not scale sufficiently well and then switchedto CORBA.
3.10.7 TransparencyObject location transparencyThe client does not need to know where an object is physically located. An object can either belinked into the client, run in a different process on the same machine, or run in a server on theother side of the planet. A request invocation looks the same regardless, and the location of anobject can change over time without, breaking applications.Server transparencyThe 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 doesnot care whether the server is running at the time the client invokes a request.Language transparencyClient and server can be written in different languages. This fact encapsulates the whole point ofCORBA; that is, the strengths of different languages can be utilized to develop different aspectsof a system, which can interoperate through IDL. A server can be implemented in a differentlanguage without clients being aware of this.Operating system transparencyClient and server are unaffected by each others operating system. In addition, source code doesnot change if you need to port the source from one operating system to anotherProtocol transparencyClients and servers do not care about the data link and transport layer. They can communicatevia token ring, Ethernet, wireless links, ATM (Asynchronous Transfer Mode), or any number ofother networking technologies.
CHAPTER 4 J2EE AND EJBThe java 2 Enterprise edition provides a multiplatform distributed component platform. Itconsists of a set of services and protocols that are used at each level of a multi-tier distributedsystem. It provides services for all tiers of the J2EE distributed component architecture as shownin fig.6. Figure .6The client-tier provides an interface for the user to interact with the system. This may be in oneof several forms: it could be a web browser (such as Netscape Navigator or Internet explorer), aJava applet or Java-based client program.The web-tier consists of Java server pages or servlets, which process and respond to requestsfrom client tier. The components of the web-tier obtain data and process information using thebusiness-tier.The business-tier is implemented in Enterprise JavaBeans (EJBs) and is commonly referred to asBusiness Logic of the application. The EJBs are executed in a bean container – an applicationthat 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.Behind the business-tier is the EIS-tier, which is comprised of the Enterprise InformationSystems (EIS). This category contains; databases, transaction processing systems, resource-planning systems and other large-scale information systems and these will often be accessed bymany different n-tier systems. For example, a bank may have one J2EE application for its tradersto use, a system for external clients to trade, and another for reporting and monitoring functionsall utilizing the same transaction processing system.4.1 MOTIVATION FOR J2EEDue to the need for multi tier computing model in web environment. A well-designed softwareapplication is partitioned into separate logical parts called layers. Each layer has a differentresponsibility in the overall architecture. These layers are purely abstractions, and do notcorrespond 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 theapplication.• Data layer. This layer is used by the business logic layer to persist state permanently. Thislayer normally consists of one or more databases where data is stored. However, other types ofdata store could also be used. For example, it is now very common to use XML documents asstorage to keep data.4.1.1 The Two-Tier ArchitectureA two-tiered application is a simple client-server application in which the processing workloadfalls onto the client computers shoulders and the server simply acts as a traffic controllerbetween the client and the data. The term "fat client" for this type of architecture is due to thebulk of processing requirements at the client side. In this architecture, the presentation layer andthe business logic layer are hosted in one tier and the data layer is on another tier. The drawbackof 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 isincreased network traffic because each client has to make multiple requests for data from theserve—even before presenting anything to the user. Another problem is cost because each clientneeds a machine with sufficient processing power. As the number of clients increase, the cost forproviding client machines alone could be astronomical. However, the most severe problem thatthis type of architecture can cause is probably a maintenance problem. Even a tiny change to theprocessing logic might require a complete rollout to the entire organization. Even though theprocess can be automated, there are always problems with larger organizations because someusers may not be ready for an upgrade, whereas others insist it be performed immediately.4.1.2 The Three-Tier ArchitectureTo overcome the problems in many client two-tiered applications, an application is broken upinto three separate tiers, instead of two. The first tier contains the presentation layer, the secondtier, or the middle tier, consists of the business logic layer, and the third tier contains the datalayer.4.1.3 The n-Tier Architecture: Vision of J2EETo achieve more flexibility, the three tiers in the three-tiered application can be segregated evenfurther. An application with this type of architecture is called an n-tiered application. In thisarchitecture, the business logic layer is divided by function instead of being physically divided. Itbreaks down like the following:• A user interface. This handles the user interaction with the application. In an Internetapplication, this is usually a web browser used to render HTML tags.• Presentation logic. This defines what the user interface displays and how user requestsare handled.• Business logic. This models the application business logic.• Infrastructure services. These provide additional functionality required by theapplication 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 costMore flexible (can support changes), more extensible (can add functionality)J2EE is open standard n-tier architecture for developing, designing, deploying and assemblingcomponent 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 services4.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) ArchitectureMVC Architecture has implemented by Trygve Reenskaug at 1979 for the first time. It wasimplemented on Smalltalk at Xerox labs. Then benefits and advantages of this architecture hasbeen 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 tothe user. Also view handles requests from user and informs controller.4.3.3ControllerThe controller is responsible for responding to user input and performs interactions on the datamodel objects. The controller receives the input, it validates the input and then performs thebusiness operation that modifies the state of the data model.Advantages of MVC 1. They are resuable : When the problems recurs, there is no need to invent a new solution, we just have to follow the pattern and adapt it as necessary. 2. They are expressive: By using the MVC design pattern our application becomes more expressive.
Figure.7 MVC Architecture4.4 ENTERPRISE JAVA BEANSEnterprise JavaBeans (EJBs) components are that are used to provide the business logic for aJ2EE application. They consist of a number of Java classes that have been packagedappropriately and are deployed to an EJB container that creates and manages the components.EJBs communicate using either Java Remote Method Invocation, or with Java Message Queues.There are a number of different types of EJBs, and are examined below:4.4.1 SESSION BEANSA session bean is used to represent the state of a single interactive communication sessionbetween 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 sessionbeans currently available to it are lost, as they are not stored in stable storage. There are twocategories of session beans.STATEFUL session bean hold the conversational state and one of these is required for each ofthe sessions that are currently open.
STATELESS session beans hold no state (outside of calls) and receive all of their required inputfrom the client-tier. These beans may be pooled and reused, thereby reducing the overheads ofmany clients accessing one server.4.4.2 ENTITY BEANSEntity beans provide an in-memory copy of long-term data. They are persistent, and are saved tostable storage to ensure they are preserved across machine crashes. Many clients may access anindividual entity bean, and can find them by searching for the desired bean with the appropriateprimary key.An example of an entity bean is one that represents the historic prices of a stock. The data couldbe loaded from a database, and this entity bean could then be cached in memory and referencedby other entity bean.4.4.3 MESSAGE-DRIVEN BEANSMessage beans were added to the Enterprise JavaBeans architecture later than session and entitybeans. Originally, EJBs communicated using Java Remote Method Invocation; however, with theadvent of the Java Message Service (JMS), message-driven beans were introduced. This form ofbean is an asynchronous JMS message consumer, and to avoid tying up servers it uses a non-blocking primitive.4.4.4 BEAN CONTAINERSAs briefly mentioned above, EJB containers are responsible for the management of EnterpriseJavaBeans. Before execution, an EJB component must be assembled into a J2EE application anddeployed 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 EJBsand for the application as a whole.
Figure.8 EJB-Containers4.5 Developing Web Applications in JavaWe normally adopt two main architectures when developing web applications in Java. The firstArchitecture utilizes servlets and JSP in the middle tier to serve clients and process the businesslogic. 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 thisis especially useful for large enterprise applications that need scalability.
Figure.10 A J2EE application architecture4.6 FACILITIES PROVIDEDThe container manages many aspects of the execution of each application. The configuration fileenables components to customize the support services provided by the J2EE application server.These include transaction management, database connection management, security, remote hostconnectivity and EJB persistence.4.7ADVANTAGESThe use of application servers such as EJB containers greatly simplifies the process ofdevelopment and deployment of distributed components. It enables developers to concentrate onthe functional and business-oriented aspects of the components they are developing, rather thanhaving to consider concurrency controls, transactional behaviours, persistence, databaseconnectivity and other complex issues.
The EJB architecture extends the concept of reusability and takes it to a practical level, wherewhole components may be reused, rather than the piecemeal reuse of individual classes thatoccurs in class based object-oriented development.
CONCLUSIONThe development of CORBA leads to vendor independent interoperatabilty irrespective of theunderlying hardware, software, operating system, languages etc. It leads to the component andobject abstraction in which the client or the implementer needs to know only essential details andnot the implementation details. Vendors can present their interface in any language on ObjectRequest 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 languageformat as required by the clients.But due to excessive load on middleware server i.e. ORB server, and inefficient loadmanagement CORBA was not able to meet the performance constraints and no standard protocolformat too was used.Above Demerits lead Sun Microsystems to present a new open, scalable, heterogeneity basedtechnology J2EE. It divided the work of application development into n- tiers separating thepresentation, business, application, database logic and hence providing efficient loadmanagement. It also provided a standard common format for purpose of interoperatabilty. Itextended the concept of CORBA using its positive aspects and added new features one of whichwas its model ,view, controller architecture and use of Enterprise Java Beans, which arecomponents are that are used to provide the business logic for a J2EE application. They consistof a number of Java classes that have been packaged appropriately and are deployed to an EJBcontainer that creates and manages the components. J2EE simplifies the concept of developmentand deployment of applications and lets the developers to concentrate on the functional andbusiness-oriented aspects of the components.
REFERENCES- Engineering Distributed Objects; Wiley & Sons, 2000.- Objects and Components http://www.cetus-links.org – Object Management Group; CORBA Basics http://www.omg.org/gettingstarted/corbafaq.html – Research into the interoperability of enterprise information technologies (Yoshi Hasegawa MSE May 2001) – Lecture slides of Architecture of Software Systems CMU-SCS Spring 2001- J2EE Tutorial http://java.sun.com/j2ee/tutorial/- OMG: CORBA Components. Joint Initial Submission, OMG 97-11-24, OMG 1997- OMG: CORBA 2.2 Specification, OMG 98-2-33, OMG, 1998- OMG: CORBA services Specification, Event Management Service, OMG document FORMAL/97-2-9, OMG 1997- taken from [SUN] Sun Microsystems :J2EE Tutorial- http://www.sun.com/developers/evangcentral/presentations/j2eeoverview.pdf