S A N K H Y A Sankhya Technologies Confidential. Copyright (c) 2003 Sankhya Technologies Private Limited SANKHYA Varadhi SE - FAQ for Enterprise customers ------------------------------------------------------------------------------- Sections: About SANKHYA Varadhi --------------------- 1. Question: What is SANKHYA Varadhi SE? SANKHYA Varadhi SE(Standard Edition) is a middleware and communication solution that can be used to integrate applications and develop distributed object oriented applications. Varadhi can speed up the development of distributed applications by as much as 90% when compared to the use of transport layer technologies like sockets. Varadhi enables distribution of software across Windows, Linux and Solaris hosts and embedded systems like mobile phones and PDAs. Varadhi applications can easily switch between the use of different standards like CORBA ® and SOAP with near zero impact on the application code ! SANKHYA Varadhi 1.2 supports Interface Repository, DII and DSI, WSDL, SOAP and UDDI and includes powerful features for developing distributed fault tolerant applications. High performance distributed server applications can take advantage of the easy to use multi-threading capabilities of Varadhi 1.2 Business advantage of SANKHYA Varadhi SE ---------------------------------------- 1. Question: Who are SANKHYA Varadhi SE top 5 competitors in the enterprise market space ? ORB Express from Objective Interface Systems, Orbix/E, Orbacus from IONA, The ACE ORB, eORB from Vertel. 2. Question: What are the business domains where SANKHYA Varadhi SE is identified to be an ideal solution development platform? * Aerospace and Defence. * Banking and Finance. - ATM integration to central banking application/server - Web enabling legacy applications - Integrating Branch, Zonal and Central applications * Building Automation. * Chemical/Petrochemical. * Education. * E-Commerce * Healthcare and Insurance. * Human resources. * Manufacturing. * Real Estate. * Research. * Software/Hardware companies. * Point-of-Sale Appliances. * Telecommunications. - Routers. - Network Management * Transportation. * Utilities. * Web Services. - Web enabling legacy applications - SOAP/HTML/XML clients for CORBA Servers * Distributed Games. - Distributed Chat Applications - 2-way and n-way distributed games * Educational institutes - For distributed computing lab. 3. Question: How a distributed application can be developed using SANKHYA Varadhi? a) The interface and methods for the distributed application is identified and idl file is developed. b) Implement the server application. c) Implement the client application. By using SANKHYA Varadhi, complexities involved in developing a distributed system, like design implementation of a communication interface/protocol between client and server avoided. 4. Question: How SANKHYA Varadhi is superior when compared to the enterprise object middlewares available in the market? a) Varadhi includes an interactive configuration and platform generation utility (vconf). This makes it easy to create a ready to use version of the Varadhi target platform for a particular target environment b) With the extensive log of messages printed by Varadhi (debug version) application developers can easily debug their applications. c) The core Varadhi library is completely independent of a particular operating system. The only OS dependent features are abstracted into the OS abstraction making it easy to add support for a new operating system. d) Designed for Minimum CORBA, Varadhi has a very optimized footprint, as low as 100KB on an x86 Linux machine ! The static version of Varadhi allows memory for the various internal objects to be configured. e) Starting at USD 495/developer license, no run-time fees and a very reasonable deployment license fee (starting at USD 999/- per application) Varadhi is very competitively priced. Executive Overview of SANKHYA Varadhi ------------------------------------- 1. Question: What are the key features of SANKHYA Varadhi ? a) SANKHYA Varadhi Conforms to OMG's CORBA 2.2(Minimum CORBA). b) Small footprint and interoperability with IIOP. c) Common Object Services like Naming service, Event service, Lightweight Logging service confirming to Common Object Services Specifications. d) Support for static/dynamic memory allocation. e) Support for debug/profile platform. f) Support to include/exclude C++ exceptions. g) Customizable NameServer. h) Highly configurable using `vconf` Varadhi configuration tool. i) Support GIOP 1.2 j) Support for DII/DSI and Interface repository. k) Support for Multithreading. l) Support for IDL to WSDL and WSDL to IDL translation. m) Support for UDDI service. n) Support for SOAP protocol. 2. Question: What are the supported platforms ? Currently, SANKHYA Varadhi SE runs on a Red Hat Linux 7.2, Solaris 2.7 and Windows NT/2000. Pricing and Availability ------------------------ 1. Question: How I can get Varadhi ? For further details and inquiries, please contact sales@sankhya.com For additional information on our object middleware products, please visit http://www.sankhya.com/info/products.html 2. Question: What is the price of SANKHYA Varadhi? SANKHYA Varadhi is competatively priced when compared to the existing simillar products. About CORBA and OMG ------------------- 1. Question: What is CORBA ? CORBA stands for Common Object Request Broker Architecture. This is a vendor independent architecture, that can be used to develop distributed applications(client and server need not be implemented in the same language) across various networks running on different operating systems. 2. Question: What is OMG ? OMG stands for Object Management Group. OMG designs the specification for CORBA. There are more than 800 companies, who are members of OMG. 3. Question: What is ORB ? ORB stands for Object Request Broker. 4. Question: Why do we need to register to RootPOA ? In a distributed object oriented system a request broker routes client requests to server objects. Server objects are implemented in an implementation languages like C++ or Java. A server object implemented using such an implementation language is referred to as a 'servant object'. Servant objects are not inherently distributed and can't be accessed remotely. To allow servant objects to be accessed remotely they will have to be registered with an object request broker. CORBA allows servant objects to be registered using the Portable Object Adapter (POA). A servant thus registered with the POA can be accessed remotely using its object reference. POA includes operations to register servant objects and obtain a 'CORBA Object Reference' for that servant object which can be accessed remotely by CORBA clients. 5. Question: In statement below in client.cc orb = CORBA::ORB_init(argc, argv, ORBid); what are the values of argc and argv.Is there any default values for them? A CORBA client or server application should initialize an ORB before using either the client or server side functionality of a CORBA object. The method ORB_init is used to initialize an ORB. The argc and argv parameters are similar to the argument count and vector parameters passed to the main function of C or C++ program. In fact, an application can simply pass on the argc, argv values of its main function to ORB_init. This function will consume any command line options that are ORB specific and remove them from the argument list. 6. Question: Why the below statements needed in server only? // Get a reference to the Root POA. CORBA::Object_var obj = orb->resolve_initial_references("RootPOA"); PortableServer::POA_var poa = PortableServer::POA::_narrow(obj); As explained in Question-1, the POA is an interface to the ORB used by server applications to register and manager servant objects. Therefore resolving and using the RootPOA (the default root POA object) is only required in server applications. 7. Question: What is POA manager and what is its role? A POA manager is an object that encapsulates the processing state of one or more POAs. Using operations on a POA manager, the developer can cause requests for the associated POAs to be queued or discarded. The developer can also use the POA manager to deactivate the POAs. 8. Question: Is it always necessary to run the server before the client runs? A CORBA Object reference may be transient (valid for the life time of creating process) or persistent (valid beyond the life time of the process creating the object reference). In general a server should be running by the time a client application invokes a request on the server object (or the request will fail with object_not_exist exception). There are exceptions -- for example when using an implementation repository, a server may be automatically started by the implementation repository when a request is sent to the server object. 9. Question: Why the poa pointer in above code not released/freed of memory in server(whereas objref object was released in client.cc). Does varadhi have any internal mechanism to do this? PortableServer::POA_var poa = PortableServer::POA::_narrow(obj); In C++, a CORBA Object (and local/pseudo object) reference can be stored either as a pointer or a "smart pointer". In general for a CORBA IDL type T, the type T_ptr is the pointer type for a T object and T_var is the smart pointer. When using a smart pointer object (like POA_var reference to a POA pseudo object), the reference is automatically deleted when the control reaches the end of the scope of the _var object. When the reference count for an object hits 0, the object is automatically destroyed. Any object explicitly created by the application (like an application created POA object) can be destroyed by the application. 'poa' pointer will be destroyed, when the orb is shutdown. 10. Question: What are the changes we have to make in "makefile" for running our own server and client and idl? Assuming that you have an idl file myserver.idl, client code in client.cc and server code in server.cc, you can edit the sample Makefile as follows: a) IDL file name Change the value of IDL variable in the makefile to 'myserver'. IDL=myserver b) To build the client/server with debug option (or) with some specific optimization level for size, then update CC_EXTRA_FLAGS. NOTE: If the client is not in 'client.cc', then update the CLIENT variable and if the server application name is not 'server.cc', update the SERVER variable.