Corba Interview Questions

Page 1, Page 2

UNDER WHAT CONDITIONS IS DSI APPROPRIATE?

The dynamic nature of DSI provides certain advantages over static request dispatching. The following types of applications would require or benefit from DSI: Server side bridges (protocol converters) Monitoring applications Interpreted or script driven services Applications which utilize DSI do not need to include or import skeletons generated by an IDL compiler in order to provide a service. These serices can support request generically and must enforce type safety.

WHAT IS AN ANY?

An any is an IDL type that can represent “any” other IDL type. An any is the most abstract type. It requires runtime information to determine what type (and value) it really is.

HOW DOES AN ANY REPRESENT ITS RUNTIME TYPE?

This is where typecodes come in. See the section on typecodes.

WHEN WOULD I USE AN ANY?

An any comes in handy whenever you need to write IDL and do not know which CORBA type is appropriate. This ambiguity rarely occurs in application IDL. Usually you know what you are dealing with and you use that type explicitly. Or, if you have an operation that may handle one of a couple of types (e.g., a float or a short), then a union is a possible type. Note, if you have an operation that is needs an abstract interface representation, then interface inheritance can be used. The ultimate base interface is CORBA::Object. There are some cases, though, where an any is needed in application IDL. There are also some places where an any is used in system and service IDL. This is because the operation has to be generic enough to work with a broad range of types. For example, imagine the need to represent a generic property, which is a name-value pair. We have three choices: Force all values to be strings, and then use a single struct. This approach has the advantage of being simple IDL. However, this potentially falls apart if it is difficult to represent the value as a string. Even if the representation is not a problem, the representation conversion is a hassle:     struct Property     {       string name;       string value;     };     interface Foo     {       Property getElement(in string key);     }; Write a lot of different structs, one for each type of value. This approach has the advantage of explicit typing with no conversion. However, this falls apart if we have to represent a type that we don’t know of, e.g., a user-defined struct. Also this would lead to a lot of variants of the same operation, one that handled each kind of struct:     struct FloatProperty     {       string name;       float  value;     };     struct ShortProperty     {       string name;       short  value;     };     //more and more     interface Foo     {       FloatProperty getFloatElement(in string key);       ShortProperty getShortElement(in string key);     }; Use an any. This approach has the advantage of simple IDL. Also, it is completely expandable to all types, including user-defined types. Additionally, the application does not have to do conversions (this is essentially done in the marshalling/unmarshalling code). The disadvantage of this approach is the runtime typing — this impacts both the application code and the speed of the ORB communication:     struct Property     {       string name;       any    value;     };     interface Foo     {       Property getElement(in string key);     };

OKAY, SO WHY NOT USE ANYS ALL THE TIME?

Sometimes the genericism of an any is appealing. But make sure you need this feature. The disadvantages of using an any include: There is no compile-time type information. This makes the application code harder to write, debug, maintain, etc. Communicating an any is relatively expensive for the ORB.

AN ANY SEEMS VERY DYNAMIC, SO WHAT’S A DYNAMIC ANY?

A Dynamic Any (DynAny) is not an IDL type, like an any. A DynAny solves a technical glitch in the role of the IDL compiler. A DynAny provides an API to construct an any even when the application code does not have benefit of the IDL (really the IDL generated code) that defines the type of the any.

WHAT IS A TYPECODE?

A typecode is a type, whose values represent the types of other things. It is a meta-type. For example, a given typecode might have the value of XXX, which represents the type “float”. In details of XXX are not particularly important.

DO ALL TYPES HAVE A TYPECODE?

Yes.

WHAT ARE THE TYPECODES FOR THE BUILT-IN IDL TYPES?

This depends on the language mapping. For example, in C++, there is a const instance of the TypeCode class for each of the built-in types. WHAT ARE THE TYPECODES FOR THE USER-DEFINED TYPES? Sticking with the above C++ example, there is a const instance of the TypeCode class for each user type. The IDL compiler generates this.

HOW DO I GET AN OBJECT’S TYPECODE

An interface’s typecode can be determined by calling _get_interface() on the object reference (IOR). This will return an InterfaceDef (Interface Definition) reference from the Interface Repository (IFR). The typecode for things like float and string are well known in the language mapping. The typecode for things like structs are generated by the IDL compiler. An any supports a call to determine its typecode. Note, the complete support for this requires Dynamic Anys.

