Image management on Internet. Eric Nzaramba

Size: px
Start display at page:

Download "Image management on Internet. Eric Nzaramba"

Transcription

1 Image management on Internet Eric Nzaramba June 2001

2 Abstract The main goal of the project is designing and implementing libraries in a client-server system that will support the management of files (biomedical images) on an internet or intranet. The system should be ergonomic, secure, portable and flexible. For this reason I choose to use the CORBA-standards for designing it. The libraries will be written in the C++ programming language, on linux. Because of its portability, QT is an adequate tool for developing a Graphic User Interface.

3 Contents 1 Introduction Objectives of the project (Object Oriented) Distributed Operating Systems Marshalling/demarshalling Proxy Copying Design Requirements Remote Procedure Call (RPC) State of the art CORBA Object Management Group Context of CORBA Definition of CORBA Compliance CORBA Overview Structure of an Object Request Broker (ORB) Dynamic Invocation Interface (DII) Dynamic Skeleton Interface (DII) Example ORBs Structure of a Client Structure of an Object Implementation Structure of an Object Adapter CORBA required Object Adapter The Project Introduction Designing the classes Integrating CORBA GUI: (UML) Users and Classes Diagram Introducing the program

4 CONTENTS 4 Used Tools MICO ( MIco is COrba ) QT Conclusion Achievments Possible improvements A Some QT classes used in the project 66 A.1 QDir Class Reference A.2 QFile Class Reference A.3 QFileInfo Class Reference A.4 QListViewItem Class Reference A.5 QListView Class Reference A.6 QString Class Reference

5 Chapter 1 Introduction 1.1 Objectives of the project The point is to develop a system that will support files exchange in a network. I should actually say another system. There already are many such systems available, some with more possibilities or user friendlier than others. The reason of the present project is to develop software specific to an organisation. And, of course, it should be simple and easy to use too. The organisation in question is a clinic which should use the system to exchange bio-medical images among its different departments across Spain. Then the obvious needed functionalities are to view the exported directory of any host connected to the (intra)net to open and/or copy a file on the local host The fact that we re dealing with images will only be important when implementing the open(file) function. Until then, we are working with streams of bytes, or just files. The main functions are connectto(host), viewandnavigate(exported directory), open(file) and import(file). We would have wanted more transparency, but in this case I m afraid we don t have any choice than to let the user (client) select the host to scan. We could of course implement a sort of dispatcher whereto the client will have to send the requests only mentionning the file name (the client should then only know the dispatcher location), but different files on different hosts can have the same name and even a lookalike path. And the user would be required to perfectly know the file name (path) which is too much asking. And finally but not least, the presence of a dispacher weakens the system making it dependant to one machine or a certain number of machines, in the case of multidispatching. In our case, it doesn t matter if a machine breaks down, others are always available, waiting to be searched. 3

6 1.2. (OBJECT ORIENTED) DISTRIBUTED OPERATING SYSTEMS The system will be based on RPC (Remote Procedure Control) which means client and server will communicate through methods with arguments and results instead of request and reply messages. We will use one of the Object Oriented Distributed System Protocols, CORBA in this case. We will only use freely available tools (OpenSource). 1.2 (Object Oriented) Distributed Operating Systems See [6], [4] Distributed object computing systems such as COM+ (and its ancestors OLE, OLE2, COM, DCOM et alia) and CORBA are the results of extensive development and research. The concept of inter-object message brokering plays a central role in these types of systems. Message brokering, often referred to as remote procedure calls (RPC), is at the heart of systems whose labels include client/server, n-tier applications and distributed object computing. The industry knowledge related to message brokering issues has evolved to where the current generation of systems have very similar feature sets. CORBA represents an effort to codify such technology in an open standard. There are many styles of inter-component communication in distributed object systems. The style used by COM+, CORBA, or Java is interface based. The concept of interfaces has been implemented since the early days of object oriented programming although more recent systems have refined the concept and represented it more explicitly in syntax. The goal of interface-based distributed object communication is to enable a software object on one machine to make method calls on a software object (potentially) located at another machine without the programmer or the objects having to directly deal with the fact that the communicating objects are possibly on separate machines. The core of this technique is that by typing the target object of the method call to an interface as opposed to a specific class, the method call can actually be made on an intermediary located on the same machine. This intermediary, that we will call a proxy, implements the same interface as the real target of the message. The proxy is simply a helper which relays the message to the intended target. Symmetrically, there is a helper object on the destination host which receives the networked message intended for the target object. This object is termed the skeleton (cf CORBA). In general, the situation is that object A runs on machine X and needs to call a method on object B which runs on machine Y: Proxy (of object B) runs on machine X. Skeleton (of object A) runs on machine Y.

7 1.2. (OBJECT ORIENTED) DISTRIBUTED OPERATING SYSTEMS The proxy and skeleton are essentially the ends of a virtual connection B s proxy has the same surface (interface) as object B Proxy and skeleton do the work of moving the request (method call) and response (method return) over the network (marshalling/demarshalling) Interface-based communication coupled with an axiomatic set of intrinsic (or primitive) data-types (Interface Definition Language) and their representation on the wire, allows objects to communicate in a language independent fashion Marshalling/demarshalling Sending objects over the network is not trivial since the network is not aware of objects. It essentially supports bit transmission. The mechanism that we use to send and receive objects is called Marshalling/demarshalling. This technique is fundamental to object passing/copying in a distributed system. For example, Java uses JRMP (Java Remote Method Protocol) to marshall/demarshall Java objects. CORBA uses RPC or IIOP. DCOM uses ORPC. Gemstone uses SRP. Opentalk has #marshallobject: and #unmarshallobject: messages on STSTStream objects. Glorp stores object into RDBMS using Smalltalk-to-database-table mapping. Jato converts Java objects into XML documents and vice versa. Some systems don t move objects, instead they only move data structure and object references. However, systems that support object migration have to worry about reading and writing object format. In summary: We need a universal mechanism to move objects and it should work with all types. We should be able to customize what to send or what not to send such as cache data or temporary or infrequently used variables We convert objects into bit streams so that we can send them across the wire. We should automatically reconstruct objects at the destination. Marshalling/Demarshalling are used for sending and receiving objects between different address spaces. Marshalling transforms an object into a stream that can be sent across the network while demarshalling transforms the stream back to the object. Both sides must use the same protocol to encode and decode object structure and data. A stream can be in either binary or ASCII format. Usually each side has the object structure so only data will be sent. If the object structure has been changed, the receiver

8 1.2. (OBJECT ORIENTED) DISTRIBUTED OPERATING SYSTEMS must be able to detect the change and either throw an exception or request the new object structure to reconstruct the object. In many cases, we need to recompile remote interfaces (IDL in CORBA) or stubs (Java RMI) and send them to the remote machines. Object A in a local machine wants to pass parameters to object B at a different machine. At the local machine, there is a proxy that represents B. Object A passes parameters to the proxy. Each object that needs to be moved has to implement an interface that writes itself into a stream (writeobject) and constructs itself from a stream (readobject). The proxy calls the writeobject method on each parameter and sends the stream to the remote location. At the remote location, the skeleton of object B retrieves the stream of each parameter and calls its readobject method to reconstruct each parameter. Finally, the skeleton calls object B with the reconstructed parameters. writeobject: usually uses object reflection to obtain a name and a value of each instance variable. On the other hand, we can write custom code to selectively serialize particular instance variables, bypassing cache or any temporary variable that can be recomputed at the destination. The default implementation of marshalling/demarshalling can be slow. There are several techniques to make the process faster. For example, they may use proxy to cache data. They may use a compression algorithm to reduce data transmission size with the expense of compression time. Or instead of sending string streams, we can use byte streams. However, string stream often has an advantage in clarity and it is human readable. Many systems use XML as an object representation to provide better interoperability across programming languages and platforms. Examples are applications based on SOAP and ebxml. Since marshalling converts objects into streams. It can be used as an object serialization to store objects in a stable storage. Once they are stored, the computer can be shut down. When it reboots, it can reconstruct them back. Or they can be shipped and executed at another computer. Proxy uses marshalling/demarshalling to pass object parameters. Object copying uses it to copy objects in distributed systems Proxy The problem we re facing here is of making objects usable where they are needed not where they reside. A consequence of this issue is the debate whether moving/copying objects is appropriate or not. Sometimes moving or copying objects around is costly or inappropriate. The system should provide a way for making references to remote objects. Objects are required to be used in an address space different from where they reside. Copying objects from where they reside to where they need

