Issues in selecting appropriate middleware

Transcription

1 Issues in selecting appropriate middleware School of Computing, Dublin Institute of Technology, Kevin Street, Dublin 8, Ireland. Abstract As enterprises expand by acquiring other companies and by combining with other companies it is getting more and more important their systems interact with one another. Enterprise enlargement can spell disaster for some enterprises. A plethora of systems are usually combined and at times no one truly knows what the result will be. For the successful interaction of different systems the correct middleware is vital. Enterprises need to know what type of middleware best suits their current systems and planned systems in the future. This paper explores middleware. First middleware is briefly described and defined. Following this is a description of three common middleware technologies. These are CORBA, COM/DCOM and Java RMI. The final section of this paper presents a framework that can be used by enterprises to help select a relevant middleware that is most appropriate to its needs. Keywords: Middleware, CORBA, COM/DCOM, Java RMI. 1 Introduction Computing is getting more complex. Enterprises are ever expanding and ever changing. This implies that enterprises have to constantly evolve and with them their systems. Whether adopting new systems or integrating different systems, there is a constant need that systems integrate with one another. Even within companies systems are constructed from different components and these components must communicate with one another. This has led several technology organisations to develop protocols and standards to allow the interaction of software components across different platforms and networks. This technology is middleware. Middleware is a class of software technologies designed to help manage the complexity and heterogeneity inherent in distributed systems, (Bakken, 1998). It is vital for organisations to choose the right middleware to fit their organisational needs. The right middleware saves enterprises time and money. Time to development is decreased and skills already within the enterprise can be taken advantage of with minimal training of staff. The right middleware can ease the transition period of two companies merging by presenting less problems and allowing the merging companies to concentrate on more important matters. This paper explores middleware in detail. In the first section distributed component computing is explored with a brief description and short history of its development. The following three sections explore three different middleware technologies; CORBA, Java RMI, and COM/DCOM. Each of these sections examines the technologies under the headings of general overview and architecture. The final section presents a framework that can be used by enterprises to choose the most appropriate middleware for an enterprises needs. 2 Distributed Component Computing Distributed computing is computing in which different components and objects comprising an application can be located on different computers connected across a network. ( 2004). 2.1 Introduction With the advent of the global economy enterprises are expanding their reach. They are spread over several locations and often their applications are also. This chapter gives a brief introduction into distributed computing, starting with a brief history and then discussing the supporting technology, middleware. 1

2 2.2 Distributed Component Computing A brief history Distributed computing first began when computers started sharing data over networks. Computers were connected to one another through networks so that data such as files and could be exchanged. Over time more and more of the computers capabilities were shared across a network creating distributed computing Client/Server The term client/server was first used in the 1980 s in reference to personal computers on a network (Schussel, 1995). The client/server architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability, and scalability as compared to centralised, mainframe, time sharing computing (Intel, 2001). Clients are defined as a requester of services as server is defined as a provider of services (Emmerich, 1998). A single machine can be both a client and a server. The architecture is shown in figure 1 (Schussel, 1995). Figure 1: Client/Sever architecture Client/Server architecture is also called 2-tier architectures because they have two layers; client and server. The user interface is located in the users desktop environment and the database management services are located in a more powerful server that is able to respond to many requests from users simultaneously (Schussel, 1995). Processing management is split between the client and server. This environment is sufficient for small user groups of up to 100. However in environments where there are over a hundred users performance begins to deteriorate (Intel, 2001) tier architecture The 3-tier architecture emerged to overcome the limitations of the 2-tier architecture. In this architecture a middle tier was added between the user system interface and the database management server environment (Emmerich, 1998). The middle takes over most of the process management such as queuing, application execution and messaging. This is shown in figure 2 (Schussel, 1995). Figure 2: A 3-tier distributed client/server architecture 2

3 The 3-tier architecture improved performance for large groups and improves flexibility by allowing applications to be upgraded more easily (Schussel, 1995) N-tier architecture N-tier architecture takes 3-tier a step further. N-tier distributes the application into many more components that can be spread across buildings and countries (Sun Microsystems, 2000). N-tier is more complex than the previous architectures discussed and implements more messaging. However this can be overcome by distributing the application according to use so most messaging, where possible stays in a geographic location (The open group, 2000). An example of n-tier architecture is shown in figure 3 (Sun Microsystems, 2000). In this example all 3 layers are spread across multiple application and servers. Users can access many data services through many business services. This allows greater flexibility of the system. Figure 3: N-tier architecture 2.3 Middleware The spreading out of components across several locations has given rise to the need for middleware. Middleware is a class of technologies designed to help manage the complexity and heterogeneity in distributed systems (Ghosh & Mathur, 2001). Middleware is defined as a layer of software above the operating system but below the application program that provides a common programming abstraction across a distributed system, as shown in figure 4 (Zhang & Jacobsen, 2003). Middleware is often referred to as plumbing because it connects parts of a distributed application with data pipes and then passes data between them (Hoffman, 1999). Middleware frameworks mask some of the kinds of heterogeneity that programmers of distributed systems must deal with. They always mask heterogeneity of networks and hardware and most mask the heterogeneity of operating systems, programming languages, or both (Zhang & Jacobsen, 2003). 3

