Mohsin Qasim Syed Abbas Ali

Transcription

1 Final version

2 Table of Content 1 -Introduction to CORBA Overview Why is CORBA important in a networked environment? HOW DOES CORBA WORKS? CORBA Architecture CORBA Overall Architecture CORBA Concepts The Object Model Open Distributed Computing Environment Component Integration and Reuse Relationship with other Technologies Comparing DCE and CORBA DCE Executive Similarities between CORBA and DCE Difference between DCE and CORBA Comparing DCOM and CORBA DCOM overview Similarities between CORBA and DCOM [3] Difference between CORBA and DCOM [3] CORBA Services CORBA Facilities CORBA Products Conclusion REFERENCES...26

3 1 -Introduction to CORBA One of the most dominating distributed object technologies or middleware CORBA. It is the extensions of traditional object-oriented systems by allowing objects to be distributed across a heterogeneous network. The objects may reside in their own address space outside of an application or on a different computer than the application and still be referenced as being part of the application. The history and evolution of each of the distributed object technologies are quite different and addresses different requirements for multiple platforms, languages or network protocols. CORBA is an open distributed object computing infrastructure standardised by the Object Management Group (OMG) and is a specification based on technologies proposed (and partly provided) by the software industry. CORBA is the most used middleware standard in the non-windows market. The OMG was founded in 1989 to promote the adoption of object-oriented technology and reusable software components. 1.1 Overview First question that arris in our mind is that, WHAT IS CORBA? Infect the answer to this question is that CORBA, or Common Object Request Broker Architecture, is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate. To explain CORBA we must be familiar with ORB that what is ORB? Why is it so important? What are its uses? To relationship between client and server is established so that objects can be used across a network the middleware that makes this happen is called Object Request broker (ORB). The jobs for ORB are to: Intercept a call from the client Find the correct object Pass it the parameters Invoke its method Return the result to the client The ORB can make this transaction happen between applications on different machines in heterogeneous distributed environments, this process seems transparent to the client. ORB provides the flexibility of communication between different operating systems, environments, and languages. They allow existing components to be used by developers far and wide. So to make this process work well a standard was required. A consortium of 700+ companies formed the Object Management Group (OMG) to create just such a standard. They introduced this standard as the Common Object Request Broker Architecture (CORBA) in According to the OMG, "CORBA allows applications to communicate with one another no matter where they are located or who has designed them." 1 This standard also defined the Interface Definition Language (IDL) and the Application Programming Interface (API) that makes client/server object interactions work in a specific implementation of an ORB. [1]

4 1.2 Why is CORBA important in a networked environment? CORBA offers many benefits to a networked environment. Objects reuse - CORBA allows wide-spread use of existing components. Flexibility - CORBA allows developers to choose, for each component of their system, the: operating system execution environment programming language Processing speed - By directly invoking methods on a server, a client can pass parameters using precompiled stubs or can generate them dynamically using CORBA's invocation services. Scalable server-to-server infrastructure - The CORBA ORB communicates with pools of server business objects, dispatching requests to the first available object. This provides a load balancing function for the incoming client requests 1.3 HOW DOES CORBA WORKS? At its basic level CORBA defines a standard framework from which an information system or software developer can easily and quickly integrate network resident software module and applications to create new more powerful applications. It combines object technology with a client server model to provide a uniform view of an enterprise computing system every thing on the network is an object. The highest level specification is referred to as the object management architecture (OMA). As in the figure 1

5 The term CORBA is often used to refer to the object request broker (ORB) itself as well as to the entire OMG architecture. The role of ORB is to route request among the other architectural components. CORBA services, CORBA facilities and CORBA domain are also defined as part of specification. CORBA SERVICES provide some basic system level services such as Naming, persistence, Event notification. CORBA FACILITIES are the set of higher level functions that cover a broad range of generically applicable facilities in area such as user interface and information management. CORBA DOMAINS are the specific to particular application domains, such as manufacturing finance and telecommunication. APPLICATION OBJECT provides the new business capabilities that are created by the system implementers.

