1. Naming Service 1 Common Principles  Object-oriented middleware uses object references to address server objects  We need to find a way to get hold of these object references without assuming physical locations  A name is a sequence of character strings that can be bound to an object reference  A name binding can be resolved to obtain the object reference

2. Naming Service 2 Common Principles  There may be many server objects in a distributed object system  Server objects may have several names  Leads to large number of name bindings  Name space has to be arranged in a hierarchy to avoid  Name clashes  Poor performance when binding/resolving names  Hierarchy achieved by naming contexts

3. Naming Service 3 Common Principles: Naming Contexts Cup Winners Cup Winners 1.FC Kaiserslautern 1.FC Kaiserslautern Premier First Man United Chelsea QPR South End United South End United England Germany 1. Liga 2. Liga BVB Bayern Bochum Lautern UEFA Manchester United Manchester United

4. Naming Service 4 Common Principles: Composite Names  Names are composed of possibly more than one component  Used to describe traversals across several naming contexts  Example: ("UEFA","England","Premier","Chelsea").

5. Naming Service 5 Common Principles: Name Server Behaviour  Name bindings are managed by name servers  Not every server object needs a name  Server objects may have several names (aliases)  Name servers must store bindings persistently  Name servers should be tuned towards efficiently resolving name bindings  Name server may itself be distributed

6. Naming Service 6 CORBA Naming Service  Supports bindings of names to CORBA object references.  Names are scoped in naming contexts.  Multiple names can be defined for object references.  Not all object references need names.  The CORBA naming service is used by  Clients to locate CORBA objects  Servers to advertise specific CORBA objects  Bootstrap service, enabling clients to find other services  Facilitate the initial connections between clients and servers  Basic function: association of names with object references

7. Naming Service 7  Server creates associations between names and object references for the CORBA objects (object binding)  Client retrieve the object references by querying the naming service and using the name as the key.  NS: a database of object bindings

8. Naming Service 8 Client Server 1. Create binding 2. resolve 3. Use target object

9. Naming Service 9 Binding Hierarchy  Context binding: an association between a name and a naming context  Object binding: an association between a name and an object reference Initial Naming Service London. region New_York.region Frankfurt.region Bankup.failover Main.failover StockExchange BrokerService

10. Naming Service 10 Components of a Stringified Name Stringified NameBinds to Empty stringInitial naming context London.regionNaming context London.region/Main.failoverNaming context London.region/Main.failover/StockExchangeObject reference  Initial naming context is always present and serves as the entry point to the naming service

11. Naming Service 11 CORBA Names  Names are composed of simple names.  Simple names are value-kind pairs.  Value attribute is used for resolving names.  Kind attribute is used to provide information about the role of the object.

12. Naming Service 12 CORBA Name  Name has two format:  Stringified name format: intuitive format that is easy to read and pass from place to place London.region/Main.failover/StockExchange  Raw name format: defined in terms of IDL complex types and can be used only within a CORBA program Module CosNaming { typedef string Istring; struct NameComponent { Istring id; Istring kind; }; typedef sequence Name; … };

13. Naming Service 13 CORBA Name  Kind field is intended to describe how a name component is used (similar to the file extension, client.exe)  Special cases:  empty kind field (omitting kind and kind separator “.”)  Empty id field (starting the name component with “.”)  Empty id field and empty kind field (denoted by “.”)  Example:././.

14. Naming Service 14 The IDL Interfaces  Naming Service is specified by two IDL interfaces:  NamingContext defines operations to bind objects to names and resolve name bindings.  BindingInterator defines operations to iterate over a set of names defined in a naming context.

15. Naming Service 15 Binding Module cosNaming{ enum BindingType{nobject, ncontext}; struct Binding{ Name binding_name; BindingType binding_type; }; typedef sequence BindingList; };