4 Figure 4: Middleware layer in context 2.4 Categories of Middleware There are a number of different types of middleware developed. These vary in terms of the programming abstractions they provide and the kinds of heterogeneity they provide beyond network and hardware (Hoffman, 1998) Distributed Database A distributed relational database offers the abstraction of distributed tables, and is the most widely deployed kind of middleware today. Distributed relational database products offer heterogeneity across programming languages, but most do not offer heterogeneity across vendor implementations (Ghosh & Mathur, 2001) Remote Procedure Call Remote procedure call (RPC) middleware extends the procedure call interface to offer the ability of being able to invoke a procedure whose body is across the network (Emmerich, 1998) Message-Oriented Middleware Message-Oriented Middleware (MOM) provides the creation of a message queue that can be accessed across a network. It is very flexible and is configured with the topology of programs that deposit and withdraw messages from a given queue (Hoffman, 1999) Distributed Object Middleware Distributed object middleware provides an object that is remote and whose methods are invoked as though the object was in the same address space as the caller (Hoffman, 1999). There are other types of middleware available for many different applications. However in this paper distributed object middleware is discussed. 3 CORBA 3.1 Introduction The Common Object Request Broker Architecture (CORBA) is an open distributed object-computing infrastructure that is standardized by the Object Management Group (OMG). CORBA is an open, vendor independent architecture and infrastructure that computer applications use to work together over networks (OMG, 2004). CORBA automates common network programming tasks such as object registration, location and activation of procedures (Siau & Tian, 2004). Using the standard CORBA Internet Inter-Orb Protocol (IIOP), a program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBAbased program from the same or any vendor, on almost any other computer, operating system, programming language and network (Joo-Hung, et al, 2003). 3.2 CORBA Overview CORBA uses a request-response architecture (Shin, et al, 2003). This architecture involves having an object implementation on the server that the client requests to execute whenever 4

5 needed. The client and the server object implementation do not have any restrictions on the address space, for example the client and the server can exist in the same address space, or can be located in separate address spaces on the same node, or can be located on separate nodes altogether (Plasil & Stal, 2000). CORBA applications are composed of objects; individual units of running software that combine functionality and data, and that frequently, but not always represent something in the real world (Chang, 2003). Typically, there are many instances of an object of a single type - for example, an e-commerce website would have many shopping cart object instances. Each would be identical in functionality but each would differ in that each is assigned to a different customer, and contains data representing the merchandise of that customer. For other types, there may be only one instance. For example, when a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network, there is usually only one instance. For each object type, such as the shopping cart mentioned, an interface in OMG Interface Definition Language (IDL) is defined. The interface is the syntax part of the contract that the server object offers to the clients that invoke it. Any client that wants to invoke an operation on the object must use this IDL interface to specify the operation it wants to perform, and to marshal the arguments that it sends (Joo-Hung, et al, 2003). When the invocation reaches the target object, the same interface definition is used there to unmarshal the arguments so that the object can perform the requested operation. The interface definition is then used to marshal the results for the response, and to unmarshal the results when the destination is reached. Figure 5: A request passing from client to object implementation. Figure 5 (Joo-Hung, et al, 2003) illustrates how CORBA works within a single process. IDL client stubs and object skeletons are compiled and objects and clients are also written for them. Stubs and skeletons serve as proxies for clients and servers, respectively (Siau & Tian, 2004). The IDL defines interfaces very strictly. This makes it relatively easy to interact with the skeleton on the server side, even if the two are compiled into different programming languages or are running on different platforms. An object reference is used to identify each object in CORBA (OMG 2004). Clients obtain the object reference from a naming service and then use the object reference to direct their invocations, identifying to the ORB the exact instance they want to invoke. The client acts as if it's invoking an operation on the object instance, but it's actually invoking on the IDL stub that acts as a proxy. Passing through the stub on the client side, the invocation continues through the ORB, and the skeleton on the implementation side, to get to the object where it is executed (Shin, et al, 2003) Remote Invocations Figure 6 (Joo-Hung, et al, 2003) illustrates a remote invocation. In this scenario the client first obtains the object reference from a naming service. To make the remote invocation, the client uses the same code from the local invocation previously described, substituting the object reference for the remote instance. The ORB examines the object reference and discovers that the target object is remote (Joo-Hung, et al, 2003). Now the ORB, 5