9 1.2. (OBJECT ORIENTED) DISTRIBUTED OPERATING SYSTEMS to be used is an expensive operation. Making copies of an object and maintaining each version updated is a costly operation and requires the implementation of a complex system of update semantics (session, transaction, etc...) and callbacks. Developers of the system should not use a different semantic at the time of invoking operations of an object based on its location. The system at run-time is the one that knows if an object is local or remote to a message sent in some part of the distributed system. Proxy is useful for alleviating the cost of moving/copying objects among parts of the distributed system. It makes possible to copy or move an object without the entire graph of referenced objects. In the case of mappings from objects systems to non-objects repositories, a similar problem is found when developers has to retrieve information from the database. Retrieving the entire graph of referenced objects is a costly operation and sometimes the user will not use all the information but a fraction of it. Developers have to be sure that the user needs the information that the system is going to retrieve from the database. A remote reference to an object stored in the database is required. The proxy is an object that traps messages sent to it. After trapping a message the proxy forwards the message and its parameters to the real object. A different implementation is having a stub for each class that is going to be distributed. The Stub-class implements the same methods as the original one but it forwards the methods and its parameters. The presence of Stub-class is usually complemented with Skeleton-class; while the Stub-class does the marshalling the messages and parameters, the Skeleton-class does the unmarshalling of messages and parameters and sends them to the real object. CORBA, RMI are in general sense examples of this implementation. In the case of distributed object-oriented system, the proxy is a forwarder of the messages it gets. In the context of client-(relational database) server applications, the proxy retrieve the object it represents from the database and then sends to it the messages it gets Copying When programming in a shared address space, it isn t natural to think about explicit copying of data. Typically, pointers are used heavily as references to a single shared copy of data. The major source of data copying in shared address space (SAS) programming occurs during function calls, when the parameters are passed by value. Thus, the central choice in SAS programming revolves around whether a set of data must be copied by value or by

10 1.2. (OBJECT ORIENTED) DISTRIBUTED OPERATING SYSTEMS reference. When copying by value, a complete copy of the data will be made, in a new location. When copying by reference, a new pointer to the data will be made, which will refer to the original set of data. In contrast, distributed object systems employ copying to a far greater degree. Since by their very nature, distributed object systems attempt to tie multiple distinct address spaces together, data must be copied so that it can reside in multiple addresses spaces at one time. Thus, the issue of data copying is more in the programmer s face. However, there are similarities to the SAS manner of programming. In order to copy by value in an distributed environment, an object copy is created and sent over the network. In order to copy by reference, a proxy object is created, that invisibly passes transactions over the network to a remote object. Implication of Object Copying The principle advantage of using an object copy is speed once the onetime transmission penalty has been paid, further access to the object runs at full system speed. The principle disadvantage of pass by value is that with multiple copies, it becomes easier for the programmer to be confused, and make updates to a copy of the object that are not reflected in the original. Furthermore, additional difficulties arise when the programmer considers if they wish to make a deep or shallow copy of their object. Deep copies incur higher copy and transmission overheads, but are more semantically correct (i.e. a deep copy will function consistently on both the remote and source hosts). Shallow copies, on the other hand, sacrifice transparency for speed (both in terms of copy complexity, and transmission complexity). Implication of Object References Similarly, the advantages and disadvantages for remote proxy method are the exact inverse of those for object copy. The principle advantage of the remote proxy is programmer consistency only one instance of the object exists in the entire world, and all changes will be made to that one instance. The principle disadvantage of the remote proxy is that each and every interaction with the original object must go through the network, which incurs latency and access concurrency (i.e. locking) overheads. Another difficulty with the remote proxy is that each remote client must create an instance of the proxy. In order to create a proxy (i.e. remote reference) to an object, its global identifier must somehow be obtained. The expense of this operation depends upon the object system, but it typically requires the maintenance of some sort of object directory service.

11 1.2. (OBJECT ORIENTED) DISTRIBUTED OPERATING SYSTEMS Copying and Passing an Object through the Network In order to implement pass by value, a copy must be made of all of the parameter objects. It isn t innately obvious, however, if other objects referenced by the parameter objects should be copied as well. The transmission of these objects over the network is accomplished via marshalling techniques Design Requirements The following are among the design requirements: Maintain programming language and platform neutrality Systems such as Java s RMI which impose constraints on the programming language of implementation are unacceptable. Other current distributed object systems are language neutral. This is a requirement for technological adoption. Interoperability across programming languages is achieved by agreeing on a common set of primitive data types. Be object-oriented Object oriented (or object based) computing has matured greatly in recent years and is now in mainstream commercial use. Any new distributed computing system should be object oriented from the ground up. This includes such concepts as user defined exceptions for reporting errors. Keep the clients and protocol simple Independent of scalability concerns, the protocol and client code should be simple. This will also allow very low end machines to be able to participate in the system. This is viewed as one of the most important requirements. Put the burden of intelligence on the servers For server robustness and scalability the design should impose the burden of intelligence on the server. This allows such chatty and complicated techniques as object reference counting and pinging to be excluded from client code and wire protocol. Object reference counting implies the representation of state in the protocol which is not natural to the Web. (Note that specific applications might still implement a pinging mechanism but such techniques must not be part of the core protocols.) A robust and scalable server cannot assume that object references will be correctly accounted on the Web; the server must be able to control resource allocation by itself. This implies a simpler wire protocol Remote Procedure Call (RPC) What it is RPC is concerned with interaction between processes. As a piece of software, it is a toolkit for building distributed processing applications. It is:

12 1.2. (OBJECT ORIENTED) DISTRIBUTED OPERATING SYSTEMS a set of rules for marshalling and unmarshalling parameters and results. This is the activity that takes place at the point where the control path in the calling and called process enters or leaves the RPC domain; a set of rules for encoding and decoding information transmitted between two processes; a few primitive operations to invoke an individual call, to return its results, and to cancel it; provision in the operating system and process structure to maintain and reference state that is shared by the participating processes. RPC requires a communications infrastructure to set up the path between the processes and provide a framework for naming and addressing. Anything that provides these services will do. There are two models that provide the framework for using the tools. These are known as the computational model and the interaction model. The computational model is almost self-explanatory: it describes how a program executes a procedure call when the procedure resides in a different process. The interaction model describes the activities that take place as the call progresses. The marshalling component and the encoding component are brought together by an Interface Definition Language (IDL). An IDL program defines the signatures of RPC operations. The signature is the name of the operation, its input and output parameters, the results it returns and the exceptions it may be asked to handle. It is tempting to describe RPC as all interactions between separate components of a distributed processing system. This is wrong. RPC has a definite model of a flow of control that passes from a calling process to a called process. This will be familiar to anyone who has written a program in a block structured language that runs on a processor with a stack. The calling process is suspended while the call is in progress and is resumed when the procedure terminates. The procedure may, itself, call other procedures. These can be located anywhere in the systems participating in the application. There are three essential differences between RPC and its local equivalent: 1. the local context representing the state of the virtual machine that is executing the process; 2. the permanent and temporary variables that are accessible, i.e. in scope, to the calling procedure and the called procedure.these are no longer in the same virtual address space;

13 1.2. (OBJECT ORIENTED) DISTRIBUTED OPERATING SYSTEMS 3. the primitive datatypes and their semantics, which may vary if the processor architectures are different. References to variables, i.e. pointers, that are transferred, created, destroyed or otherwise manipulated are particularly difficult to handle. The RPC tools must ensure that sufficient information is transferred between the processes to maintain these aspects of process state.good design practice aimed at elimination of side-effects will minimise the dangers caused by these dislocations of time, space, and semantics. What it is not RPC is not a model for all kinds of interaction between components of a distributed processing system. It is easy enough to identify specific examples just by looking for interaction models that do not transfer a locus of control. This includes streams of data that are self contained, or distributed systems composed of processes that cooperate from time to time but lead a separate independent life otherwise. This latter class includes transaction processing systems and the increasing number of object-oriented applications, in particular network management. They may be closely coupled systems, there may be hundreds or thousands of components, but they are not RPC systems. This does not mean that an RPC toolkit is not appropriate to develop parts of these applications. Each part of the toolkit has a high value as a means of getting information between processes. Every distributed system needs the marshalling function to get data in and out over the boundary between the application and the communications system. Every communications platform needs encoding rules to convey datatypes between systems. The IDLs that make this possible are found everywhere. Standards People like to make facetious remarks about the rich variety of standards and play around with ways of doing the same thing using different standards. This is not the point of course: standards compete and evolve; the fittest survive. A single standard for a particular application is not necessarily the best outcome. The important part is to be sure that it states clearly what it means, what it does, and how it does it to provide a basis of common understanding. RPC is a good case study of this process. There are several unclassified species, de- facto standards among them, SUN RPC being one. The other, better catalogued, varieties are tended by standards bodies such as: ISO, through JTC1/SC21. Both WG8 (OSI upper layers) and WG7 (ODP) are working on RPC and related topics. Maybe they will converge in time. For the present, the ODP groups are focussing on IDLs