16. Naming Service 16 Binding and Unbinding Operations Module cosNaming{ interface NamingContext{ void bind(in Name n, in Object obj) raise(NotFound, InvalidName, AlreadyBound, CannotProceed); void rebind( in Name n, in Object obj) raise(NotFound, InvalidName, CannotProceed); void bind_context(in Name n, in NamingContext nc) raise(NotFound, InvalidName, AlreadyBound, CannotProceed); void rebind_context(in Name n, in NamingContext nc) raise(NotFound, InvalidName, CannotProceed); void unbind(in Name n) raise(NotFound, InvalidName, CannotProceed); };

17. Naming Service 17 bind() and rebind()  Both operations create an object binding that associates the name n (in raw format) with the naming context nc.  Rebind(): it creates a new object binding for the given name n or if a binding already exists with that name, overwrites the existing binding.  Bind(): it creates a new object binding for the given name n as long as there is no existing binding with that name. If a binding already exists, an AlreadyBound exception is thrown.  These operations create object bindings relative to the naming context on which they are invoked.  Example: A/B/C/MyObj on initial naming context, or MyObj on A/B/C naming context

18. Naming Service 18 bind_context() and rebind_context()  Parameter is context  Similar semantics as bind() and re_bind()

19. Naming Service 19 Create Context Module cosNaming{ //interface NamingContext{ NamingContext new_context(); NamingContext bind_new_context(in Name n); raise(NotFound, InvalidName, AlreadyBound, CannotProceed); //}; };  A naming context can be created (new_context()) and then be binded (bind_context())  Bind_new_context() creates a new context and binds it as a subcontext of the context on which the operation is invoked.

20. Naming Service 20 Before Binding Context1 Context5Context4 Context3Context2

21. Naming Service 21 After Binding Context1 Context5Context4 Context3Context2 MyName IOR of Object

22. Naming Service 22 Naming Scenario: Binding Promote Bielefeld to German '1. Liga' and relegate Frankfurt 1L=resolve("UEFA","Germany","1. Liga") root: Naming Contextc:Client1L:NamingContext bind("Arm. Bielefeld", bielefeld) unbind("Eintr. Frankfurt")

23. Naming Service 23 Resolve Names Module cosNaming{ //interface NamingContext{ Object resolve(in Name n) raise(NotFound, InvalidName, CannotProceed); //}; };  It resolves the first component of the name to an object reference.  If there are no remaining components, it returns this object reference to the caller.  Otherwise, it narrows the object reference to a NamingContext and passes the reminder of the name to its resolve operation

24. Naming Service 24 NotFound Exception Module cosNaming{ … interface NamingContext{ … enum NotFoundReason {missing_node, not_context, not_object}; exception NotFound { NotFoundReason why; Name rest_of_name; };

25. Naming Service 25 Browsing Contexts Module cosNaming{ //interface NamingContext{ interface BindingIterator { boolean next_one(out Binding b); boolean next_n(in unsigned long how_many, out BindingList bl); void destroy(); }; void list (in unsigned long how_many, out BindlingList bl, out BindingIterator bi); //}; };

26. Naming Service 26 Converting Names: NamingContextExt Module cosNaming{ interface NamingContextExt:NamingContext{ typedef string StringName; typedef string Address; typedef string URLString; StringName to_string(in Name n) raises (InvalidName); Name to_name(in StringName sn) raises (InvalidNames); URLString to_url(in Address addrKey, in StringName sn) raises(InvalidAddress, InvalidName); Object resolve_str(in StringName sn) raises(NotFound, CannotProceed, InvalidName); };

27. Naming Service 27 Federated Naming Service  Naming service supports federation: distinct naming servers can be linked together to create a single naming graph.  A client can then navigate seamlessly throughout the naming graph without being aware that it is federated.  The support is through bind_context()  Graph or hierarchy?  Cycles in the graph

28. Naming Service 28 Federated Naming Service A B C Naming Service X Naming Service Y

29. Naming Service 29 Federated Naming Service A B U V Context A can be accessed by: A, A/B/V/U/A, or A/B/V/U/A/B/U/V/A Avoid infinite loop

30. Naming Service 30 Building Applications Using CORBA  Room booking system:  Booking rooms for meetings for a duration (from 9:00 am to 4:00 pm by hour);  Canceling the bookings  The number and names of rooms can change  When booking a room, a purpose and the name of the person making the booking should be given  System design decisions:  Rooms and meetings are CORBA objects  A meeting object defines a purpose and the person responsible for the meeting  A meeting factory creates meeting objects  A room stores meetings indexed by time slots  Room have a name and register themselves under this name with the Naming Service

31. Naming Service 31 Room Booking System MeetingFactoryImpl MeetingImpl MeetingFactoryServer NamingContext CORBA Naming Service RoomImpl RoomServer RoomImpl RoomServer RoomImpl RoomServer Proxy Client Application CreateMeeting() bind() resolve() view() book() cancelBooking() bind()

32. Naming Service 32 Room Booking Naming Convention Root Naming Context BuildingApplications Rooms Context Object Board Room Meeting Room Chairmen’s Office Object Name Meeting Factory

33. Naming Service 33 Source Code  Chapter 8  Client  ClientApplication.java (“main”)  RoomBookingClient.java (“Impl”)  Server  Room –RoomServer.java –RoomImpl.java  MeetingFactory –MeetingFactoryServer.java –MeetingFactoryImpl.java  Meeting –MeetingImpl.java

34. Naming Service 34 Source Code  Client  ClientApplication.java (“main”)  Create “impl” client = RoomBookingClient();  Initialize NS: client.init_from_ns();  View existing bookings: client.view()  RoomBookingClient (“impl”)  Private: –orb, root_context, room_context, meeting_factory, rooms, meetings, booked, ior  Constructor: –Initialize orb –Get root_context  Init_from_ns: –From root_context get room_context –From root_context get meeting_factory  View: –Get rooms, –List meetings

35. Naming Service 35 Source Code  Server  Room  RoomServer.java –Initialize ORB orb = ORB.init( args, null ); POA poa = POAHelper.narrow( orb.resolve_initial_references( "RootPOA")); poa.the_POAManager().activate(); –Create room object and export the object reference org.omg.CORBA.Object room_obj = poa.servant_to_reference ( new RoomImpl( args[0] ) ); –Register with naming service NamingContextExt root = NamingContextExtHelper.narrow ( orb.resolve_initial_references("NameService")); root.bind_new_context( root.to_name( context_name )); str_name = context_name + "/" + args[0]; root.bind( root.to_name( str_name), room_obj ); –Wait for request orb.run();

36. Naming Service 36 Source Code  Server  Room  RoomImpl.java –Inherit from RoomPOA public class RoomImpl extends RoomPOA –Implement all the operations declared in the idl: »Attributes »View »Book »Cancelbooking

37. Naming Service 37 Source Code  Server  MeetingFactory  MeetingFactoryServer.java –Initialize ORB orb = ORB.init( args, null ); POA poa = POAHelper.narrow( orb.resolve_initial_references( "RootPOA")); poa.the_POAManager().activate(); –Create room object and export the object reference org.omg.CORBA.Object meeting_factory_obj = poa.servant_to_reference ( new MeetingFactoryImpl( ) ); –Register with naming service NamingContextExt root = NamingContextExtHelper.narrow ( orb.resolve_initial_references("NameService")); root.bind_new_context( root.to_name( context_name )); str_name = context_name + "/" + args[0]; root.bind( root.to_name( str_name), meeting_factory_obj ); –Wait for request orb.run();

38. Naming Service 38 Source Code  Server  MeetingFactory  MeetingFactoryImpl.java –Inherit from MeetingFactoryPOA public class MeetingFactoryImpl extends MeetingFactoryPOA –Implement all the operations declared in the idl: »createMeeting MeetingImpl meetingImpl = new MeetingImpl(purpose, participants); try { org.omg.CORBA.Object obj = _poa().servant_to_reference(meetingImpl); Meeting meeting = MeetingHelper.narrow(obj); return meeting; } …

39. Naming Service 39 Source Code  Server  Meeting  MeetingImpl.java –Inherit from MeetingPOA public class MeetingImpl extends MeetingPOA –Implement all the operations declared in the idl: »Attributes »Destory  Not all Corba objects need to be registered with NS  servant_to_reference(meetingImpl) is done by other entity (MeetingFactoryImpl)

40. Naming Service 40 Limitations of Naming Service  Limitation of Naming in all approaches: Client always has to identify the server by name.  Inappropriate if client just wants to use a service at a certain quality but does not know from who:  Automatic cinema ticketing,  Video on demand,  Electronic commerce.