6 using IIOP routes the invocation out over the network to the remote objects ORB. 3.3 CORBA Architecture Figure 6: Interoperability uses ORB-to-ORB communication The following sections provide a top-level view of the elements that make up the CORBA infrastructure Object Request Broker (ORB) In-order for objects in any application to make requests and receive responses from other objects remotely or locally, an Object Request Broker (ORB) is used (OMG, 2004). Using an ORB the client is not aware of the mechanisms used to communicate with, activate, or store server objects. The predefined language IDL, achieves this Siau, et al, 2004). There are a variety of distributed middleware services provided by CORBA ORBs. Objects can discover each service during runtime and invoke other client services using the ORB (Joo-Hung, et al, 2003). An ORB is more sophisticated than alternative forms of client/ server middleware, including the traditional Remote Procedure Calls (RPCs), and peer-topeer services (Patil & Rzajesh, 2000). Benefits that every CORBA ORB provides include (OMG, 2004): 1. Static and dynamic method invocations Using this, developers can statically define method invocations at compile time, or dynamically discover them at run time by making use of the CORBA ORB. 2. High-level language bindings CORBA provides language-neutral data types and separates interface from implementation. This makes it possible to call objects across language and operating system boundaries. 3. Self-describing system In order to provide the client with updated information about the various server interfaces, CORBA provides run-time metadata for describing every server interface known to the system. The CORBA ORB provides this information through an Interface Repository (IR) The IR contains realtime information describing the functions a server provides and their parameters. The clients use the metadata to discover how to invoke services at run time. It also helps tools to generate code on the fly. 4. Local/ remote transparency As described, inter ORB interconnection is possible in CORBA using the IIOP. An ORB can run in standalone mode on a laptop, or it can be interconnected to every other ORB using CORBA IIOP services. 5. Built-in security and transactions In order to handle security and transactions across machine and ORB boundaries, the ORB includes context information in its messages. This is useful for security and transactions. 6. Coexistence with existing systems - CORBA's separation of an object's definition from its imp lementation is perfect for encapsulating existing applications CORBA Services CORBA services are collections of systemlevel services packaged with IDL-specified interfaces. They are used to expand and complement the functionality of the ORB (Medvidovic, 2003). OMG (2004) has published standards for sixteen object services: 1. The Life Cycle Service defines operations for creating, copying, 6

7 moving and deleting components on the ORB. 2. The Persistence Service provides a single interface for storing components persistently on a variety of storage servers, including Object Databases (ODBMS), Relational Databases (RDBMSs), and simple files. 3. The Naming Service component on the ORB is used to locate other components by name. The service also allows objects of be bound to existing network directories. 4. The Event Service allows components on the bus to dynamically register or unregister their interest in specific events. 5. The Concurrency Control Service provides a lock manager that can obtain locks on behalf of either transactions or threads. 6. The Transaction Service provides two-phase commit coordination among recoverable components using either flat or nested transactions. 7. The Relationship Service provides a way to create dynamic associations between components that know nothing or each other. It also provides mechanisms for traversing the links that group these components. 8. The Externalization Service provides a standard way for getting data into and out of a component using a stream-like mechanism. 9. The Query Service provides query operations for objects. 10. The Licensing Service provides operations for metering the use of components to ensure fair compensation for use. The service supports any model of usage control at any point in a component's life cycle. 11. The Properties Service provides operations that let developers associate named values (or properties) with any components. Using this service, the properties can be associated with a component's state, e.g. a title or date. 12. The Time Service provides interface for synchronizing time in a distributed object environment. It also provides operations for defining and managing time-triggered events. 13. The Security Service provides a complete framework for distributed object security. It supports authentication, access control lists, confidentiality and non-repudiation. 14. The Trader Service provides a directory for objects; it allows objects to publicize their services and bid for jobs. 15. The Collection Service provides CORBA interfaces to generically create and manipulate the mo st common collections. 16. The Startup Service enables requests to automatically start up when an ORB is invoked CORBA Facilities CORBA facilities are collections of IDLdefined frameworks that provide services to application objects. The two categories of common facilities, horizontal and vertical, define rules of engagement that business components need to effectively collaborate (Shin, et al, 2003). Distributed Document Components Facilities (DDCF) specifies presentation services for components and a document interchange standard. The common facilities include mobile agents, data interchange, business object frameworks and internationalization (Joo-Hung, et al, 2003) CORBA Business Objects In-order to provide a natural way for describing application-independent concepts such as customer, employee, and account, business objects are used. Business Objects encourage a view of software that is superior to tools, applications, databases, and other system concepts. A business object, by definition, independent of any single application, is an application-level component that can be used in unpredictable combinations (Siau & Tian, 2004). It represents a recognizable everyday life entity. On the other hand, system-level objects represent entities that make sense only to information systems and programmers. In the CORBA model, a business object consists of three kinds of objects (OMG, 2004): a) Business objects encapsulate the storage, metadata, concurrency and business rule associated with an active entity. They also define how the object reacts to changes in the views. b) Business process objects encapsulate the business logic at the enterprise level. In CORBA, the business object handles shortlived process functions. The business process object handles long-lived processes that involve other business objects. The process object typically acts as the glues to unite the other objects. 7