14 1.3. STATE OF THE ART and the trading tools, so called middleware, that allow applications to be constructed in an open and dynamic way; X/Open, which sits between ISO and the consortia of manufacturers, vendors and users (such as the Open Software Foundation). X/Open promotes open standards and functional standards in industry and in standards bodies; Internet Engineering Task Force. European Computer Manufacturers Association. Other organisations take on more specialised roles. The IEEE promotes programming interfaces through POSIX, for example. 1.3 State of the art See [5], [3]. There are various Distributed Objects Systems. Here is a list of some of them with some of their features: CORBA/SOM: IDL x-os x-language Pass object by value Pass object by reference Dynamic Invocation (Interface Repository) DCOM: MIDL/ODL NT, Solaris, Windows 95 (Soon: Mac Linux, Digital Unix, IBM MVS) x-language Pass object by value Pass object by reference Dynamic Invocation (Type Library) NeXT PDO/WebObject: ObjectiveC NT, Solaris,Mach (Soon: Mac)

15 1.3. STATE OF THE ART RMI: Java x-os x-language Pass object by value Dynamic Invocation (Reflection) Visigenic s VisiBroker for Java: Java x-os HORB: E: Pass object by value Pass object by reference Java x-os Pass object by value Pass object by reference E x-os Evaluating the Systems: Corba Pro s: Cross: CPU/Architecture, OS, Language Maturity (3rd generation) Open Standard controlled by Committee Multiple implementations Con s: IDL - Cross platform/os/language means interface complexity Committees can move slowly (currently 18 mos. spec to impl) Implementors must make money on Orbs / limiting dissemintation

16 1.3. STATE OF THE ART DCom RMI Pro s: Windows integration Widespread Dissemination Pass by reference and value Just COM w/ a longer wire Can inject code into the client. Con s: No interface inheritance. Not a true OOP system No state maintained between connections Immature (1st generation) IDL/ODL Code injection appears to be limited to supported binaries... Java DCOM doesn t garbage collect... leaving it to the OS at program exit (bad for Servers) Pro s: HORB Cross: cpu/os Autodisemmination Pass by reference and value Con s: Pro s Not as full featured as the Corba spec Really only available in JDK kb additional to a HORB enabled applet Considerably faster than RMI in some areas. Remote Object Creation Con s : No private variables yet (poor mans serialization) WebBroker Systems From the developers perspective, WebBroker unifies the Web browsing and distributed object paradigms. Previous systems required an application to drop out of the Web paradigm if ORB-like functionality is needed (e.g Netscape 4 which shipped with an IIOP ORB or Microsoft IE4 and the

17 1.3. STATE OF THE ART DCOM protocol). By formulating a ORB-like mechanism in terms of Web standards the two models are unified and so ease the developer learning curve. This also reduces the amount of code. The transport mechanism is already provided by HTTP; no need for another wire protocol. Likewise, this reduces the number of parsers needed on the client. In general less code means less software errors, lighter clients, and greater interoperability. Simply recasting distributed computing binary file formats to XML document types is beneficial. The extensible, hierarchical nature of XML increase interoperability. Consider such constructs as Microsoft s type libraries (TypeLibs). These are privately formatted binary documents which are accessible through the Win32 TypeLib APIs. They are simply declarative documents which describe software components. By recasting these to XML documents (one of XML deliverables in progress) they are open and extensible. This way there is no need for a specialized TypeLib parser on light weight clients; the XML processor is sufficient. TypeLibs can be interlinked. This can be recast to linked XML documents. Another candidate for syntactical translation is the Interface Definition Language (IDL). IDL documents look like procedural source code but are purely declarative documents void of procedural code. They are made to look like C code (with extra attributes ) because they are meant to represent interfaces to software objects. Interfaces are essentially collections of methods. Declarative documents on the Web are to be expressed in XML syntax. So IDL files and TypeLibs can both be expressed as XML documents. Indeed they are one and the same. The CORBA Interface Repository and the COM+ type information in the Registry both become a collection of interlinked XML documents available on a Web server. No longer is there an unnecessary distinction between interface description and interface repository. DICOM: The Value and Importance of an Imaging Standard[3] DICOM (Digital Imaging and Communications in Medicine) is the industry standard for transferral of radiologic images and other medical information between computers. Patterned after the Open System Interconnection of the International Standards Organization, DICOM enables digital communication between diagnostic and therapeutic equipment and systems from various manufacturers. Such connectivity is important to cost-effectiveness in health care. DI- COM users can provide radiology services within facilities and across geographic regions, gain maximum benefit from existing resources, and keep costs down through compatibility of new equipment and systems. For example, workstations, CT scanners, MR imagers, film digitizers, shared archives, laser printers, and host computers and mainframes made by multiple ven-

18 1.3. STATE OF THE ART dors and located at one site or many sites can talk to one another by means of DICOM across an open-system network. As a result, medical images can be captured and communicated more quickly, physicians can make diagnoses sooner, and treatment decisions can be made sooner.

19 Chapter 2 CORBA See [2], [1]. 2.1 Object Management Group The Object Management Group 1, Inc. (OMG) is an international organization supported by over 800 members, including information system vendors, software developers and users. Founded in 1989, the OMG promotes the theory and practice of object-oriented technology in software development. The organization s charter includes the establishment of industry guidelines and object management specifications to provide a common framework for application development. Primary goals are the reusability, portability, and interoperability of object-based software in distributed, heterogeneous environments. Conformance to these specifications will make it possible to develop a heterogeneous applications environment across all major hardware platforms and operating systems. OMG s objectives are to foster the growth of object technology and influence its direction by establishing the Object Management Architecture (OMA). The OMA provides the conceptual infrastructure upon which all OMG specifications are based. 2.2 Context of CORBA The key to understanding the structure of the CORBA architecture is the Reference Model, which consists of the following components: Object Request Broker, which enables objects to transparently make and receive requests and responses in a distributed environment. It is the foundation for building applications from distributed objects and for interoperability between applications in hetero- and homogeneous environments

20 2.3. DEFINITION OF CORBA COMPLIANCE Object Services, a collection of services (interfaces and objects) that support basic functions for using and implementing objects. Services are necessary to construct any distributed application and are always independent of application domains. For example, the Life Cycle Service defines conventions for creating, deleting, copying, and moving objects; it does not dictate how the objects are implemented in an application. Specifications for Object Services are contained in CORBA services: Common Object Services Specification. Common Facilities, a collection of services that many applications may share, but which are not as fundamental as the Object Services. For instance, a system management or electronic mail facility could be classified as a common facility. Information about Common Facilities will be contained in CORBA facilities: Common Facilities Architecture. Application Objects, which are products of a single vendor on in-house development group that controls their interfaces. Application Objects correspond to the traditional notion of applications, so they are not standardized by OMG. Instead, Application Objects constitute the uppermost layer of the Reference Model. The Object Request Broker, then, is the core of the Reference Model. It is like a telephone exchange, providing the basic mechanism for making and receiving calls. Combined with the Object Services, it ensures meaningful communication between CORBA-compliant applications. 2.3 Definition of CORBA Compliance The minimum required for a CORBA-compliant system is adherence to the specifications in CORBA Core and one mapping. Each additional language mapping is a separate, optional compliance point. Optional means users aren t required to implement these points if they are unnecessary at their site, but if implemented, they must adhere to the CORBA specifications to be called CORBA-compliant. For instance, if a vendor supports C++, their ORB must comply with the OMG IDL to C++ binding specified in the C++ Language Mapping Specification. Interoperability and Interworking are separate compliance points. As described in the OMA Guide, the OMG s Core Object Model consists of a core and components. Likewise, the body of CORBA specifications is divided into core and component-like specifications. The CORBA core specifications are categorized as follows: CORBA Core, CORBA Interoperability and CORBA Interworking. I will just give an overview of the CORBA core, for more information visit the sites and

21 2.4. CORBA OVERVIEW 2.4 CORBA Overview The Common Object Request Broker Architecture (CORBA) is structured to allow integration of a wide variety of object systems Structure of an Object Request Broker (ORB) Figure 2.1 shows a request being sent by a client to an object implementation. The Client is the entity that wishes to perform an operation on the object and the Object Implementation is the code and data that actually implements the object. Figure 2.1: A Request Being Sent Through the Object Request Broker The ORB is responsible for all of the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. The interface the client sees is completely independent of where the object is located, what programming language it is implemented in, or any other aspect that is not reflected in the object s interface. Figure 2.2 shows the structure of an individual Object Request Broker (ORB). The interfaces to the ORB are shown by striped boxes, and the arrows indicate whether the ORB is called or performs an up-call across the interface. To make a request, the Client can use the Dynamic Invocation interface (the same interface independent of the target object s interface) or an OMG IDL stub (the specific stub depending on the interface of the target object). The Client can also directly interact with the ORB for some functions. The Object Implementation receives a request as an up-call either through the OMG IDL generated skeleton or through a dynamic skeleton. The Ob-