WHAT IS THE INTERFACE REPOSITORY?

The CORBA specification defines IDL as a mechanism for describing a set of interfaces and data types. These interface definitions can represented within a textual IDL representation. They can also be managed by, or stored within a repository service. IDL can be compiled into a running interface repository serice. This sercices can then provide information about other objects interfaces. The Interface Repository service is (of course) defined in IDL.

WHY DOES CORBA NEED THE INTERFACE REPOSITORY?

The CORBA specification support self desribing data types. These are supported by the ANY data type and its associated typecodes. The CORBA specification also provides Dynamic Invocation Interface and Dynamic Skeleton Interface . Since the IIOP specification does not provide self descirbing messages, an objects interface must be accessible via the Interface Repository. This capability is also critical for supporting up and down casting of super and sub interfaces types.

WHAT IS THE BOA?

NOTE: The BOA has been deprecated by the OMG and replaced by the POA. ORB vendors may support both the BOA and POA or either. The CORBA specification defines the BOA pseudo object in PIDL. BOA stands for Basic Object Adapter. The BOA’s main purpose is to allow an object server to interact with the ORB. A server process uses the BOA to tell the ORB when an object is ready to perform operations.

WHAT ARE THE FOUR BOA ACTIVATION POLICIES FOR A CORBA SERVER?

NOTE: The BOA has been deprecated by the OMG and replaced by the POA. ORB vendors may support both the BOA and POA or either. CORBA defines four activation policies for objects. Activation policies are specific to the server process that “owns” the CORBA object. The activation policy defines how objects are created within a server process. The BOA object ensures that these activation policies are enforced. Enforcement of these rules can simplify application development. Note: The CORBA activation policies are specific to creation. This means that the activation policy does not manage the connection policy of a CORBA object. A particular un-shared server might have only one CORBA object in its address space. The activation policy does not forbid several client applications from having object references that point to the same CORBA object. An application is always free to _duplicate an object reference and pass it to some other application. Shared Server: A shared server is a server process that is shared by many CORBA objects. This means that a shared server could have more than one instance of a particular CORBA object in its address space. This implies that different object references of the same type refer to different CORBA object implemented within the same process. Un-Shared Server: An un-shared server is allowed to construct at most one CORBA object (of a given type) within its address space. This implies that different object references of the same type refer to CORBA objects implemented within different server processes. Persistent Server: A persistent server is a shared server that manages the activation of objects itself. The BOA is not involved with enforcement of the activation policy. A persistent server might start up at boot time and create a fixed number of CORBA objects of varied types. Per-Method Server: The per-method policy results in a separate server for each request made on the specified object. The BOA activates a per-method server for each and every request made on the object. The server runs only until the request has been serviced.

WHAT IS THE POA?

The Portable Object Adapter (POA) superceeds the Basic Object Adapter (BOA) as the primary way of making implementation objects available to the ORB for servicing requests. All object adapters are concerned with the mechanisms to create CORBA objects and associate the CORBA objects with programming language objects that can actually do the work. The POA provides an expanded set of mechanisms for doing this.

WHY IS THE POA NEEDED?

The POA was added to the CORBA specification for a number of reasons: The BOA was under-specified. This meant that each ORB vendor provided different APIs and different extensions to make the BOA useful. The POA fixes this by being more completely specified. The POA, itself, is specified in IDL, and addresses complex issues in more detail than the BOA did. The BOA was insufficient for large-scale systems. The POA provides a lot more functionality than the POA with respect to implementing large-scale systems. Servers can better handle connections and requests from multiple clients through automatic, policy-driven behavior. Servers are better able to manage thousands, if not millions, of fine-grained objects via the POA’s ability to manage lifecycles and associations of CORBA objects and implementation objects. The BOA was not completely location transparent. Whereas some semantics of the BOA changed if the implementation object was actually in the same process as the caller (client) vs. being remotely located, the POA makes the semantics much more consistent. In fact, a CORBA call on a local object will still go through the POA. This allows the POA to uniformly apply policy and service decisions. In this sense, the POA is more like the “container” concept in EJB.

DOES THE POA AFFECT CLIENTS?

No. No object adapter or server-side concept affects clients. CORBA-compliant clients that used BOA-based servers should be able to use POA-based servers.

