IT-SC book: Advanced CORBA® Programming with C++

Another potential problem of additional properties is that because there is no type definition for the property, the trader cannot enforce type consistency. Instead, for additional properties, it accepts values of any type at all. This places the burden of maintaining type consistency on the developer. For example, in the code example on page 864, we used an additional property called Description and gave it a string value. If we create a number of such service offers, we could supply a floating-point number as the value of the Description property in some of these offers (most likely because of a bug in the code). This can create havoc: half the offers in the trader might have a string in the Description property, whereas the other half might contain floating-point values. What happens when we formulate a query using this property is undefined in this case.

Because of the potential pitfalls with additional properties, we recommend that you use the feature with caution. If you decide to use additional properties, take care that value types are consistent. Otherwise, queries will yield unpredictable results.

19.8 Withdrawing Service Offers

The withdraw operation deletes a service offer from the trader:

// In module CosTrading...

exception IllegalOfferId { OfferId id;

};

exception UnknownOfferId { OfferId id;

};

exception ProxyOfferId { OfferId id;

};

// ...

interface Register : TraderComponents, SupportAttributes { // ...

void withdraw(in OfferId id) raises( IllegalOfferId, UnknownOfferId, ProxyOfferId

);

// ...

};

The id parameter passed to withdraw is an offer ID previously returned by an export operation on the same trader. The operation raises UnknownOfferId if the id parameter identifies a non-existent service offer. IllegalOfferId indicates that

746

IT-SC book: Advanced CORBA® Programming with C++

the offer ID does not conform to whatever syntax is used by the trader for its offer IDs. Attempts to delete a proxy offer by calling withdraw raise a ProxyOfferId exception. To delete a proxy offer, you must use the Proxy::withdraw_proxy operation.

19.9 Modifying Service Offers

You can use the Register::modify operation to change the property values of a service offer in place:

//In module CosTrading...

exception NotImplemented {};

//...

interface Register : TraderComponents, SupportAttributes {

// ...

) raises(

NotImplemented, IllegalOfferId,

UnknownOfferId, ProxyOfferId, IllegalPropertyName, UnknownPropertyName, PropertyTypeMismatch, ReadonlyDynamicProperty, MandatoryProperty, ReadonlyProperty, DuplicatePropertyName

);

// ...

};

You can use modify to add optional properties to an existing offer, to change the value of existing modifiable properties, and to delete existing optional and modifiable properties. You are not allowed to delete an optional but read-only property because doing so would allow you to modify a read-only property by deleting it and adding it again with a new value.

The modify operation requires three parameters. id

This parameter identifies the service offer to modify by specifying the offer ID returned from the export operation used to create the offer.

del_list

747

IT-SC book: Advanced CORBA® Programming with C++

This parameter contains a sequence of property names. Properties whose names are on this sequence are removed from the service offer.

modify_list

This parameter supplies names and values for properties to be added or changed.

As you can see, the operation can raise a number of exceptions. The NotImplemented exception is raised by traders that do not support modifiable properties. (For such traders, the supports_modifiable_properties attribute on the

SupportAttributes interface is false.) The remaining exceptions have the same meaning as with the export and withdraw operations.

19.10 The Trader Constraint Language

Before we can look at how to import service offers, we must examine the trader constraint language. To select the service offers to be returned, the importer specifies a constraint using the constraint language. The constraint is a Boolean expression over the properties of service offers that have a nominated service type or have a service type derived from the nominated type. The trader matches service offers against the constraint. Those service offers that match become candidates to be returned from an import operation.

Note that the trader is free to return service offers that have a derived service type because derived service types guarantee two things: first, the IDL interface type of the object reference inside a derived service offer is compatible with that of the base service type; second, a derived service offer has all the properties defined in its base service type. In our controller example, these guarantees mean that if the importer asks for a controller, the trader is also free to return matching multiprotocol controllers because a multiprotocol controller can do everything an ordinary controller can. (You can suppress this polymorphic behavior by setting an import policy. However, suppressing polymorphism is generally a bad idea; the feature is provided mainly for trader maintenance purposes.)

19.10.1 Literals

The constraint language uses the same syntax as IDL for integer and floating-point literals. For example, -10.068E5 is a valid floating-point literal, and 999 is a valid integer literal.