22 2.4. CORBA OVERVIEW Figure 2.2: The Structure of Object Request Interfaces ject Implementation may call the Object Adapter and the ORB while processing a request or at other times. Definitions of the interfaces to objects can be defined in two ways. Interfaces can be defined statically in an interface definition language, called the OMG Interface Definition Language (OMG IDL). This language defines the types of objects according to the operations that may be performed on them and the parameters to those operations. Alternatively, or in addition, interfaces can be added to an Interface Repository service; this service represents the components of an interface as objects, permitting run-time access to these components. In any ORB implementation, the Interface Definition Language (which may be extended beyond its definition in this document) and the Interface Repository have equivalent expressive power. The client performs a request by having access to an Object Reference for an object and knowing the type of the object and the desired operation to be performed. The client initiates the request by calling stub routines that are specific to the object or by constructing the request dynamically (see figure 2.3). The dynamic and stub interface for invoking a request satisfy the same request semantics, and the receiver of the message cannot tell how the re-

23 2.4. CORBA OVERVIEW Figure 2.3: Client Using the Stub or Dynamic Invocation Interface quest was invoked. The ORB locates the appropriate implementation code, transmits parameters, and transfers control to the Object Implementation through an IDL skeleton or a dynamic skeleton (see figure 2.4). Skeletons are specific to the interface and the object adapter. In performing the request, the object implementation may obtain some services from the ORB through the Object Adapter. When the request is complete, control and output values are returned to the client. The Object Implementation may choose which Object Adapter to use. This decision is based on what kind of services the Object Implementation requires. Figure 2.5 shows how interface and implementation information is made available to clients and object implementations. The interface is defined in OMG IDL and/or in the Interface Repository; the definition is used to generate the client Stubs and the object implementation Skeletons. The object implementation information is provided at installation time and is stored in the Implementation Repository for use during request delivery.

24 2.4. CORBA OVERVIEW Figure 2.4: An Object Implementation Receiving a Request Object Request Broker In the architecture, the ORB is not required to be implemented as a single component, but rather it is defined by its interfaces. Any ORB implementation that provides the appropriate interface is acceptable. The interface is organized into three categories: 1. Operations that are the same for all ORB implementations 2. Operations that are specific to particular types of objects 3. Operations that are specific to particular styles of object implementations Different ORBs may make quite different implementation choices, and, together with the IDL compilers, repositories, and various Object Adapters, provide a set of services to clients and implementations of objects that have different properties and qualities. There may be multiple ORB implementations (also described as multiple ORBs), which have different representations for object references and different means of performing invocations. It may

25 2.4. CORBA OVERVIEW Figure 2.5: Interface and Implementation Repositories be possible for a client to simultaneously have access to two object references managed by different ORB implementations. When two ORBs are intended to work together, those ORBs must be able to distinguish their object references. It is not the responsibility of the client to do so. The ORB Core is that part of the ORB that provides the basic representation of objects and communication of requests. CORBA is designed to support different object mechanisms, and it does so by structuring the ORB with components above the ORB Core, which provide interfaces that can mask the differences between ORB Cores. Clients A client of an object has access to an object reference for the object, and invokes operations on the object. A client knows only the logical structure of the object according to its interface and experiences the behavior of the object through invocations. Although we will generally consider a client to be a program or process initiating requests on an object, it is important to recognize that something is a client relative to a particular object. For example, the implementation of one object may be a client of other objects. Clients generally see objects and ORB interfaces through the perspective of a language mapping, bringing the ORB right up to the programmer s level. Clients are maximally portable and should be able to work without

26 2.4. CORBA OVERVIEW source changes on any ORB that supports the desired language mapping with any object instance that implements the desired interface. Clients have no knowledge of the implementation of the object, which object adapter is used by the implementation, or which ORB is used to access it. Object Implementations An object implementation provides the semantics of the object, usually by defining data for the object instance and code for the object s methods. Often the implementation will use other objects or additional software to implement the behavior of the object. In some cases, the primary function of the object is to have side-effects on other things that are not objects. A variety of object implementations can be supported, including separate servers, libraries, a program per method, an encapsulated application, an object-oriented database, etc. Through the use of additional object adapters, it is possible to support virtually any style of object implementation. Generally, object implementations do not depend on the ORB or how the client invokes the object. Object implementations may select interfaces to ORB-dependent services by the choice of Object Adapter. Object References An Object Reference is the information needed to specify an object within an ORB. Both clients and object implementations have an opaque notion of object references according to the language mapping, and thus are insulated from the actual representation of them. Two ORB implementations may differ in their choice of Object Reference representations. The representation of an object reference handed to a client is only valid for the lifetime of that client. All ORBs must provide the same language mapping to an object reference (usually referred to as an Object) for a particular programming language. This permits a program written in a particular language to access object references independent of the particular ORB. The language mapping may also provide additional ways to access object references in a typed way for the convenience of the programmer. There is a distinguished object reference, guaranteed to be different from all object references, that denotes no object. OMG Interface Definition Language The OMG Interface Definition Language (OMG IDL) defines the types of objects by specifying their interfaces. An interface consists of a set of named operations and the parameters to those operations. Note that although IDL provides the conceptual framework for describing the objects manipulated

27 2.4. CORBA OVERVIEW by the ORB, it is not necessary for there to be IDL source code available for the ORB to work. As long as the equivalent information is available in the form of stub routines or a run-time interface repository, a particular ORB may be able to function correctly. IDL is the means by which a particular object implementation tells its potential clients what operations are available and how they should be invoked. From the IDL definitions, it is possible to map CORBA objects into particular programming languages or object systems. Mapping of OMG IDL to Programming Languages Different object-oriented or non-object-oriented programming languages may prefer to access CORBA objects in different ways. For object-oriented languages, it may be desirable to see CORBA objects as programming language objects. Even for nonobject-oriented languages, it is a good idea to hide the exact ORB representation of the object reference, method names, etc. A particular mapping of OMG IDL to a programming language should be the same for all ORB implementations. Language mapping includes definition of the language-specific data types and procedure interfaces to access objects through the ORB. It includes the structure of the client stub interface (not required for object-oriented languages), the dynamic invocation interface, the implementation skeleton, the object adapters, and the direct ORB interface. A language mapping also defines the interaction between object invocations and the threads of control in the client or implementation. The most common mappings provide synchronous calls, in that the routine returns when the object operation completes. Additional mappings may be provided to allow a call to be initiated and control returned to the program. In such cases, additional language-specific routines must be provided to synchronize the program s threads of control with the object invocation. Client Stubs For the mapping of a non-object-oriented language, there will be a programming interface to the stubs for each interface type. Generally, the stubs will present access to the OMG IDL-defined operations on an object in a way that is easy for programmers to predict once they are familiar with OMG IDL and the language mapping for the particular programming language. The stubs make calls on the rest of the ORB using interfaces that are private to, and presumably optimized for, the particular ORB Core. If more than one ORB is available, there may be different stubs corresponding to the different ORBs. In this case, it is necessary for the ORB and language mapping to cooperate to associate the correct stubs with the particular object reference.

28 2.4. CORBA OVERVIEW Object-oriented programming languages, such as C++ and Smalltalk, do not require stub interfaces. Dynamic Invocation Interface An interface is also available that allows the dynamic construction of object invocations, that is, rather than calling a stub routine that is specific to a particular operation on a particular object, a client may specify the object to be invoked, the operation to be performed, and the set of parameters for the operation through a call or sequence of calls. The client code must supply information about the operation to be performed and the types of the parameters being passed (perhaps obtaining it from an Interface Repository or other run-time source). The nature of the dynamic invocation interface may vary substantially from one programming language mapping to another. Implementation Skeleton For a particular language mapping, and possibly depending on the object adapter, there will be an interface to the methods that implement each type of object. The interface will generally be an up-call interface, in that the object implementation writes routines that conform to the interface and the ORB calls them through the skeleton. The existence of a skeleton does not imply the existence of a corresponding client stub (clients can also make requests via the dynamic invocation interface). It is possible to write an object adapter that does not use skeletons to invoke implementation methods. For example, it may be possible to create implementations dynamically for languages such as Smalltalk. Dynamic Skeleton Interface An interface is available, which allows dynamic handling of object invocations. That is, rather than being accessed through a skeleton that is specific to a particular operation, an object s implementation is reached through an interface that provides access to the operation name and parameters in a manner analogous to the client side s Dynamic Invocation Interface. Purely static knowledge of those parameters may be used, or dynamic knowledge (perhaps determined through an Interface Repository) may be also used, to determine the parameters. The implementation code must provide descriptions of all the operation parameters to the ORB, and the ORB provides the values of any input parameters for use in performing the operation. The implementation code provides the values of any output parameters, or an exception, to the ORB after performing the operation. The nature of the dynamic skeleton interface