8 c) Presentation objects represent the object visually to the user. Each business object can have multiple presentations for multiple purposes. The presentations communicate directly with the business object to display data on the screen. The OMG also recognizes that there are non-visual interfaces to business objects. The business object and the process object typically reside on a server. Here the business object may have different presentation objects spread across multiple clients (Joo-Hung, et al, 2003). The CORBA based architecture provides a unique view in which all the constituent objects have IDL defined interfaces and can run on ORBs (Siau & Tian, 2004). 3.4 Benefits of CORBA Programming-language independent interface Legacy integration Rich distributed object infrastructure Location transparency Network transparency Direct object communication 4 COM/DCOM 4.1 Introduction The Component Object Model (COM) and Distributed COM (DCOM) is a protocol that enables software components to communicate directly over a network in a reliable, secure and efficient manner. DCOM is designed for use across multiple network transports including both LAN and WAN protocols (Microsoft, 2000). DCOM is an extension of Microsoft s Component Object Model (COM) technology that allows applications to be built from different components that are deployed on a single machine. 4.2 COM/DCOM Overview COM defines how components and their clients interact. This interaction is defined so that the client and the component can connect directly. Figure 7 (Roy & Ewald, 1999) illustrates this in the notation of the Component Object Model: Figure 7: COM components in the same process Today's operating systems do not allow clients and components to communicate directly. These situations require the use of an inter process that is provided by the operating system (Inverardi & Tivoli, 2003). COM provides this communication transparently. COM intercepts calls from the client and forwards them to the component in another process. Figure 8 (Roy & Ewald, 1999) illustrates how the COM/DCOM run-time libraries provide the link between client and component. Figure 8: COM components in different processes When client and component reside on different machines, DCOM replaces the local interprocess communication with a network protocol (Ghosh & Mathur, 2001). Neither the client nor the component is aware that they are connected over a network. Figure 9 (Roy & Ewald, 1999) illustrates the overall DCOM architecture. The COM runtime provides object-oriented services to clients and components and uses RPC and the security provider to generate standard network packets that conform to the DCOM wireprotocol standard (Inverardi & Tivoli, 2003). 8

9 Figure 9: DCOM: COM components on different machines 4.3 COM Architecture COM is an object based programming model designed to allow development of software components at different times by different vendors using a variety of languages, tools, and platforms (Microsoft, 2000). This is only possible with the use of its interfaces, classes and servers, object life cycle, binary interoperability, and location transparency Interfaces A COM interface defines the behaviour or capabilities of a software component as a set of methods and properties. An interface acts as a contract between objects. An interface guarantees consistent semantics with the objects that support it (Inverardi & Tivoli, 2003). Each COM object must support at least one interface, although it may support more. Interfaces are described in the IDL. From the description in the IDL, the proxy and stub are generated automatically in code. The proxy and stub communicate with one another. They exchange requests and responses allowing the objects to act like a single application (Chiang, 2003). Each interface is assigned a universally unique identifier to eliminate any ambiguity that might arise from name collisions. This identifier serves as the cornerstone for all interfaces. The identifier is used to call and break procedures among objects (Chiang, 2003) Classes and Servers A COM class is a body of source code consisting of an implementation of one or more COM interfaces. A class provides functions in the supporting programming language for each interface method it supports (Metvidovic & Dashofy, 2003). Like interfaces each class has a unique identifier. To interact with a component, a client application must know at least one class ID and one interface ID that is supported by that class (Patil, et al, 2000). Using this information, clients can ask COM to create an object and return an appropriate interface pointer. One or more COM classes can now be packaged into a server. Depending on how the class are packaged inside the server, there can be two types (Microsoft, 2000): a) In-process server Here a COM server is packaged as a dynamic link library that is loaded into the client process when a class within the server is first accessed by a client. b) Out-of-process server-this type of server can run on the same machine as a client or on a remote machine that is accessible using DCOM. Here the server is packaged as a separate executable Object Life Cycle This section examines how a client causes a COM object to be created. Each COM object is an instance of a COM class. Each COM class is associated with another COM class called a class factory. The class factory creates instances of a COM class (Microsoft, 2000). 9

