1 / 34

Java/CORBA

Java/CORBA. CSE525. CORBA. CORBA stands for Common Object Request Broker Architecture It is the product of a consortium called the Object Management Group (OMG) over 800 companies does not include Microsoft which has its own competing architecture DCOM (Distributed Component Object Model).

reese
Télécharger la présentation

Java/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. Java/CORBA CSE525

  2. CORBA • CORBA stands for Common Object Request Broker Architecture • It is the product of a consortium called the Object Management Group (OMG) • over 800 companies • does not include Microsoft which has its own competing architecture DCOM (Distributed Component Object Model)

  3. CORBA • CORBA defines how software components should be built and how they can interoperate. By choosing CORBA one chooses an open field for distributed computing. • CORBA is middleware; that is, software that bridges clients and servers supporting discovery and communication of distributed objects - often called a “software bus”

  4. CORBA • CORBA provides both • object interoperability (bus) standards • bus services: create objects, delete objects, … • Success of OMG/CORBA is that they create specifications…NOT CODE and they combine this with a requirement that the specification have a demonstrable implementation

  5. CORBA OBJECTS • binary components that can exist anywhere on a network. • remote clients may access these objects via method invocation. • location of component transparent to the client. • implementation language of the server object is unknown to the client.

  6. Language independence • In order to achieve programming language independence the client must know the interface that the service offers. The interface is a contract between client and server. If you advertise a method then you will respond as advertised. • BUT WHAT LANGUAGE FOR THE INTERFACE?

  7. The Interface Definition Language (IDL) • CORBA specifies a language called IDL. • IDL is a purely declarative language, there are no control constructs associated with the language. • An IDL specification can be translated into a C++ header file, a Java interface, an ADA specification, a Smalltalk …., an ObjectiveC ...

  8. IDL • IDL must specify • a components attributes • parent classes it inherits from • exceptions it raises • events it emits • methods it supports including parameters, returns and their types.

  9. IDL • IDL must provide the lowest common denominator (greatest number of common features) of all languages to which IDL can be translated. • IDL is largely influenced by C++

  10. The Bus Architecture

  11. In 1990 the OMG published the Object Management Architecture guide. Revised in 1992 and again in 1995 the main components of the architecture are: • Object Request Broker: • defines the object bus • CORBA services: • defines the system-level framework to deal with the bus. • CORBA facilities • horizontal and vertical application frameworks • Application Objects • consumers of CORBA

  12. The Object Resource Broker (ORB) • This software lets object make requests to and receive responses from other objects located locally or remotely. • VERSIONS • CORBA 1.1 only specified IDL and APIs for interfacing to the ORB • CORBA 2.0 specified interoperability across vendor ORBs

  13. ORBs ORBs must provide • support for static method invocation (compile time determination of method called) or dynamic method invocation (discovery at runtime of the methods offered by an object). • provide an Interface Repository that provides information to other ORBs

  14. An Example • Step 1 : Write the interface. module HelloApp interface Hello { string sayHello(); }; }; • Run a program that translates the IDL to the target language

  15. IDL to Java • The CORBA/Java standards define • the map from IDL to Java • a Java to IDL mapping (to allow RMI to migrate to CORBA) • relationships between IDL and “beans”

  16. Major Java/Corba players The big three are • Visibroker for Java • OrbixWeb • Java IDL

  17. JavaSoft’s IDL • Currently the Java IDL supports both static and dynamic CORBA invocations, but it does not support the “Interface Repository” which is a run-time distributed database that contains the metadata required by ORBs to provide unique and globally identifiable components among multivendor ORBs.

  18. JavaSoft’s IDL Because this ORB comes free with Java 1.2, we include and discuss its usage. • The program “idltojava” translates the idl into a java interface class along with classes that provide for a server skeleton, a client stub, helper classes that contain methods to deal with Corba objects and a class that provides support of “out” and “in-out” parameters which are a part of IDL, but not easily dealt with in Java.

  19. idltojava idltojava -fno-cpp Hello.idl produces 5 files in a subdirectory HelloApp: • Hello.java this is the Java interface version of the IDL. The class extends org.omg.CORBA.object so that CORBA object functionality ispresent • _HelloImplBase.java an abstract class that provides functionality for the server. • _HelloStub.java the client stub that implements the Hello.java interface.

  20. idltojava • HelloHelper.java providing functionality required to cast CORBA object references to their correct type. • HelloHolder.java providing the operations for out, inout arguments which are foreign to Java semantics • The subdirectory containing these files corresponds to the idl module translated into a java package (directory)

  21. RMI vs CORBA • As with RMI, the classes generated are of little concern to the programmer, but do provide the information and run time support for dynamic invocation. The programmer’s concern is the client and the server.

  22. Writing the Client • Import the packages required by the client import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CORBA.*; • declare the client class public class HelloClient { // the main goes here // }

  23. Main program • The main sets up a try-catch block try { //client code } catch(Exception e) { System.out.println(“Error:” + e); e.printStackTrace(System.out); }

  24. Client code • The client needs an ORB ORB orb = ORB.init(args,null); • Orb is asked to locate the object it needs. As with RMI, a naming service will provide this information. org.omg.CORBA.Object objref = orb.resolve_initial_references(“NameService”);

  25. Client code • The naming service object is a generic CORBA object and must be “narrowed” to the correct type. The HelloHelper class is being used here. NamingContext ncRef = NamingContextHelper.narrow(objRef); • Now the goal is to use the naming service object to get a reference to the remote object.

  26. Client code • getting the object requires using the naming service’s method “resolve” which requires a parameter of type NameComponent[]. So we need to first create a NameComponent NameComponent nc = new NameComponent( “Hello” , “”); NameComponent path[] = {nc};

  27. Client code • Now we can get the reference we need Hello helloRef = HelloHelper.narrow( ncRef.resolve(path)); • From this point on the helloRef acts as a local object. String Hello = helloRef.sayHello(); System.out.println(Hello);

  28. Developing the Server • Import the packages required import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*;

  29. Developing the Server • Declare the Class to implement the interface public class HelloServant extends _HelloImplBase { public String sayHello() { return “\nHello world\n”; }

  30. Developing the Server • Now declare the Server Class public class HelloServer { static public void main(String args[]) { try { //server code goes here } catch(Exception e) { System.err.println(“Error: “+ e); e.printStackTrace(System.out); }

  31. Developing the Server • The server also needs an ORB ORB orb = ORB.init(args,null); • Now create an instance of the HelloServant class to do the work HelloServant helloRef = new HelloServant(); • and connect the servant to the ORB orb.connect(helloRef);

  32. Developing the Server • The server needs to register with the naming service…but first get this service org.omb.CORBA.Object objRef = orb.resolve_initial_references(“NamingService”) NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent (“Hello”,””);

  33. Developing the Server NameComponent path[] = {nc}; • Now register ncRef.rebind(path,helloRef); • and set up a wait to give the service synchronized(sync) { sync.wait(); }

  34. Running the client & server • Start the Java IDL name server tnameserv -ORBInitialPort 32767 & The default port is 900, but only superusers can initiate services on ports under 1024. • Start the server java HelloServer -ORBInitialPort 32767 & • Run the client java HelloClient -ORBInitialPort 32767

More Related