29 2.4. CORBA OVERVIEW may vary substantially from one programming language mapping or object adapter to another, but will typically be an up-call interface. Dynamic skeletons may be invoked both through client stubs and through the dynamic invocation interface; either style of client request construction interface provides identical results. Object Adapters An object adapter is the primary way that an object implementation accesses services provided by the ORB. There are expected to be a few object adapters that will be widely available, with interfaces that are appropriate for specific kinds of objects. Services provided by the ORB through an Object Adapter often include: generation and interpretation of object references, method invocation, security of interactions, object and implementation activation and deactivation, mapping object references to implementations, and registration of implementations. The wide range of object granularities, lifetimes, policies, implementation styles, and other properties make it difficult for the ORB Core to provide a single interface that is convenient and efficient for all objects. Thus, through Object Adapters, it is possible for the ORB to target particular groups of object implementations that have similar requirements with interfaces tailored to them. ORB Interface The ORB Interface is the interface that goes directly to the ORB, which is the same for all ORBs and does not depend on the object s interface or object adapter. Because most of the functionality of the ORB is provided through the object adapter, stubs, skeleton, or dynamic invocation, there are only a few operations that are common across all objects. These operations are useful to both clients and implementations of objects. Interface Repository The Interface Repository is a service that provides persistent objects that represent the IDL information in a form available at run-time. The Interface Repository information may be used by the ORB to perform requests. Moreover, using the information in the Interface Repository, it is possible for a program to encounter an object whose interface was not known when the program was compiled, yet, be able to determine what operations are valid on the object and make an invocation on it. In addition to its role in the functioning of the ORB, the Interface Repository is a common place to store additional information associated with interfaces to ORB objects. For example, debugging information, libraries of

Middleware Lou Somers

Middleware Lou Somers Middleware Lou Somers April 18, 2002 1 Contents Overview Definition, goals, requirements Four categories of middleware Transactional, message oriented, procedural, object Middleware examples XML-RPC, SOAP,

More information

Infrastructure that supports (distributed) componentbased application development

Infrastructure that supports (distributed) componentbased application development Middleware Technologies 1 What is Middleware? Infrastructure that supports (distributed) componentbased application development a.k.a. distributed component platforms mechanisms to enable component communication

More information

Chapter 6. CORBA-based Architecture. 6.1 Introduction to CORBA 6.2 CORBA-IDL 6.3 Designing CORBA Systems 6.4 Implementing CORBA Applications

Chapter 6. CORBA-based Architecture. 6.1 Introduction to CORBA 6.2 CORBA-IDL 6.3 Designing CORBA Systems 6.4 Implementing CORBA Applications Chapter 6. CORBA-based Architecture 6.1 Introduction to CORBA 6.2 CORBA-IDL 6.3 Designing CORBA Systems 6.4 Implementing CORBA Applications 1 Chapter 6. CORBA-based Architecture Part 6.1 Introduction to

More information

Motivation Definitions EAI Architectures Elements Integration Technologies. Part I. EAI: Foundations, Concepts, and Architectures

Motivation Definitions EAI Architectures Elements Integration Technologies. Part I. EAI: Foundations, Concepts, and Architectures Part I EAI: Foundations, Concepts, and Architectures 5 Example: Mail-order Company Mail order Company IS Invoicing Windows, standard software IS Order Processing Linux, C++, Oracle IS Accounts Receivable

More information

Module 17. Client-Server Software Development. Version 2 CSE IIT, Kharagpur

Module 17. Client-Server Software Development. Version 2 CSE IIT, Kharagpur Module 17 Client-Server Software Development Lesson 42 CORBA and COM/DCOM Specific Instructional Objectives At the end of this lesson the student would be able to: Explain what Common Object Request Broker

More information

Introduction to CORBA. 1. Introduction 2. Distributed Systems: Notions 3. Middleware 4. CORBA Architecture

Introduction to CORBA. 1. Introduction 2. Distributed Systems: Notions 3. Middleware 4. CORBA Architecture Introduction to CORBA 1. Introduction 2. Distributed Systems: Notions 3. Middleware 4. CORBA Architecture 1. Introduction CORBA is defined by the OMG The OMG: -Founded in 1989 by eight companies as a non-profit

More information

Internationalization and Web Services

Internationalization and Web Services Internationalization and Web Services 25 th Internationalization and Unicode Conference Presented by Addison P. Phillips Director, Globalization Architecture webmethods, Inc. 25 th Internationalization

More information

SOAP - A SECURE AND RELIABLE CLIENT-SERVER COMMUNICATION FRAMEWORK. Marin Lungu, Dan Ovidiu Andrei, Lucian - Florentin Barbulescu

SOAP - A SECURE AND RELIABLE CLIENT-SERVER COMMUNICATION FRAMEWORK. Marin Lungu, Dan Ovidiu Andrei, Lucian - Florentin Barbulescu SOAP - A SECURE AND RELIABLE CLIENT-SERVER COMMUNICATION FRAMEWORK Marin Lungu, Dan Ovidiu Andrei, Lucian - Florentin Barbulescu University of Craiova, Faculty of Automation, Computers and Electronics,

More information

The Advantages of CorBA For Network Based Training Systems

The Advantages of CorBA For Network Based Training Systems Support of multimedia services for distributed network training applications in CORBA-3 Fausto Rabitti CNUCE-CNR, Via S. Maria, 36, Pisa, Italy Abstract In this paper, fundamental technological issues

More information

Chapter 2: Remote Procedure Call (RPC)

Chapter 2: Remote Procedure Call (RPC) Chapter 2: Remote Procedure Call (RPC) Gustavo Alonso Computer Science Department Swiss Federal Institute of Technology (ETHZ) alonso@inf.ethz.ch http://www.iks.inf.ethz.ch/ Contents - Chapter 2 - RPC

More information

Base One's Rich Client Architecture

Base One's Rich Client Architecture Base One's Rich Client Architecture Base One provides a unique approach for developing Internet-enabled applications, combining both efficiency and ease of programming through its "Rich Client" architecture.

More information

Overview of CORBA 11.1 I NTRODUCTION TO CORBA. 11.4 Object services 11.5 New features in CORBA 3.0 11.6 Summary

Overview of CORBA 11.1 I NTRODUCTION TO CORBA. 11.4 Object services 11.5 New features in CORBA 3.0 11.6 Summary C H A P T E R 1 1 Overview of CORBA 11.1 Introduction to CORBA 11.2 CORBA architecture 11.3 Client and object implementations 11.4 Object services 11.5 New features in CORBA 3.0 11.6 Summary In previous

More information

Introduction CORBA Distributed COM. Sections 9.1 & 9.2. Corba & DCOM. John P. Daigle. Department of Computer Science Georgia State University

Introduction CORBA Distributed COM. Sections 9.1 & 9.2. Corba & DCOM. John P. Daigle. Department of Computer Science Georgia State University Sections 9.1 & 9.2 Corba & DCOM John P. Daigle Department of Computer Science Georgia State University 05.16.06 Outline 1 Introduction 2 CORBA Overview Communication Processes Naming Other Design Concerns

More information

Introduction to Service Oriented Architectures (SOA)

Introduction to Service Oriented Architectures (SOA) Introduction to Service Oriented Architectures (SOA) Responsible Institutions: ETHZ (Concept) ETHZ (Overall) ETHZ (Revision) http://www.eu-orchestra.org - Version from: 26.10.2007 1 Content 1. Introduction

More information

CHAPTER 2 MODELLING FOR DISTRIBUTED NETWORK SYSTEMS: THE CLIENT- SERVER MODEL

CHAPTER 2 MODELLING FOR DISTRIBUTED NETWORK SYSTEMS: THE CLIENT- SERVER MODEL CHAPTER 2 MODELLING FOR DISTRIBUTED NETWORK SYSTEMS: THE CLIENT- SERVER MODEL This chapter is to introduce the client-server model and its role in the development of distributed network systems. The chapter

More information

SOFT 437. Software Performance Analysis. Ch 5:Web Applications and Other Distributed Systems

SOFT 437. Software Performance Analysis. Ch 5:Web Applications and Other Distributed Systems SOFT 437 Software Performance Analysis Ch 5:Web Applications and Other Distributed Systems Outline Overview of Web applications, distributed object technologies, and the important considerations for SPE

More information

Distributed Objects and Components

Distributed Objects and Components Distributed Objects and Components Introduction This essay will identify the differences between objects and components and what it means for a component to be distributed. It will also examine the Java

More information

E-Business Technologies for the Future

E-Business Technologies for the Future E-Business Technologies for the Future Michael B. Spring Department of Information Science and Telecommunications University of Pittsburgh spring@imap.pitt.edu http://www.sis.pitt.edu/~spring Overview

More information

Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme. Middleware. Chapter 8: Middleware

Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme. Middleware. Chapter 8: Middleware Middleware 1 Middleware Lehrstuhl für Informatik 4 Middleware: Realisation of distributed accesses by suitable software infrastructure Hiding the complexity of the distributed system from the programmer

More information

Event-based middleware services

Event-based middleware services 3 Event-based middleware services The term event service has different definitions. In general, an event service connects producers of information and interested consumers. The service acquires events

More information

Service-Oriented Architecture and Software Engineering

Service-Oriented Architecture and Software Engineering -Oriented Architecture and Software Engineering T-86.5165 Seminar on Enterprise Information Systems (2008) 1.4.2008 Characteristics of SOA The software resources in a SOA are represented as services based

More information