10 Figure 10: COM servers expose class and class factories COM s factory mechanism is shown in figure 10 (Microsoft, 2000). The factory typically supports a standard interface defined by COM. Given a class ID and a description of the COM associated COM server, COM can locate a factory for the given class ID (Suresh, 1999). Once a COM object has been created, COM specifies a standard protocol for tracking how many outstanding references there are to an object and when that object can be destroyed. COM objects maintain a reference count of all associated class Ids. When the reference count goes to zero, it is assumed that there are no longer any clients referring to the object, and so it can be destroyed (Inverardi & Tivoli, 2003) Binary Interoperability At the centre of COM is that components should be interoperable. For this, COM defines a binary call standard that defines the layout of the call stack for all method invocations. DCOM extends this interoperability by defining a network interoperability protocol. These interoperability specifications enable developers to focus on building components that will interoperate with all client environments (Plasil & Stal, 2000). The binary standard makes it easy to use offthe-shelf components without having access to source code. The binary standard defines pointers that point at function tables Packaging Transparency An important feature of the COM architecture is packaging transparency. Developers can deploy components as DLLs or as executables. COM client applications are not concerned with how a server is packaged or where its DLL or executable is located. Instead, the application uses COM to create objects based on a desired CLSID. The client can restrict the kind of server but does not need to do so. The client code for interacting with an in-process server is identical to that for calling out-ofprocess servers (Microsoft, 2000). The COM Library locates the implementation of a requested class and establishes a connection between the client and the server. COM offers this service by requiring providers of COM classes to register information about the type of server and the location of its DLL or executable in a local registry (Plasil & Stal, 2000). COM's Service Control Manager (SCM) looks up the CLSID in the registry and takes the appropriate action to activate the server. Developers do not interact with the SCM directly; instead, the COM library uses the SCM when asked to create an object or locate a class factory (Plasil & Stal, 2000). 4.4 DCOM extending COM Distributed COM extends the programming model introduced by COM to work across the network. These extensions include improved location and packaging transparency, additional threading models, improved security options, and additional administration capabilities. In this section, these extensions are briefly examined. 10

11 4.4.1 Location and Packaging Transparency With COM, client applications are written independently of the packaging of the server. COM objects may be loaded into the client process or launched in a separate process on the same machine. DCOM extends this transparency to include location transparency, allowing objects to exist anywhere on the network (Roy & Ewald, 1999). DCOM Object RPC (ORPC) is based on DCE RPC. It extends RPC to include an object reference data type and adds a parameter to each call for the target object. When a client requests a COM class factory for a remote object, the local SCM contacts the SCM on the remote machine. The remote SCM locates and launches the server and returns an RPC connection to the requested class factory provided by the server. A class factory proxy is created for the client application, and the object creation continues as in the nondistributed case (Roy & Ewald, 1999) Free-Threading Model Several factors impact the scalability of distributed object systems. To achieve the highest throughput on a single machine, developers typically need to build multithreaded servers. DCOM extends COM's support for development of multithreaded servers (Ghosh, & Mathur, 2001). With free threading, a separate thread handles each incoming object invocation, and multiple incoming calls can be dispatched on a single object at the same time in different threads. The COM library in conjunction with the RPC runtime library manages dispatching (Emmerich, 1998) Security DCOM provides multiple levels of security that can be selected as required by the developer and administrator. The ability to configure security of a component provides another level of transparency for developers. The same binary component can be used in one environment with no security requirements and in another environment that requires very strict security (Microsoft, 2000) Reference Counting and Pinging One of the issues faced by distributed application developers is writing servers that can detect when their clients have died (Zhang & Jacobsen, 2003). This is particularly important with DCOM, given the use of reference counting to determine when an object should go away. The typical solution is to perform periodic pings that indicate that a process is still alive (Medvidovic et al, 2003). This can increase traffic on the network. To optimize pinging, DCOM uses keep-alive messages on a per-machine basis. That is, independent of the number of client processes on a machine and the number of component servers being accessed on a particular remote machine, a single ping message is used between machines. If a client process dies, DCOM detects the situation and invokes the Release calls on the appropriate server interface pointers Microsoft, 2000). 4.5 COM+ COM+ is the next extension of the COM/DCOM architecture. Improvements here include a new threading model and an easier way to handle database connections. COM+ also enables easier interconnection of different languages and includes default implementations of standard COM interfaces that speeds up development time. 4.6 Benefits of DCOM Large User Base and Component Market Large-scale software reuse (no source code) Cross-language software reuse. On-line software update. Allows updating a component in an application without recompilation, relinking or restarting. Multiple interfaces per object Wide selection of programming tools available, most of which provide automation of standard code.5 Java RMI 5.1 Java RMI Introduction Java Remote Method Invocation (RMI) allows applications to call object methods located remo tely, sharing resources and processing load across systems. RMI allows any Java object type to be passed to and from methods. RMI allows both client and server to dynamically load new object types as required (Sun, 2000). Java RMI is a mechanism that allows an object to invoke a method on an object that exists in another address space. The other address space could be on the same machine or a different 11