DOES THE POA AFFECT SERVERS?

Yes. Transitioning from a BOA-based server to a POA-based server needs to be done with some forethought. It is not necessarily a difficult task, but should be done carefully. The POA is policy based with lots of policy choices. The task is to determine the set of policy decisions that give you the functionality you want. Since the POA superceeds most of the BOA functionality, if you want to simply migrate a BOA-based server to a POA-based server without changing behavior, then this can be done rather easily. There are some API changes. See POA Policies. Chances are, though, if you are using the POA, you are going to want to take advantage of some of its benefits.

HOW DOES THE POA BENEFIT NON-DISTRIBUTED OBJECTS?

The POA is very consistent in the treatment of local and remote objects. Specifically, all CORBA calls on a CORBA object go through the POA, even if the target object is local (in the same address space). This allows the POA to uniformly apply the POA Policies.

HOW DOES THE POA MANAGE OBJECT LIFECYCLE?

The POA distinguishes between the CORBA object reference (IOR) and the implementation object that does the work. This implementation object is called a servant. A BOA-based approach has the IOR and servant existing at the same time. A POA-based approach can support this, but can also support IORs existing without being associated with servants, and also servants existing without being associated with IORs. Obviously, the association between an IOR and a servant has to be made at some point, to make the servant a useable CORBA object. But this association can be done on-demand. Consider the following example scenarios to motivate the advantages of on-demand association: A pool of servants can be instantiated, and then associated in turn with IORs, as needed. A set of IORs can be created for the purposes of publishing the references to the Name Service, without going through the work to actually instantiate the servants. Moreover, the POA allows a single servant to simultaneously support several IORs. All of the above significantly contribute to scalable applications.

HOW DOES THE POA MAKE THE ASSOCIATION BETWEEN SERVANTS AND CORBA OBJECTS?

This is where the Object ID and and POA Active Object Map come in. So, for a given POA, the Object ID identifies a specific CORBA object, which is used in the Active Object Map to identify the servant.

HOW ARE MULTIPLE POAS DISTINGUISHED?

Each POA has a name.

HOW ARE MULTIPLE POAS ORGANIZED?

This is up to the application developer, but a POA hierarchy is supported. Each POA has a parent POA. There is an implicit Root POA.

WHAT ARE THE SEMANTICS OF THE POA HIERARCHY?

This is better answered by describing what the semantics of the POA hierarchy are not. The POAs deal with policies, and the POA hierarchy is not a policy hierarchy. The POA hierarchy does not imply any default policies. The POA hierarchy does not imply any factoring of the servants by IDL interface or servant class. In most cases, each servant is associated with at most one POA. The POA “owns” the servant and there are deletion responsibilities the POA will take. Deleting a POA will cause its servants to be deleted. Hence, the semantics of the POA hierarchy are only a containment hierarchy for POA deletion.

WHERE DOES THE POA MANAGER FIT IN?

The POA Manager is really a different beast all together. The POA Manager groups one or more POAs and provides common system resources, such as a network connection, to its POAs.

WHAT ARE THE POA POLICES?