It is the thinnest layer in the OSI model. At the time the model was formulated, it was not clear that a session layer was needed.

It is the thinnest layer in the OSI model. At the time the model was formulated, it was not clear that a session layer was needed. Session Layer The session layer resides above the transport layer, and provides value added services to the underlying transport layer services. The session layer (along with the presentation layer) add

More information

What is Middleware? Software that functions as a conversion or translation layer. It is also a consolidator and integrator.

What is Middleware? Software that functions as a conversion or translation layer. It is also a consolidator and integrator. What is Middleware? Application Application Middleware Middleware Operating System Operating System Software that functions as a conversion or translation layer. It is also a consolidator and integrator.

More information

Web Services. Copyright 2011 Srdjan Komazec

Web Services. Copyright 2011 Srdjan Komazec Web Services Middleware Copyright 2011 Srdjan Komazec 1 Where are we? # Title 1 Distributed Information Systems 2 Middleware 3 Web Technologies 4 Web Services 5 Basic Web Service Technologies 6 Web 2.0

More information

Layering a computing infrastructure. Middleware. The new infrastructure: middleware. Spanning layer. Middleware objectives. The new infrastructure

Layering a computing infrastructure. Middleware. The new infrastructure: middleware. Spanning layer. Middleware objectives. The new infrastructure University of California at Berkeley School of Information Management and Systems Information Systems 206 Distributed Computing Applications and Infrastructure Layering a computing infrastructure Middleware

More information

System types. Distributed systems

System types. Distributed systems System types 1 Personal systems that are designed to run on a personal computer or workstation Distributed systems where the system software runs on a loosely integrated group of cooperating processors

More information

Distributed Systems Architectures

Distributed Systems Architectures Software Engineering Distributed Systems Architectures Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain the advantages and disadvantages of different distributed systems

More information

An Object Model for Business Applications

An Object Model for Business Applications An Object Model for Business Applications By Fred A. Cummins Electronic Data Systems Troy, Michigan cummins@ae.eds.com ## ## This presentation will focus on defining a model for objects--a generalized

More information

The Integration Between EAI and SOA - Part I

The Integration Between EAI and SOA - Part I by Jose Luiz Berg, Project Manager and Systems Architect at Enterprise Application Integration (EAI) SERVICE TECHNOLOGY MAGAZINE Issue XLIX April 2011 Introduction This article is intended to present the

More information

MIDDLEWARE 1. Figure 1: Middleware Layer in Context

MIDDLEWARE 1. Figure 1: Middleware Layer in Context MIDDLEWARE 1 David E. Bakken 2 Washington State University Middleware is a class of software technologies designed to help manage the complexity and heterogeneity inherent in distributed systems. It is

More information

Characteristics of Java (Optional) Y. Daniel Liang Supplement for Introduction to Java Programming

Characteristics of Java (Optional) Y. Daniel Liang Supplement for Introduction to Java Programming Characteristics of Java (Optional) Y. Daniel Liang Supplement for Introduction to Java Programming Java has become enormously popular. Java s rapid rise and wide acceptance can be traced to its design

More information

Project Proposal Distributed Project Management

Project Proposal Distributed Project Management Proposal Distributed Management by Passakon Prathombutr Ashok Emani CS551 Fall 2001 CSTP UMKC 1 Contents Introduction...3 Goal and Objectives...4 Overall goal... 4 Specific objectives... 4 Significance...

More information

Migrating Legacy Software Systems to CORBA based Distributed Environments through an Automatic Wrapper Generation Technique

Migrating Legacy Software Systems to CORBA based Distributed Environments through an Automatic Wrapper Generation Technique Migrating Legacy Software Systems to CORBA based Distributed Environments through an Automatic Wrapper Generation Technique Hyeon Soo Kim School of Comp. Eng. and Software Eng., Kum Oh National University

More information