12 one. The RMI mechanism is an object-oriented RPC mechanism (Suresh, 1999). RMI facilitates object function calls between Java Virtual Machines (JVMs). JVMs can be located on the same or separate machines. 5.2 JAVA RMI Overview The structure of an RMI-based method call involves a client, a server and a registry. Figure 11: Java RMI Overview To make a call to a remote object, the client first looks up the object that it is going to invoke a method on in the registry. The registry returns a reference to the object on the server, which the client can use to invoke any methods that the remote object implements. The client communicates with the remote object via a user-defined interface that is implemented by the remote object (Chiang, 2003). The client does not deal directly with the remote object at all, but with a code stub like in CORBA and COM that deals with the process of communication between client and server. On the server side a skeleton deals with client communication. The RMI compiler generates the code stub and skeleton automatically (Zhang & Jacobsen, 2003). Remote objects can be invoked with parameters that can be objects with methods. The basic structure is shown in figure 11 (Sun, 2000). The RMI server must implement the remote object's interface, and it must implement the methods in that interface. In addition to the methods of the interface, the server must also undertake a certain amount of initialisation that involves making the remote object available by binding it into the registry (Marquess, 2002). The client sets up a security manager, and must lookup the name of the remote object in the registry. The lookup process will return a reference to the remote object. The remote object can then be treated as if it was local (Marquess, 2002). 5.3 JAVA RMI Architecture The RMI system consists of three layers (Maasen, et al, 2002): The stub/skeleton layer - client-side stubs (proxies) and server-side skeletons The remote reference layer - remote reference behaviour (e.g. invocation to a single object or to a replicated object) The transport layer - connection set up and management and remote object tracking 12

13 The application layer sits on top of the RMI system. The relationship between the layers is shown in figure 12. Figure 12: The 3 layers of JAVA RMI architecture The RMI registry RMI uses a network-based registry to keep track of the distributed objects (Maasen, et al, 2001). The server object makes a method available for remote invocation by binding it to a name in the registry. The client object, in turn, checks for availability of an object by looking up its name in the registry. The registry acts as a limited central management point for RMI. The registry is a name repository (Marquess, 2002). It does not address the problem of actually invoking the remote method Stubs and Skeletons Because two objects reside on different machines, a mechanism is needed to transmit the client s request to invoke a method on the server object to the server object and provide a response. The compiler generates two files: a stub and a skeleton (Marquess, 2002) like in CORBA and COM/DCOM. The stub and skeleton reside on the client and server respectively. Both are comprised of JAVA code that provides the necessary links between the two objects. When the client invokes a server method, the JVM inspects the stub for type checking. The request is then routed to the skeleton on the server, which in turn calls the appropriate method on the server object (Patil, et al, 2000). In this way the stub acts as a proxy to the skeleton and the skeleton is a proxy to the remote method. 5.4 Advantages of RMI Support seamless remote invocation on objects in different virtual machines. Support call backs from servers to applets Integrate the distributed object model into the Java language Make differences between the distributed object model and local Java object model apparent Make writing reliable distributed applications as simple as possible. Preserve the safety provided by the Java runtime environment. Single language. 6 The middleware decision framework In the previous chapters various middleware technologies were discussed. In this chapter a framework is presented that can be used by enterprises to assist in the decision of which middleware to choose. 13