6 The key to integrating application object is the specification of standard interfaces using the interface definition language (IDL). Once all applications and data have an IDL-compliant interface communication is independent of physical location platform type networking protocol programming language An information system is created by using CORBA to medicate the flow of control and information among these software objects. 1.4 CORBA Architecture The pivotal component of CORBA is the ORB which is responsible for the communication of requests, passing requests from the client to the correct object. The details of the CORBA architecture are shown in Figure 2 Figure 2 The figure can be explained as follows. As described by the OMG,

7 "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." The Client requests services through the IDL Stub or (dynamically) through the Dynamic Invocation Interface (DII). A General Inter-ORB Protocol (GIOP) is defined to support interoperability of different ORB products. A specification of the GIOP on TCP/IP connection is defined as the Internet Inter-ORB Protocol (IIOP). With the help of the Object Adapter, the ORB Core then passes the request through an IDL Skeleton or (dynamically) through the Dynamic Skeleton Interface (DSI) to the Object. The service is encapsulated by the object. The Interface Repository provides at runtime, both: persistent objects with IDL information, and help in identifying the interface and operations of objects. The Implementation Repository stores the information that ORB use to locate and activate implementations of objects.[1] 1.5 CORBA Overall Architecture The overall architecture of CORBA is divided into three layers as illustrated in Figure 3 figure 3 In the top layer (Basic Programming Architecture) a client may request an object and invoke its methods. The server responds by creating an object instance and making it available to the client. The middle layer (Remoting Architecture) makes it seem as if the client and server are in the same address space. Sending data across different address spaces requires a standard format for packing and unpacking the transmission. Marshalling is the term used when a method call's parameters are packed at a client's space or when return values are packed at a server's space. Unmarshaling is the unpacking of the standard format to a data presentation appropriate for the address space of the receiving process. The ORB serves as the object bus. The Object Adaptor connects the Object to the ORB. The Libraries on the client-side and server-side are

8 linked at compile time. The bottom layer (Wire Protocol Architecture) is where the wire protocol is specified for the support of a client and a server on different machines.

9 2- CORBA Concepts Corba is based on three important concepts: Object-oriented model Open distributed computing environment Component integration and reuse The OMG has done enough effort to develop CORBA object model. first model was completed in 1992 The architecture of CORBA was needed as there was no single uniformly supported object model had been developed by the computing industry. How ever it provide some benefits as well The ability to contain the complexity of the overall system To improve the reusability of the system components 2.1 The Object Model CORBA is solidly grounded in fundamental object-oriented concepts, as shown in Figure 4. These concepts, important to understanding which are:

10 Objects- Software entities that contain attributes and exhibit behavior through methods. In traditional terminology, attributes can be thought of as data or data structures and behaviors can be thought of as operations. Classes-clusters of objects that share common behavior. Encapsulation-The bundling of attributes and behaviors into well-defined software packages, concealing the internal structure of attributes and the details of behaviors through a public interface. Inheritance-The ability of a class to pass on attributes and behaviors to its descendants. Polymorphism-The ability of two or more classes to respond to the same message, each in its own way. These same concepts are applied to many other aspects of computing technology. For example, object-oriented analysis and design techniques (the art of understanding the system and how implement it) focus on discovering objects, attributes, and relationships, as well as the required behavior of objects. Database systems based on these concepts provide for the storage and management of objects. However, detailed nuances of these concepts allow for different implementations and conflicts (as you will quickly discover if you put two object-oriented methodologists in the same room). The CORBA object model defines key boundaries and meanings to enable unambiguous interpretation of these concepts. Without a common object model, the implementation of CORBA-compliant tools by independent software manufacturers might otherwise produce fatal incompatibilities. CORBA s object model is based on a complete object approach in which a client sends a message to an object. The message identifies an object, and one or more parameters are included. The first parameter defines the operation to be performed, although the specific method used is determined by the receiving object (or in some cases, the ORB). The CORBA object model consists of: Objects--- An encapsulated entity that provides services to a client. Requests---An action created by a client directed to a target object that includes information on the operation to be performed and zero or more actual parameters. Object Creation and Destruction--- Based on the state of request, objects are created or deleted. Types--- An identifiable entity defined over values. Legal values are shown in Figure 5.