Boolean literals are also the same as in IDL: TRUE and FALSE. The simplest possible constraint expression is TRUE—it matches all service offers.

Character literals differ from their IDL counterparts. The trader constraint language, like IDL, uses single quotation marks to delimit character literals but does not support the same escape sequences. The following are all valid character literals:

'A'

748

IT-SC book: Advanced CORBA® Programming with C++

' '

'\''

'\\'

You can include a literal single quotation mark by escaping it with a backslash, and you can include a literal backslash by escaping it with another backslash. There are no other escape sequences, so a literal such as '\023' is illegal.[3]

[3] A future revision of the specification may permit such escape sequeces.

String literals are also delimited by single quotation marks. Here are a few legal string literals:

'A'

'Hello World' 'Isn\'t this nice?'

'Literal backslash: \\'

The escape sequence conventions are the same as for character literals, so the only legal escape sequences are \' and \\. Note that a single-character literal, such as 'A', is both a legal character literal and a legal string literal. The trader uses the context in which the literal appears to deduce its type.

19.10.2 Identifiers

Whenever an identifier appears in a constraint, it refers to a property name. Identifiers follow the syntax for IDL identifiers. Because the properties are the only thing that can be named in a constraint, identifiers cannot be qualified using a :: operator (there is never a need to qualify them).

19.10.3 Comparison Operators

The constraint language provides the usual comparison operators:

==

!=

<

>

<=

>=

These operators have the same meaning as they do in C++. All of them can be applied to numeric types, strings, characters, and Boolean values. For strings and characters, comparisons use the ISO Latin-1 collating sequence. For Boolean comparisons, TRUE is greater than FALSE.

19.10.4 Arithmetic Operators

749

IT-SC book: Advanced CORBA® Programming with C++

The constraint language supports the following arithmetic operators:

+

-

*

/

The - operator is both unary and binary. There is no modulo operator. The arithmetic operators apply to integer and floating-point types. Mixed-mode arithmetic is supported. The trader applies type promotion rules to permit mixed-mode arithmetic, but the specification does not spell out these type promotion rules. You should be careful about conditions such as overflow, underflow, and value truncation because the results are implementation-dependent.

19.10.5 Boolean Operators

The constraint language provides the Boolean operators and, or, and not. These operators are reserved words, so do not create properties with these names; otherwise, you will not be able to use them in queries. For example, if you create a property called and, there is no way to use that property name in an expression because it will result in a syntax error.

19.10.6 Set Membership

The in operator tests for set membership. The left-hand operand must be an integer, floating-point, character, string, or Boolean value. The right-hand operand must be a sequence of elements of the type of the left-hand operand. For example:

'Visa' in CreditCards

The in operator returns true if CreditCards is a property of type sequence of string and if 'Visa' appears as one of the elements of the sequence. Note that the in operator cannot test for set membership of an enumerated value in a sequence.

19.10.7 Substring Matching

The ~ operator tests whether the string on the left appears as a substring of the string on the right. The match is always a literal string match; there are no wild cards or regular expressions. Here is a simple example:

'part' ~ 'departments'

This expression returns true. Either the left-hand or the right-hand (or both) operands can be identifiers that name a property, so the following is legal:

'90' ~ Model

750

IT-SC book: Advanced CORBA® Programming with C++

This expression returns true if 90 appears anywhere in the Model string property.

19.10.8 Testing for Existence

The exist operator is a unary operator. It returns true if the property named by its righthand argument exists. For example:

exist Model

The exist operator permits you to test for the existence of optional properties:

exist Model and Model == 'BFG-9000'

This expression returns true if a service offer has the optional Model property and if that property's value is 'BFG-9000'. Strictly speaking, the exist operator is redundant in the preceding expression. We could also write

Model == 'BFG-9000'

This has the same meaning because all comparison operators return false if they are applied to an optional property that does not exist in a service offer. As a result, the exist operator is required only if you want to locate service offers that have an optional property without specifying a value for that property.

19.10.9 Precedence

The operators for the constraint language have the following precedence, from highest to lowest (operators on the same line have the same precedence):

exist - (unary minus) not

* / + -

~

in

== != < <= > >= and

or

You can use parentheses to override precedence as necessary.

19.10.10 Constraint Language Example

Here again is the query from page 831:

751