Corba Fundamentals   «Prev 

CORBA comparison with distributed computing architectures?

Distributed computing consisting of Service Provider and Service User
Distributed computing consisting of Service Provider and Service User
The basic idea centers around a software component that provides some service:
  1. data retrieval,
  2. calculations,
  3. hotel reservation,
  4. service management metrics,
  5. supply chain,
  6. mobile payment
There are also other software components that wish to make use of the provider's services.
Distributed computing allows the two components, provider and user to communicate across a network.

Summary of Key Corba Features

  1. Naming Service: The CORBA naming service provides a naming structure for remote objects.
  2. Event Service: Another COS that provides a supplier-consumer communication model that creates asynchronous communication between the objects via an Event Channel. The flow of data into the Event Channel is handled by supplier objects, while the flow of data out of the event channel is handled by consumer objects. The Event Service supports both the push and pull model. In the push model, supplier objects control the flow of data by pushing it to consumers and in the pull model, consumer objects control the flow of data by pulling data from the supplier. Instead of directly communicating with each other, the supplier and consumer can each obtain a proxy object from the Event Channel and communicate with it. Supplier objects obtain a consumer proxy and the consumer objects acquire a supplier proxy.
  3. Life Cycle Service: The Life Cycle Service defines conventions for creating, deleting, copying and moving objects. Because CORBA-based environments support distributed objects, life cycle services define services and conventions that allow clients to perform life cycle operations on objects in different locations.
  4. Persistent Object Service: The Persistent Object Service (POS) provides a set of common interfaces to the mechanisms used for retaining and managing the persistent state of objects.
  5. Transaction Service: The Transaction Service supports multiple transaction models, including the flat (mandatory in the specification) and nested (optional) models.
  6. Concurrency Control Service: The Concurrency Control Service enables multiple clients to coordinate their access to shared resources. Coordinating access to a resource means that when multiple, concurrent clients access a single resource, any conflicting actions by the clients are reconciled so that the resource remains in a consistent state.
  7. Relationship Service: The Relationship Service allows entities and relationships to be explicitly represented. Entities are represented as CORBA objects. The service defines two new kinds of objects: relationships and roles. A role represents a CORBA object in a relationship. The Relationship interface can be extended to add relationshipspecific attributes and operations. In addition, relationships of arbitrary degree can be defined. Similarly, the Role interface can be extended to add role-specific attributes and operations.
  8. Externalization Service: The Externalization Service defines protocols and conventions for externalizing and internalizing objects. Externalizing an object is to record the object state in a stream of data (in memory, on a disk file, across the network, and so forth) and then be internalized into a new object in the same or a different process. The externalized object can exist for arbitrary amounts of time, be transported by means outside of the ORB, and be internalized in a different, disconnected ORB. For portability, clients can request that externalized data be stored in a file whose format is defined with the Externalization Service Specification.
  9. Query Service: The purpose of the Query Service is to allow users and objects to invoke queries on collections of other objects. The queries are declarative statements with predicates and include the ability to specify values of attributes; to invoke arbitrary operations; and to invoke other Object Services.
  10. Licensing Service: The Licensing Service provides a mechanism for producers to control the use of their intellectual property. Producers can implement the Licensing Service according to their own needs, and the needs of their customers, because the Licensing Service does not impose it own business policies or practices.
  11. Property Service: Provides the ability to dynamically associate named values with objects outside the static IDL-type system
  12. Time Service: 1) Enables the user to obtain current time together with an error estimate associated with it. 2) Ascertains the order in which "events" occurred. 3) Generates time-based events based on timers and alarms. 4) Computes the interval between two events.
  13. Security Service:The security functionality defined by this specification comprises: a) Identification and authentication of principals (human users and objects which need to operate under their own rights) to verify they are who they claim to be. b) Authorization and access control - deciding whether a principal can access an object, normally using the identity and/or other privilege attributes of the principal (such as role, groups, security clearance) and the control attributes of the target object (stating which principals, or principals with which attributes) can access it.
    c) Security auditing to make users accountable for their security related actions. It is normally the human user who should be accountable. Auditing mechanisms should be able to identify the user correctly, even after a chain of calls through many objects.
    d) Security of communication between objects, which is often over insecure lower layer communications. This requires trust to be established between the client and target, which may require authentication of clients to targets and authentication of targets to clients. It also requires integrity protection and (optionally) confidentiality protection of messages in transit between objects. e) Non-repudiation provides irrefutable evidence of actions such as proof of origin of data to the recipient, or proof of receipt of data to the sender to protect against subsequent attempts to falsely deny the receiving or sending of the data. f) Administration of security information (for example, security policy) is also needed.
  14. Object Trader Service: The Object Trader Service provides a matchmaking service for objects. The Service Provider registers the availability of the service by invoking an export operation on the trader, passing as parameters information about the offered service. The export operation carries an object reference that can be used by a client to invoke operations on the advertised services, a description of the type of the offered service (i.e., the names of the operations to which it will respond, along with their parameter and result types), information on the distinguishing attributes of the offered service
  15. (P63)
  16. Object Collections Service: Collections are groups of objects which, as a group, support some operations and exhibit specific behaviors that are related to the nature of the collection rather than to the type of object they contain. Examples of collections are sets, queues, stacks, lists, binary, and trees. The purpose of the Collection Object Service is to provide a uniform way to create and manipulate the most common collections generically.