11 Interfaces--- The specification of operations that a client can request from an object. Operations--- An identifiable entity that defines what a client can request from an object. Object implementation in CORBA, illustrated in Figure 6, is realized through a model consisting of two parts: the construction model and the execution model. The construction model describes how services are defined; the execution model describes how services are performed. With respect to the construction model, the object implementation definition provides the information needed to create objects and allow them to provide services, including definitions of methods and the intended type of an object. The execution model ensures that the requested service is performed by executing code that operates on data.[3]

12 2.2 Open Distributed Computing Environment Mohsin Qasim CORBA is based on a client-server model of distributed computing. In the client-server model, a request for service is made from one software component to another on a network. CORBA adds an additional dimension to this model by inserting a broker between the client and server components. The broker reduces the complexity of implementing the interaction between the client and server. The broker plays two key roles. First, it provides common services, including basic messaging and communication between client and server, directory services, meta-data description, security services, and location transparency. Second, it insulates the application from the specifics of the system configuration, such as hardware platforms and operating systems, network protocols, and implementation languages. CORBA is based on a peer-to-peer communications model and supports both synchronous and a limited version of asynchronous communications. The underlying interprocess communication in CORBA is handled through the general inter-orb protocol ( GIOP ). The GIOP was specified to allow interoperability among ORB implementations. It assumes an underlying connection-oriented transport layer. The GIOP defines transfer syntax; know as common data representation (CDR), and seven basic message types. The mapping of GIOP to TCP/IP is referred to as the internet inter-orb protocol (IIOP). The interoperable object reference (IOR) is the mechanism through which objects are accessed through the IIOP and between ORB vendors. The IOR includes the ORB s internal object reference, Internet host address, and port numbers. It is managed by the interoperating ORBs and is not visible to application programmers. In addition to IIOP, the DCE environment-specific inter-orb protocol (DCEESIOP) provides support for DCE s RPC mechanism, allowing CORBA to coexist with a DCE-based system. The ORB itself handles the communications routing of a request, as well as any ancillary services required performing the request, as shown in Figure 7.

13 The object that makes the request is referred to as the client. If an abnormal condition occurs during the execution of a request, an exception value is returned to the client. Requests can be of both a static and dynamic nature. Static invocations are requests that have been fully defined at compile time and are made through an IDL stub to a skeleton on the server side. Dynamic invocations provide the ability to add new objects and interfaces without requiring changes to the client code. Dynamic invocation requires the use of the dynamic invocation interface (DII). The dynamic skeleton interface (DSI) is the server-side equivalent. 2.3 Component Integration and Reuse The twin concepts of software reuse and software integration are closely related since integration is the combination of two or more existing components. Without good integration tools and techniques, reuse is difficult and will probably not happen to any significant degree because, without a back plane or broker, custom interfaces must be defined for each interaction between components. With a broker, however, each interface is defined just once and subsequent interactions are handled by the broker. With CORBAidl, these interfaces can be defined in a standardized, platformindependent fashion. The advantage to the software developer is a significant reduction in complexity. Without the broker, the number of interfaces is an N-squared problem; with the broker, only N interfaces are required, as shown is Figure 8. The advantages of this are clear when one considers the cost of extending a relatively large and complex system. With the custom interface solution, the integration of each

14 additional component requires the development of N+1 new interfaces while the broker-based approach required only one. Extending the broker to include carefully selected services can further facilitate the rapid integration and reuse of components. The CORBA Interface and Implementation Repositories are examples of these types of services. The Interface Respository allows clients to discover interface information. Clients can determine which operations are valid and perform invocations at run time. In addition, the interface Repository is used for storing other type and interface information, including stubs, skeletions, routines to browse interfaces, and debugging information. The Implementation Repository allows ORBs to located and activates implementation Repository allows ORBs to locate and activates implementation s of objects. Used in combination, these repositories provide the developer with the ability to browse, select, and located objects at either development or run time. Furthermore, CORBA services contain a rick assortment of additional tools. The completeness of this assortment of services is the reason why CORBA exlipses all other currently available distributed technology solutions. CORBA includes welldeveloped service specifications in each of the following areas. [3] Lifecycle Object transaction Properties Naming Concurrency Object trader Event notification Security Object startup Persistent objects Time Object collections Relationship Licensing Externalization Object query In addition, CORBA provides a set of higher-level CORBA facilities to support the development of applications and to handle object interoperability. The facilities are composed of four basic categories: User interface, Information Management, Systems Management, and the Task Management. They support compound document presentation and interchange, internationalization and time services, data and information exchange, rendering management, printing, change management, system management, scripting, agents, rule management, and other sophisticated capabilities. The CORBA domains specifications are also currently being developed to describe objects for various vertical industry domains, such as healthcare, financial services, and telecommunications.

