1 / 34

Chapter 17: CORBA case study

Chapter 17: CORBA case study. By Carrie Mace and William Coley. 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.

aveline
Download Presentation

Chapter 17: CORBA case study

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. 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 • http://htm4.ee.queensu.ca:8000/ling/corba.html • http://www.omg.org/gettingstarted/corbafaq.htm • http://www.cs.indiana.edu/hyplan/kksiazek/tuto.html • http://www.cs.wustl.edu/~schmidt/corba.html

More Related