14 6.1 The middleware decision framework CORBA COM/DCOM Java RMI Language independent Preferred language: Visual Basic C++ skills Java Skills Platform independent Microsoft environment Type of application: Desktop Enterprise level Internet Can perform complex tasks Ease of learning Time to development The middleware decision framework helps an enterprise make decisions about choosing the correct middleware. It is illustrated in table 1 and the rows are defined as follows: Language independent: Does the middleware rely on a specific underlying language? CORBA and COM/DCOM are language independent. CORBA is a specification and if the specification is followed can be written using any language. COMDCOM also supports multiple programming languages since it is a binary standard and works under the language level. Java RMI however is solely based on the Java language and so is not language independent. For this reason CORBA and COM/DCOM are awarded a point each and Java RMI is awarded 0. Language: The next 3 rows points out the preferred language for each middleware. Although CORBA and DCOM are language independent, they are best programmed in C++ and VB respectively, while as already stated Java RMI exclusively uses Java. So for the purposes of the framework each technology is awarded a point for the language it is best implemented in. This can be used by enterprises when deciding on the best technology for its particular implementation. For example if a company already extensively uses Java, Java RMI will get awarded more points. More points will be awarded because less training will be needed for staff and there will be fewer complications that usually arise when introducing a new technology. Table 1: The middleware decision framework Platform Independent: Can the middleware be implemented across any platform? This row examines if the technologies can be implemented across multiple platforms and how easily this is achieved. In this area CORBA and Java RMI both receive 2 points. This is because they can be relatively easily implemented across any platform. COM/DCOM is platform independent but is not as easily implemented as the other technologies. COM/DCOM can be more easily implemented across a Microsoft platform and for this reason gets 1 point. Microsoft Environment: The next row follows on from the previous and asks if the current business environment is mainly a Microsoft environment or not. Although both CORBA and Java RMI can be implemented across a Microsoft environment COM/DCOM has been designed for this purpose and can be more easily integrated into a Microsoft environment. For this reason DCOM is awarded 1 and the other technologies are awarded 0. Type of Application: The next 3 rows define what kind of application the middleware is used best to aid development, although each is able to perform all of the named tasks. If components are connected to make a desktop application, DCOM is best, if components connect to make an enterprise wide application, CORBA is the best, and if components are connected to make an Internet application, Java RMI is best. For this reason each technology is awarded 1 point for the application that it is best suited to. 14

15 Can perform complex tasks: This row asks how complex are the tasks that will be performed? This relates to the passing of methods and objects between objects. Because Java RMI is based on Java it can perform anything that can be performed using Java giving it a lot more flexibility and enabling it to do complex tasks. While both CORBA and DCOM can use an assortment of languages, they do not fully take advantage of a lot of language functions. For this reason Java RMI is awarded 2 points while the other two technologies are awarded 1 each. Ease of learning: In this row the question of how easy the technology is to learn is asked. By this, it is meant, for some one with little or no experience with these technologies, how easy would it be to learn? CORBA is a specification that helps bind very deep underpinnings in technology. It is very complex and is difficult to learn. COM/DCOM is however better as it is heavily intertwined with Microsoft technology and persons with this background should be able to learn the necessary skills. The same is for Java RMI. Persons with a Java background should be able to learn the technology easily. For these reasons Java RMI and COM/DCOM are awarded 1 each while CORBA is awarded 0. Time to development: In this row the question of time to development is asked. How long would it take to develop applications so they are fully linked with one another? In this area tools and other features that speed up development time are examined. CORBA has been around the longest and has an extensive range of tools and applications that can be deployed to speed up development. Java RMI and COM/DCOM are however still extensively supported but not as much as CORBA is. For this reason CORBA is awarded 2 while Java RMI and COM/DCOM are awarded 1 each Using the framework Use of the framework is relatively simple. An enterprise will view the list of selections and rewrite the list with the most important item on the top and second most important item below it and so on until the list is rewritten with each item ranked. CORBA DCOM Java RMI Preferred language: C++ (6) Platform independent (5) Time to development (4) Type of application: Internet (3) Can perform complex tasks (2) Preferred language: Java (1) Microsoft environment Type of application: Desktop Enterprise level Language independent Ease of learning Preferred language: Visual Basic If the enterprise does not require all items on the table, the items can be left out and so are not counted. Table 2: The middleware decision framework: Ranked The figures under each of the technologies are then multiplied by the relevant weight to give a new table shown in table 3. Now weights are added to each item in the relevant part of the table. The least is awarded with 1 and the next with 2 and so on until the top of the list is awarded with the highest weight as is shown is table 2. When all the figures are multiplied, each row is then added together to give each technology a final score. In table 3 CORBA gets the highest score and so in this case would be the best suited for the particular enterprise. 15