The POA policies are used to configure the POA for a particular application design or scalability optimization. For example, if you have lots of a fine-grain objects, you may want one kind of optimization, whereas if you have lots of long-duration operations, you may want another kind of optimization. The list of POA policies includes: Thread Policy ORB_CTRL_MODEL - the ORB controls how threads are dispatched. SINGLE_THREAD_MODEL - the is only one thread. Lifespan Policy TRANSIENT - the POA’s object references are transient (i.e., likely conversational objects). PERSISTENT - the POA’s object references are persistent, which means the POA should be registered with an locator/activator (i.e., likely entity objects). ID Uniqueness Policy UNIQUE_ID - the POA does not allow a servant to be associated with more than one CORBA Object (Object ID). MULTIPLE_ID - the POA will allow a servant to be associated with more than one CORBA Object (Object ID). NOTE: The name of this policy is potentially confusing. The Object IDs are always unique for a given POA. This policy is describing the uniqueness or non-uniqueness of the association between Object IDs and servants. ID Assignment Policy USER_ID - the application code can/will determine Object IDs for the POA’s CORBA Objects. SYSTEM_ID - the POA will determine Object IDs for its CORBA Objects. Implicit Activation Policy IMPLICIT_ACTIVATION - Allows the POA to add the servant to the AOM under conditions where the association is implicit, e.g., calling servant_to_reference(). NO_IMPLICIT_ACTIVATION - Servants can only be associated with an Object ID through an explicit call to do so. Servant Retention Policy RETAIN - The POA uses an Active Object Map (AOM). NON_RETAIN - The POA does not use an Active Object Map (AOM). NOTE: The name of this policy is potentially confusing. The policy influences whether the POA has an Active Object Map (AOM) or not to track which servants are associated with Object IDs. The application is always in control of making and breaking this association. The NON_RETAIN policy means that no AOM is used, and hence the application has supplied a Servant Manager. Request Processing Policy USE_ACTIVE_OBJECT_MAP_ONLY - The POA relies on its Active Object Map (AOM) only to determine which Object IDs are valid and associated with servants. USE_DEFAULT_SERVANT - The POA will use a default servant for requests to Object IDs that are not in the AOM. USE_SERVANT_MANAGER - The POA will use a servant manager to activate an Object ID/servant that is not in the AOM. Note, there are some cases where the policies are inter-related in most practical situations. For example, a PERSISTENT Lifespan Policy probably implies a USER_ID ID Assignment Policy. Also, the use of the USE_ACTIVE_OBJECT_MAP_ONLY requires the use of RETAIN, and the use of IMPLICIT_ACTIVATION requires the use of SYSTEM_ID and RETAIN. Since the POA and its policies are defined in IDL, this list may be extended, or features within a particular policy may be expanded.

WHAT IS A SERVANT MANAGER?

The Servant Manager is application code that essentially replaces the functionality of the POA’s Active Object Map (AOM). A servant manager is needed for sophisticated schemes to map Object IDs to servants.

HOW DOES A REQUEST GET TO THE RIGHT POA AND RIGHT SERVANT?

The POA’s name is part of the IOR. Also, of course, the Object ID is in the IOR. So once the request gets delivered to the right machine (part of the request’s IOR), and to the right port (part of the request’s IOR), the POA Manager listening on that port looks at the object key (part of the request’s IOR). The object key contains the POA name and the Object ID. The POA Manager uses the object key to deliver the request to the right POA, and the POA uses the object key to determine the Object ID. Depending on the POA’s policies, it directly or indirectly uses that Object ID to deliver the request to the right servant.

HOW DOES THE POA SUPPORT OBJECT RELOCATION?

Very well, indeed. The POA is the unit of location and activation. This means the POA is the unit of relocation. This is powerful. Since a POA can one object, a few objects, or a lot of objects, by design, then objects can be relocated individually are in groups. A great way to think of the POA is as a named, logical endpoint.

HOW DO I MIGRATE FROM BOA TO POA?

There is no specific answer. The migration impacts will depend on the system complexity. In particular, many large systems developed with the BOA needed to do POA-like things any way to scale. There will be some emerging case studies. It is likely that POA migration is one of those things that is not overly difficult, but should not be done without a thought. An important thing to understand is that the migration can be an evolutionary thing as the use of the POA does not affect clients, and mixed POA and BOA systems interoperate at the network (IIOP) level.

WHAT IS IMPORTANT FOR INTEROPERABILITY BESIDES IIOP?

The IIOP specification provides resolve initial references as a mechanism to obtain an initial object reference. This object referenced must be implemented with the same ORB product as the client. If this is not the case, then string to object can be used. CORBA 2.0 does not provide a mechanism to transport this string or provide direct access to “foreign objects” The Interoperable Name Service specification will address this and other related problems.

WHAT IS AN IOR?

An IOR is an Interoperable Object Reference. It is a specialized object reference. An IOR is used by an application in the exact same way that an object reference is used. An IOR allows an application to make remote method calls on a CORBA object. Once an application obtains an IOR, it can access the remote CORBA object via IIOP. The CORBA object can be implemented with any CORBA 2.0 compliant product that supports IIOP. The application that obtains the IOR can be developed with a different CORBA 2.0 product. The application constructs a GIOP message and sends it. The IOR contains all the information needed to route the message directly to the appropriate server.

ARE IORS OBTAINED IN THE SAME MANNER AS OBJECT REFERENCES?

Obtaining IORs is exactly the same as obtaining object references. The one caveat is that ORB::resolve_initial_references returns an IOR but it usually must be implemented within the same CORBA product environment.

