C O R B A Unit 4

Distributed Systems The Beginning: Monolithic Systems and Mainframes The Revolution: Client/Server Architecture The Evolution: Multitier Client/Server The Next Generation: Distributed Systems

The Beginning: Monolithic Systems and Mainframes

The Revolution: Client/Server Architecture

The Evolution: Multitier Client/Server

The Next Generation: Distributed Systems Exposes all functionality of the application as objects, each of which can use any of the services provided by other objects in the system, or even objects in other systems. The architecture can also blur the distinction between "client" and "server" because the client components can also create objects that behave in server-like roles. The distributed system architecture provides the ultimate in flexibility. Distributed systems are really multitier client/server systems in which the number of distinct clients and servers is potentially large .

Purpose of CORBA CORBA Provides a Standard mechanism for defining the interfaces between components as well as some tools to facilitate the implementation of those interfaces using the developer’s choice of languages. Two features that CORBA provides are: Platform Independence Language Independence Platform Independence means that CORBA objects can be used on any platform for which there is a CORBA ORB implementation. Language Independence means that CORBA objects and clients can be implemented in just about any programming language.

Exploring CORBA Alternatives Socket Programming Socket is a channel through applications can connect with each other and communicate The most straight forward way to communicate between application components The API for socket programming is rather low-level. However, because the API is low-level, socket programming is not well suited to handling complex data types, especially when application components reside on different types machines (or) are implemented in different programming languages.

Exploring CORBA Alternatives (Contd…) Remote Procedure Call (RPC): Provides a function-oriented interface to socket-level communications Using RPC, rather than directly manipulating the data that flows to and from a socket, the developer defines a function and generates codes that makes that function look like a normal functions to the caller. Because RPC provides a function-oriented interface, it is often much easier to use than raw socket programming. DCE Set of Standards by the OSF, includes a standard for RPC. It was never gained wide acceptance and exists today as little more than an historical curiosity.

Exploring CORBA Alternatives (Contd…) DCOM It is a relatively robust object model, that enjoys particular good support on Microsoft O/S. However, being a Microsoft technology, the availability of DOM is sparse outside the realm of Windows O/S. CORBA-DCOM bridges enable CORBA objects to communicate with DCOM objects vice versa. RMI Advantage - it supports the passing of objects by value, a feature not (currently) supported by CORBA. Disadvantage - it is a java-only solution, that is RMI servers and clients must be written in JAVA.

CORBA Architecture Overview CORBA is an object-oriented architecture CORBA objects exhibit many features and traits of other object-oriented systems, including interface inheritance and polymorphism . What makes CORBA even more interesting is that it provides this capability even when used with non object-oriented languages such as C and COBOL Interface inheritance allows an interface to be derived from another. Even though interfaces can be related through inheritance, the implementations for those interfaces need not be.

CORBA Architecture Overview (Contd…) The Object Request Broker An ORB is a software component whose purpose is to facilitate communication between objects. Locates a remote object, given an object reference. Marshals parameters and return values to and from remote method invocations. CORBA is the standard that implements this ORB capability.

CORBA Architecture Overview (Contd…) Interface Definition Language Specifies interfaces between CORBA objects, is instrumental in ensuring CORBA's language independence. Example: Client written in C++ can communicate with a server written in Java, which in turn can communicate with another server written in COBOL, and so forth. It is not an implementation language. The sole purpose of IDL is to define interfaces; providing implementations for these interfaces is performed using some other language.

CORBA Architecture Overview (Contd…) The CORBA Communications Model CORBA uses the notion of object references (Interoperable Object References, or IORs) to facilitate the communication between objects. Using the IOR, the client object can then invoke methods on the server object A client is simply any application that uses the services of a CORBA object A server is an application that creates CORBA objects and makes the services provided by those objects available to other applications CORBA ORBs usually communicate using the Internet Inter-ORB Protocol (IIOP).

CORBA Architecture Overview (Contd…) The CORBA Object Model All communication between objects is done through object references Visibility to objects is provided only through passing references to those objects; objects cannot be passed by value Another aspect of the CORBA object model is the Basic Object Adapter (BOA) A BOA basically provides the common services available to all CORBA objects.

CORBA Architecture Overview (Contd…) CORBA Clients and Servers A component can act as both a client and as a server. Essentially, a component is considered a server if it contains CORBA objects whose services are accessible to other objects. Likewise, a component is considered a client if it accesses services from some other CORBA object. A component can simultaneously provide and use various services So a component can be considered a client or a server, depending on the scenario in question.

CORBA Architecture Overview (Contd…) Stubs and Skeletons A client stub is a small piece of code that allows a client component to access a server component. This piece of code is compiled along with the client portion of the application. Server skeletons are pieces of code that you "fill in" when you implement a server. No need to write the client stubs and server skeletons; these pieces of code are generated during compilation of IDL interface definitions.

