13.6.7 of the CORBA 2.3 specification states: "The context data for a particular service will be encoded as specified for its service-specific OMG IDL definition, and that encoded representation will be encapsulated in the context_data member of IOP::ServiceContext. (See Section 15.3.3, Encapsulation, on page 15-13)."

The descriptions of service contexts in the FT spec are missing an explicit statement of the encoding of the service context data.

Proposed Resolution:

Add the following sentence in all appropriate sections: "When encoded in a request or reply message header, the <code>context_data</code> component of the <code>ServiceContext</code> struct will contain a CDR encapsulation of the xxxxxx struct."

see below

Motivation: The Notifier will be easier to replicate if it is a single
object. At present, all Filters created by the Notifier must also be
replicated. Furthermore, there is no requirement that a Filter be destroyed
by the client that created it (once it is done using it), raising a garbage
collection issue. FOr a connected consumer, if the consumer no longer
exists the Notifier can discard the connection. There is no analagous test
for Filters.

The Notifier interface is already a collapsed version of multiple
CosNotification APIs to get rid of the channel/admin/proxy objects in favor
of one object, so I am just proposing we carry through on that approach.

Óne proposal:

First, remove method create_subscription_filter.

Second, change the 2 connect_foo_fault_consumer methods
(connect_structured_fault_consumer + connect_sequence_fault_consumer) to
take just a consumer and a grammar:
ConsumerId connect_foo_fault_consumer (in CosNotifyComm::FooPushConsumer,
in string constraint_grammar)
raises (ÏnvalidGrammar, AlreadyConnected)

One or more event forwarding constraints is associated with each connected
consumer, with the default being a constraint that matches all events. The
ConsumerID returned from a call can be passed into methods that modify
these constraints. When a consumer is disconnected, the associated
constraints are discarded.

Third add methods for manipulating constraints associated with a ConsumeID:

string constraint_grammar(in ConsumerID)
void add_constraints(in ConsumerID, ...)
void remove_constraints(in ConsumerID, ...)
void remove_all_constraints(in ConsumerID)
void modify_constraints(in ConsumerID, ...)
ConstraintExpSeq get_constraints(in ConsumerID)

where ... means the normal arguments that are in the corresponding methods
in the Filter spec.

The above methods correspond to the Filter methdos that are required in the
current version of the spec, except I left out 2 of them, match_structured
and destroy. I do not think we need to support match_structured – only the
Notifier needs to be able to do matching. destroy is not needed because
there is no filter object to be destroyed. (disconnect is sufficient.)

ALTERNATE PROPOSAL

A simpler scheme is to associate a single constraint with each consumer.
This is not very restrictive, especially when you consider that there is
currently only one event type in use in the FT spec. The default would
still be a constraint that matched all events. In this case the only method
needed to modify this constraint is:

void replace_constraint(in ConsumerID,
in EventTypeSeq event_types,
in string constraint_expression)

Further, if we are willing to stick to the default constraint grammar, no
grammar needs to be specified, which simplifies connect_foo_consumer – not
only by removing the constraint_grammar argument but also by removing the
InvalidGrammar exception, which comes from CosNotifyFilter. I believe one
could simplify things enough to get rid of any dependencies on
CosNotifyFilter. It is not clear how important this is, but I thought I
should mention the possibility.

see below

The Fault Tolerant CORBA specification contains the following struct.

struct FactoryInfo

;

This causes a problem for the IDL compilers of some vendors, because
"factory" is a keyword in CORBA V2.3. See CORBA V2.3, page 3-8, Lexical
Conventions, June 1999.

We need to change "factory" in this struct to "fact", "fctry",
"generic_factory", or whatever. What is your preference?

see below

The Fault Tolerant CORBA specification defines the State used by the
get_state(), set_state(), get_update(), set_update() methods, as

typedef sequence<octet> State

Those methods must be implemented by the application programmers.
They will find their task easier if we define the State as:

typedef any State

rejected

Basically, the Failure OBJ_ADAPTER is considered a failover condition in the
document that was sent out. In most cases OBJ_ADAPTER exception may be thrown
when there is an internal ORB error. In case of an internal ORB error, the
retry on the TAG_ALTERNATE_IIOP_ADDRESS may still yield the same exception. This
may be inefficient. Do you see situations where doing a failover on this
particular exception is useful.

Remove OBJ_ADAPTER from this list.

On page 27-9 of the FT CORBA spec, under "Application-Controlled Membership",

"The application-controlled (MEMB_INF_CTRL) Membership Style"

should be corrected to read

"The application-controlled (MEMB_APP_CTRL) Membership Style"

Correct the above statement with the revised text given below.

Throughout the document, the authors use the term "method" several times where they should be talking about "operations" instead. This violates the general understanding of the OMG terminology, where IDL interfaces contain "operations", not "methods". The term "method" is usually reserved as a concept of oo programming languages.

I recommend that for the next revision, the authors run a global search&replace and identify where they want to talk about methods and where of operations.

No Data Available

Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM
exception because of several reasons :

• it was badly specified
• it made the implementation of hash() difficult, and broke most of the
  existing ones.

It turns out that the Fault Tolerance specification published a little
earlier crucially requires a similar mechanism.
In normal life, most applications can rely on plain LOCATE_FORWARD because
there is no reason to expect the death of the originally pointed component.
In the case of Fault Tolerant CORBA, this is entirely different: it is
precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that
the original component is dead, and might never return. If all the backup
profiles of an IOR enjoy the same death, all hope is gone.

This means that without a mechanism similar to LOCATE_FORWARD_PERM, the
Fault Tolerant CORBA spec cannot address the requirements of real
fault-tolerant systems.

This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM
re-introduced in some way. Here are a few ideas that might help :

Issue of scope:
The scope of LOCATE_FORWARD_PERM is ORB lifetime.

Issue of hash() :
Let us be reminded that the Fault-Tolerant CORBA spec defines teh concept of
an Interoperable Object Group Reference (IOGR). The IOGR contains a specific
profile that contains a group identifier.

• When an ORB receives and IOGR, it should compute the value of hash() based
  on the GroupID contained in the IOGR, and performs LOCATE_FORWARD_PERMs if
  requested.
• When an ORB receives a normal IOR (i.e. an IOR lacking a group profile) it
  computes hash() in the customary way, and doesn't have to respond to
  LOCATE_FORWARD_PERMs.

see below

One additional issue I have is that the
ReplicationStyleValue, MembershipStyleValue, ConsistencyStyleValue,
FaultMonitoringStyleValue, FaultMonitoringGranularityValue
are typedefed to long, whereas the
InitialNumberReplicasValue and MinimumNumberReplicasValue
are typedefed to unsigned short. It might be more appropriate
to typedef all of these to unsigned short.

see below