CAN AN APPLICATION REFER TO OBJECTS IMPLEMENTED WITH MULTIPLE CORBA PRODUCTS?

Well, they’re sure supposed to be able to do so. Here’s how. Let us assume that an application needs to access two objects. Object A is implemented with CORBA product Aa and object B is implemented with CORBA product Bb. Let us look at several scenarios: The front-end application will be implemented with CORBA product Aa: The simplest approach is for the front-end application to obtain an object reference to A by calling ORB::resolve_initial_references(). Since the front-end application is implemented with product Aa it cannot obtain an object reference to B by calling ORB::resolve_inital_references(). It can acquire the stringified object reference to B and convert it to an IOR by calling ORB::string_to_object(). How does it obtain the stringified object reference? Object B’s constructor could be implement to stringify itself and write the string to a file that is accessible to the front end application (access might be provided by NFS). Every CORBA product that supports IIOP should be support ORB::string_to_object(). The front-end application will be implemented with CORBA product Cc: This scenario is very similar to the first. The application can not use ORB::resolve_initial_references() since neither object A or B are implemented with product Cc. The front end application will obtain an IOR to A and an IOR to B by first acquiring stringified object references. It will then converting the strings to IORs by calling to ORB::string_to_object(). Every CORBA product that supports IIOP should be support ORB::string_to_object(). The front-end application will be implemented with CORBA product Cc. It will obtain IORs A and B from product Cc’s implementation of the CORBA NameService. It will not need to acquire any stringified object references. The real question is how are IOR A and IOR B bound within product Cc’s CORBA NameService. The processes implementing object A and Object B must acquire an object reference to product Cc’s CORBA NameService. This can only occur by obtaining a stringified object reference to product Cc’s CORBA NameService. How is the stringified object reference to product Cc’s NameService initially created? A simple application implemented with product Cc obtains the NameService by calling ORB::resolve_inital_references(), it then stringifies it by calling ORB::object_to_string(), once this has been done it externalizes the string so that it can be accessed by the processes implementing object A and B. Note: Stringified objects cannot be exchanged using CORBA based communication. This is your classic catch 22 situation

CAN CORBA VENDORS SIMPLIFY INTEROPERABILITY AND THE PROCESS OF OBTAINING OTHER VENDOR’S OBJECT REFERENCES?

CORBA vendors can simplify the process of obtaining external object references by providing small pieces of code designed only to create external IORs. This might be a function called ExternalORB::create_external_references(). Vendors could provide this code to the public or directly to other ORB vendors.

WHAT IS THE INITIALIZATION SERVICE?

The Initialization Service is used to find well-known system and user-defined services. The Initialization Service is best understood in the catch-22 presented by the Name Service: If the Name Service holds the system’s application object references (IOR)... ...and the Name Service, itself, is composed of NamingContext objects (IORs) for storing and retreiving application IORs... ...and a client cannot access an object until it has its IOR... ...then, how does a client get a reference to a root NamingContext? The answer to the above question is that the reference has to be supplied to the client administratively. The Initialization Service provides a simple interface into this administrative information. The method is named “resolve_initial_reference()” and takes a string representing the name of the service, and returns a CORBA::Object accessing that service.

WHAT ARE THE IDL INTERFACES DEFINED WITHIN THE COSNAMING MODULE?

The CORBA Name Service is composed of two basic interfaces. The NameContext and the Binding Iterator. Remember that since the NameContext and the Binding Iterator are both CORBA interfaces, they are accessed via object references and are distributed. The NameContext contains “named” object references or other “named” NameContexts. It is similar to a directory that can contain named files or other named directories. NameContexts and Binding Iterators are usually implemented in the same Name Server process, but this is not a requirement. The CORBA NameService can be constructed as a set of interconnected NameContext objects and NameService processes. The BindingIterator is used to iterate across object references contained within a particular NameContext. It basically provides a mechanism to get the number of named object references within a NameContext. It also provides a next_one and a next_n operation to retrieve individual named object references or contexts. Continuing with the directory analogy, The BindingIterator is a mechanism to do a ls or dir operation on a directory.

HOW DO I USE A NAMECONTEXT?

