Professional Documents
Culture Documents
Fundamental concepts in Distributed System i) Single tier architecture A single computer that contains the database and front end to access the database. Generally these are found in small business. There is a single computer which stores all the companys data in a single database. The interface used to interact with the database may be part of the database or another program which ties into the database itself. Advantages: Cost-effective system Disadvantages Impractical for the large organizations which requires the interactions among more users. ii)Two-tier architecture In this the client/server describes the relationship between two computer in which one program(Client) makes a service request from another program(Server),which fulfills its request. Why we need this model? Early computer systems are monolithic systems in which all the processing is occurred on the same machine. But its very time consuming processes. So we adopt this client server model. Using Client/server model we can
Split work among multiple machines. Maintain a database on server that separates from clients provide more security.
Clients access data from the data base which is in the server. How they access this data? They use some non procedural language.SQL (Structured Query Language) is an example. They didnt allow the user to specify processing semantics within a query. This meant that large amounts of data often needed to be transferred to the client to be processed even if the result after processing was very small. Network congestion was inevitable. So the vendors of the database needed a way to move some of the processing back to the database server. So they offered some stored procedures which is a code that executes on the server side within the database management system. The stored procedure can be used to access data within the database and process it before sending the result to the client. Since the result is much smaller than the data being processed, the traffic between the client and server is substantially reduced. The stored procedures can also be shared between multiple clients. But its downside is that stored procedures are inherently non portable because they are vendor-specific. In Two-tier architecture management of database occurred on the server tier and all other processing occurred on the client tier. significant processing power. In the two tier architecture the client has to do a lot of processing work. In order to minimize the processing work we need a model that will distribute the work. So the client side processing was possible to separate into application presentation and business logic processing resulted in three tiers: a client tier for visual presentation, a middle tier for processing based on business logic and a data tier for persistent data management.
Presentation logic = User Interface, displaying data to the user, accepting input from the user.
Business logic = Data Validation, ensuring the data is kosher before being added to the database.
Data Access Logic = Database Communication, accessing tables and indices, packing and unpacking data
iii)Three-Tier Client/Server Architectures In a three-tier or multi-tier environment, the client implements the presentation logic (thin client). The business logic is implemented on an application server(s) and the data resides on database server(s). A Multi-tier architecture is thus defined by the following three component layers: 1. 2. 3. A front-end component, which is responsible for providing A back-end component, which provides access to dedicated A middle-tier component, which allows users to share and
portable presentation logic; services, such as a database server. control business logic by isolating it from the actual application;
Advantages of Multi-Tier Client/Server architectures 1. Network bottlenecks are minimized because the application layer does not transmit extra data to the client, only what is needed to handle a task.
2. When business logic changes are required, only the server has to be updated. In twotier architectures, each client must be modified when logic changes. 3. The client is insulated from database and network operations. The client can access data easily and quickly without having to know where data is or how many servers are on the system. 4. Database connections can be 'pooled' and thus shared by several users, which greatly reduces the cost associated with per-user licensing. 5. The organization has database independence because the data layer is written using standard SQL which is platform independent. The enterprise is not tied to vendorspecific stored procedures. 6. Changes to the user interface or to the application logic are largely independent from one another, allowing the application to evolve easily to meet new requirements. 7. The application layer can be written in standard third or fourth generation languages, such as Java, C or COBOL, with which the organization's in-house programmers are experienced
How communication between tiers is possible? Client/Server applications spread on multiple computers, so they need to communicate with each other. How they communicate with each other? For this they rely on a networking infrastructure such as TCP/IP or IPX.But if we implement such a low level communication the transaction to multi-tier systems would not have been possible.
In two tier system the task of abstracting the network protocols can easily be done. The database vendors provided specialized libraries and drivers to access the database that abstracted the various n/w protocols. Client-tier applications could be written without regard for the actual location of the database. The client tier applications were able to link in the appropriate library (either statically or dynamically) that allowed the communication with the data tier. Since the relational model provide a very structured and generic means for accessing the database, abstracting the networking code was not overly difficult. But the communication between the client applications and middle tier services cant be done in a generic and structured way as had be done in two-tier systems. Because client needs a model of communication that blends in with the development platform being used to implement the client applications. So standardization began to emerge.
So what actually a middle ware is? Middleware is connectivity software that consists of a set of enabling services that allow multiple processes running on one or more machines to interact across a network. Middleware is essential to migrating mainframe applications to client/server applications and to providing for communication across heterogeneous platforms. Middleware services are sets of distributed software that exist between the application and the operating system and network services on a system node in the network.
Do you know which is the first middle ware technology that gain the wide acceptance? Middleware services provide a more functional set of Application Programming Interfaces (API) than the operating system and network services to allow an application to
locate transparently across the network, providing interaction with another application or service be independent from network services be reliable and available scale up in capacity without losing function
Remote Procedure Calls (RPCs), which enable the logic of an application to be distributed across the network. Program logic on remote systems can be executed as simply as calling a local routine.
Message Oriented Middleware (MOM), which provides program-to-program data exchange, enabling the creation of distributed applications. MOM is analogous to email in the sense it is asynchronous and requires the recipients of messages to interpret their meaning and to take appropriate action.
Object Request Brokers (ORBs), which enable the objects that comprise an application to be distributed and shared across heterogeneous networks.
What is RPC? ( The first middle ware technology that gain the wide acceptance) Remote Procedure Call (RPC) is a client/server infrastructure that increases the interoperability, portability and flexibility of an application by allowing the application to be distributed over multiple heterogeneous platforms. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the
application developer from the details of the various operating system and network interfacesfunction calls are the programmer's interface when using RPC. Why we choose ORB instead of RPC? RPC is appropriate for client/server applications in which the client can issue a request and wait for the server's response before continuing its own processing. Because most RPC implementations do not support peer-to-peer, or asynchronous, client/server interaction, RPC is not well-suited for applications involving distributed objects or objectoriented programming. What is ORB? An object request broker (ORB) is a middleware technology that manages communication and data exchange between objects. ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects- from different vendors- that communicate with each other via the ORB. The implementation details of the ORB are generally not important to developers building distributed systems. The developers are only concerned with the object interface details. ORB technology promotes the goal of object communication across machine, software, and vendor boundaries. The relevant functions of an ORB technology are
interface definition location and possible activation of remote objects communication between clients and object.
An ORB allows objects to hide their implementation details from clients. This can include programming language, operating system, host hardware, and object location. Each of these can be thought of as a "transparency, and different ORB technologies may choose to support different transparencies, thus extending the benefits of object orientation across platforms and communication channels.
There are many ways of implementing the basic ORB concept; for example, ORB functions can be compiled into clients, can be separate processes, or can be part of an operating system kernel. These basic design decisions might be fixed in a single product; or there might be a range of choices left to the ORB implementer. There are two major ORB technologies: The Object Management Group's (OMG) Common Object Request Broker
CORBA INTRODUCTION CORBA products provide a framework for the development and execution of distributed applications. But why would one want to develop a distributed application in the first place? As you will see later, distribution introduces a whole new set of difficult issues. However, sometimes there is no choice; some applications by their very nature are distributed across multiple computers because of one or more of the following reasons:
The data used by the application are distributed The computation is distributed The users of the application are distributed
Data are distributed Some applications must execute on multiple computers because the data that the application must access exist on multiple computers for administrative and ownership reasons. The owner may permit the data to be accessed remotely but not stored locally. Or perhaps the data cannot be co-located and must exist on multiple heterogeneous systems for historical reasons. Computation is distributed Some applications execute on multiple computers in order to take advantage of multiple processors computing in parallel to solve some problem. Other applications may execute on multiple computers in order to take advantage of some unique feature of a particular system. Distributed applications can take advantage of the scalability and heterogeneity of the distributed system. Users are distributed Some applications execute on multiple computers because users of the application communicate and interact with each other via the application. Each user executes a piece of the distributed
application on his or her computer, and shared objects, typically execute on one or more servers. A typical architecture for this kind of
Distributed Object Systems Distributed object systems are distributed systems in which all entities are modeled as objects. Distributed object systems are a popular paradigm for object-oriented distributed applications. Since the application is modeled as a set of cooperating objects, it maps very naturally to the services of the distributed system. what is CORBA? 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. The OMG The Object Management Group (OMG) is responsible for defining CORBA. The OMG comprises over 700 companies and organizations, including almost all the major vendors and developers of distributed object technology, including platform, database, and application vendors as well as software tool and corporate developers What is CORBA good for? CORBA is useful in many situations. Because of the easy way that CORBA integrates machines from so many vendors, with sizes ranging from mainframes through minis and desktops to handheld and embedded systems, it is the middleware of choice for large (and even not-so-large) enterprises. One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability. CORBA works behind the scenes in the computer rooms of many of the world's largest websites; ones that you probably use every day. Specializations for scalability and fault-tolerance support these systems. But it's not used just for large applications; specialized versions of CORBA run real-time systems, and small embedded systems.
CORBA ARCHITECTURE The picture below shows the main components of the ORB architecture and their interconnections
Figure : CORBA ORB Architecture The central component of CORBA is the Object Request Broker (ORB). It consists all of the communication infrastructure necessary to identify and locate objects, handle connection management and deliver data. In general, the ORB is not required to be a single component; it is simply defined by its interfaces. The ORB Core is the most crucial part of the Object Request Broker; it is responsible for communication of requests. The basic functionality provided by the ORB consists of passing the requests from clients to the object implementations on which they are invoked. In order to make a request the client can communicate with the ORB Core through the IDL stub or through the Dynamic Invocation Interface (DII). The stub represents the mapping between the language of implementation of the
client and the ORB core. Thus the client can be written in any language as long as the implementation of the ORB supports this mapping. The ORB Core then transfers the request to the object implementation which receives the request as an up-call through either an IDL skeleton, or a dynamic skeleton.
Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant. Servant -- This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.
Client -- This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args). The remaining components in Figure 2 help to support this level of transparency.
Object Request Broker (ORB) -- The ORB provides a mechanism for transparently communicating client requests to target object implementations. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.
ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described below.
CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue'' between the client and server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.
Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.
Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. The client making the request has no idea whether the implementation is using the typespecific IDL skeletons or is using the dynamic skeletons.
Object Adapter -- This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).
Corba has the versatility of Broad Language support :- Mapping between different programming languages and the IDL Diverse platform support Compatible with UNIX, Windows 95,98,OS/2 etc.Java based ORBs can be used in any platform that supports the JVM. Multivendor support Many vendors develop and supply CORBA products . Vendors like IONA technologies , Inprise, BEA Systems , IBM etc are some among them.IIOP helps in interoperability.
CORBA is currently the dominant remote architecture Why? 1. CORBA IDL 2. Dynamic Invocation 3. Portable Object Adaptor 4. Interoperability 5. Multi programming Language Support The fundamental traits of distributed object system include
Interfaces: is used to describe the contracts that describe the capabilities of the distributed object in the system
Data types: A doc must support data types that allow data to be transmitted to and from distributed objects. CORBA provides a rich set of types as well as support for enumerated types, constants and structures.
Marshaling & unmarshaling: This is for ensuring data integrity. Marshalling process packages data into a standard format so that it can be transmitted. Un marshalling is the reverse process.
Proxies, stubs & skeletons: mechanism used for the seamless access to remote objects. Object handles:(object reference):used to reference distributed object instances within the context of a clients programming language or script
Object creation: A DOC must provide a mechanism for creating a new instance of distributed object. A factory is a special type of object used to create other distributed object. In CORBA factory interfaces are user defined.
Object invocation: mechanism for invoking operations on a distributed object. CORBA provides both static and dynamic invocation.
Object destruction: mechanism for removing a distributed object instance from the system once it is no longer in use. But in CORBA distributed object remains alive forever unless explicitly or timed out.
Introduction to CORBA IDL The CORBA Interface Definition Language (IDL) is used to define interfaces to objects in your network. This chapter introduces the features of CORBA IDL and illustrates the syntax used to describe interfaces. The first step in developing a CORBA application is to define the interfaces to the objects required in your distributed system. To define these interfaces, you use CORBA IDL. IDL allows you to define interfaces to objects without specifying the implementation of those interfaces. To implement an IDL interface, you define a C++ class that can be accessed through that interface and then you create objects of that class within an Orbix server application. In fact, you can implement IDL interfaces using any programming language for which an IDL mapping is available. An IDL mapping specifies how an interface defined in IDL corresponds to an implementation defined in a programming language. CORBA applications written in different programming languages are fully interoperable. CORBA defines standard mappings from IDL to several programming languages, including C++, Java, and Smalltalk. The Orbix IDL compiler converts IDL definitions to corresponding C++ definitions, in accordance with the standard IDL to C++ mapping.
IDL Modules and Scoping An IDL module defines a naming scope for a set of IDL definitions. Modules allow you to group interface and other IDL type definitions in logical name spaces. When writing IDL definitions, always use modules to avoid possible name clashes. The following example illustrates the use of modules in IDL: // IDL module BankSimple { interface Bank { ... }; interface Account { ... }; }; The interfaces Bank and Account are scoped within the module BankSimple. IDL definitions are available directly within the scope in which you define them. In other naming scopes, you must use the scoping operator (::) to access these definitions. For example, the fully scoped name of interfaces Bank and Account are BankSimple::Bank and BankSimple::Account respectively. IDL modules can be reopened. For example, a module declaration can appear several times in a single IDL specification if each declaration contains different data types. In most IDL specifications, this feature of modules is not required.
Defining IDL Interfaces An IDL interface describes the functions that an object supports in a distributed application. Interface definitions provide all of the information that clients need to access the object across a network. Consider the example of an interface that describes objects which implement bank accounts in a distributed application. The IDL interface definition is as follows: //IDL module BankSimple { // Define a named type to represent money. typedef float CashAmount; // Forward declaration of interface Account. interface Account; interface Bank { ... }; interface Account { // The account owner and balance. readonly attribute string name; readonly attribute CashAmount balance; // Operations available on the account. void deposit (in CashAmount amount); void withdraw (in CashAmount amount); }; };
The definition of interface Account includes both attributes and operations. These are the main elements of any IDL interface definition. Attributes in IDL Interface Definitions Conceptually, attributes correspond to variables that an object implements. Attributes indicate that these variables are available in an object and that clients can read or write their values. In general, attributes map to a pair of functions in the programming language used to implement the object. These functions allow client applications to read or write the attribute values. However, if an attribute is preceded by the keyword readonly, then clients can only read the attribute value. For example, the Account interface defines the attributes name and balance. These attributes represent information about the account which the object implementation can set, but which client applications can only read. Operations in IDL Interface Definitions IDL operations define the format of functions, methods, or operations that clients use to access the functionality of an object. An IDL operation can take parameters and return a value, using any of the available IDL data types. For example, the Account interface defines the operations deposit() and withdraw() as follows: //IDL module BankSimple { typedef float CashAmount; ... interface Account { // Operations available on the account. void deposit(in CashAmount amount);
void withdraw(in CashAmount amount); ... }; }; Each operation takes a parameter and has a void return type. Each parameter definition must specify the direction in which the parameter value is passed. The possible parameter passing modes are as follows: in out The parameter is passed from the caller of the operation to the object. The parameter is passed from the object to the caller.
Parameter passing modes clarify operation definitions and allow an IDL compiler to map operations accurately to a target programming language. Raising Exceptions in IDL Operations IDL operations can raise exceptions to indicate the occurrence of an error. CORBA defines two types of exceptions:
System exceptions are a set of standard exceptions defined by CORBA. User-defined exceptions are exceptions that you define in your IDL specification.
Implicitly, all IDL operations can raise any of the CORBA system exceptions. No reference to system exceptions appears in an IDL specification. To specify that an operation can raise a user-defined exception, first define the exception structure and then add an IDL raises clause to the operation definition. For example, the
operation withdraw() in interface Account could raise an exception to indicate that the withdrawal has failed, as follows: // IDL module BankExceptions { typedef float CashAmount; ... interface Account { exception InsufficientFunds { string reason; }; void withdraw(in CashAmount amount) raises(InsufficientFunds); ... }; }; An IDL exception is a data structure that contains member fields. In the preceding example, the exception InsufficientFunds includes a single member of type string. The raises clause follows the definition of operation withdraw() to indicate that this operation can raise exception InsufficientFunds. If an operation can raise more then one type of user-defined exception, include each exception identifier in the raises clause and separate the identifiers using commas. Invocation Semantics for IDL Operations By default, IDL operations calls are synchronous, that is a client calls an operation and blocks until the object has processed the operation call and returned a value. The IDL keyword oneway allows you to modify these invocation semantics.
If you precede an operation definition with the keyword oneway, a client that calls the operation will not block while the object processes the call. For example, you could add a oneway operation to interface Account that sends a notice to an Account object, as follows: module BankSimple { ... interface Account { oneway void notice(in string text); ... }; }; Orbix does not guarantee that a oneway operation call will succeed; so if a oneway operation fails, a client may never know. There is only one circumstance in which Orbix indicates failure of a oneway operation. If a oneway operation call fails before Orbix transmits the call from the client address space, then Orbix raises a system exception. A oneway operation cannot have any out or inout parameters and can not return a value. In addition, a oneway operation cannot have an associated raises clause. Passing Context Information to IDL Operations CORBA context objects allow a client to map a set of identifiers to a set of string values. When defining an IDL operation, you can specify that the operation should receive the client mapping for particular identifiers as an implicit part of the operation call. To do this, add a context clause to the operation definition. Consider the example of an Account object, where each client maintains a set of identifiers, such as sys_time and sys_location that map to information that the operation deposit() logs for each deposit received. To ensure that this information is passed with every operation call, extend the definition of deposit() as follows:
// IDL module BankSimple { typedef float CashAmount; ... interface Account { void deposit(in CashAmount amount) context("sys_time", "sys_location"); ... }; }; A context clause includes the identifiers for which the operation expects to receive mappings. Note that IDL contexts are rarely used in practice. Inheritance of IDL Interfaces IDL supports inheritance of interfaces. An IDL interface can inherit all the elements of one or more other interfaces. For example, the following IDL definition illustrates two interfaces, called CheckingAccount and SavingsAccount, that inherit from interface Account: // IDL module BankSimple{ interface Account { ... }; interface CheckingAccount : Account { readonly attribute overdraftLimit; boolean orderChequeBook (); };
interface SavingsAccount : Account { float calculateInterest (); }; }; Interfaces CheckingAccount and SavingsAccount implicitly include all elements of interface Account. An object that implements CheckingAccount can accept invocations on any of the attributes and operations of this interface, and on any of the elements of interface Account. However, a CheckingAccount object may provide different implementations of the elements of interface Account to an object that implements Account only. The following IDL definition shows how to define an interface that inherits both CheckingAccount and SavingsAccount: // IDL module BankSimple { interface Account { ... }; interface CheckingAccount : Account { ... }; interface SavingsAccount : Account { ... }; interface PremiumAccount :
CheckingAccount, SavingsAccount { ... }; }; If you define an interface that inherits from two interfaces which contain a constant, type, or exception definition of the same name, you must fully scope that name when using that constant, type, or exception. An interface can not inherit from two interfaces that include operations or attributes that have the same name.
Figure : Multiple Inheritance of IDL Interfaces The Object Interface Type IDL includes the pre-defined interface Object, which all user-defined interfaces inherit implicitly. The operations defined in this interface are described in the Orbix C++ Edition Programmer's Reference. While interface Object is never defined explicitly in your IDL specification, the operations of this interface are available through all your interface types. In addition, you can use Object as an attribute or operation parameter type to indicate that the attribute or operation accepts any interface type, for example:
// IDL interface ObjectLocator { void getAnyObject (out Object obj); }; Note that it is not legal IDL syntax to inherit interface Object explicitly. Forward Declaration of IDL Interfaces In an IDL definition, you must declare an IDL interface before you reference it. A forward declaration declares the name of an interface without defining it. This feature of IDL allows you to define interfaces that mutually reference each other. For example, IDL interface Bank includes an operation of IDL interface type Account, to indicate that Bank stores a reference to an Account object. If the definition of interface Account follows the definition of interface Bank, you must forward declare Account as follows: // IDL module BankSimple { // Forward declaration of Account. interface Account; interface Bank { Account create_account (in string name); Account find_account (in string name); }; // Full definition of Account. interface Account { ... };
}; The syntax for a forward declaration is the keyword interface followed by the interface identifier. Stubs and Skeletons
When you make your call to the object, you must create the correct messages: this is what the stub is used for. The skeleton(server stub) is responsible for translating these messages to the correct calls to the objects. The programmer is responsible for writing the stub and skeleton. The stub acts a a local 'representative' or proxy of the remote object, thus enabling working with a remote object as if it were local. The skeleton does the exactly the opposite thing. Note for COM-programmers: a CORBA-stub is what's called a proxy in COM-lingo, while a skeleton(server stub) plays roughly the same role a COM stub does.
The word stub has several meanings. A dictionary definition of stub is the short end
remaining after something bigger has been used up, for example ,a pencil stub or a cigarette stub. In traditional (non-distributed)programming, a stub procedure is a dummy implementation of a procedure that is used to prevent undefined label errors at link time. In a distributed middleware system like CORBA, remote calls are implemented by the client making a local call upon a stub procedure/object. The stub uses an inter-process communication mechanism (such as TCP/IP sockets)to transmit the request to a server process and receive back the reply.
The term proxy is often used instead of stub. A dictionary definition of proxy is a person authorized to act for another. For example, if you would like to vote on an issue but are unable to attend the meeting where the vote will be take place then you might instruct somebody else to vote on your behalf. If you do this then you are voting by proxy. The term proxy is very appropriate in CORBA (and other object-oriented middleware systems). A CORBA proxy is simply a client-side object that acts on behalf of the real object in a server process. When the client application invokes an operation on a proxy, the proxy uses an inter-process communication mechanism to transmit the request to the real object in a server process; then the proxy waits to receive the reply and passes back this reply to the application-level code in the client.
The term skeleton code refers to the server-side code for reading incoming requests and dispatching them to application-level objects. The term skeleton may seem like a strange choice. However, use of the word skeleton is not limited to discussions about bones; more generally, it means a supporting infrastructure. Skeleton code is so called because it provides supporting infrastructure that is required to implement server applications. A CORBA product must provide an IDL compiler, but the CORBA specification does not state what is the name of the compiler or what command-line options it accepts. These details vary from one CORBA product to another.
A client invokes a remote method. The remote method is actually invoked in the client stub. The client stub creates a message containing information needed for the RMI(marshalling) The client stub sends the message to the server stub using the communication bus The server stub receives the message and unpack it.(unmarshalling)
The server stub calls the appropriate server method based on the information provided in the message The server stub creates a message based on the outputs of the call to the server
The server stubs sends the result message to the client stub using the communication bus The client stub receives the result message, unpacks the message, and returns the result to the client.
The stub and skeleton are used to support the custom interfaces that are used in the system. So it should not be a hand-coding. So CORBA provides tools to generate client and server stubs from IDL description. CORBA services Object life cycle defines how CORBA objects are created, removed, moved, and copied Naming defines how CORBA objects can have friendly symbolic names Events decouples the communication between distributed objects Relationships provides arbitrary typed n-ary relationships between CORBA objects Externalization coordinates the transformation of CORBA objects to and from external media Transactions coordinates atomic access to CORBA objects Concurrency Control provides a locking service for CORBA objects in order to ensure serializable access Property supports the association of name-value pairs with CORBA objects Trader supports the finding of CORBA objects based on properties describing the service offered by the object Query supports queries on objects
Implementing a simple CORBA client and CORBA server using C++ Simple C++ client The client is an application starting from main().The pseudocode is i. ii. iii. iv. Initialize CORB ORB Find a reference to the service Cast the service to the right type Call methods on the service
For IDL interface Hello { void sayHello(); }; The client can use the method void sayHello();
The client is
#include<OB/CORBA.h> #includeHello.h
#include<fstream.h> int main(int argc, char **argv) { // initialize CORBA ORB CORBA_ORB_VAR orb=CORBA_ORB_init(argc,argv); // find service- here pick a string from out of a file const char* refFile=Hello.ref; ifstream in(refFile); in >> s; CORBA_Object_var obj = orb string_to_object(s); // cast to right type Hello_var hello = Hello::_narrow(obj); // invoke methods hellosayHello(); sayHello(); exit(0); }
Simple C++ server Pseudocode for the server is i. ii. iii. initialize CORBA ORB initialize the BOA create a reference to the service
iv. v.
export the reference (so the clients can find it) enter client request loop.
#include<OB/CORBA.h> #include<Hello_impl.h> #include<fstream.h> int main(int argc, char ** argv) { // initialize CORBA ORB CORBA_ORB_VAR orb=CORBA_ORB_init(argc,argv); //initialize the BOA CORBA_BOA_var boa= orb BOA_init(argc,argv); // create a reference to the service Hello_var p = new Hello_impl; // export the reference CORBA_String_var s = orb object_to_string(p); const char* refFile=Hello.ref; ofstream out(refFile); out << s << endl; out.close();
// enter the client request loop boa impl_is_ready ( CORBA_ImplementationDef:: _nil( )); } The Hello_impl class is defined in two files : a header file and an implementation file. The header file Hello_impl.h is #include <Hello.skel.h> class Hello_impl:public Hello_skel { public : virtual void sayHello(); }; And the implementation file Hello_impl.cpp is #include<OB/CORBA.h> #include<Hello_impl.h> void Hello_impl::sayHello(); { cout << Hello world << endl; }