Invocación remota (based on M. L. Liu Distributed Computing -- Concepts and Application http://www.csc.calpoly.edu/~mliu/book/index.

Invocación remota (based on M. L. Liu Distributed Computing -- Concepts and Application http://www.csc.calpoly.edu/~mliu/book/index. Departament d Arquitectura de Computadors Invocación remota (based on M. L. Liu Distributed Computing -- Concepts and Application http://www.csc.calpoly.edu/~mliu/book/index.html) Local Objects vs. Distributed

More information

Implementing Java Distributed Objects with JDBC

Implementing Java Distributed Objects with JDBC Implementing Java Distributed Objects with JDBC Pritisha 1, Aashima Arya 2 1,2 Department of Computer Science Bhagwan Mahaveer institute of engineering & technology (BMIET), Deenbandhu Chhotu Ram University

More information

What Is the Java TM 2 Platform, Enterprise Edition?

What Is the Java TM 2 Platform, Enterprise Edition? Page 1 de 9 What Is the Java TM 2 Platform, Enterprise Edition? This document provides an introduction to the features and benefits of the Java 2 platform, Enterprise Edition. Overview Enterprises today

More information

Lesson 4 Web Service Interface Definition (Part I)

Lesson 4 Web Service Interface Definition (Part I) Lesson 4 Web Service Interface Definition (Part I) Service Oriented Architectures Module 1 - Basic technologies Unit 3 WSDL Ernesto Damiani Università di Milano Interface Definition Languages (1) IDLs

More information

Interface Definition Language

Interface Definition Language Interface Definition Language A. David McKinnon Washington State University An Interface Definition Language (IDL) is a language that is used to define the interface between a client and server process

More information

Virtual Credit Card Processing System

Virtual Credit Card Processing System The ITB Journal Volume 3 Issue 2 Article 2 2002 Virtual Credit Card Processing System Geraldine Gray Karen Church Tony Ayres Follow this and additional works at: http://arrow.dit.ie/itbj Part of the E-Commerce

More information

Elements of Advanced Java Programming

Elements of Advanced Java Programming Appendix A Elements of Advanced Java Programming Objectives At the end of this appendix, you should be able to: Understand two-tier and three-tier architectures for distributed computing Understand the

More information

Outline SOA. Properties of SOA. Service 2/19/2016. Definitions. Comparison of component technologies. Definitions Component technologies

Outline SOA. Properties of SOA. Service 2/19/2016. Definitions. Comparison of component technologies. Definitions Component technologies Szolgáltatásorientált rendszerintegráció Comparison of component technologies Simon Balázs, BME IIT Outline Definitions Component technologies RPC, RMI, CORBA, COM+,.NET, Java, OSGi, EJB, SOAP web services,

More information

Agenda. Distributed System Structures. Why Distributed Systems? Motivation

Agenda. Distributed System Structures. Why Distributed Systems? Motivation Agenda Distributed System Structures CSCI 444/544 Operating Systems Fall 2008 Motivation Network structure Fundamental network services Sockets and ports Client/server model Remote Procedure Call (RPC)

More information

Client/Server Computing Distributed Processing, Client/Server, and Clusters

Client/Server Computing Distributed Processing, Client/Server, and Clusters Client/Server Computing Distributed Processing, Client/Server, and Clusters Chapter 13 Client machines are generally single-user PCs or workstations that provide a highly userfriendly interface to the

More information

Research on the Model of Enterprise Application Integration with Web Services

Research on the Model of Enterprise Application Integration with Web Services Research on the Model of Enterprise Integration with Web Services XIN JIN School of Information, Central University of Finance& Economics, Beijing, 100081 China Abstract: - In order to improve business

More information

Service Oriented Architectures

Service Oriented Architectures 8 Service Oriented Architectures Gustavo Alonso Computer Science Department Swiss Federal Institute of Technology (ETHZ) alonso@inf.ethz.ch http://www.iks.inf.ethz.ch/ The context for SOA A bit of history

More information

Introduction to Web Services

Introduction to Web Services Department of Computer Science Imperial College London CERN School of Computing (icsc), 2005 Geneva, Switzerland 1 Fundamental Concepts Architectures & escience example 2 Distributed Computing Technologies

More information

THE EVOLVING ROLE OF DATABASE IN OBJECT SYSTEMS

THE EVOLVING ROLE OF DATABASE IN OBJECT SYSTEMS THE EVOLVING ROLE OF DATABASE IN OBJECT SYSTEMS William Kent Database Technology Department Hewlett-Packard Laboratories Palo Alto, California kent@hpl.hp.com 1990 CONTENTS: ABSTRACT 1 INTRODUCTION...

More information

Middleware: Past and Present a Comparison

Middleware: Past and Present a Comparison Middleware: Past and Present a Comparison Hennadiy Pinus ABSTRACT The construction of distributed systems is a difficult task for programmers, which can be simplified with the use of middleware. Middleware

More information

A Java-based system support for distributed applications on the Internet

A Java-based system support for distributed applications on the Internet A Java-based system support for distributed applications on the Internet D. Hagimont 1, D. Louvegnies 2 SIRAC Project INRIA, 655 av. de l Europe, 38330 Montbonnot Saint-Martin, France Abstract: We have

More information

PERFORMANCE COMPARISON OF COMMON OBJECT REQUEST BROKER ARCHITECTURE(CORBA) VS JAVA MESSAGING SERVICE(JMS) BY TEAM SCALABLE

PERFORMANCE COMPARISON OF COMMON OBJECT REQUEST BROKER ARCHITECTURE(CORBA) VS JAVA MESSAGING SERVICE(JMS) BY TEAM SCALABLE PERFORMANCE COMPARISON OF COMMON OBJECT REQUEST BROKER ARCHITECTURE(CORBA) VS JAVA MESSAGING SERVICE(JMS) BY TEAM SCALABLE TIGRAN HAKOBYAN SUJAL PATEL VANDANA MURALI INTRODUCTION Common Object Request

More information

Architecture of the CORBA Component Model CORBA 3.0

Architecture of the CORBA Component Model CORBA 3.0 Architecture of the CORBA Component Model CORBA 3.0 What is CORBA CORBA (Common Request Broker Architecture) is a distributed object-oriented client server platform. It provides: An object oriented remote

More information

Last Class: OS and Computer Architecture. Last Class: OS and Computer Architecture

Last Class: OS and Computer Architecture. Last Class: OS and Computer Architecture Last Class: OS and Computer Architecture System bus Network card CPU, memory, I/O devices, network card, system bus Lecture 3, page 1 Last Class: OS and Computer Architecture OS Service Protection Interrupts

More information

Service-Oriented Architectures

Service-Oriented Architectures Architectures Computing & 2009-11-06 Architectures Computing & SERVICE-ORIENTED COMPUTING (SOC) A new computing paradigm revolving around the concept of software as a service Assumes that entire systems

More information

COMP5426 Parallel and Distributed Computing. Distributed Systems: Client/Server and Clusters

COMP5426 Parallel and Distributed Computing. Distributed Systems: Client/Server and Clusters COMP5426 Parallel and Distributed Computing Distributed Systems: Client/Server and Clusters Client/Server Computing Client Client machines are generally single-user workstations providing a user-friendly

More information

Building Applications Using Micro Focus COBOL

Building Applications Using Micro Focus COBOL Building Applications Using Micro Focus COBOL Abstract If you look through the Micro Focus COBOL documentation, you will see many different executable file types referenced: int, gnt, exe, dll and others.

More information

Report of the case study in Sistemi Distribuiti A simple Java RMI application

Report of the case study in Sistemi Distribuiti A simple Java RMI application Report of the case study in Sistemi Distribuiti A simple Java RMI application Academic year 2012/13 Vessio Gennaro Marzulli Giovanni Abstract In the ambit of distributed systems a key-role is played by

More information

Architecture of a Distributed Object Firewall Proxy. Abstract

Architecture of a Distributed Object Firewall Proxy. Abstract NAI Labs #0768 Architecture of a Distributed Object Firewall Proxy July 16, 2000 Gary Lamperillo Gary_Lamperillo@NAI.com NAI Labs - The Security Research Division Network Associates 3415 S. Sepulveda Blvd.

More information

Communications Management. 3ICT12 (with thanks to Prof. George Pavlou, University of Surrey)

Communications Management. 3ICT12 (with thanks to Prof. George Pavlou, University of Surrey) Communications Management 3ICT12 (with thanks to Prof. George Pavlou, University of Surrey) 1 Communications Management Network Management Overview What is Network Management? Manager Agent Model OSI Management:

More information

independent systems in constant communication what they are, why we care, how they work

independent systems in constant communication what they are, why we care, how they work Overview of Presentation Major Classes of Distributed Systems classes of distributed system loosely coupled systems loosely coupled, SMP, Single-system-image Clusters independent systems in constant communication

More information

Introduction into Web Services (WS)

Introduction into Web Services (WS) (WS) Adomas Svirskas Agenda Background and the need for WS SOAP the first Internet-ready RPC Basic Web Services Advanced Web Services Case Studies The ebxml framework How do I use/develop Web Services?

More information

The Service Revolution software engineering without programming languages

The Service Revolution software engineering without programming languages The Service Revolution software engineering without programming languages Gustavo Alonso Institute for Pervasive Computing Department of Computer Science Swiss Federal Institute of Technology (ETH Zurich)

More information

PIE. Internal Structure

PIE. Internal Structure PIE Internal Structure PIE Composition PIE (Processware Integration Environment) is a set of programs for integration of heterogeneous applications. The final set depends on the purposes of a solution

More information

A standards-based approach to application integration

A standards-based approach to application integration A standards-based approach to application integration An introduction to IBM s WebSphere ESB product Jim MacNair Senior Consulting IT Specialist Macnair@us.ibm.com Copyright IBM Corporation 2005. All rights

More information

PART IV Performance oriented design, Performance testing, Performance tuning & Performance solutions. Outline. Performance oriented design

PART IV Performance oriented design, Performance testing, Performance tuning & Performance solutions. Outline. Performance oriented design PART IV Performance oriented design, Performance testing, Performance tuning & Performance solutions Slide 1 Outline Principles for performance oriented design Performance testing Performance tuning General

More information

Software: Systems and Application Software

Software: Systems and Application Software Software: Systems and Application Software Computer Software Operating System Popular Operating Systems Language Translators Utility Programs Applications Programs Types of Application Software Personal

More information

A Scalability Model for Managing Distributed-organized Internet Services

A Scalability Model for Managing Distributed-organized Internet Services A Scalability Model for Managing Distributed-organized Internet Services TSUN-YU HSIAO, KO-HSU SU, SHYAN-MING YUAN Department of Computer Science, National Chiao-Tung University. No. 1001, Ta Hsueh Road,

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Charlie Abela Department of Artificial Intelligence charlie.abela@um.edu.mt Last Lecture Web Ontology Language Problems? CSA 3210 Service Oriented Architecture 2 Lecture Outline

More information

A Web-Based Real-Time Traffic Monitoring Scheme Using CORBA

A Web-Based Real-Time Traffic Monitoring Scheme Using CORBA A Web-Based Real-Time Traffic Monitoring Scheme Using CORBA Yuming Jiang, Chen-Khong Tham, Chi-Chung Ko Department of Electrical Engineering, National University of Singapore, 10 Kent Ridge Crescent, Singapore

More information

How To Write A Network Operating System For A Network (Networking) System (Netware)

How To Write A Network Operating System For A Network (Networking) System (Netware) Otwarte Studium Doktoranckie 1 Adaptable Service Oriented Architectures Krzysztof Zieliński Department of Computer Science AGH-UST Krakow Poland Otwarte Studium Doktoranckie 2 Agenda DCS SOA WS MDA OCL

More information

A Java Based Tool for Testing Interoperable MPI Protocol Conformance

A Java Based Tool for Testing Interoperable MPI Protocol Conformance A Java Based Tool for Testing Interoperable MPI Protocol Conformance William George National Institute of Standards and Technology 100 Bureau Drive Stop 8951 Gaithersburg MD 20899 8951 1 301 975 4943 william.george@nist.gov

More information

Lecture 7: Java RMI. CS178: Programming Parallel and Distributed Systems. February 14, 2001 Steven P. Reiss

Lecture 7: Java RMI. CS178: Programming Parallel and Distributed Systems. February 14, 2001 Steven P. Reiss Lecture 7: Java RMI CS178: Programming Parallel and Distributed Systems February 14, 2001 Steven P. Reiss I. Overview A. Last time we started looking at multiple process programming 1. How to do interprocess

More information

A Generic Virtual Reality Interaction System and its Extensions Using the Common Object Request Broker Architecture (CORBA)

A Generic Virtual Reality Interaction System and its Extensions Using the Common Object Request Broker Architecture (CORBA) A Generic Virtual Reality Interaction System and its Extensions Using the Common Object Request Broker Architecture (CORBA) ABSTRACT The paper describes the design and implementation of an immersive Virtual

More information

XII. Distributed Systems and Middleware. Laurea Triennale in Informatica Corso di Ingegneria del Software I A.A. 2006/2007 Andrea Polini

XII. Distributed Systems and Middleware. Laurea Triennale in Informatica Corso di Ingegneria del Software I A.A. 2006/2007 Andrea Polini XII. Distributed Systems and Middleware Laurea Triennale in Informatica Corso di Outline Distributed Systems Basics Middleware generalities Middleware for Distributed Objects Distributed Computing Models

More information

JavaPOS TM FAQ. What is an FAQ? What is JavaPOS?

JavaPOS TM FAQ. What is an FAQ? What is JavaPOS? JavaPOS TM FAQ What is an FAQ? An FAQ is a list of frequently asked questions. In addition to supplying background material, this document will provide answers for the most frequently asked questions about

More information

AS/400 System Overview

AS/400 System Overview Chapter 1 AS/400 System Overview 1.1 Major Characteristics of AS/400 1.1.1 High Level of Integration 1.1.2 Object Orientation 1.1.3 Relational and Integrated Database 1.1.4 Data and Program Independence

More information

Developers Integration Lab (DIL) System Architecture, Version 1.0

Developers Integration Lab (DIL) System Architecture, Version 1.0 Developers Integration Lab (DIL) System Architecture, Version 1.0 11/13/2012 Document Change History Version Date Items Changed Since Previous Version Changed By 0.1 10/01/2011 Outline Laura Edens 0.2

More information

Information integration platform for CIMS. Chan, FTS; Zhang, J; Lau, HCW; Ning, A

Information integration platform for CIMS. Chan, FTS; Zhang, J; Lau, HCW; Ning, A Title Information integration platform for CIMS Author(s) Chan, FTS; Zhang, J; Lau, HCW; Ning, A Citation IEEE International Conference on Management of Innovation and Technology Proceedings, Singapore,

More information

Chapter 16 Distributed Processing, Client/Server, and Clusters

Chapter 16 Distributed Processing, Client/Server, and Clusters Operating Systems: Internals and Design Principles Chapter 16 Distributed Processing, Client/Server, and Clusters Eighth Edition By William Stallings Table 16.1 Client/Server Terminology Applications Programming

More information

What can DDS do for You? Learn how dynamic publish-subscribe messaging can improve the flexibility and scalability of your applications.

What can DDS do for You? Learn how dynamic publish-subscribe messaging can improve the flexibility and scalability of your applications. What can DDS do for You? Learn how dynamic publish-subscribe messaging can improve the flexibility and scalability of your applications. 2 Contents: Abstract 3 What does DDS do 3 The Strengths of DDS 4

More information

Computer Network. Interconnected collection of autonomous computers that are able to exchange information

Computer Network. Interconnected collection of autonomous computers that are able to exchange information Introduction Computer Network. Interconnected collection of autonomous computers that are able to exchange information No master/slave relationship between the computers in the network Data Communications.

More information

Service Oriented Architecture (SOA) Implementation Framework for Satellite Mission Control System Software Design

Service Oriented Architecture (SOA) Implementation Framework for Satellite Mission Control System Software Design Service Oriented Architecture (SOA) Implementation Framework for Satellite Mission Control System Software Design GSAW2006 28 th March 2006 Soon Hie Tan K I Thimothy Nanyang Technological University Singapore

More information

3-Tier Architecture. 3-Tier Architecture. Prepared By. Channu Kambalyal. Page 1 of 19

3-Tier Architecture. 3-Tier Architecture. Prepared By. Channu Kambalyal. Page 1 of 19 3-Tier Architecture Prepared By Channu Kambalyal Page 1 of 19 Table of Contents 1.0 Traditional Host Systems... 3 2.0 Distributed Systems... 4 3.0 Client/Server Model... 5 4.0 Distributed Client/Server

More information

How To Understand The Concept Of A Distributed System

How To Understand The Concept Of A Distributed System Distributed Operating Systems Introduction Ewa Niewiadomska-Szynkiewicz and Adam Kozakiewicz ens@ia.pw.edu.pl, akozakie@ia.pw.edu.pl Institute of Control and Computation Engineering Warsaw University of

More information

A Type Management System for an ODP Trader

A Type Management System for an ODP Trader A Type Management System for an ODP Trader J. Indulskaa, M. Bearmanband K. Raymondc acrc for Distributed Systems Technology, Department of Computer Science, University of Queensland, Brisbane 4072, Australia

More information

A NOVEL ARCHITECTURE FOR DYNAMIC LEAST COST ROUTING

A NOVEL ARCHITECTURE FOR DYNAMIC LEAST COST ROUTING A NOVEL ARCHITECTURE FOR DYNAMIC LEAST COST ROUTING Peer Hasselmeyer Information technology Transfer Office, Darmstadt University of Technology Wilhelminenstr. 7, 64283 Darmstadt, Germany E-mail: peer@ito.tu-darmstadt.de

More information

Chapter 1 Introduction to Enterprise Software

Chapter 1 Introduction to Enterprise Software Chapter 1 Introduction to Enterprise Software What Is Enterprise Software? Evolution of Enterprise Software Enterprise Software and Component-Based Software Summary If you have heard of terms such as

More information

Topics. Introduction. Java History CS 146. Introduction to Programming and Algorithms Module 1. Module Objectives

Topics. Introduction. Java History CS 146. Introduction to Programming and Algorithms Module 1. Module Objectives Introduction to Programming and Algorithms Module 1 CS 146 Sam Houston State University Dr. Tim McGuire Module Objectives To understand: the necessity of programming, differences between hardware and software,

More information

How To Create A C++ Web Service

How To Create A C++ Web Service A Guide to Creating C++ Web Services WHITE PAPER Abstract This whitepaper provides an introduction to creating C++ Web services and focuses on:» Challenges involved in integrating C++ applications with

More information

Review from last time. CS 537 Lecture 3 OS Structure. OS structure. What you should learn from this lecture

Review from last time. CS 537 Lecture 3 OS Structure. OS structure. What you should learn from this lecture Review from last time CS 537 Lecture 3 OS Structure What HW structures are used by the OS? What is a system call? Michael Swift Remzi Arpaci-Dussea, Michael Swift 1 Remzi Arpaci-Dussea, Michael Swift 2

More information

Extracting, Storing And Viewing The Data From Dicom Files

Extracting, Storing And Viewing The Data From Dicom Files Extracting, Storing And Viewing The Data From Dicom Files L. Stanescu, D.D Burdescu, A. Ion, A. Caldare, E. Georgescu University of Kraiova, Romania Faculty of Control Computers and Electronics www.software.ucv.ro/en.

More information

To Java SE 8, and Beyond (Plan B)

To Java SE 8, and Beyond (Plan B) 11-12-13 To Java SE 8, and Beyond (Plan B) Francisco Morero Peyrona EMEA Java Community Leader 8 9...2012 2020? Priorities for the Java Platforms Grow Developer Base Grow Adoption

More information

Java in Education. Choosing appropriate tool for creating multimedia is the first step in multimedia design

Java in Education. Choosing appropriate tool for creating multimedia is the first step in multimedia design Java in Education Introduction Choosing appropriate tool for creating multimedia is the first step in multimedia design and production. Various tools that are used by educators, designers and programmers

More information

The EMSX Platform. A Modular, Scalable, Efficient, Adaptable Platform to Manage Multi-technology Networks. A White Paper.

The EMSX Platform. A Modular, Scalable, Efficient, Adaptable Platform to Manage Multi-technology Networks. A White Paper. The EMSX Platform A Modular, Scalable, Efficient, Adaptable Platform to Manage Multi-technology Networks A White Paper November 2002 Abstract: The EMSX Platform is a set of components that together provide

More information

Chapter 7, System Design Architecture Organization. Construction. Software

Chapter 7, System Design Architecture Organization. Construction. Software Chapter 7, System Design Architecture Organization Object-Oriented Software Construction Armin B. Cremers, Tobias Rho, Daniel Speicher & Holger Mügge (based on Bruegge & Dutoit) Overview Where are we right

More information

A generic framework for game development

A generic framework for game development A generic framework for game development Michael Haller FH Hagenberg (MTD) AUSTRIA haller@hagenberg.at Werner Hartmann FAW, University of Linz AUSTRIA werner.hartmann@faw.unilinz.ac.at Jürgen Zauner FH

More information

Service Mediation. The Role of an Enterprise Service Bus in an SOA

Service Mediation. The Role of an Enterprise Service Bus in an SOA Service Mediation The Role of an Enterprise Service Bus in an SOA 2 TABLE OF CONTENTS 1 The Road to Web Services and ESBs...4 2 Enterprise-Class Requirements for an ESB...5 3 Additional Evaluation Criteria...7

More information

Subnetting and Network Management Omer F. Rana. Networks and Data Communications 1

Subnetting and Network Management Omer F. Rana. Networks and Data Communications 1 Subnetting and Network Management Omer F. Rana Networks and Data Communications 1 Subnetting Subnetting is an important concept in establishing TCP/IP based networks important in integrating small Local

More information

GenericServ, a Generic Server for Web Application Development

GenericServ, a Generic Server for Web Application Development EurAsia-ICT 2002, Shiraz-Iran, 29-31 Oct. GenericServ, a Generic Server for Web Application Development Samar TAWBI PHD student tawbi@irit.fr Bilal CHEBARO Assistant professor bchebaro@ul.edu.lb Abstract

More information

Introduction to Distributed Computing using CORBA

Introduction to Distributed Computing using CORBA Introduction to Distributed Computing using CORBA Rushikesh K. Joshi Dept of Computer Science & Engineering Indian Institute of Technology, Bombay Powai, Mumbai - 400 076, India. Email: rkj@cse.iitb.ac.in

More information

1 Organization of Operating Systems

1 Organization of Operating Systems COMP 730 (242) Class Notes Section 10: Organization of Operating Systems 1 Organization of Operating Systems We have studied in detail the organization of Xinu. Naturally, this organization is far from

More information