The NameContext interfaces supports two main operations, bind and resolve. Once a NameContext object reference is obtained, it can be used to “name” some other CORBA object, or retrieve an object reference by name. This means that you can call the bind method on a NameContext passing it an object reference and a name. This will place a named object reference into the NameContext for future resolve calls. If an application wishes to obtain an object reference by name is simply obtains the appropriate NameContext and call resolve with the particular name. This will cause the named object reference to be returned to the application making the resolve invocation.

WHAT IF I DO NOT KNOW THE NAME OF THE OBJECT?

The CORBA NameService was designed to allow object references to be obtained by name. Names need to be either agreed upon between servers or clients, or perhaps passed between components in the distributed application. It is also possible to use the BindingIterator interface to connect to any name object reference. The CORBA trading service might be more appropriate if the CORBA NameService is too limiting. Other architectures such as factories might be appropriate mechanisms to obtain object references.

WHAT IS THE INTEROPERABLE NAME SERVICE (INS)?

The Interoperable Name Service (INS) fixes a technical glitch in the original CORBA Name Service. The original Name Service did not truly allow object references from different ORB vendors to be stored and accessed from within a single Name Server. This is fixed by the INS. There are no API or IDL changes, so application developers should not notice a difference.

WHAT IS THE EVENT SERVICE?

The CORBA event service provides support for the producer/consumer pattern. It support a channel which provides the producer with the ability to create “events” and the consumers with the ability to receive these “events”. Events are any valid IDL defined interface or data type. Both consumer and producer applications must be a CORBA server. There may be multiple channels in use. A single channel may have multiple producers and multiple consumers. A consumer receives all the events on the channel.

ARE THERE MORE THAN ONE TYPE OF EVENT SERVICE?

The Event Service specification supports two types of event reception. One is push and one is pull. The push model allows consumers to receive ongoing events by just connecting. The pull model requires that the consumer poll for all events sent to the channel since the last pull. The Event service also allow the events to be either typed or in typed. In the typed model, the Event service ensures that the channel support a specific IDL datatypes. In the untyped model the Chnnel distributes events as an ANY. In this case, it is up to the consumer to enforce type safety.

WHAT IS THE QUALITY OF SERVICE PROVIDED BY THE EVENT SERVICE?

The Event Service specification does not require a specific quality of service. It is up to the implementor of the event service to determine what the provided level is. For example, an event service implentation may ensure that events are deliver even if some piece to the event service fails. An event service could also support transactional events using OTS. An event service could also provide deliver via a non IIOP transport such as UDP broadcast or multicast. This could, of course, limit interoperability. An event service could also ensure that connections to a channel are persistent. This would mean that consumers would not have to re-connect if the server failed and then came back online.

WHAT IS NOTIFICATION SERVICE?

The Notification Service extends the Event Service and adds several new kinds of functionality. CORBA has defined the Notification Service model that allows applications to send messages to objects in other applications without any knowledge of that receiving objects. The Notification model is an extension to the CORBA Event Service model. Applications that are providing messages to other applications are called suppliers and applications receiving the messages supplied are called consumers. The suppliers and consumers are completely decoupled thus having no knowledge of their location. In addition, suppliers have no idea of how many consumers are listening to the messages being supplied.

HOW DOES THE NOTIFICATION SERVICE WORK?

The Notification model uses an architectural element called an event channel which allows messages to be transfered between suppliers and consumers. Consumers register with the event channel and express an interest of certain events. The channel receives events from suppliers and forwards the events to the interested consumers for that event. Suppliers and Consumers connect to the event channel and not directly to each other.

HOW DOES THE NOTIFICATION SERVICE EXTEND THE EVENT SERVICE?

The Notification Service extends the Event Service in two areas: Event Filtering - Event filtering allows that Notification channel to deliver only certain types of events to interested consumers. In the much simpler Event Service model all events are sent to all consumers. Quality of Service - Quality of Service (QoS) allows an applications to change some of the elements defined in the Notification Channel, such as event delivery.

WHAT DOES THE QUALITY OF SERVICE GIVE ME?

The Quality of Service, or QoS, allows you to set and tune your service to the demands of your business. Notification defines the following QoS properties: Reliability Priority Expiery Time Earliest delivery time Order policy Discard policy Maximum batch size Pacing interal Proxy push supplier properties These properties can be applied at cartain levels of the Notification service: Notification Channel Supplier or Consumer admin objects Proxy suppliers and consumers Individual event messages The QoS is a very powerful extension that allows you to modify the service according to your requirements both from an administrative and an application requirement perspective.