15 3. Relationship with other Technologies 3.1 Comparing DCE and CORBA DCE supports the construction and integration of C-based client/server applications in heterogeneous distributed environments as in figure DCE Executive The DCE Executive consists of the following components:[4] Security Services that support authentication (using Kerberos V5, clients and servers can prove who they are), authorization (servers can use access control lists to determine whether a client is authorized to obtain a given service), integrity (checksums guarantee that information is received as transmitted), and privacy (DES encryption protects sensitive information from disclosure during transmission between a client and server). Directory Services that support local DCE administration domains called cells and inter-cell name resolution. These services consist of a Cell Directory Service (CDS), Global Directory Service (GDS, which uses X.500), Domain Name Service (DNS, not supplied, but used by DCE), and a Global Directory Agent (GDA).

16 A Distributed Time Service (DTS) that synchronizes clocks on all hosts in a DCE cell, as well as between cells. DTS uses the UTC standard and is interoperable with NTP. A Remote Procedure Call (RPC) mechanism by which clients invoke procedures in servers. A client may use directory services to bind to a particular server of interest at run time, and the client and server may use security services to guarantee desired levels of authentication, authorization, integrity, and privacy. The RPC mechanism insulates clients from details of where servers are located on the network, the types of hardware and operating system platforms on which they execute, differences in data representations between client and server platforms, and the particular network transports in use. A Threads package based on POSIX a (draft 4) that supports the creation and management of multiple threads of control within a client or server. A multi-threaded client may perform additional work (perhaps invoke additional RPCs) while one RPC is pending. The dispatcher that receives RPCs at a server and invokes the appropriate RPC handlers is already multi-threaded, automatically permitting DCE servers to handle multiple RPCs concurrently. The maximum number of concurrent RPCs at a server is easily configured by the developer, who is also responsible for ensuring the thread-safe behavior of all RPC handlers Similarities between CORBA and DCE SIMILARTIES DCE CORBA Problem space Distributed heterogeneous client-server application development Distributed heterogeneous client-server application development based on Controlling body Open software foundation A standards-setting consortium Tens of vendors,including IBM,H-P, and DEC objects Object management group - A standards-setting consortium Supporting organizations Hundreds of vendors and more then 700 users including IBM,H-P, and DEC and sun Specifications DCE 1.0 in 1992 CORBA 1.0 in late 1991 Vendor Products Available in 1993 Available in 1993 Services similarities Directory, time, threads, security events network management Directory, time, threads, security events network management

17 3.1.3 Difference between DCE and CORBA Mohsin Qasim DIFFERENCE DCOM CORBA Programming style Procedural- can do object oriented programming but not directly supported by DCE Inheritance. Product of controlling body Specification, references implementations and validation suites Object oriented-supports encapsulation, abstraction, polymorphism and Specification, implementations left to vendor and validation suites to be offered Interoperability among DCE1.0 in 1992 CORBA 2.0 in 1995 vendor products Data types Handles pointers Permits any arbitrary data type to be sent Services differences Provides a distributed file system Maturity Events and networks management option under construction Significant number of services including persistence properties query traders transactions as well as facilities in the areas of user interface information management systems management lastly services in finance distributed simulations and computer integrated manufactures Many of the services facilities and domain functionality are under construction Extensible No Yes Interfaces Static innovation Static and dynamic innovation IDL supports inheritance 3.2 Comparing DCOM and CORBA DCOM overview DCOM is described as COM with a longer wire; this is an extension to Component Object Model (COM). DCOM- Distributed Component Object Model- supports remote object by running on protocol called the Object Remote Procedure Call (ORPC).

