1 / 52

Introduction to CORBA

Introduction to CORBA. Organizational Communications and Technologies Prithvi N. Rao H. John Heinz III School of Public Policy and Management Carnegie Mellon University. Readings. Posting on the Class Web Site. Objectives. Examine features of an ORB Present the use of an IDL

fawzia
Download Presentation

Introduction to CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to CORBA Organizational Communications and Technologies Prithvi N. Rao H. John Heinz III School of Public Policy and Management Carnegie Mellon University

  2. Readings Posting on the Class Web Site

  3. Objectives • Examine features of an ORB • Present the use of an IDL • Present the creation and activation of an object implementation • Present a simple client implementation

  4. Problems Addressed by CORBA • Platform and language dependent software • Software still specific to hardware platforms • Software specific to language • Leads to software legacy that is expensive to change • Cannot easily use software from other developers • Monolithic applications • Can have lots of “useless” features • Can take up valuable memory resources to run basic features of application

  5. Plug and Play Components • Goal is to combine software components written in various languages • Goal to move away from monolithic applications • Discrete components contain required features • Goal towards smart components • Versioning • Security and self testing

  6. API and the Software Bus • Bus is a framework into which components can be plugged • Permits components to talk to each other • Similar to the hardware bus • Application Programmer’s Interface (API) is an attempt to provide a software bus • Current APIs are still language specific • Current

  7. Goals of Object Management Group (OMG) • Reduce complexity and accelerate development time • Increase reusability, interoperability and portability

  8. Interoperability Interoperability is the ability of a component to be invoked across networks, languages, operating systems and tools. For CORBA interoperability means the ability of objects and applications to exchange requests via ORBs. i.e. the ability to make requests and respond to requests on the same machine or across a network that uses the CORBA standard

  9. Reusability Reusability is the ability of a system to grow functionality through the extension of existing components and the ability to combine existing components in new ways in order to create new components

  10. Portability Portability is the ability to transfer a program from one hardware and /or software environment to another.

  11. CORBA Services • Augment the core CORBA capabilities that make it possible for developers to share objects, component and applications • Object creation • Control access to objectsExamples are persistence service, naming service, transaction service and many others.

  12. CORBA Domains • Provide capabilities for developing applications in specific areas • Medicine • Telecommunications • FinanceGoal is to provide a specification of how to architect objects and components for domain specific applications.

  13. Object Management Architecture CORBA Facilities CORBA Domains CORBA Applications Common Object Request Broker Architecture (CORBA) CORBA Services

  14. The CORBA ORB • ORB is • Software that enables communication between distributed heterogeneous applications • Software located between servers and clients that permits them to communicate An ORB allows applications to communicate with one another no matter where they are located or what kind of system on which they run.

  15. Client A client is an object component or application that makes requests for services from other objects, components, or applications (also called implementation objects or servers). A given object or, component or application can be a client for some requests and a server for other requests. The client is not part of the ORB but uses the ORB

  16. Server (object implementation) A server (also called an object implementation) also provides a response to requests for services from other objects, components or applications. A given object, component or application can be a server for some requests and a client for other requests. Servers are not part of the ORB

  17. The ORB Core • Responsible for communicating requests and encompasses the entire infrastructure required • Identify and locate objects • Handle connection administration • Deliver data

  18. CORBA (revisited) client server Dynamic Invocation Interface (DII) IDL Client Stub IDL Server Skeleton Dynamic Skeleton interface ORB Interface ORB Interface Object adapter ORB Core ORB Core IIOP

  19. Internet Inter-ORB Protocol (IIOP) • Standard protocol for communication between ORBs on TCP/IP based networks • ORBs must support IIOP in order to be ORB compliant • Can support other protocols but IIOP must be supported for compliancy

  20. IDL Client Stubs • Client stub generated by the IDL compiler • Permits the client to invoke an implementation object’s services • Client stubs using the IDL are static • Also considered stodgy • Alternative is the dynamic invocation interface (DII)

  21. Dynamic Invocation Interface (DII) • Defines client side of interface that allows dynamic creation and invocation of requests to objects • DII offers a non-static way to invoke server operations

  22. IDL Server Skeletons • Compiler generates IDL server skeletons • Code providing means by which server’s operation can be accessed

  23. Dynamic Skeleton Interface (DSI) • Provides run-time binding mechanism for servers not statically defined at compilation • DSI is similar to DII • Looks at parameter values of incoming requests and determines target object • Determines target operation

  24. Object Adapter • Primary mechanism by which server object has access to ORB services • Performs several functions • Generates object references • Invokes methods • Basic security

  25. ORB Interface • Collection of operations providing services common to object implementations and clients • ORB initialization and facilities to obtain necessary object references • Contains functions regardless of which ObjectAdapter is used

  26. Steps to Creating a CORBA Application (Static) • Thorough OO analysis and design to determine distributed objects • Use static IDL to describe objects and compile the IDL file • Write a target language implementation • Write a main program that instantiates implementation objects • Write client applications that use implementation objects • Compile all source files (stubs, skeletons) and link executable • Run the ORBs and clients after starting the servers first

  27. Object Request Broker Interfaces • ORB can be a single component or a collection of components • Vendor dependent • ORB interface is the intermediary between objects and ORB i.e • object_to_string() converts object reference to a string • resolve_initial_reference() finds well-known server objects • string-to-object() converts a string to an object reference • BOA_init() returns an object that is a Basic Object Adapter

  28. Interesting ORB flavors • Client and implementation • Resides in the client application • Server-based • Exists in separate process • Routes communications between clients and object implementations • System-based • Server-like but ORB is part of OS • Enhances security

  29. Object Identification • Identify an object by • Requesting an object reference • Name method to be invoked • Using all parameters required for method • Return value for the method in call status = foo.getPassword(“John”);

  30. object_to_string() • String reference to an object implementation can be created • Client can read the string and use the method string_to_object to convert reference to object

  31. Directory Server • Some objects contain methods that return other object references • Client must know the reference to one of these objects in order to get access to references to other objects • Client uses the reference to the directory object and calls a method with the name of a service that it requires

  32. Naming Service • Used for registering their object references and names • Clients look up a known name to get object reference • Naming context is like a disk drive • Naming component is like a file • Have a root context

  33. Using the Naming Service • Locate Naming Service root context server objectresolve_initial_reference(“NameService”); • Narrow returned object to a Naming Context object • Do some error checking • Create a Name for the Naming Context • Create Naming context using root context • Repeat step 5 above • Add the Name Component with the bind() operation

  34. resolve_initial_references() • Interface can resolve several key ORB interfaces including the Naming Service • Can call service’s methods in order to locate other servers that have registered with the service

  35. Turning Method Calls into Requests • Client obtains an object reference for server • Client packages reference along with method name, parameters andtype of return value • Client executes server’s method by calling corresponding method inclient stub • Inside client stub call is turned into request • ORB interface operation is called to pass newly created request to ORB

  36. CORBA (revisited) client server Client method call 3 4 IDL Client Stub IDL Server Skeleton Object adapter ORB Core ORB Core 1 IIOP 2

  37. Describing Objects with IDL • Interface Definition Language is basis for object definition • Language independent way to define objects • Independent of OS and hardware platform • Permits design portability • Use IDL to define objects and modules making up applications • Creates stubs and skeletons

  38. Precursor to IDL • Must know what objects are • Must know name of each object • Must know data that objects deal with • Must know what each object is supposed to do

  39. IDL Elements • Data Type • Description of accepted values for return values parameters etc. • Operations • Action that object performs or service a client can invoke • Signature of a method • Interface • Defines an object’s data and its operations • Module • Group of interfaces

  40. Example in Java In the real world it is likely that an application developer will be handed several completely implemented server classes that are written in Java. The application developer is required to write the server application and some client applications that use them. Need to know the desired activation policy Need to know the constructor parameters for one or more server objects We will look at the persistence server policy in this example. This means that once the server is activated it will wait forever for client connections.

  41. Procedure • Decide on a server activation policy and write a server application inJava. • Look in the implementation class source code for server objects. • Examine the interface definition language file for server objects todetermine their interfaces • Write client(s) in Java or other language

  42. Persistent Server • Implemented as a standalone application • In java it is a class with a main() method • Activation policy is a procedure by which server object is made ready to process method calls from clients • Decide on a server activation policy • Identify which server objects must be created • Decide how to make server object reference available

  43. Persistent Server • Import server object implementation class and other needed classes • Create a class that has a single main() method • In the main() method (inside a try block) initialize the ORB • Create initial instance of desired server object(s) • Make reference to server object available to client applications • Wait for client application

  44. Server Activation import PortfolioBrokerImplementation;import org.omg.CORBA.ORB; import org.omg.CORBA.objectimport org.omg.CosNaming.NameComponent;import org.omg.CosNaming.NameHolder;import org.omg.CORBA.SystemException;import SimpleNames;public final class JavaServer { public static void main(String args[]) { try { ORB orb = new ORB.init(args, null); ORB myOrb = new ORB(); myOrb.init(args, null);

  45. Creating an Instance of a Server • PortfolioBrokerImplementation broker; • broker = new PortfolioBrokerImplementation(); • orb.connect((Object)broker); • Create an instance of a server using new • Use orb.connect() to tell the ORB that the server is readyNo need to do an orb.connect() more than once for a persistent server activation policy

  46. Using the Naming Service • Have a server object ready to name • Place the name into an array of NameComponent objects • Use the SimpleNames.bindToName() static object method to bind the object to the name

  47. Steps for Server NameComponent myName[] = new NameComponent[3];myName[0] = new NameComponent(“Examples”, “OC&T”);myName[1] = new NameComponent(“src”, “OC&T”);if (!SimpleNames.bindToName(orb, (Object)broker, myName)){ return;}

  48. Server Epilogue try { Thread.currentThread.join(); } catch(InterrruptedException e1) { System.exit(1); } } catch(SystemException e2) { System.exit(1); } }}

  49. Writing a Client Import Portfolio.PortfolioBroker;import org.omg.CORBA.ORB;import org.omg.CORBA.Object;import org.omg.CosNaming.NameComponent;import org.omg.CORBA.SystemException;import SimpleNames;public final class FindBrokerFn { public final static PortFolioBroker FindBroker(ORB orb) { Object obj; PortFolioBroker Broker = null; try {

  50. Writing a Client NameComponent name[] = new NameComponent[3];name[0] = new NameComponent(“Example”, “OC&T”); Name[1] = new NameComponent(“src”, “OC&T”);obj = SimpleNames.getReference(orb, name); Broker = PortfolioBrokerHelper.narrow(obj);}catch(SystemException e1) { Broker = null;}

More Related