WHEN DO I NEED A SERVICE LIKE NOTIFICATION?

It depends on what your business requirements dictate. We can see a need for Notification in a scenario where you are interested in receiving certain information which another source owns. The example that always comes to mind is the stock market. Information about stocks flows rapidly, and frequently. This information can be supplied through a Notification channel to which many consumers can register their interest in certain stocks. As new information about the stocks is collected, a supplier can push that information to the Notification channel which will pass this information to all the interested consumers on that channel. There are many more examples but the bottom line here is that it can be used in a variety of scenarios and they will have to be analyzed to see where Notification fits in.

HOW DO I DEFINE NOTIFICATION EVENTS?

Notification events are defined using standard IDL. There are two types of events: Structured Events Untyped Events Structured events provide a well-defined data structure into which messages can be inserted and sent to interested consumers. Messages can be defined using standard IDL structs and provide, both consumers and suppliers, with a much strongly typed event. In addition, a sequence of these events can be transmitted between suppliers and consumers that can increase the efficiency of communications between them. With the sequence you can batch any number of events and trasmit them all at once. Structured Events can constain all IDL types that are defined in the standard IDL. Here’s an example:     struct Message     {       long messageType;       string messageBody;     };     typedef sequence<Message> MessageSeq; Suppliers would fill the contents of this messages and supply them to interested consumers that have registered with the notification channel. The untyped event is simply a CORBA::any into which the event is inserted and sent to consumers. So the above example can be inserted into the CORBA::Any type and sent to any consumers on the channel.

CAN I FEDERATE NOTIFICATION CHANNELS?

Yes. You will have to do this within your program but the concept becomes clear once you have done it. The way you do the federation is to create two channels and essentially connect them together logically. The consumer proxy of one channel, channel A, is supplied to the supplier proxy of the other channel, channel B. The reverse is done with the supplier proxy of channel B where it’s exchanged with channel A and voila we are now federated. So essentially what you have is a channel that becomes a consumer and which will forward the events to its consumers.

WHAT IS THE PURPOSE OF THE LIFECYCLE SERVICE?

The basic purpose of the Lifecycle Service is to provide basic capabilities to CORBA Objects, such as the ability to create, copy, move and destroy themselves. More than any other service, the Lifecycle Service is tied to the actual ORB implementation used to provide CORBA support.

WHAT IS THE PURPOSE OF THE OBJECT TRANSACTION SERVICE?

The OTS provides a mechanism for distributed CORBA Objects to participate in a distributed transaction through a two phase commit protocol.

WHAT IS THE PURPOSE OF THE COS TRADER SERVICE?

The Trader Service was designed to provide access to CORBA objects based upon capabilities as opposed to name or interface type. The Trader Service is a factory since its purpose is to return other CORBA Objects. Unlike the Naming Service, a global name or identifier is NOT used to specify the CORBA Object to return. The Trader Service has been likened to the Yellow Pages, while the Naming Service is more like the White Pages.

WHAT IS THE PURPOSE OF THE PERSISTENT OBJECT SERVICE?

The Persistent Object Service was designed to provide two things: A database like access to CORBA objects. This provided CORBA clients with IDL control interfaces to a CORBA object’s underlying storage. A means for CORBA objects to uniformly save their state into a database. This was an internal API for implementation objects (the objects that really have the state) to save their data into a database. The Persistent Object Service was not widely received and potentially never implemented by any vendor. As a specification, it has been retracted. The Persistant State Service (PSS) superceedes the POS.

WHAT IS THE PURPOSE OF THE PERSISTENT STATE SERVICE?

The Persistent State Service (PSS) is designed to be a CORBA-friendly form of persistence management. The PSS superceeds the POS. Unlike the POS that attempted to provide both a client IDL interface for persistence control and a server-side layer for allowing CORBA implementation objects to save their state, the PSS focuses on only the latter. At a high-level the PSS is an IDL defined abstraction layer of data storage. It needs to be implemented for a particular datastore, such as a file system, a relational database, or an OODB. This allows CORBA implementation objects to be abstracted from their storage mechanisms, much like ODBC/JDBC abstract relational databases.

WHAT ARE OBJECTS BY VALUE?

