Chapter 17: CORBA case study - PowerPoint PPT Presentation

chapter 17 corba case study n.
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 17: CORBA case study PowerPoint Presentation
Download Presentation
Chapter 17: CORBA case study

play fullscreen
1 / 34
Chapter 17: CORBA case study
Download Presentation
Download Presentation

Chapter 17: CORBA case study

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Chapter 17: CORBA case study By Carrie Mace and William Coley

  2. What is CORBA ? • CORBA is a middleware design • Allows application programs to communicate without restriction to: • Programming languages • Hardware platforms • Software platforms • Networks they communicate over

  3. Applications and CORBA • Applications are built from CORBA objects • Objects implement interfaces defined in CORBA’s interface definition language(IDL) • Clients use remote method invocation to access methods in the interface design language • The Object Request Broker is the middleware component that supports remote method invocation

  4. Main Components of CORBA’s RMI framework • CORBA IDL (Interface Definition Language) • CORBA architecture • GIOP (General Inter-ORB Protocol) - defines external data representation • IIOP - defining a standard form for remote object references

  5. CORBA architecture Implementation repository interface repository server client request ORB core object adapter servant A skeleton ORB core client program Proxy for A reply Or dynamic skeleton Or dynamic invocation Figure 17.6 from the textbook: The Main Components of the CORBA architecture

  6. Object Request Broker Core • Carries out the request-reply protocol • Provides an interface that includes: • Operations enabling start and stop • Operations to convert between remote objects and strings • Operations to provide argument lists for references using dynamic invocation

  7. Object Adapter • Bridges the gap between CORBA objects with IDL interfaces and the programming language interfaces of the corresponding servant. • Creates remote object interfaces • Dispatches each RMI to the appropriate skeleton • Activates objects • Gives each object a unique object name

  8. Skeletons • Classes generated in the language of the server by an IDL compiler • Unmarshals arguments in requests • Marshals exceptions and replies in responses

  9. Client stubs/proxies • In the client’s language • Marshals the arguments in invocation requests • Unmarshals the exceptions and results in replies

  10. Implementation Repository • Responsible for activating registered servers on demand • Locates servers currently running • Uses the object adapter name to refer to servers when registering or activating them Implementation Repository entry: Pathname of object implementation Hostname and port number of server Object adapter name

  11. Interface Repository • Provides information about registered IDL interfaces to clients and servers that require it • Not required if static invocation is used for client stubs and server skeletons • Not all Object Request Brokers provide an interface repository

  12. Dynamic Invocation Interface • Used when not practical to use proxies • Client may not have the appropriate proxy class to invoke a remote service • The client can obtain from the interface repository the needed information to construct an invocation

  13. Dynamic Skeleton Interface • Allows the CORBA object to accept invocations when a skeleton doesn’t exist • Perhaps the interface was unknown at compile time • Inspects the request for target object, method to be invoked, and arguments

  14. CORBA architecture Implementation repository interface repository server client request ORB core object adapter servant A skeleton ORB core client program Proxy for A reply Or dynamic skeleton Or dynamic invocation Figure 17.6 from the textbook: The Main Components of the CORBA architecture

  15. CORBA: Interface Definition Language • Defines modules, interfaces, types, attributes and method signatures • Same lexical rules as C++ • Has additional keywords to support distribution (i.e. interface, any, attribute, in, out, inout, readonly, raises)

  16. IDL Modules • Allows interfaces and IDL type definitions to be organized into logical units • Defines a naming scope • Prevents names defined within a module from clashing with names defined outside of it

  17. IDL Interfaces • Describes the methods that are available in CORBA objects that implement that interface • Defines a set of operations and attributes • Generally depends on a set of types defined within it

  18. IDL Methods • General form of a method signature: [oneway]<return_type><method_name> (parameter1,…,parameterL)[raises(except1,…,exceptN)][context(name1,…,nameM)]

  19. IDL Methods Continued • Parameters labeled as in are passed to the invoked object • Parameters labeled as out are to be returned to the client • Parameters labeled as inout are seldom used

  20. IDL Methods Continued • Return type may be void if no value is to be returned • The expression oneway is optional. Made with maybe semantics Indicates client is not blocked • The expression raises is optional Indicates user-defined exceptions • The expression context is also optional Supplies mappings from string names to string values

  21. IDL Types • Supports 15 primitive types • Constants can be declared • Special type called Object • values are remote object references • 6 constructed types, all passed by value • arrays and sequences used as arguments must be defined in typedefs • No data type can contain references

  22. Attributes of IDL interfaces • Attributes are private to CORBA objects • Each attribute declared results in the IDL compiler generating methods to retrieve and set the attribute • Attributes can be readonly • Only the retrieve method is generated by the IDL compiler

  23. IDL interfaces: Inheritance • Extended interfaces can redefine types, constants, and exceptions • Not allowed to redefine methods • Can extend more than one interface • An interface may not inherit methods or attributes with common names from two different interfaces

  24. How Legacy Code is Handled • Legacy code is existing code designed without distributed objects in mind • Legacy code can become a CORBA object by • Defining an IDL interface for the code • Providing implementation of the object adaptor and skeletons

  25. CORBA Remote Object References • IOR: Interoperable Object References • Defined in CORBA 2.0 • Format: protocol and address details IDL interface type Object Key Interface repository identifier adapter name object name host domain name port number IIOP • Transient IORs last as long as the hosting process. • Persistent IORs last between activations of the CORBA objects.

  26. CORBA Services • Provide generic facilities that may be used by a wide variety of applications • Naming Service • Event and Notification Service • Security Service • Transaction and Concurrency Services • Trading Services • Persistent Object Service

  27. Naming Service • Allows names to be bound to the remote object references • A naming context is the scope within which a set of names applies • CORBA objects are given hierarchical names, which cannot be used as pathnames • Allows for the Federation of Naming Services. • Each server provides a subset of the naming graph

  28. CORBA Event Service • Defines interfaces allowing objects of interest to communicate notifications to subscribers • Event channels: allow multiple suppliers to communicate with multiple consumers in an asynchronous manner

  29. CORBANotification Service • Extends the CORBA Event Service • Notifications may be data structures • Consumers may use filters • Suppliers may discover what events consumers are interested in • Possible to configure the properties of a channel, a proxy, or an event

  30. CORBASecurity Service • Authentication of users and servers • Access controls can be applied to CORBA objects • Auditing by servers of remote method invocations • Facilities of non-repudiation • Verifies an invocation was carried out

  31. Trading Services • Allows CORBA objects to be located by attributes • Database contains mapping from service types and their attributes to the remote object reference of CORBA objects • Can form federations that • Use their own database • Can perform queries on behalf of other clients

  32. Concurrency and Transaction Services • Allows distributed CORBA objects to participate in flat and nested transactions • RMI calls are introduced with begin, commit or rollback • Clients can suspend or resume transactions • Concurrency control services use locks to control access to CORBA object • Can be used within transactions • Can be used independent of transactions

  33. Persistent Object Service • Suitable for use as a persistent object store for CORBA objects • Can be implemented using • Files • A Relational Database System • An Object-Oriented Database System • The data store request to the POS can be implemented by the client or by the CORBA object

  34. More Information • • • •