16 It should be noted that this framework is an aid in helping enterprises making the correct decision. To make the correct decision many Table 3: The middleware decision framework: Results more aspects should be examined that involve examining code and the inner workings of systems. CORBA DCOM Java RMI Preferred language: C++ (6) Platform independent (5) Time to development (4) Type of application: Internet (3) Can perform complex tasks (2) Preferred language: Java (1) Conclusions This paper discussed middleware technologies in detail. Middleware is very important technology that is essential for the integration of old systems and other company systems. Opening this paper was a section on distributed component computing. In this section a brief introduction into distributed component computing was discussed as well as a brief history. This was followed by an introduction into the technology that enables distributed component computing. That is middleware. This section was followed by three sections, each focusing on a particular middleware technology. These were CORBA, COM/DCOM and Java RMI. Each of these technologies was examined with a general overview. This was followed by a study of each of the technologies underlying architecture. In the final section a framework was presented that helps enterprises make the decis ion on what is the right middleware for its particular situation. The framework examined each of the middleware s strong and weak points and placed them in a table. Enterprises could now examine the table and prioritise what was most important to its own situation. This could then be used to aid the enterprise in making the decision of choosing the correct middleware. Choosing the correct middleware is crucial for any enterprise that is planning on combining components and systems. The correct middleware can allow for an efficient link between systems that can be scalable, cost efficient and interoperable. The wrong choice of middleware can create a lot of problems including that of bad data, which may not be spotted for some time. 8 References BAKKEN, DAVID, Middleware, 1998, Washington State University CHIANG, C, The use of adapters to support interoperability of components for reusability, Information & Software Technology, EMMERICH, WOLFGANG, Distributed Component technologies and their software engineering implications, International Conference on software engineering, GHOSH, SUDIPTO, MATHUR, ADITYA, Certification of distributed component computing Middleware and application, Colorado state university, HOFFMAN, RICHARD, No more middle ground for middleware, Network Computing, INTEL, Building a better ebusiness infrastructure, Intel ebusiness white paper, 2001 INVERARDI, Paola, Tivoli, Massimo, Deadlock free software architectures for COM/DCOM applications, Journal of Systems and software, JOO-HUNG, OH, PARK, JUN-HO, JUNG, GI- HOON, KANG, SOON-JU, CORBA based Core Middleware Architecture Supporting Seamless Interoperability between standard home network middlewares, IEEE Transactions on Consumer Electronics, MAASEN, JASON, VAN NIEUWPOORT, ROB, VELDEMA, RONALD, BAL, HENRI, KIELMANN, THILO, JACOBS, CERIEL, HOFMAN, RUTGER, Efficient Java RMI for parallel programming, ACM Transactions on Programming Languages & Systems, MARQUESS, PAULO, Building Secure RMI Servers, Dr. Dobbs Journal: Software 16

17 Tools for the professional programmer, MEDVIDOVIC, NENAD, DASHOFY, ERIC, TAYLOR, RICHARD, The role of middleware in architecture-based software development International Journal of Software Engineering & Knowledge Engineering, MICROSOFT WHITE PAPER, Windows COM/DCOM architecture, OMG, Common Object Request Broker Architecture: Core Specification, PATIL, ABHISHEK, KORDE, RAJESH, SABHARWAL, A comparison of middleware technologies CORBA, RMI, & COM/DCOM, Michigan State University, PLASIL, FRANTISEK, STAL, MICHAEL, An architectural View of Distributed Objects and Components in CORBA, Java RMI, and COM/DCOM, A submission to software, concepts and tools, ROY, MARK, EWALD, ALAN, Inside DCOM, DBMS and Internet systems, SCHUSSEL, GEORGE, Client/Server: Past, present, and future, available [online]: , [April 2004]. SHIN, JUNHO, PARK, SUNGSIK, JU, CHULJIN, CHO, HYUNBO, CORBA based integration framework for distributed shop floor control, Computers and Industrial Engineering, SIAU, KENG, TIAN, YAHONG, Supply chains integration: Architecture and enabling technologies, Journal of Computer Information Systems, SUN MICROSYSTEMS, Scaling the n-tier architecture, SUN WHITE PAPER, Java Remote Method Invocation-Distributed Computing for Java, SURESH GOPALAN, DCOM, CORBA, Java RMI-A step by step comparison, 1999, available online [ ompare.html], April 04. THE OPEN GROUP, Distributed Computing for the extended enterprise-challenges and directions, Discussion paper, Definition of distributed computing, available [online]: RM/d/distributed_computing.html, 2004 [April 2004]. Zhang, Charles, Jacobsen, Hans-Arnold, Refactoring middleware with aspects, IEEE Transactions on Parallel & Distributed Systems, Copyright Copyright 2004 The author assigns to Dublin Institute of Technology a non-exclusive license to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive license to Dublin Institute of Technology to publish this document in full on the World Wide Web (prime sites and mirrors) and in printed form within Dublin Institute of Technology publications. Any further usage is prohibited without the express permission of the author. 17