18 10 millions of people using Windows daily in networked environment DCOM become widely used main goal of DCOM is to support the development of components that can be dynamically activated and that can interact with each other. DCOM object model is centered on the implementations of interfaces. COM provides operation through which a client can connect to one or more server applications.[2] DCOM Details. DCOM object model is centered around the implementations of interfaces: MIDL- Microsoft Interface Definition Language is used to define interfaces for the DCOM object. It supports two different forms of interface descriptions:[1] o o o basic IUNKNOWN every object must be implement in this interface Query interface is a method to navigate among the interfaces. IDISPATCH- extends IUNKNOWN- is a sort of gateway interface- to many more interfaces AddRef() Relese() (MIDL) associates classes to the interfaces. Benefit of binary interfaces is that interfaces are programming independent. Libraries- store the type of information of the object. Can be also used to invoke objects implementing the IDISPACH interface. each interface in DCOM has unique 128-bit identifier called Interface Identifier IID

19 OLE is best known as compound document framework. Recent extensions to OLE extended this notation to a fully functional desktop integration framework. The services provided by OLE are: [3] Compound documents- The ability to link information in a document through three services o In place Activation Allow containers application to display component object. Providing the user with an ability to edit component application operations. o Linking- provides access to common data with updates o Embedding- Provides a separate copy of source data into container objects Drag-and-drop -Adds OLE objects to windows drag-and-drop Automation dispatch service to control application and provides features similar to the dynamic innovation mechanism of CORBA The Com provides the basic communication mechanism on which all the other services rely: o Uniform data transfer- Extends the clipboard to handle OLE objects o Monikers- Naming of objects; Limitations include names being server specific o Persistent storage- Stores multiple objects with in a container objects provided by the compound files services One of the DCOM key distinctions is its specification of binary interface standards that is supposed to provide better portability then CORBA. However the reliance on the win32 API eliminates portability in circumstances in which it is not available on UNIX or MVS Similarities between CORBA and DCOM [3] SIMILARITIES DCOM CORBA Object model Yes Yes Standards body Recently made formal; managed by the active group, an open group affiliate Interface similarities Microsoft IDL allows for separation of interface and implementation and providing a repository for storage of interface (although the IDL interface is not complete.) Formal; managed by the object management group CORBA IDL allows for separation of interface and implementation and provides a repository for storage of interface Language independency YES YES Compound document Yes (OLE) Yes open disc model Location transparency Yes Yes

20 3.2.4 Difference between CORBA and DCOM [3] DIFFERENCE DCOM CORBA Focus Desktop first Enterprise second Enterprise first Desktop second Platforms Windows NT; Future support for windows (all version) Macintosh, Unix(various) and MVS Availability Services differences Single vendor; Availability from other vendor expected Active X interface content standard Maturity NT shipped in 1996; decade-long evolution of OLE and COM products, most services and facilities under construction Language binding C,C++: working on JAVA, visual basic, ADA Interface inheritance Supports aggregation but not inheritance; interface are not classes MVS, UNIX(various), Windows (all version), Macintosh Multi-vendor Significant number of additional services, including query, trader, transactions, as well as facilities in the area of information management and systems management. Lastly service in areas such as finance distributed simulation and computer integrated manufacturing Product since 1992; Many services and facility under construction C++, Smalltalk, Ada95:JAVA and COBOL in process Multiple inheritance; Interfaces are classes

21 4 CORBA Services CORBA Services are services that are essential for implementing objects. The CORBA Services that have been specified thus far by OMG include:[2] A Concurrency Control Service that protects the integrity of an object's data when multiple requests to the object are processed concurrently. An Event Service that supports the notification of interested parties when programdefined events occur. An Externalization Service that supports the conversion of object state to a form that can be transmitted between systems by a means other than a request broker. Life Cycle Services that support creation, copying, moving, and destruction of objects. A Naming Service that permits object references to be retrieved through associations between names and objects, and for those associations to be created and destroyed. A Persistent Object Service that supports the persistence of an object's state when the object is not active in memory and between application executions. A Query Service that supports operations on sets and collections of objects that have a predicate-based, declarative specification and may result in sets or collections of objects. A Relationship Service that provides for creating, deleting, navigating, and managing relationships between objects (for example, a containment relationship between a "folder" object and the "document" objects that are considered to be "in" that folder). A Transaction Service that provides support for ensuring that a computation consisting of one or more operations on one or more objects satisfies the requirements of atomicity (if a transaction is interrupted by a failure, any partially completed results are undone), isolation (transactions are allowed to execute concurrently, but the results are the same as if they executed serially), and durability (if a transaction completes successfully, the results of its operations are never lost, except in the event of catastrophe).