CORBA and Networking Model Essentially, CORBA applications are built on top of GIOP-derived protocols such as IIOP. These protocols, in turn, rest on top of TCP/IP, DCE, or whatever underlying transport protocol the network uses. rather than supplant network transport protocols, the CORBA architecture creates another layer--the inter-ORB protocol layer--which uses the underlying transport layer as its foundation. This, too, is a key to interoperability between CORBA applications, as CORBA does not dictate the use of a particular network transport protocol.

CORBA Object Model Every object-oriented architecture features an object model, which describes how objects are represented in the system. Because CORBA is a distributed architecture, however, its object model probably differs somewhat from the traditional object models Three of the major differences between the CORBA object model and traditional models lie in CORBA's "semi-transparent" support for object distribution , its treatment of object references , and its use of what are called object adapters--particularly the Basic Object Adapter (BOA) .

Object Distribution A remote method call looks exactly like a local method call, thanks to the use of client stubs. Thus, the distributed nature of CORBA objects is transparent to the users of those objects; the clients are unaware that they are actually dealing with objects which are distributed on a network. Object distribution brings with it more potential for failure, CORBA must offer a contingency to handle such possibilities. (SystemExceptions)

Object References In a distributed application, there are two possible methods for one application component to obtain access to an object in another process. One method is known as passing by reference When an object is passed by reference, the object itself remains "in place" while an object reference for that object is passed. Operations on the object through the object reference are actually processed by the object itself. The second method of passing an object between application components is known as passing by value When an object is passed by value, the object's state is copied and passed to its destination, where a new copy of the object is instantiated. Operations on that object's copy are processed by the copy, not by the original object.

Basic Object Adapters (BOA) Primary purpose of BOA is to interface an object's implementation with its ORB. New object adapter types be created only when necessary and provides three sample object adapters: The Basic Object Adapter (BOA), which you will concentrate on, The Library Object Adapter Object-Oriented Database Adapter, both of which are useful for accessing objects in persistent storage. The BOA provides CORBA objects with a common set of methods for accessing ORB functions. These functions range from user authentication to object activation to object persistence. The BOA is, in effect, the CORBA object's interface to the ORB. According to the CORBA specification, the BOA should be available in every ORB implementation.

Contd… The BOA supports four types of activation policies, which indicate how application components are to be initialized. These activation policies include the following: The shared server policy, in which a single server is shared between multiple objects The unshared server policy, in which a server contains only one object The server-per-method policy, which automatically starts a server when an object method is invoked and exits the server when the method returns The persistent server policy, in which the server is started manually

The ORB It is the infrastructure mechanism standardized by CORBA. The role of the ORB is to unify access to application services, which it does by providing a common object-oriented, remote procedure call mechanism. Using CORBA technologies with object orientation is a better way to separate interfaces and implementation. It enables programmers to hide what they need to hide and expose what they need to expose, through interfaces.

Role of ORB Uniform access to services: Common RPC Uniform discovery of resources: Common Naming Uniform error handling Uniform security policies Uniform legacy application integration Application ORB Distributed Services

Similarities between DCOM and CORBA Yes Yes Location Transparency Yes-OpenDoc Yes-OLE Compound document model Yes Yes Language independence CORBA IDL allows for separation of interface and implementation and provides a repository for storage of interfaces. Microsoft IDL allows for specification of interface and implementation and provides a repository for storage of interfaces. Interface similarities Formal: managed by the Object Management Group Recently made formal; managed by the Active Group, an Open Group affiliate Standards body Yes Yes Object Model CORBA DCOM Similarities

Differences between DCOM and CORBA Significant number of additional services, including query, trader, transactions, as well as facilities in the areas of information management and system management. Lastly, services in areas such as finance, distributed simulation, and computer integrated manufacturing ActiveX-interactive content standard Service differences Multi-vendor Single vendor; availability from other vendors expected Availability MVS, UNIX, Windows (all), Macintosh Windows NT; future support for Windows (all), Macintosh, UNIX, MVA Platforms Enterprise first; desktop second Desktop first; enterprise second Focus CORBA DCOM Differences

Differences between DCOM and CORBA Multiple Inheritance; interfaces are classes. Supports aggregation but not inheritance; interfaces are not classes. Interface Inheritance C++, Smalltalk, Ada95; JAVA and COBOL in process C, C++; working on JAVA, Visual Basic, Ada Language Binding Products since 1992; many services and facilities under construction NT shipped in 1996; decade-long evolution of OLE and COM products; most services and facilities under construction Maturity CORBA DCOM Differences

Value Basic Value Constructed Value Object Reference Primitive Types Integer Types Floating Point void Boolean Char & wchar Long & long long Float Double & Long Double Unsigned long & Unsigned long long Short & Unsigned short octet string

C O R B A Unit 4

Recommended

More Related Content

What's hot (20)

Similar to C O R B A Unit 4 (20)

More from Roy Antony Arnold G (20)

Recently uploaded (20)

C O R B A Unit 4