The Objects By Value (OBV) defintion includes semantics of pass-by-value similar to that of standard programming languages. The current CORBA specification only defines object reference semantics. The Objects By Value specification defines extensions to CORBA (and IDL) that allows designers the flexibility to allow the receiving side of a parameter to receive a new instance of the object.

HOW CAN I USE OBV?

The valuetype definition supports both data members and operations, similar to C++ and Java class definitions. The receiving side creates its own copy of the object and all operations invoked on valuetypes are always local to the receiving process. So, how can you use OBV? In our opinion, very carefully :-). This extension offers some flexibilities and a lot of rope to hang oneself. In particular, there are several very complex edge effects of the OBV specification, such as when interface references and valuetypes are intermixed. By focusing on a few, simple valuetypes that provide operations that are basic functionality (such as edit rules, data validations, conversions and queries (e.g., what day is 1/1/2000), and other utility operations), the use of valuetypes will be clearer to those that use them.

WHAT DOES OBV REALLY PROVIDE?

From the OBV specification: Valuetypes provide semantics that bridge between CORBA structs and CORBA interfaces: They support description of complex state (i.e arbitrary graphs). Their instances are always local to the context in which they are used (because they are always copied when passed in a remote call). They support both public and private (to the implementation) data members. They can be used to specify the state of an object implementation, i.e they can support an interface. They support single inheritance (of valuetypes) and can support multiple interfaces. They may be also be abstract.

WHAT IS A VALUE TYPE?

A Value Type is an object whose semantics lie between a CORBA interface and a structure. There are two types a Value Types that can be declare: Concrete Value Types Abstract Value Types Concrete Value Types define state (properties) and the implementation is always local. Abstract Value Types do not define properties. Both Concrete and Abstract Value Types can define operations (interface) and inherit from other Value Types and interfaces.

IN WHAT CASES DO I NEED A VALUE TYPE?

In some cases it is desirable to have a receiving party instantiate a copy of an object. This implies that the receiver knows how to implement the object (instantiate it, initialize it, provide implementations of the operations). More importantly, this also implies the receiver knows something about the semantics of the object and can utilize those semantics locally. The new instance created by the receiving side has a separate identity from the original object, and once the parameter passing operation is complete, there is no relationship between the two instances.

HOW DOES A VALUE TYPE DIFFER FROM AN INTERFACE TYPE?

An Value Type differs from an interface in that it potentially carries additional properties that define state and that the operation implementation are executed locally. If you recall, when we pass or receive an interface type ( an object reference ) and execute operations on it, these operations end up as remote invocations to the “real” implementation object. Again, Value Types are not meant to replace interface types, and should be used in very specific instances in which the receiving side can benefit from not making remote invocations.

WHAT IS AN ABSTRACT VALUE TYPE?

An Abstract Value Type is a Value Type that may not be instantiated. Only Concrete Types can be instantiated and implemented. Also, no state information may be specified in an Abstract Type.

WHAT IS THE PURPOSE OF THE ASYNCHRONOUS MESSAGING INTERFACE?

The AMI extends the request/response nature of CORBA into messaging services. The messaging services are richer than the “oneway” or “deferred synchronous” functionalities in the core CORBA specification, and also pull in elements from the Event and Notification Services. The AMI works with the notion of “implied IDL”. The means that although the IDL for an interface, Foo, has a single operation, bar, there are other implied operations, e.g., try_bar, that are used to support asynchronous communications.

CAN CORBA BE INTEGRATED WITH XML?

INDEX:XML@Integration with CORBA INDEX:CORBA@Integration with XML Yes. And in a number of ways, depending on the need and approach. Using IDL to communicate XML. This means setting up simple interfaces to communicate the XML Document Type Description (DTD) and the XML document itself. Obviously, there may be a repository of DTDs, and the actual communication of the XML document simply refer to its DTD. Using XML as a transport. This means there is a DTD for, essentially, IIOP. A CORBA request or response is communicated in XML. A variation on the previous item, once the XML to CORBA request/response conversion is in place, a gateway can take XML or CORBA requests from various sources and map them into XML or CORBA requests on various services. Using XML as an abstract system description language. XML could be used to describe a system interfaces, workflow, API mapping logic, data definitions, other semantics, etc., and then this XML is used to produce IDL. Chances are the XML would also be used to code generate supporting system integration class libraries and potentially entire clients/servers.

Page 1, Page 2