22 CORBA Services that are in the process of being specified and are expected to be completed in 1995 include: A Licensing Service that will control and manage remuneration of suppliers for services rendered. A Property Service that will support the association of arbitrary named values (the dynamic equivalent of attributes) with an object. A Security Service that will support authentication, authorization, integrity, and privacy to degrees, and using mechanisms, that are yet to be determined. A Time Service that will provide synchronized clocks to all objects, regardless of their locations. CORBA Services that are not yet in the process of being specified include: A Change Management Service that would support the identification and consistent evolution of configurations of objects. A Collection Service that would support the creation and manipulation of collections of objects. A Data Interchange Service that would support the exchange of data between objects. A Replication Service that would provide for the explicit replication of objects in a distributed environment (for the purpose of availability or fault tolerance) and for the management of consistency of replicated copies. A Trader Service that would provide a matchmaking service between clients seeking services and objects offering services.

23 5 CORBA Facilities CORBA Facilities are useful for constructing applications across a wide range of application domains. They are divided into Horizontal CORBA Facilities, which are typically more useroriented, and Vertical CORBA Facilities, which support specific application domains. The Horizontal CORBA Facilities currently identified by OMG are grouped into four areas: User Interface Facilities, which include Compound Presentation, Desktop Management, Rendering Management, Scripting, and User Support Facilities. Information Management Facilities, which include Compound Interchange, Data Encoding and Representation, Data Interchange, Information Exchange, Information Modeling, Information Storage and Retrieval, and Time Operations Facilities. System Management Facilities, which include Collection Management, Consistency, Customization, Data Collection, Event Management, Instance Management, Instrumentation, Policy Management, Process Launch, Quality of Service Management, Scheduling Management, and Security Facilities. Task Management Facilities, which include Agent, Automation, Rule Management, and Workflow Facilities. No Horizontal CORBA Facilities have been specified as yet. The first CORBA Facilities RFP was issued in October of 1994 for Compound Document Facilities (Compound Presentation and Compound Interchange). Further RFPs will be forthcoming in The Vertical CORBA Facilities currently identified by OMG (as a result of responses from interested vertical market segments to an OMG RFI) are: Accounting, Application Development, Computer Integrated Manufacturing, Currency, Distributed Simulation, Imagery, Information Superhighways, Internationalization, Mapping, Oil and Gas Exploration and Production, Security, and Telecommunication. No Vertical CORBA Facilities have been specified as yet.[2]

24 6 CORBA Products CORBA is a specification; it is a guide for implementing products. Several vendors provide CORBA products for various programming languages. The CORBA products that support the Java programming language include: The Java 2 ORB ORB VisiBroker for Java OrbixWeb WebSphere Netscape Communicator Various free or shareware ORBs Description The Java 2 ORB comes with Sun's Java 2 SDK. It is missing several features. A popular Java ORB from Inprise Corporation. VisiBroker is also embedded in other products. For example, it is the ORB that is embedded in the Netscape Communicator browser. A popular Java ORB from Iona Technologies. A popular application server with an ORB from IBM. Netscape browsers have a version of VisiBroker embedded in them. Applets can issue request on CORBA objects without downloading ORB classes into the browser. They are already there. CORBA implementations for various languages are available for download on the web from various sources. Providing detailed information about all of these products is beyond the scope of this introductory course. This course will just use examples from both Sun's Java 2 ORB and Inprise's VisiBroker 3.x for Java products[2]

25 7 Conclusion This next generation Web must be able to handle Internet, intranet, and extranet interactions. Business-to-business and consumer-to-business transactions are pushing the use of distributed objects. The Web is evolving into the role of a full-blown client/server medium of distributed computing. CORBA creates a distributed objects infrastructure which makes activating and accessing remote objects transparent. CORBA offers a flexibility and adaptability that give it a promising future.

26 8 REFERENCES [1] [2] c/wasee_content/corbaio/concepts/ccbasic.htm [3] INSIDE CORBA by Mowbray-Ruh [4]