Building a CORBA Application
- The outline of the process is
- Define the server’s interfaces using IDL
- Choose an implementation approach for the server’s interfaces
- Use the IDL compiler to generate client stubs and server skeletons for the server interfaces.
- Implement the server interfaces.
- Compile the server application
- Run the server application
Building a CORBA Server
- Since a server can be tested without a client, the first step is to implement the server.
- The server interfaces define the capabilities that will be made available by the server and how these capabilities are accessed.
- Implement those interfaces and finally compile and run the server.
a) Defining the Server Interfaces (Stock Market Server Example)
§ A Service is desired that, when given a stock symbol, will return the value of that stock at that particular time.
§ As an added convenience, the service will also return a list of all known stock symbols upon the request.
§ So, the StockServer interface could be defined to provide two services: (1) getStockValue() (2) getStockSymbols()
§ getStockValue() should take a StockSymbol as a parameter and return a floating-point result.
§ getStockSymbol() need not take any arguments and should return a list of StockSymbol objects.
StockMarket.idl
module StockMarket {
typedef string StockSymbol;
typedef sequence <StockSymbol> StockSymbolList;
interface StockServer {
float getStockValue (in StockSymbol symbol);
StockSymbolList getStockSymbols();
};
};
§ Group the related interfaces and types into IDL modules.
§ IDL offers two constructs to represent lists. (1) the sequence (2) the array.
§ Here, the size of the list is unknown, so the sequence is used.
§ However a method cannot return a sequence directly. So
typedef sequence <StockSymbol> StockSymbolList; is used.
b) Choosing an implementation approach
§ CORBA supports two mechanisms for implementation of IDL interfaces
i. Inheritance mechanism – in which a class implements an interface by inheriting from that interface class.
ii. Delegation mechanism – in which the methods of the interface class call the methods of the implementing class.
§ Implementation by inheritance consists of a base class that defines the interfaces of a particular object and a separate class, inheriting from this base class, which provides the actual implementations of these interfaces.
§ Implementation by delegation consists of a class that defines the interfaces for an object and then delegates their implementations to another class or classes.
§ The primary differences between the inheritance and delegation approaches is that in delegation, the implementation classes need not derive from any class in particular.
§ A tie class, or simply a tie, is the class to which implementations are delegated in the delegation approach. Thus, the approach is often referred to as the tie mechanism or tying.
§ Most IDL compilers accept command-line arguments to determine which implementation approach to generate code for.
b) How to choose an implementation approach
§ If an application makes use of legacy code to implement an interface, it might not be practical to change the classes in that legacy code to inherit from a class generated by the IDL compiler.
§ Therefore, for such an application it would make more sense to use the delegation approach; existing classes can readily be transformed into the classes.
Using the IDL Compiler
- The command to invoke the IDL compiler, included with Sun’s Java IDL product is,
idltojava –fno-cpp –fclient –fserver StockMarket.idl
-fno-cpp : switch instructs the IDL compiler to not invoke the C preprocessor before compiling the file.
-fclient and –fserver : switches instruct the IDL compiler to generate client stubs and server skeletons, respectively.
- Client Stubs and Server Skeletons
ü When the IDL compiler is invoked, it generates code that conforms to the language mapping used by that particular product.
ü The IDL compiler will generate a number of files – some of them helper classes, some them client stub classes, and some of them server skeleton classes.
ü The stubs do nothing more than tell the client’s ORB to marshal and unmarshal outgoing and incoming parameters.
ü The skeletons pass incoming parameters to the implementation code and passing outgoing parameters back to the client.
ü The names of the files generated by the IDL compiler are dependent on the language mapping used and sometimes on command-line arguments passed to the IDL compiler.
ü The contents of these files will remain the same, for the most part, regardless of the IDL compiler used.
