ORBacus
Trader
Version 1.0
Copyright (c) 1998 Object-Oriented Concepts, Inc. All Rights Reserved.
“Object-Oriented Concepts” and “ORBacus” are trademarks or registered trademarks of
Object-Oriented Concepts, Inc.
“OMG”, “CORBA”, and “Object Request Broker” are trademarks or registered trademarks of the Object Management Group.
“Java” is a trademark of Sun Microsystems, Inc.
Other names, products, and services may be the trademarks or registered trademarks of
their respective holders.
2
ORBacus Trader
CHAPTER 1
Introduction to
ORBacus Trader
Overview
7
7
Audience 7
What is a Trading Service? 7
What is ORBacus Trader? 8
Basic Concepts
8
Roles 8
Service Types 9
Service Offers 11
Design Issues 12
Importing Service Offers
13
Service Type 13
Constraint 13
Preference 14
Policies 15
Offer Management
15
Exporting a Service Offer 15
Modifying a Service Offer 15
Withdrawing Service Offers 16
Dynamic Properties 16
Trader Federation with Links 18
Supporting Legacy Applications with Proxy Offers
Summary 20
CHAPTER 2
19
Getting Started with ORBacus Trader
21
Starting the ORBacus Trader Server 21
Overview of the Sample Programs 22
Sample Service Type 23
The LenderDemo Module 23
Interactions of the Client, Server and Trading Service 23
The Basic Server
24
Initializing the ORB 25
Connecting to the Trading Service 26
Withdrawing Old Service Offers 27
Reading the List of Products 28
Creating the Lender object 29
ORBacus Trader
3
Installing the Service Type 29
Exporting Service Offers 32
Starting the ORB’s Event Loop 33
The LenderImpl Class 33
Running the Server 34
Examples 35
The Client
35
Initializing the ORB 36
Connecting to the Trading Service 36
Loading the Importer Policies 36
Invoking the Query operation 36
Displaying the Results 37
Running the Client 39
Examples 39
The Dynamic Server
40
Dynamic Properties 40
Overview 40
Exporting Service Offers 41
The RateEval Class 42
Running the Server 43
Examples 43
The Database Server
44
Preparing the Database 45
Connecting to the Database 45
Exporting Service Offers 45
The RateEval Class 47
The LenderImpl Class 48
Running the Server 48
Examples 49
CHAPTER 3
The Trader Console
51
Starting the Application 51
Terminology 53
The Trader Console Menus 53
The Console menu 53
The Edit menu 53
The View menu 55
The Insert menu 55
4
ORBacus Trader
The Tools menu
55
The Toolbar 55
Managing Service Types
56
Adding a New Service Type 56
Removing a Service Type 58
Masking a Service Type 58
Unmasking a Service Type 59
Managing Offers
59
Adding a New Offer 59
Modifying an Offer 61
Withdrawing Offers 62
Managing Proxy Offers
64
Adding a New Proxy Offer 64
Withdrawing Proxy Offers 66
Managing Links
67
Adding a New Link 67
Modifying a Link 67
Removing a Link 68
Configuring the Trader Attributes
68
Support Attributes 69
Import Attributes 70
Link Attributes 72
Admin Attributes 72
Executing Queries 73
Connecting to a New Trader
CHAPTER 4
75
Configuring ORBacus Trader
77
Format of the Properties File 77
Modifying the Properties File 79
Configuration Properties 79
ALLOW_NIL_OBJECTS 79
DEF_FOLLOW_POLICY 79
DEF_HOP_COUNT 80
DEF_MATCH_CARD 80
DEF_RETURN_CARD 80
DEF_SEARCH_CARD 80
LOCAL_TYPE_REPOSITORY 81
MAX_DYNPROP_THREADS 81
ORBacus Trader
5
MAX_FOLLOW_POLICY 82
MAX_HOP_COUNT 82
MAX_LINK_FOLLOW_POLICY 82
MAX_LINK_THREADS 82
MAX_LIST 83
MAX_MATCH_CARD 83
MAX_PROXY_THREADS 83
MAX_RETURN_CARD 83
MAX_SEARCH_CARD 84
REQUEST_ID_STEM 84
SERVER_NAME 84
SUPPORTS_DYNAMIC_PROPERTIES 84
SUPPORTS_MODIFIABLE_PROPERTIES 85
SUPPORTS_PROXY_OFFERS 85
USE_INTERFACE_REPOSITORY 85
APPENDIX A
Trading Service Reference
87
Module CosTrading 87
Interface CosTrading::TraderComponents 95
Interface CosTrading::SupportAttributes 96
Interface CosTrading::ImportAttributes 97
Interface CosTrading::LinkAttributes 99
Interface CosTrading::Lookup 100
Interface CosTrading::Register 105
Interface CosTrading::Link 112
Interface CosTrading::Proxy 116
Interface CosTrading::Admin 120
Interface CosTrading::OfferIterator 127
Interface CosTrading::OfferIdIterator 128
Module CosTradingDynamic 129
Interface CosTradingDynamic::DynamicPropEval 131
Module CosTradingRepos 132
Interface CosTradingRepos::ServiceTypeRepository 133
References
6
ORBacus Trader
141
CHAPTER 1
Introduction to
ORBacus Trader
1.1
Overview
1.1.1
Audience
This document is intended for use by application developers who wish to familiarize
themselves with the Trading Service and ORBACUS TRADER. This document assumes that
the reader is familiar with the Common Object Request Broker Architecture[3], Java and
the IDL-to-Java language mapping[4].
1.1.2
What is a Trading Service?
The development of distributed object applications using the Common Object Request
Broker Architecture (CORBA) can be a complex undertaking, and the need for objects to
locate one another in an indirect fashion is a necessity in all but the simplest of applications. As part of the CORBAservices[5] specification, the Object Management Group
(OMG) has defined two services that support object discovery: the Naming Service and
the Trading Service.
The Naming Service maintains a hierarchical tree of name-object pairs similar in some
respects to directory services such as X.500, Novell Directory Services (NDS) or the
Lightweight Directory Access Protocol (LDAP). Using the Naming Service, a server can
make an object available to its clients by giving the object a unique name and placing it in
the hierarchy of name-object bindings managed by the service. A client locates the object
ORBacus Trader
7
Introduction to ORBacus Trader
by navigating down the tree or requesting the object by name. Once a client has obtained
the object reference, it can communicate directly with the object without the involvement
of the Naming Service. The Naming Service is easy to understand and use, and works well
in applications where object identity is important.
In the Trading Service, an object does not have a name. Rather, a server advertises an
object in the Trading Service based on the kind of service provided by the object. A client
locates objects of interest by asking the Trading Service to find all objects that provide a
particular service. The client can further restrict the search to select only those objects
with particular characteristics. The Trading Service returns the object references of all
objects that satisfy the client’s search criteria, and the client can interact with those objects
without further involvement of the Trading Service.
As you can see, both services facilitate object discovery, yet they differ significantly in the
kinds of applications for which they are suited. A useful analogy that illustrates the difference between the Naming and Trading services likens the Naming Service to the white
pages of a phone book and the Trading Service to the yellow pages. For example, a client
searching for a suitable auto repair service often will not be as interested in the name of
the service (“Jim’s Studebaker Repair”) as in the makes of cars supported, the hours of
operation, the proximity of the shop and ultimately the cost of performing a repair.
1.1.3
What is ORBacus Trader?
ORBACUS TRADER is a Java implementation of the Trading Service specification[6].
ORBACUS TRADER conforms to the specification’s definition of a full-service trader,
meaning that ORBACUS TRADER supports all of the functionality described in the specification.
1.2
Basic Concepts
This section provides a brief discussion of the concepts involved in the Trading Service.
For a more information, refer to the Trading Service specification.
1.2.1
Roles
The client of a trading service (also known as a trader) plays one of two roles at any particular point in time. If the client is advertising a service, it is playing the role of an exporter.
If the client is searching for a service, it is playing the role of an importer.
8
ORBacus Trader
Basic Concepts
1.2.2
Service Types
A service type is used to define a particular type of service, and is similar to a database
schema or a class in NDS. All of the service type definitions are stored in a service type
repository managed by the Trading Service. An exporter that advertises a service must
associate the service with a service type.
A service type consists of the following information:
•
A service type name uniquely identifies the service type.
•
An interface type defines the IDL interface to which an advertised object of this type
must conform.
•
A collection of property types defines additional attributes of the service offer.
Service Type Names
Each service type in the repository has a unique name. Although the specification is not
completely clear about the format of these names, ORBACUS TRADER supports two formats:
•
Scoped names - These names have formats such as ::One::Two. Other supported
variations include Three::Four and simply Five.
•
Interface repository identifiers - These names adhere to the format of interface
repository identifiers. The most common format is
IDL:[prefix/][Module/]Interface:X.Y
Note: Although both naming formats follow interface repository conventions, service type
names are never used to lookup information in the interface repository.
Interface Types
An interface type describes the computational signature of the advertised service. The
interface type is a string whose format should be a scoped name or an interface repository
identifier as described above for service type names. When a new service is exported,
ORBACUS TRADER may use the interface repository to confirm that the object being
advertised conforms1 to the interface defined by the interface type.
1. An object conforms to an interface if it implements that interface, or if it implements a subclass
of that interface.
ORBacus Trader
9
Introduction to ORBacus Trader
Property Types
A service type can have zero or more property types, representing additional information
that can be associated with an advertised service.
A property type definition consists of a name, a value type and a mode. The value type is a
CORBA::TypeCode, and the mode indicates whether a property is mandatory and whether
it is read-only. The property modes have the following semantics:
•
Mandatory - The exporter must provide a value for a mandatory property at the time
the service is exported. Mandatory properties cannot be removed.
•
Read-only - Once an exporter has supplied a value for a read-only property, that
property cannot be modified. A read-only property can be removed.
•
Mandatory and Read-only - A property that is both mandatory and read-only must
have a value when the service is exported, and cannot subsequently be changed or
removed.
A property that is neither mandatory nor read-only is considered optional, and can be
changed and removed.
ORBACUS TRADER accepts Java-style identifiers as property names, meaning a property
name must start with a letter, and may consist of letters, numbers and underscores.
Super Types
Service types can inherit from other service types, which enables the definition of abstract
super types that encapsulate behavior and characteristics common to many service types.
When a new service type is created that has super types, the trader performs several validation steps:
1. All super types must already exist in the service type repository.
2. Any property type definitions in the new service type that have the same name as a
definition in a super type must be compatible with the super type definition. For two
property definitions to be compatible, their value types must match, and the mode of
the new definition must be the same as, or stronger than, the mode of the property in
the super type.
3. The interface type of the new service type must conform to the interface type of all
super types. ORBACUS TRADER may use the interface repository to verify that this is
true.
For example, consider two IDL interfaces, InterfaceA and InterfaceB, defined below:
interface InterfaceA {
10
ORBacus Trader
Basic Concepts
void do_something();
};
interface InterfaceB : InterfaceA {
void do_something_else();
};
Here, InterfaceB is defined as a subclass of InterfaceA. Now, let’s define two service
types:
service ServiceTypeA
{
interface InterfaceA;
property string name;
};
service ServiceTypeB : ServiceTypeA
{
interface InterfaceB;
mandatory property string name;
readonly property float cost;
};
In the example above, ServiceTypeB inherits from ServiceTypeA. As such, it inherits all
of the property types from ServiceTypeA, and declares an interface type of InterfaceB,
which conforms to the interface type of its super type because InterfaceB is a subclass of
InterfaceA.
Notice that ServiceTypeB redefines the mode of the “name” property. Whereas the definition in ServiceTypeA does not specify a mode (making the property optional), the definition in ServiceTypeB makes this property mandatory, therefore a value for the property
must be supplied when the offer is exported. Note that the reverse is not allowed; a subtype cannot redefine a mandatory property to be optional.
ServiceTypeB also adds a new property, “cost”, which is defined to be read-only. Because
the property is not mandatory, an exporter does not need to supply a value for it at the time
a service offer is exported. However, once a value has been defined for this property, it
cannot subsequently be changed.
1.2.3
Service Offers
A service offer is an instance of a service type and represents the advertisement of a service by a service provider.
A service offer has the following characteristics:
ORBacus Trader
11
Introduction to ORBacus Trader
•
A service type name associates the offer with a particular service type.
•
An object reference provides the “pointer” (the object reference) to the advertised
object that is necessary for clients to invoke the service being offered.
•
A set of properties describe this service offer and must conform to the property types
defined by the service type.
The trader uses the definition of the specified service type to perform several validation
steps on a new offer:
1. The exporter must provide values for all mandatory properties (including all
mandatory properties that the service type inherits from its super types, if any).
2. The object must conform to the interface type defined by the service type.
3. The value types of all properties must match the value types as defined by the service
type. For example, a value of type double is not allowed for a property whose type is
defined as string in the service type.
Note: ORBACUS TRADER allows an exporter to supply values for named properties that
are not defined in the service type.
The value of a property in a service offer can be modified if the mode of the property is
not read-only. A property can be removed from a service offer if the property is not mandatory. New properties can also be added to an existing service offer.
1.2.4
Design Issues
The Trading Service can be a tool for constructing efficient distributed applications. The
advantage of annotating a service offer with properties, and allowing offers to be filtered
on the basis of those properties using a constraint, is that importers can select offers without having to incur the overhead of invoking operations on each object.
For example, suppose ServiceTypeB did not have the “cost” property. Instead, let’s pretend that InterfaceB has an additional operation, “cost”, which returned a value of type
float:
interface InterfaceB : InterfaceA {
void do_something_else();
float cost();
};
In this situation, if the importer needed to select only those objects whose cost is within a
certain range, the importer would need to iterate over each object returned by the Trading
Service to invoke the “cost” operation. In a distributed environment, the overhead of this
12
ORBacus Trader
Importing Service Offers
activity could be prohibitively expensive. It is the developer’s responsibility to anticipate
the types of queries that importers will need to perform and design their service types
accordingly.
1.3
Importing Service Offers
The primary responsibility of a Trading Service is satisfying an importer’s request for
matching service offers. The CosTrading::Lookup interface defines a single operation, “query”, for use by importers. This operation takes a number of parameters, the most
important of which are explained below.
1.3.1
Service Type
The service type informs the Trading Service about the kind of service in which the
importer is interested. The service type effectively narrows the total number of service
offers the Trading Service must search to completely satisfy the importer’s request. Unless
the importer requests otherwise, the Trading Service will also consider the offers of service types that are subtypes of the given service type.
1.3.2
Constraint
The constraint is a boolean expression in a constraint language. The Trading Service evaluates each potential service offer against the constraint; if the expression evaluates to
TRUE, then the offer is considered a match. One constraint language is defined by the
Trading Service specification, but proprietary query languages can also be accommodated.
ORBACUS TRADER supports the standard OMG constraint language, which includes many
of the features commonly found in query languages and is described in detail in the Trading Service specification.
The standard constraint language has constructs similar to common programming and
database query languages, including comparative functions, substring matching, set membership, and mathematical and logical operators. The most important aspect of the constraint language, however, is its ability to refer to the properties of a service offer, enabling
importers to include or exclude a potential service offer on the basis of its properties. If the
offer does not contain a property that is necessary in order to completely evaluate the constraint, then that offer is skipped.
Constraint expressions are restricted to operating only on properties of the following
types:
•
boolean, short, unsigned short, long, unsigned long, float, double, char, string
ORBacus Trader
13
Introduction to ORBacus Trader
•
sequences of the above types
This restriction does not imply that more complex property types are forbidden. However,
properties of complex types cannot be referred to in a constraint expression, except in the
context of the exist operator, which simply tests for the existence of a property.
The simplest constraint is “TRUE”, which evaluates to TRUE for every potential service
offer, effectively matching every offer that is considered. Using this constraint, importers
have a simple means of obtaining all of the offers for a particular service type.
Using the example service type ‘ServiceTypeB’, we can form a more complex constraint
example: “’Bill’ ~ name and cost < 7.5”. In this example, we are searching for all offers of
type ServiceTypeB where the “name” property contains the string “Bill” and the “cost”
property has a value less than 7.5.
1.3.3
Preference
The preference is an expression that indicates how the Trading Service should order the
matching offers before it returns them to the importer. The specification defines the following five forms of a preference expression:
•
max expression - The offers are sorted in descending order based on the value of the
numeric expression.
•
min expression - The offers are sorted in ascending order based on the value of the
numeric expression.
•
with expression - The offers are ordered based on the boolean expression such that
all offers for which the expression is TRUE are returned before those for which the
expression evaluates to FALSE.
•
random - The offers are returned in a random order.
•
first - The offers are returned in the order they are discovered by the Trading
Service.
The expression associated with max, min and with is defined using the constraint language. If the expression cannot be evaluated for a service offer, that offer is still returned
(because it is a matching offer). However, the offer is returned after all offers for which
the expression could be successfully evaluated.
For example, the preference expression “min cost” would order the matching offers in
ascending order based on the value of the “cost” property.
14
ORBacus Trader
Offer Management
1.3.4
Policies
Policies provide a means for importers to exert additional influence over the query operation. The specification defines a number of standard policies, but implementations may
support additional ones. A policy is represented as a name-value pair. The Trading Service
administrator can establish default values for each policy to be used when an importer
does not supply a value for a policy. Maximum values for policies can also be established
to constrain the importer’s policy values.
Some of the standard policies are described below:
•
search_card – The upper bound (“cardinality”) on the total number of service
offers to be searched
•
match_card – The upper bound on the total number of matching service offers
•
return_card – The upper bound on the total number of matching offers to be
returned
•
exact_type_match – If the value for this policy is TRUE, the Trading Service
will only consider service offers exported for the given service type. If the value is
FALSE or is not supplied, the Trading Service will also consider service offers
exported for subtypes of the given service type.
ORBACUS TRADER supports all of the policies defined by the specification.
1.4
Offer Management
The CosTrading::Register interface provides operations for managing the service
offers of the Trading Service, including the ability to export, modify and withdraw
(remove) service offers.
1.4.1
Exporting a Service Offer
Exporting a service offer is a relatively simple task. The exporter must know the service
type, have a valid object reference, and have values for all of the mandatory properties
defined by the service type (and any of its super types). After the Trading Service has validated the new offer, a unique identifier is assigned to the offer and returned to the
exporter.
1.4.2
Modifying a Service Offer
The Trading Service allows service offers to be modified, with a few restrictions. First, the
object reference associated with an offer cannot be changed. Second, a client may add,
ORBacus Trader
15
Introduction to ORBacus Trader
modify and delete the properties of an offer only within the limitations of the property
modes established by the service type.
Each of the property mode combinations is described below, along with the limitations (if
any) in place when modifying a service offer.
1.4.3
•
Normal – Properties that are neither mandatory nor read-only can be added, modified,
and deleted without restriction.
•
Read-only – Once a value has been defined for a read-only property, it cannot be
modified. A read-only property that was not defined when the offer was exported can
be added during a modification operation. Read-only properties can be deleted.
•
Mandatory – A mandatory property can be modified but cannot be deleted.
•
Mandatory and read-only – A property that is both mandatory and read-only cannot
be modified or deleted.
Withdrawing Service Offers
There are two distinct ways to withdraw service offers. First, a client application or the
Trading Service administrator can remove individual offers one at a time using the unique
identifier associated with each offer. Exporters that will eventually need to clean up obsolete service offers are responsible for remembering the identifiers assigned to their service
offers.
Multiple service offers can be removed using an operation that accepts a service type and
a constraint expression. Every offer of the service type that matches the constraint expression is withdrawn. For this operation, offers of subtypes are not considered. A simple way
of removing all of the offers for a service type is to use “TRUE” for the constraint expression.
1.5
Dynamic Properties
In many situations, an exporter will need to periodically update the properties of a service
offer to reflect changing conditions. The interest rate on a loan is an example of a property
that might fluctuate frequently throughout the day. The requirement for an exporter to
keep all of its offers up to date may become overly burdensome, so the Trading Service
supports a feature called dynamic properties that can simplify these activities.
Rather than supplying a static value for a property, an exporter can substitute a special
data structure containing an object reference implementing the CosTradingDynamic::DPEval interface. When a trader requires the value of a dynamic property, a
request is made on the given object reference to obtain the property’s value. In essence,
16
ORBacus Trader
Dynamic Properties
the value of the property is delegated to another object, which might look up the value in a
database, compute the value on the fly, etc.
Dynamic properties introduce additional overhead during query processing, therefore the
importer can use a policy to exclude offers with dynamic properties. Furthermore, ORBACUS TRADER is careful to ensure that it does not needlessly evaluate a dynamic property.
Figure 1.1 illustrates the interactions of the objects involved.
Figure 1.1: Dynamic Property Evaluation
Importer
Exporter
3. evalDP
2. query
1. export
Trader
DynamicPropEval
Offer
1. An exporter advertises a service offer containing a dynamic property.
2. Some time later, an importer invokes the trader’s query() operation to search for
service offers.
3. If, during the processing of the query, the trader requires1 the value of the dynamic
property, the trader will invoke the evalDP() operation on the DynamicPropEval
object whose reference was provided by the exporter. This operation will determine
the value of the property and return it to the trader.
1. The trader will require the value of a property if the property is used in a constraint or preference
expression, or if the property is one of the desired properties requested by the importer.
ORBacus Trader
17
Introduction to ORBacus Trader
1.6
Trader Federation with Links
A powerful feature of the Trading Service allows administrators to establish links between
traders for the propagation of query requests. When an importer executes a query operation, the trader will always search its own set of service offers, but may also forward the
request on to any linked traders. The matching local offers, plus any offers found by the
linked traders, are returned to the importer. The importer is not aware of the query propagation, but can use policies to control the trader’s use of links.
A link is a unidirectional, point-to-point connection from one trader to another. The “target” trader is not notified when a new link to it is created in another trader. Of course, bidirectional links can be established by creating a link in each trader referring to the other
trader.
Each link has a name that is unique among all links in a trader. In a trader “network”, a
particular trader can be identified by a path composed of the names of the links that must
be traversed to navigate from a starting trader to the desired one. In addition to the link
name, the other attributes of a link consist of the object reference of the target trader’s
CosTrading::Lookup object and rules that govern query propagation for that particular link.
As you can imagine, there are significant performance issues associated with the use of
links, therefore the Trading Service provides importers and administrators with a great
deal of control over the trader’s linked behavior during a query operation. In particular,
each link has a rule that dictates under what circumstances the trader should propagate a
query to the target trader. Three possibilities exist, as defined in the FollowOption enumerated type:
1. local_only - Never propagate a query request (effectively disabling the link).
2. if_no_local - Only propagate a query request if no matching offers were found
among the trader’s local offers.
3. always - Always propagate a query request.
In addition, an importer may supply a value for the link_follow_rule policy containing one of the above settings. When the trader executes a query operation, it uses the
following algorithm to decide how it should behave for each of its links:
18
•
If the importer has not supplied a value for the link_follow_rule policy, the
trader’s default value will be used instead. Otherwise, the importer’s value is checked
to ensure that it does not exceed the trader’s maximum value for this policy.
•
If the policy is more restrictive than the rule established for the link, the importer’s
policy (or the default value) will be used.
ORBacus Trader
Supporting Legacy Applications with Proxy Offers
•
If the link’s rule is more restrictive, then the link’s rule takes precedence.
Importers may use the hop_count policy to limit the total number of “hops” that occur
for each link of a query. For example, using a value of five means that the query can be
propagated to a depth of at most four from the originating trader.
To prevent infinite loops, traders can be configured to generate unique identifiers to be
passed along when a query request is propagated to other traders. If the request happens to
be propagated back to the originating trader, it will recognize the unique identifier it generated and will take no further action on that request.
Links provide a great deal of flexibility to system designers. They can be used in a manner
similar to partitions in NDS, where responsibility for resources is distributed among multiple independent but interconnected entities. Links can also be applied in a more controlled fashion, where administrators selectively make the service offers of one trader
available to one or more other traders.
1.7
Supporting Legacy Applications with Proxy Offers
A proxy offer is a special kind of service offer, in that it has properties like a service offer
and can be matched during a query like a service offer. But rather than returning the offer
to the importer, the trader formulates a modified query request and forwards it to an object
specified by the proxy offer that implements the CosTrading::Lookup interface. In this
way, the match of a single proxy offer can result in a number of service offers being
returned to the importer.
In addition to the information contained in a service offer, a proxy offer contains:
•
the object reference of an object implementing the CosTrading::Lookup interface.
•
a boolean value, if_match_all, which indicates to the trader performing a query
that it should consider this proxy offer a match if the service type matches. In other
words, if this value is TRUE, the trader does not need to evaluate the importer’s
constraint against the properties of this offer; if the service type matches, then the
proxy offer is considered a match.
•
a constraint recipe, which specifes how the trader should rewrite the query constraint
before passing it to the proxy offer’s target object.
•
zero or more policies that the trader should pass on to the proxy offer’s target object.
An importer can specify a policy during a query that causes the trader to exclude all proxy
offers. One of the common uses for proxy offers is wrapping a legacy application with a
CORBA object that implements the CosTrading::Lookup interface. A single proxy
offer is exported, containing a reference to this wrapper object. The object can implement
ORBacus Trader
19
Introduction to ORBacus Trader
the “query” operation to invoke the legacy application, passing it the constraint expression. The trader’s ability to rewrite the query constraint helps to minimize the amount of
work that needs to be done by the wrapper object. The results returned by the legacy application can be translated into service offers and returned to the importer.
1.8
Summary
The Trading Service is a valuable addition to a distributed system developer’s toolbox,
acting as an agent that dynamically locates the providers of a service of interest to its client. ORBACUS TRADER provides an efficient, portable and complete implementation of
the Trading Service that can be applied in a wide variety of distributed systems.
20
ORBacus Trader
CHAPTER 2
2.1
Getting Started with
ORBacus Trader
Starting the ORBacus Trader Server
The simplest way to start the server is by using the obtrader script that was created during installation. You can edit this file to customize the server start-up parameters for your
particular environment.
If you do not wish to use a script to start the server, you can use
java com.ooc.CosTrading.Server.TradingService [options]
The command line options are described below:
-o iorfile
According to the specification, the primary object associated with a trading service is an instance of the Lookup interface. This option causes the server to
write the interoperable object reference (IOR) of the Lookup object to the
specified file.
-d dbpath
The server requires a subdirectory in which to store its configuration information, including the databases containing the trader’s service types, offers and
links. This option specifies the pathname of this subdirectory, which should
already exist. If this option is not supplied, the server will use the default path of
db, which is a subdirectory called “db” located in the current working directory.
Note: Two or more servers cannot share the same databases.
ORBacus Trader
21
Getting Started with ORBacus Trader
Displays the supported command-line options.
-h
In addition to the options listed above, you may also need to specify ORB-specific command-line options or Java system properties. Refer to the ORBACUS TRADER installation
notes for more information.
2.2
Overview of the Sample Programs
A number of sample programs are included with the ORBACUS TRADER distribution.
From the discussion of these programs presented in this chapter, you will learn how to:
•
Implement a client program to connect to the trading service and perform query
operations
•
Implement a server to interact with the trading service to export and withdraw service
offers
•
Implement dynamic properties
•
Query a SQL database using JDBC
You can find the source code for these programs in the demo subdirectory where the
ORBACUS TRADER distribution was installed.
The sample programs illustrate the use of a trading service in the context of a mortgage
broker company. Only one kind of simplified transaction is demonstrated by the sample
programs: the request for a new loan from a lender.
Three server programs are included. They each describe the available loans to the trader,
and respond to requests for new loans from a client. The servers vary in the complexity of
their use of the trading service.
A client program is provided that allows you to search for loans meeting your criteria and
request a new loan from a lender. The client program provides a great deal of control over
the query, allowing you to specify the constraint and preference expressions as well as the
values for importer policies that govern the trader's behavior during a query.
22
ORBacus Trader
Overview of the Sample Programs
2.2.1
Sample Service Type
The service type used by the sample programs is described below. The service type is
automatically installed by a server if the server discovers that the type does not exist.
Type Name:
Interface:
2.2.2
Mortgage
IDL:LenderDemo/Lender:1.0
Property
Mode
Type
Description
product_id
PROP_MANDATORY
string
The identifier for a loan product
rate
PROP_MANDATORY
float
The mortgage rate (e.g., 7.5 for a 7.5% rate)
pct_down
PROP_MANDATORY
float
The amount required for a down payment
(e.g., 10.0 for a 10% down payment requirement)
years
PROP_MANDATORY
short
The duration of the loan in years
The LenderDemo Module
The IDL definitions used by the sample programs are contained in the file
LenderDemo.idl, which defines the module LenderDemo containing a single interface,
Lender. The Lender interface has a read-only attribute for obtaining the name of the
lending company, and an operation for requesting a new loan.
module LenderDemo
{
exception UnknownProduct
{
string product_id;
};
interface Lender
{
readonly attribute string company_name;
boolean request_loan(in string product_id)
raises(UnknownProduct);
};
};
2.2.3
Interactions of the Client, Server and Trading Service
It can be somewhat confusing when trying to understand the relationship between the service type and the IDL interface, and how the client, server and trading service all interact.
ORBacus Trader
23
Getting Started with ORBacus Trader
Figure 2.1 shows an interaction diagram, which is explained below. The diagram omits the
creation of the service type.
1. When the server starts, it instantiates one or more servant objects that implement the
LenderDemo::Lender interface. The server then connects to the trading service and
exports a number of service offers for the Mortgage service type. Each service offer
contains a reference to a servant object created by the server.
2. The client connects to the trading service and invokes the query() operation. The
trading service evaluates all of the offers of type Mortgage, looking for those that
satisfy the client’s criteria. The list of matches is returned to the client.
3. The client iterates through each service offer, and invokes the request_loan()
operation on the Lender object contained in the offer.
Figure 2.1: Interaction diagram of Client, Server and Trader
Client
Server
3. request_loan
2. query
1. export
Trader
Lender
Offer
2.3
The Basic Server
The first program we will examine is the Basic Server. The source code for this server can
be found in the basic subdirectory. The Basic Server performs the following steps:
24
•
Initializes the ORB
•
Connects to the trading service
•
Withdraws offers from previous executions of the server
ORBacus Trader
The Basic Server
•
Reads the list of available products from a file
•
Creates an instance of our implementation of LenderDemo::Lender
•
Installs the Mortgage service type (if necessary)
•
Exports an offer for each available loan product
•
Enters the ORB's event loop
The following classes are used in the implementation of the Basic Server:
•
demo.basic.BasicServer - Contains main() and supporting methods
•
demo.basic.LenderImpl - An implementation of LenderDemo::Lender
•
demo.basic.ProductInfo - A simple class that contains the details of each loan
product
•
2.3.1
demo.util.DemoUtil - Contains utility methods for connecting to the trading
service, installing the Mortgage service type and withdrawing old service offers.
This class is used by the sample client program as well as all of the sample servers.
Initializing the ORB
The class com.ooc.Util.CORBA.Port.ORBLayer represents an abstract interface to an
ORB. Because the OMG IDL-to-Java mapping has not yet completely specified portable
interfaces to the ORB, the ORBLayer class was developed to allow the ORBACUS TRADER
server to be developed so that it is not reliant on any particular ORB vendor. Some vendor-specific features are accommodated by this interface, but in such a way that clients of
ORBLayer remain portable. The ORBLayer class can also be used by client applications,
as illustrated by the sample programs described in this chapter.
The code below shows how the Basic Server initializes the ORBLayer class.
String serverName = System.getProperty("demo.server");
com.ooc.Util.CORBA.Port.ORBLayer orbLayer =
com.ooc.Util.CORBA.Port.ORBLayer.instance();
org.omg.CORBA.ORB orb = orbLayer.init(serverName, args);
Some ORB vendors support the notion of a named server. The Basic Server recognizes the
system property demo.server, which you may define when starting the server if your
ORB supports named servers. Supplying a server name has no effect for those ORBs that
do not support named servers.
The ORBLayer class is what is known as a Singleton[7] class, in that there can only be one
instance of the class. This instance is accessible via the static method instance(). The
Basic Server obtains the ORBLayer instance, and then initializes it with the server name
ORBacus Trader
25
Getting Started with ORBacus Trader
(which may be null if the property is not defined) and the command line arguments that
were passed to the main() method.
2.3.2
Connecting to the Trading Service
Once the ORB layer has been initialized, the server connects to the trading service using
the demo.util.DemoUtil class.
org.omg.CosTrading.Lookup trader = demo.util.DemoUtil.connect(orb);
As you can see, the return value of the connect() method is a reference to the trader’s
CosTrading::Lookup object, which is defined by the trading service specification to be
the primary object of a trading service.
The connect() method in the DemoUtil class supports two ways of connecting to the
trading service. The first is by reading the stringified interoperable object reference (IOR)
of the CosTrading::Lookup object from a file (see “Starting the ORBacus Trader
Server” on page 21 for information on how to cause the server to write its IOR to a file).
The connect() method looks for the system property trader.file, which, if present,
should provide the pathname to this file.
The other way to connect to the trading service is by resolving the TradingService initial reference using the ORB's method resolve_initial_references(). Refer to the
installation instructions for information on registering ORBACUS TRADER as an initial service.
The code below illustrates how the connect() method reads the IOR from a file.
try
{
java.io.FileReader fr = new java.io.FileReader(iorfile);
java.io.BufferedReader in = new java.io.BufferedReader(fr);
String ref = in.readLine();
fr.close();
org.omg.CORBA.Object obj = orb.string_to_object(ref);
if(obj == null)
System.err.println("Error: Invalid IOR in file ‘" +
iorfile + "'");
else
result = org.omg.CosTrading.LookupHelper.narrow(obj);
}
catch(java.io.IOException ex)
{
System.err.println("Error: Unable to read IOR from file ‘" +
iorfile + "'");
26
ORBacus Trader
The Basic Server
ex.printStackTrace();
}
This is how the connect() method resolves the TradingService initial reference.
try
{
org.omg.CORBA.Object obj =
orb.resolve_initial_references("TradingService");
result = org.omg.CosTrading.LookupHelper.narrow(obj);
}
catch(org.omg.CORBA.ORBPackage.InvalidName ex)
{
System.err.println("Error: Unable to resolve initial " +
"reference ‘TradingService'");
}
2.3.3
Withdrawing Old Service Offers
Now that the server is connected to the trading service, it attempts to withdraw old service
offers using the cleanOffers() method in the DemoUtil class. As you will see, the
Basic Server writes to a file the identifiers of the offers that it exports. Every time the
server starts, it invokes the cleanOffers() method, which checks for the presence of
this file and withdraws these obsolete offers.
Offers from previous executions of the server are obsolete because the Basic Server creates a transient Lender implementation object, whose reference is included with each
exported service offer. The nature of a transient object is such that as soon as the server
that created that object is terminated, the reference to that object is no longer valid. Therefore, we need to withdraw the obsolete offers to prevent clients from interacting with
objects that no longer exist.
Note: There are vendor-specific features you can utilize to make an object reference valid
across executions of the server, but that is not the primary purpose of these sample
programs.
The following code demonstrates how cleanOffers() withdraws service offers.
java.io.File f = new java.io.File(fileName);
if(f.exists())
{
String[] offers = readOffers(f);
System.out.println("Removing old offers...");
ORBacus Trader
27
Getting Started with ORBacus Trader
try
{
org.omg.CosTrading.Register reg = trader.register_if();
if(reg == null)
{
System.err.println("Error: Trader does not support " +
"the Register interface");
System.exit(1);
}
for(int i = 0 ; i < offers.length ; i++)
{
try
{
reg.withdraw(offers[i]);
}
catch(org.omg.CORBA.UserException ex)
{
// ignore
}
}
}
catch(org.omg.CORBA.SystemException e)
{
...
}
}
The offer identifiers are read from the file by the readOffers() method, which returns
an array of String objects representing the identifiers. The CosTrading::Register
interface is obtained from the trader using the register_if() operation, and each offer
is withdrawn using the withdraw() operation.
2.3.4
Reading the List of Products
The file products.dat contains the details of each loan product that is to be advertised
by the server. The contents of this file are shown below.
# This file contains the list of products offered by a lender.
#
# The format of the file is:
#
# product_id,rate,pct_down,years
#
LOAN_A1,7.0,20.0,30
28
ORBacus Trader
The Basic Server
LOAN_A2,7.25,10.0,30
LOAN_B1,6.625,10.0,15
LOAN_B2,6.5,20.0,15
As the comments in the file indicate, the fields of the file correspond directly to the properties of the Mortgage service type.
The loadProducts() method in BasicServer.java reads the contents of this file,
creates a ProductInfo object for each product, and stores the ProductInfo objects in a
Hashtable using the product_id field as the key.
2.3.5
Creating the Lender object
After the server has loaded the products, it determines the name of the company to be used
and creates an instance of the class LenderImpl. This class is an implementation of
LenderDemo::Lender, and a reference to this object will be included with each service
offer exported by the server.
The code below illustrates the creation of a LenderImpl object.
String company =
System.getProperty("demo.company", defaultCompany_);
LenderImpl lender = new LenderImpl(company, products);
orb.connect(lender);
Notice that the server also connects the object with the ORB, which is the portable way to
make an object available to clients.
2.3.6
Installing the Service Type
Next, the server invokes the static method installServiceType() in the DemoUtil
class to ensure that the Mortgage service type is present prior to exporting service offers.
The installServiceType() method first checks to see if the service type already
exists in the trader’s service type repository.
boolean typeExists = false;
org.omg.CosTradingRepos.ServiceTypeRepository repos = null;
org.omg.CORBA.ORB orb =
com.ooc.Util.CORBA.Port.ORBLayer.instance().getORB();
//
// Verify that the type "Mortgage" already exists in the
// service type repository; if not, we need to install it
//
ORBacus Trader
29
Getting Started with ORBacus Trader
try
{
org.omg.CORBA.Object obj = trader.type_repos();
repos = org.omg.CosTradingRepos.
ServiceTypeRepositoryHelper.narrow(obj);
repos.describe_type(serviceType_);
typeExists = true;
}
catch(...)
{
...
}
The variable typeExists is used to indicate whether the type already exists. The service
type repository object is obtained via the trader’s type_repos() operation, and is then
narrowed to the appropriate interface. The repository’s describe_type() operation is
used simply to verify that the type exists. If an exception is raised, then the typeExists
variable remains set to false, and we know that the type does not exist. If the
describe_type() operation succeeds, then typeExists is set to true and we have
nothing left to do.
If the typeExists variable is false, then we need to install the service type.
if(! typeExists)
{
...
try
{
String[] superTypes = new String[0];
//
// Define the properties for this service type
//
PropStruct[] props = new PropStruct[4];
props[0] = new PropStruct();
props[0].name = "product_id";
props[0].value_type = orb.create_string_tc(0);
props[0].mode = PropertyMode.PROP_MANDATORY;
props[1] = new PropStruct();
props[1].name = "rate";
props[1].value_type =
30
ORBacus Trader
The Basic Server
orb.get_primitive_tc(org.omg.CORBA.TCKind.tk_float);
props[1].mode = PropertyMode.PROP_MANDATORY;
props[2] = new PropStruct();
props[2].name = "pct_down";
props[2].value_type =
orb.get_primitive_tc(org.omg.CORBA.TCKind.tk_float);
props[2].mode = PropertyMode.PROP_MANDATORY;
props[3] = new PropStruct();
props[3].name = "years";
props[3].value_type =
orb.get_primitive_tc(org.omg.CORBA.TCKind.tk_short);
props[3].mode = PropertyMode.PROP_MANDATORY;
repos.add_type(serviceType_,
demo.LenderDemo.LenderHelper.id(),
props, superTypes);
}
catch(...)
{
...
}
}
The Mortgage service type has no super types, therefore an empty array of String
objects is created and stored in superTypes.
Next, an array of PropStruct objects is created to hold the property definitions for the
service type. Each property is then defined, which includes a name, a CORBA::TypeCode,
and a property mode. All of the properties have the mode PROP_MANDATORY, which
requires that a value be supplied for each property at the time an offer is exported, yet
allows the properties to modified later.
Finally, the type is added using the repository’s add_type() operation. The value for the
if_name argument is obtained from the id() method in the LenderHelper class, which
returns the interface repository identifier for the LenderDemo::Lender interface. If the
trading service is configured to use the interface repository, then it will ensure that the
object reference of every exported offer for service type Mortgage conforms to this interface.
ORBacus Trader
31
Getting Started with ORBacus Trader
2.3.7
Exporting Service Offers
Now that the service type is installed, the server exports a service offer for each loan product.
As mentioned previously, the server saves the identifiers of its exported offers in a file, so
that they can be withdrawn later. Creating this file is the first step taken by the server.
Next, the server obtains the object reference of the trading service’s
CosTrading::Register object.
org.omg.CosTrading.Register reg = trader.register_if();
Finally, the server iterates over each of the ProductInfo elements contained in the
products hashtable. An array of Property objects is created to describe the properties
of the product, and an offer is exported. The server then writes the offer’s identifier to the
file.
java.util.Enumeration elements = products.elements();
while(elements.hasMoreElements())
{
ProductInfo prod = (ProductInfo) elements.nextElement();
org.omg.CosTrading.Property[] props =
new org.omg.CosTrading.Property[4];
props[0] = new org.omg.CosTrading.Property();
props[0].name = "product_id";
props[0].value = orb.create_any();
props[0].value.insert_string(prod.productId);
props[1] = new org.omg.CosTrading.Property();
props[1].name = "rate";
props[1].value = orb.create_any();
props[1].value.insert_float(prod.rate);
props[2] = new org.omg.CosTrading.Property();
props[2].name = "pct_down";
props[2].value = orb.create_any();
props[2].value.insert_float(prod.pctDown);
props[3] = new org.omg.CosTrading.Property();
props[3].name = "years";
props[3].value = orb.create_any();
props[3].value.insert_short(prod.years);
32
ORBacus Trader
The Basic Server
String id = reg.export(lender,
demo.util.DemoUtil.getServiceType(), props);
writer.println(id);
}
2.3.8
Starting the ORB’s Event Loop
The ORBLayer class encapsulates the necessary vendor-specific behavior for entering an
event loop. The Basic Server invokes the mainLoop() method of the ORBLayer class,
signaling that all initialization has been performed and the server is ready to process client
requests.
orbLayer.mainLoop();
2.3.9
The LenderImpl Class
The LenderImpl class is our implementation of the IDL interface
LenderDemo::Lender. When the object is created, the Basic Server supplies the company name and the hashtable of product information, which the object saves for later use.
The company_name() method is the implementation of the read-only IDL attribute
company_name, and it simply returns the name of the lender company.
The request_loan() method is invoked by clients when a new loan is requested. The
client supplies the product identifier, which is validated against the products in the hashtable. The method will raise the UnknownProduct exception if a match is not found.
A very simple algorithm is used to determine whether the lender agrees to provide the loan
to the requesting client. A random number generator is used to generate an integer; if the
integer is evenly divisible by two, then the loan is granted. A real implementation would
require significantly more involved inputs, as well as complex decision-making processes,
before a loan would be granted.
public class LenderImpl extends demo.LenderDemo._LenderImplBase
{
private String company_;
private java.util.Hashtable products_;
private java.util.Random rand_;
public LenderImpl(String company, java.util.Hashtable products)
{
company_ = company;
products_ = products;
rand_ = new java.util.Random();
ORBacus Trader
33
Getting Started with ORBacus Trader
}
public String company_name()
{
return company_;
}
public boolean request_loan(String product_id)
throws demo.LenderDemo.UnknownProduct
{
//
// Make sure we support this product
//
if(! products_.containsKey(product_id))
throw new demo.LenderDemo.UnknownProduct(product_id);
//
// Give the client a 50% chance of being approved
//
return ((rand_.nextInt() % 2) == 0);
}
}
2.3.10 Running the Server
To run the Basic Server, type the following:
java [properties] demo.basic.BasicServer [options]
The Basic Server will attempt to read the file products.dat, and will expect the file to
reside in the current working directory, therefore you need to start the server from the
basic subdirectory.
The first time you run the server, you can expect the following output:
Reading products from products.dat...
Exporting service offers...
Server for ‘ACME Loan Corp' is ready...
The server will create the file offers.dat in the current working directory, which contains the identifiers of the exported service offers.
Subsequent executions of the server will produce slightly different output, as the server
will report when it withdraws old service offers.
34
ORBacus Trader
The Client
Several system properties are supported by the server:
demo.server
The server name to supply to the ORBLayer.init() method.
demo.company The name of the company to be used by the LenderImpl object.
trader.file
The name of a file containing the stringified IOR of the trader’s
CosTrading::Lookup object. If this property is not defined, the server will
attempt to resolve the TradingService initial reference.
The server supports two command line options:
-w
Withdraws old service offers and immediately terminates the server. This is useful if you
want to clean out the offers exported by the server.
-h
Displays a help message describing the supported properties and command line options.
2.3.11 Examples
To specify the name of the company, you would use:
java -Ddemo.company="My Lender" demo.basic.BasicServer
To specify the name of a file containing the trader’s IOR, use:
java -Dtrader.file=trader.ref demo.basic.BasicServer
When you are finished using the Basic Server, you can clean up its offers using:
java demo.basic.BasicServer -w
2.4
The Client
The Client program is contained in the file Client.java in the demo subdirectory. The
program demonstrates the use of the query() operation, which in many respects is the
most important operation of a trading service. It is the query() operation that allows clients to find objects providing a service and then invoke operations on those objects.
The Client program performs the following steps:
•
Initializes the ORB
•
Connects to the trading service
•
Reads a file containing importer policies
ORBacus Trader
35
Getting Started with ORBacus Trader
2.4.1
•
Invokes the query() operation
•
Displays the results
Initializing the ORB
The Client program initializes the ORBLayer class using a method provided for use by clients.
org.omg.CORBA.ORB orb =
com.ooc.Util.CORBA.Port.ORBLayer.instance().initClient(args);
2.4.2
Connecting to the Trading Service
The Client program connects to the trading service in exactly the same way as the Basic
Server, because both programs are clients of the trading service (although they use the
trading service in different ways).
org.omg.CosTrading.Lookup lookup = demo.util.DemoUtil.connect(orb);
2.4.3
Loading the Importer Policies
A client that invokes the query() operation is also known as an importer. An importer
can influence the behavior of the query() operation by supplying values for importer
policies that are supported by the trading service.
The Client program's getPolicies() method reads the file policies.dat, which contains values for the most relevant importer policies and provides a description of each policy. You can edit this file to experiment with different policy values. You can also disable
any of the policies by placing a hash (#) at the beginning of a line. If a policy is not
defined by the importer, the trading service will use a default value.
2.4.4
Invoking the Query operation
The Client program has several steps to take to prepare for invoking the query() operation. As already mentioned, it obtains the importer policies:
org.omg.CosTrading.Policy[] policies = getPolicies(orb);
Next, it establishes which properties it wants the trading service to return with each matching offer:
org.omg.CosTrading.LookupPackage.SpecifiedProps desiredProps =
new org.omg.CosTrading.LookupPackage.SpecifiedProps();
desiredProps.all_dummy((short)0);
36
ORBacus Trader
The Client
By invoking the all_dummy() method on the SpecifiedProps union, the client is indicating that it wants all properties to be returned.
The client then creates Holder objects to hold the values of the out parameters returned
by the query() operation:
org.omg.CosTrading.OfferSeqHolder offers =
new org.omg.CosTrading.OfferSeqHolder();
org.omg.CosTrading.OfferIteratorHolder iter =
new org.omg.CosTrading.OfferIteratorHolder();
org.omg.CosTrading.PolicyNameSeqHolder limits =
new org.omg.CosTrading.PolicyNameSeqHolder();
Finally, the query() operation is invoked, passing all of these parameters, plus the constraint and preference expressions obtained from command line arguments.
lookup.query(type, constraint, preference, policies, desiredProps,
20, offers, iter, limits);
A value of 20 is supplied for the how_many argument, indicating that the client wants at
most 20 offers to be supplied in the offers argument, with the remaining offers (if any)
accessible via the OfferIterator object returned in the iter argument.
After the completion of the query() operation, the client checks to see if no matching
offers were found:
if(offers.value.length == 0 && iter.value == null)
{
System.out.println("No offers found.");
System.exit(0);
}
Technically, this if-test is overkill. Since a non-zero value was provided for the how_many
argument, any offers found would be placed in the offers argument first, therefore simply checking that the length of the offers.value array is 0 is sufficient.
2.4.5
Displaying the Results
The showOffers() method processes an array of service offers. The client invokes
showOffers() once for the offers.value array, and then once for each array of offers
obtained from the OfferIterator object (if any):
showOffers(offers.value);
//
// If we received an iterator, then add all of its
ORBacus Trader
37
Getting Started with ORBacus Trader
// offers to the vector
//
if(iter.value != null)
{
org.omg.CosTrading.OfferSeqHolder seq =
new org.omg.CosTrading.OfferSeqHolder();
boolean more;
do
{
more = iter.value.next_n(20, seq);
showOffers(seq.value);
}
while (more);
iter.value.destroy();
}
Note: The client is responsible for destroying the iterator object after it has finished
retrieving all of the service offers. Failure to destroy the iterator will result in
resource leaks in the trading service.
The showOffers() method performs several steps in the processing of an offer. First, it
narrows the object reference of the offer to a Lender object:
demo.LenderDemo.Lender lender =
demo.LenderDemo.LenderHelper.narrow(offers[i].reference);
Next, it extracts the values of the offer’s properties:
String productId = null;
float rate = 0, pctDown = 0;
short years = 0;
for(int n = 0 ; n < offers[i].properties.length ; n++)
{
org.omg.CosTrading.Property prop = offers[i].properties[n];
if(prop.name.equals("rate"))
rate = prop.value.extract_float();
else if(prop.name.equals("pct_down"))
pctDown = prop.value.extract_float();
else if(prop.name.equals("years"))
years = prop.value.extract_short();
else if(prop.name.equals("product_id"))
productId = prop.value.extract_string();
38
ORBacus Trader
The Client
}
Finally, it determines the name of the lender company, and invokes the request_loan()
operation:
String company = lender.company_name();
boolean approved = lender.request_loan(productId);
2.4.6
Running the Client
To run the Client program, type the following:
java [properties] demo.Client [-h] constraint [preference]
The Client will attempt to read the file policies.dat, and will expect the file to reside
in the current working directory, therefore you need to run the program from the demo
subdirectory. If the program does not find the policies.dat file in the current working
directory, no importer policies will be defined for the query.
One system property is supported by the client:
trader.file
The name of a file containing the stringified IOR of the trader’s
CosTrading::Lookup object. If this property is not defined, the client will
attempt to resolve the TradingService initial reference.
The program supports one command line option:
-h
Displays a help message describing the supported properties and command line options.
The command line arguments constraint and preference are expressions that control
the selection and ordering of service offers. The constraint argument is required, while
the preference argument is optional. If the preference argument is not supplied, the
client will use "first" as the preference expression.
2.4.7
Examples
To specify the name of a file containing the trader’s IOR, use:
java -Dtrader.file=trader.ref demo.Client ...
The following command uses a constraint that selects all loans with an interest rate of
7.5% or less:
ORBacus Trader
39
Getting Started with ORBacus Trader
java demo.Client "rate <= 7.5"
This example finds all 30-year loans with an interest rate of 7%:
java demo.Client "years == 30 and rate == 7"
This example finds all 15-year loans, and uses a preference to order the matched offers by
their interest rate, in ascending order:
java demo.Client "years == 15" "min rate"
2.5
The Dynamic Server
The Dynamic Server is very similar to the Basic Server, but it employs an additional feature of the trading service that makes the Dynamic Server a somewhat more practical
example.
2.5.1
Dynamic Properties
The Dynamic Server uses the trader’s dynamic property mechanism to delegate the evaluation of the rate property, based on the assumption that loan rates can fluctuate frequently throughout the day. See “Dynamic Properties” on page 16 for more information
about dynamic properties.
2.5.2
Overview
The following classes are used in the implementation of the Dynamic Server:
•
demo.dynamic.DynamicServer - Contains main() and supporting methods
•
demo.dynamic.LenderImpl - Our implementation of LenderDemo::Lender.
This implementation is identical to that of the Basic Server.
•
demo.dynamic.RateEval - An implementation of
CosTradingDynamic::DynamicPropEval, which provides dynamic values for
the rate property
•
demo.dynamic.ProductInfo - A simple class that contains the details of each loan
product
•
demo.util.DemoUtil - Contains utility methods for connecting to the trading
service, installing the Mortgage service type and withdrawing old service offers.
The source code for these classes can be found in the dynamic subdirectory.
The Dynamic Server reads its list of products from the file dynprod.dat. This file has a
slightly different format than the products.dat file used by the Basic Server:
40
ORBacus Trader
The Dynamic Server
# This file is for use by DynServer and contains the list of products
# offered by a lender.
#
# The format of the file is:
#
# product_id,rate_min,rate_max,rate_inc,pct_down,years
#
LOAN_D1,6.5,7.0,0.125,20.0,30
LOAN_D2,7.25,7.75,0.125,10.0,30
There are three fields used to determine values for the rate property:
•
rate_min - The minimum allowable value for a rate
•
rate_max - The maximum allowable value for a rate
•
rate_inc - The increments in which a rate can change
The RateEval object, when asked by the trader to provide a value for a rate, will select a
value at random between rate_min and rate_max, at intervals determined by
rate_inc.
2.5.3
Exporting Service Offers
The Dynamic Server operates differently than the Basic Server when exporting service
offers. For each service offer, the Dynamic Server must create a
CosTrading::DynamicProp struct to use as the value of the rate property. This struct
contains the object reference of a RateEval object, a CORBA::TypeCode indicating the
type returned for this property, and a CORBA::Any containing information needed by the
RateEval object.
props[1] = new org.omg.CosTrading.Property();
props[1].name = "rate";
props[1].value = orb.create_any();
org.omg.CosTradingDynamic.DynamicProp dp = new
org.omg.CosTradingDynamic.DynamicProp();
dp.eval_if = new RateEval(orb, prod);
orb.connect(dp.eval_if);
dp.returned_type =
orb.get_primitive_tc(org.omg.CORBA.TCKind.tk_float);
dp.extra_info = orb.create_any();
org.omg.CosTradingDynamic.DynamicPropHelper.
insert(props[1].value, dp);
The value of dp.returned_type must match the type of the property as it is defined in
the service type, so in this case, the type is tk_float. The dp.extra_info member is
ORBacus Trader
41
Getting Started with ORBacus Trader
not used in this case, but it must still be initialized with a CORBA::Any object. The last
statement inserts the DynamicProp struct into the property’s CORBA::Any object.
2.5.4
The RateEval Class
The other significant addition to the Dynamic Server example is the RateEval class.
RateEval is an implementation of the IDL interface CosTradingDynamic::DynamicPropEval, and it is responsible for providing dynamic values for the rate property.
The evalDP() method is invoked by the trader when a value for a dynamic rate property is needed:
public org.omg.CORBA.Any
evalDP(String name,
org.omg.CORBA.TypeCode returned_type,
org.omg.CORBA.Any extra_info)
throws org.omg.CosTradingDynamic.DPEvalFailure
{
org.omg.CORBA.Any result;
if(! name.equals("rate"))
throw new org.omg.CosTradingDynamic.
DPEvalFailure( name, returned_type, extra_info);
//
// Compute a new rate somewhere between rateMin and rateMax
//
int intervals = (int)((info_.rateMax - info_.rateMin) /
info_.rateIncrement);
int n = Math.abs(rand_.nextInt()) % intervals;
float newRate = info_.rateMin + (n * info_.rateIncrement);
result = orb_.create_any();
result.insert_float(newRate);
return result;
}
The method first ensures that the property for which it is being asked to provide a value is
the rate property, and throws an exception if this is not the case.
The method then computes the value for the rate property, creates a CORBA::Any object
in which to store the value, and returns the object.
The Dynamic Server creates one RateEval object for each loan product, which is not a
scalable design if there are many products. For this simple example, however, the
RateEval constructor is supplied with a ProductInfo object containing all of the information needed by evalDP() to compute the rate.
42
ORBacus Trader
The Dynamic Server
2.5.5
Running the Server
To run the Dynamic Server, type the following:
java [properties] demo.dynamic.DynamicServer [options]
The Dynamic Server will attempt to read the file dynprod.dat, and will expect the file to
reside in the current working directory, therefore you need to start the server from the
dynamic subdirectory.
The first time you run the server, you can expect the following output:
Reading products from dynprod.dat...
Exporting service offers...
Server for ‘ACME Loan Corp' is ready...
The server will create the file dynoffer.dat in the current working directory, which
contains the identifiers of the exported service offers.
Subsequent executions of the server will produce slightly different output, as the server
will report when it withdraws old service offers.
Several system properties are supported by the server:
demo.server
The server name to supply to the ORBLayer.init() method.
demo.company The name of the company to be used by the LenderImpl object.
trader.file
The name of a file containing the stringified IOR of the trader’s
CosTrading::Lookup object. If this property is not defined, the server will
attempt to resolve the TradingService initial reference.
The server supports two command line options:
2.5.6
-w
Withdraws old service offers and immediately terminates the server. This is useful if you
want to clean out the offers exported by the server.
-h
Displays a help message describing the supported properties and command line options.
Examples
To specify the name of the company, you would use:
java -Ddemo.company="My Lender" demo.dynamic.DynamicServer
ORBacus Trader
43
Getting Started with ORBacus Trader
To specify the name of a file containing the trader’s IOR, use:
java -Dtrader.file=trader.ref demo.dynamic.DynamicServer
You can run both the Basic Server and the Dynamic Server to provide more offers to clients. You can also experiment with different values for the importer policies that are read
by the Client program from the file policies.dat. In particular, you can change the
use_dynamic_properties policy to false, which will cause the trader to exclude the
offers exported by the Dynamic Server.
When you are finished using the Dynamic Server, you can clean up its offers using:
java demo.dynamic.DynamicServer -w
2.6
The Database Server
The Database Server uses the JDBC classes to communicate with a SQL database. The
server queries the database when determining the available products and when determining the current value of a rate property. Dynamic properties are used by the Database
Server to allow interest rates to be retrieved on demand from the database.
The following classes are used in the implementation of the Database Server:
•
demo.database.DatabaseServer - Contains main() and supporting methods
•
demo.database.DatabaseInfo - Manages database configuration information
•
demo.database.LenderImpl - An implementation of LenderDemo::Lender
•
demo.database.RateEval - An implementation of
CosTradingDynamic::DynamicPropEval, which provides dynamic values for
the rate property
•
demo.database.CreateTables - A standalone program that creates the necessary
tables in the database
•
demo.database.LoadTables - A standalone program that inserts rows in the
tables to describe the available products
•
demo.util.DemoUtil - Contains utility methods for connecting to the trading
service, installing the Mortgage service type and withdrawing old service offers
The source code for these classes can be found in the database subdirectory. See the
ORBACUS TRADER installation instructions for information on configuring this program.
44
ORBacus Trader
The Database Server
2.6.1
Preparing the Database
The Database Server expects the following two tables to exist in the database:
Table: PRODUCTS
Column
Type
PRODUCT_ID
char(25)
PCT_DOWN
real
YEARS
int
Table: RATES
Column
Type
PRODUCT_ID
char(25)
RATE
real
The CreateTables program creates the above tables:
java demo.database.CreateTables
Next, you need to load some sample data into the tables using the LoadTables program:
java demo.database.LoadTables
2.6.2
Connecting to the Database
The DatabaseServer class uses DatabaseInfo when connecting to the database:
Class c = Class.forName(DatabaseInfo.getDriverClass());
c.newInstance();
sqlConnection = java.sql.DriverManager.getConnection(
DatabaseInfo.getURL(), DatabaseInfo.getUser(),
DatabaseInfo.getPassword());
The JDBC driver class is obtained, and a new instance is created. The server then connects
to the database and obtains a java.sql.Connection object.
2.6.3
Exporting Service Offers
The server executes a SQL query to determine the list of available loan products:
ORBacus Trader
45
Getting Started with ORBacus Trader
stmt = sqlConnection.createStatement();
java.sql.ResultSet rs =
stmt.executeQuery("select distinct * from PRODUCTS " +
" order by PRODUCT_ID");
The server then iterates over the results of the query, exporting a service offer for each
product.
while(rs.next())
{
String productId = rs.getString("PRODUCT_ID");
float pctDown = rs.getFloat("PCT_DOWN");
short years = rs.getShort("YEARS");
org.omg.CosTrading.Property[] props =
new org.omg.CosTrading.Property[4];
...
props[1] = new org.omg.CosTrading.Property();
props[1].name = "rate";
props[1].value = orb.create_any();
org.omg.CosTradingDynamic.DynamicProp dp =
new org.omg.CosTradingDynamic.DynamicProp();
dp.eval_if = dynEval;
dp.returned_type =
orb.get_primitive_tc(org.omg.CORBA.TCKind.tk_float);
dp.extra_info = orb.create_any();
dp.extra_info.insert_string(productId);
org.omg.CosTradingDynamic.DynamicPropHelper.
insert(props[1].value, dp);
...
String id = reg.export(lender,
demo.util.DemoUtil.getServiceType(),
props);
...
}
The server obtains the values of the PRODUCT_ID, PCT_DOWN and YEARS columns from
each row, which are used to define the array of properties for the offer.
Like the Dynamic Server, the Database Server creates a DynamicProp struct for the rate
property. In this instance, however, the Database Server uses a single RateEval object
for all offers. This is a much more efficient and scalable design, because a single object
can service requests for all products. However, in order for the RateEval object to look
up the rate for a product, the object must know the product’s identifier. This information is
46
ORBacus Trader
The Database Server
provided by the dp.extra_info member, which the trader passes to the evalDP() operation of the RateEval object.
2.6.4
The RateEval Class
RateEval is an implementation of the IDL interface CosTradingDynamic::DynamicPropEval, and it is responsible for providing dynamic values for the rate property.
The evalDP() method is invoked by the trader when a value for a dynamic rate property is needed:
public synchronized org.omg.CORBA.Any
evalDP(String name,
org.omg.CORBA.TypeCode returned_type,
org.omg.CORBA.Any extra_info)
throws org.omg.CosTradingDynamic.DPEvalFailure
{
org.omg.CORBA.Any result = null;
//
// Validate the property name
//
if(! name.equals("rate"))
throw new org.omg.CosTradingDynamic.
DPEvalFailure(name, returned_type, extra_info);
java.sql.Statement stmt = null;
try
{
//
// The extra_info argument contains the product ID
//
String productId = extra_info.extract_string();
stmt = conn_.createStatement();
java.sql.ResultSet rs =
stmt.executeQuery("select RATE from RATES " +
" where PRODUCT_ID = ’" +
productId + "’");
if(rs.next())
{
float rate = rs.getFloat("RATE");
result = orb_.create_any();
result.insert_float(rate);
}
}
ORBacus Trader
47
Getting Started with ORBacus Trader
catch(...)
{
}
...
return result;
}
The method first ensures that the property for which it is being asked to provide a value is
the rate property, and throws an exception if this is not the case.
As mentioned earlier, the extra_info object is used to supply the product identifier to
the evalDP() method. The identifier is extracted from the CORBA::Any object, and is
used to execute a query to obtain the current value of the rate from the RATES table. If the
result set contains a row, then the value of the RATE column is extracted and stored in the
CORBA::Any object returned to the trader.
2.6.5
The LenderImpl Class
The request_loan() operation of the LenderImpl class still uses a simplistic algorithm for determining whether to grant a loan, but it uses the SQL database to confirm that
the requested loan exists:
stmt = sqlConnection_.createStatement();
java.sql.ResultSet rs =
stmt.executeQuery("select PRODUCT_ID from PRODUCTS where " +
"PRODUCT_ID = ’" + product_id + "’");
if(! rs.next())
throw new demo.LenderDemo.UnknownProduct(product_id);
2.6.6
Running the Server
To run the Database Server, type the following:
java [properties] demo.database.DatabaseServer [options]
The first time you run the server, you can expect the following output:
Exporting service offers...
Server for ‘ACME Loan Corp' is ready...
The server will create the file dboffer.dat in the current working directory, which contains the identifiers of the exported service offers.
48
ORBacus Trader
The Database Server
Subsequent executions of the server will produce slightly different output, as the server
will report when it withdraws old service offers.
Several system properties are supported by the server:
demo.server
The server name to supply to the ORBLayer.init() method.
demo.company The name of the company to be used by the LenderImpl object.
trader.file
The name of a file containing the stringified IOR of the trader’s
CosTrading::Lookup object. If this property is not defined, the server will
attempt to resolve the TradingService initial reference.
The server supports two command line options:
2.6.7
-w
Withdraws old service offers and immediately terminates the server. This is useful if you
want to clean out the offers exported by the server.
-h
Displays a help message describing the supported properties and command line options.
Examples
To specify the name of the company, you would use:
java -Ddemo.company="My Lender" demo.database.DatabaseServer
To specify the name of a file containing the trader’s IOR, use:
java -Dtrader.file=trader.ref demo.database.DatabaseServer
When you are finished using the Database Server, you can clean up its offers using:
java demo.database.DatabaseServer -w
ORBacus Trader
49
Getting Started with ORBacus Trader
50
ORBacus Trader
CHAPTER 3
The Trader Console
The TRADER CONSOLE allows you to manage all aspects of the trading service. The functionality provided by this application includes:
3.1
•
Managing service types, offers, proxy offers and links
•
Performing queries
•
Configuring the trader attributes
Starting the Application
The simplest way to start the application is by using the tconsole shell script (for Unix)
or the tconsole.bat batch file (for Windows). You can edit these files to customize the
start-up parameters for your particular environment.
If you do not wish to use a script to start the application, you can use
java com.ooc.CosTradingConsole.TraderConsole [options]
The following options are supported by the application:
-f file
Specifies the name of a file containing the stringified IOR of the trading service. If this option is not provided, the application will attempt to resolve the
TradingService initial reference.
--windows
Uses the Windows Look and Feel (not available on all platforms).
ORBacus Trader
51
The Trader Console
Uses the Motif Look and Feel.
--motif
--look class Specifies the name of a Look and Feel class.
Displays a help message describing the supported command line options.
-h
The TRADER CONSOLE main window appears as shown in Figure 3.1.
Figure 3.1: The Trader Console main window
The main window includes the following elements:
52
Menu bar
Provides access to all of the application’s features
Toolbar
Shortcuts for the most common menu commands
Item type selector
Selects which type of item is shown in the item list
Item list
Displays the names or identifiers of all items contained in the trader
Item description
Provides a textual summary of the selected item
ORBacus Trader
Terminology
Status bar
3.2
Displays information about the trader to which the console is currently
connected, including the host, port and IDL interface
Terminology
The TRADER CONSOLE application uses the term item to generically refer to the four types
of data managed by a trading service:
•
Service types
•
Offers
•
Proxy offers
•
Links
The console window is used to browse these items. The window only shows one type of
item at a time, which you can change using the item type selector drop-down list1 or by
selecting a type from the View menu. When a new item type is selected, the current list of
items is retrieved from the trading service and displayed in the item list.
3.3
The Trader Console Menus
This section describes the TRADER CONSOLE menu commands.
3.3.1
The Console menu
You use the commands in the Console menu to manage the TRADER CONSOLE windows.
3.3.2
New Window
Creates a new console window, connected to the current trader.
Connect
Opens the Connect dialog box, allowing you to connect to a different
trading service.
Close
Closes the current console window. If this window is the last console
window present, the application will exit.
Exit
Quits the application.
The Edit menu
The TRADER CONSOLE application supports the typical notion of a clipboard, which can
be manipulated using cut, copy and paste commands. However, the TRADER CONSOLE
1. Also known as a combo-box.
ORBacus Trader
53
The Trader Console
application does not use the system clipboard, and therefore the application clipboard can
only be accessed by windows from the same execution of the application. In other words,
if you start two instances of the TRADER CONSOLE application, you cannot cut and paste
between them. You will be able to cut and paste if you start a single instance of the application, and create multiple windows using the Console/New Window command.
Cut
Copies the selected items to the clipboard and then permanently
removes the selected items
Copy
Copies the selected items to the clipboard
Paste
Pastes the items from the clipboard into the current trader
Select All
Selects all of the items in the item list
Clone
Creates a clone of the selected item. The appropriate dialog box is displayed to allow you to create a new item, but the fields of the dialog
box are initialized with the values from the selected item.
Modify
Edits the currently selected item
Delete
Permanently removes the selected items
There are some issues to be aware of when using the cut, copy and paste operations. First,
service types and links must have unique names; therefore, you will not be able to paste
one of these items if an item already exists in the trader with the same name.
Secondly, a certain amount of forethought is advised when you wish to cut and paste service types. Since service types can inherit from other service types, you cannot cut a service type that has subtypes. If you wish to cut or delete a number of service types, and if
inheritance relationships exist between any of them, you must cut the types without any
subtypes first. The same principle applies to pasting service types, in that you cannot paste
a type if its supertypes do not exist or have not yet been pasted. It is recommended that
you only operate on one service type at a time when using the cut, copy, paste or delete
commands.
Some types of items, namely service types and proxy offers, cannot be modified. The
Modify command (and its toolbar equivalent) are disabled while these types are displayed.
The Clone and Modify commands operate on a single item at a time. If more than one
item is currently selected, the application will use the first of the selected items.
54
ORBacus Trader
The Toolbar
3.3.3
The View menu
You use the View menu to select the type of items you wish to be displayed in the item
list. Selecting a new type of item from this menu is equivalent to changing the setting of
the item type selector.
The Refresh command causes the application to retrieve an updated list of items from the
trader and display them in the item list. This command can be useful if you know (or suspect) that the list of items has been changed by some other client of the trading service.
3.3.4
The Insert menu
You use the Insert menu when you want to create a new item. A dialog box will be displayed in which you can supply the information about the new item. If you need to create
a new item that will be similar to an existing item, you can also use the Edit/Clone command.
3.3.5
The Tools menu
The commands available in the Tools menu provide access to additional features of the
trading service.
3.4
Query
Perform query operations on the trader and review the matching offers
Attributes
Configure the trader attributes
Withdraw Offers
Removes offers using a constraint expression
Mask Type
Masks the selected service type
Unmask Type
Unmasks the selected service type
The Toolbar
The toolbar contains buttons for the most common menu commands.
New
Item
Copy
Query
Edit
Cut
ORBacus Trader
Paste
Delete
Refresh
55
The Trader Console
3.5
Managing Service Types
Using the TRADER CONSOLE application, you can manage all aspects of the trader’s service type repository.
Note: Although ORBACUS TRADER supports properties with user-defined types, the
TRADER CONSOLE application only supports simple types and sequences of simple
types.
Refer to “Service Types” on page 9 for more information on service types.
3.5.1
Adding a New Service Type
To add a new service type, do the following:
1. Select Insert/Service Type. The New Service Type dialog box appears as shown
below.
56
ORBacus Trader
Managing Service Types
2. Enter a name for the service type in the Service type name text box. The name must
be unique among all of the service types managed by the trader.
3. Enter an interface repository identifier in the Interface text box. If the interface
repository service is available, clicking the Browse... button will display an interface
repository browser as shown below.
The browser displays only modules and interfaces. When you select an interface, its
identifier is displayed in the ID text box below. Click OK to accept the identifier you
have selected.
4. Use the Add... and Delete buttons to add and remove super types. Clicking the Add...
button displays the Super Types dialog box as shown below. Select any service types
you wish to use as super types for the new type and click OK. The order in which you
add super types is not important.
ORBacus Trader
57
The Trader Console
5. Use the Add..., Edit... and Delete buttons to manipulate the properties for this service
type. Clicking the Add... or Edit... buttons displays the Property dialog box as shown
below. Enter a name for the property, select a property type, and use the checkboxes to
indicate the mode of this property. Click OK to add the new property.
6. Click OK on the New Service Type dialog box to add the new service type.
3.5.2
Removing a Service Type
To remove a service type, do the following:
1. Select View/Service Types to display the service types in the item list.
2. Select the service type you wish to remove.
3. Select Edit/Delete. A confirmation dialog will appear.
4. Click Yes to permanently remove the service type.
Note: If a service type has subtypes, you will not be able to remove the type until all of its
subtypes have been removed.
3.5.3
Masking a Service Type
To mask a service type, do the following:
1. Select View/Service Types to display the service types in the item list.
2. Select the service type you wish to mask.
3. Select Tools/Mask Type.
58
ORBacus Trader
Managing Offers
3.5.4
Unmasking a Service Type
To unmask a service type, do the following:
1. Select View/Service Types to display the service types in the item list.
2. Select the service type you wish to unmask.
3. Select Tools/Unmask Type.
3.6
Managing Offers
3.6.1
Adding a New Offer
To add a new offer, do the following:
1. Select Insert/Offer. The New Offer dialog box appears as shown below.
2. Select a service type from the drop-down list. Each time you select a service type, the
Properties table will be updated to reflect the properties defined for that service type.
3. Select a method for specifying the object reference for this offer. Select the IOR
toggle if you want to paste the stringified interoperable object reference into the text
box. If you want the application to read the reference from a file, select From file and
enter the filename in the text box, or click the Browse... button to display a file
ORBacus Trader
59
The Trader Console
selection dialog box. If the trading service is configured to allow nil objects, and you
do not wish to specify an object reference for this offer, you may leave the object
reference blank.
4. Enter values for the properties in the Properties table. All properties have a checkbox
to the left of the property name. For a mandatory property, the checkbox will be
disabled, meaning that a value must be provided for this property. For an optional
property, you can use the checkbox to indicate whether this property should be
included with the offer. To enter a value for a property, double-click on the property
value field. For properties with sequence types, you can enter multiple values by
separating them with commas. Press Return when you are finished entering the value
for a property.
5. Click the Add... button if you wish to add a property that is not defined by the service
type. The Add Property dialog box appears as shown below. Enter a name for the
property, select the property’s type from the drop-down list, and enter a value in the
text box. The name you use for the property must not be the same as any existing
properties. Click OK to add the property to the Properties table.
Note: Once the property has been added to the Properties table, you can edit it
directly, just as you can with any other property. If you later decide that you do not
want to include the property with the offer, simply uncheck the property’s checkbox.
6. If you wish to make a property dynamic, select the property and click the Dynamic...
button. The Dynamic Property dialog box appears as shown below. Select a method
for specifying an object reference as outlined in step 3 above. If you wish to include
additional data, select a type from the drop-down list and enter a value in the text box.
60
ORBacus Trader
Managing Offers
Click OK to save the dynamic property. The property table will display <dynamic> as
the value of a dynamic property.
7. To clear the value of a property, select the property and click Reset. You can use this
command to convert a property from a dynamic property to a regular property.
8. Click OK to add the new offer. The application will validate the information and
report any errors in a dialog box.
Note: For properties of type string, an empty value is accepted as a valid value, even
for mandatory properties.
3.6.2
Modifying an Offer
To modify an offer, do the following:
1. Select View/Offers to display the offers in the item list.
2. Select the offer you wish to modify.
ORBacus Trader
61
The Trader Console
3. Select Edit/Modify. The Edit Offer dialog box appears as shown below.
4. You can modify a property by double-clicking on the property value. Press Return
when you have finished editing a property value.
5. You can remove an existing property from the offer (if it is an optional property) by
unchecking its checkbox. Similarly, you can add a property to the offer by checking its
checkbox and entering a value for the property.
6. See the discussion of adding a new offer above for details on adding new properties
and configuring dynamic properties.
7. Click OK to update the offer.
3.6.3
Withdrawing Offers
There are two distinct ways to withdraw offers. The first way is by selecting individual
offers, as outlined below:
1. Select View/Offers to display the offers in the item list.
2. Select the offer(s) you wish to withdraw.
3. Select Edit/Delete. A confirmation dialog will appear.
4. Click Yes to withdraw the offers.
The above method is suitable for withdrawing a limited number of specific offers. A more
efficient method for removing a large quantity of offers for a single type, or for removing
62
ORBacus Trader
Managing Offers
offers without having to manually search for the right ones, is by withdrawing offers using
a constraint expression:
1. Select Tools/Withdraw Offers. The Withdraw Offers dialog box appears as shown
below.
2. Select the service type from the drop-down list. Only offers of this service type will be
considered for withdrawal. Offers for subtypes of this service type are not considered.
3. Enter a constraint expression in the text box. See “Constraint” on page 13 for more
information on constraint expressions.
4. Click OK to withdraw the offers. Only offers that match the constraint expression will
be withdrawn. An error message will appear if no matching offers were found.
Note: A simple way to remove all of the offers for a service type is to use “TRUE” for the
constraint expression.
ORBacus Trader
63
The Trader Console
3.7
Managing Proxy Offers
3.7.1
Adding a New Proxy Offer
To add a new proxy offer, do the following:
1. Select Insert/Proxy Offer. The New Proxy Offer dialog box appears as shown
below.
2. Select a service type from the drop-down list. Each time you select a service type, the
property table will be updated to reflect the properties defined for that service type.
64
ORBacus Trader
Managing Proxy Offers
3. Select a method for specifying the object reference of the target
CosTrading::Lookup object for this proxy offer. Select the IOR toggle if you want
to paste the stringified interoperable object reference into the text box. If you want the
application to read the reference from a file, select From file and enter the filename in
the text box, or click the Browse... button to display a file selection dialog box.
4. Enter the constraint recipe in the text box.
5. Select If match all if a matching service type is all that is required for this proxy offer
to be considered a match during a query.
6. Enter values for the properties in the Properties table. All properties have a checkbox
to the left of the property name. For a mandatory property, the checkbox will be
disabled, meaning that a value must be provided for this property. For an optional
property, you can use the checkbox to indicate whether this property should be
included with the offer. To enter a value for a property, double-click on the property
value field. For properties with sequence types, you can enter multiple values by
separating them with commas. Press Return when you are finished entering the value
for a property.
7. If you wish to add a property that is not defined by the service type, click the Add...
button. The Add Property dialog box appears as shown in “Adding a New Offer” on
page 59. Enter a name for the property, select the property’s type from the drop-down
list, and enter a value in the text box. The name you use for the property must not be
the same as any existing properties. Click OK to add the property to the Properties
table.
Note: Once the property has been added to the Properties table, you can edit it
directly, just as you can with any other property. If you later decide that you do not
want to include the property with the proxy offer, simply uncheck the property’s
checkbox.
8. If you wish to make a property dynamic, select the property and click the Dynamic...
button. The Dynamic Property dialog box appears as shown in “Adding a New
Offer” on page 59. Select a method for specifying an object reference as outlined in
step 3 above. If you wish to include additional data, select a type from the drop-down
list and enter a value in the text box. Click OK to save the dynamic property. The
property table will display <dynamic> as the value of a dynamic property.
9. To clear the value of a property, select the property and click Reset. You can use this
command to convert a property from a dynamic property to a regular property.
ORBacus Trader
65
The Trader Console
10. Use the Add..., Edit... and Delete buttons to manipulate the policies to be passed on to
the target object. Clicking the Add... or Edit... buttons displays the Policy dialog box
as shown below.
11. Click OK to add the new proxy offer. The application will validate the information
and report any errors in a dialog box.
Note: For properties of type string, an empty value is accepted as a valid value, even
for mandatory properties.
3.7.2
Withdrawing Proxy Offers
To withdraw a proxy offer, do the following:
1. Select View/Proxy Offers to display the proxy offers in the item list.
2. Select the proxy offer you wish to withdraw.
3. Select Edit/Delete. A confirmation dialog will appear.
4. Click Yes to withdraw the proxy offer.
66
ORBacus Trader
Managing Links
3.8
Managing Links
3.8.1
Adding a New Link
To add a new link, do the following:
1. Select Insert/Link. The New Link dialog box appears as shown below.
2. Enter a name for this link in the text box.
3. Select a method for specifying the target trader’s object reference for this link. Select
the IOR toggle if you want to paste the stringified interoperable object reference into
the text box. If you want the application to read the reference from a file, select From
file and enter the filename in the text box, or click the Browse... button to display a file
selection dialog box.
4. Select the appropriate link-follow rules from the drop-down lists.
5. Click OK to add the new link.
3.8.2
Modifying a Link
To modify a link, do the following:
1. Select View/Links to display the links in the item list.
2. Select the link you wish to modify.
ORBacus Trader
67
The Trader Console
3. Select Edit/Modify. The Edit Link dialog box appears as shown below.
4. Update the settings for the link-follow rules.
5. Click OK to update the link.
3.8.3
Removing a Link
To remove a link, do the following:
1. Select View/Links to display the links in the item list.
2. Select the link you wish to remove.
3. Select Edit/Delete. A confirmation dialog appears.
4. Click Yes to remove the link.
3.9
Configuring the Trader Attributes
To configure the trader attributes, select Tools/Attributes. The Attributes dialog box
appears, containing a tabbed folder with four tabs. The tabs provide access to the attributes
from the following four IDL interfaces:
•
CosTrading::SupportAttributes
•
CosTrading::ImportAttributes
•
CosTrading::LinkAttributes
•
CosTrading::Admin
Each of the tabs is described below. Click OK when you have finished modifying the
attributes.
68
ORBacus Trader
Configuring the Trader Attributes
3.9.1
Support Attributes
Supports modifiable properties
If enabled, the trader will consider offers with modifiable properties (that is, properties
that are not read-only) during a query, unless the importer requests otherwise using the
use_modifiable_properties policy. If disabled, the trader will not consider offers
with modifiable properties, regardless of the importer’s wishes. This setting also determines the behavior of the modify operation in the CosTrading::Register interface. If
enabled, the server will allow modification of offers. If disabled, the modify operation will
raise the NotImplemented exception.
Supports dynamic properties
If enabled, the trader will consider offers with dynamic properties during a query, unless
the importer requests otherwise using the use_dynamic_properties policy. If disabled, the trader will not consider offers with dynamic properties, regardless of the
importer’s wishes. The trading service specification does not define the behavior of a
trader when this option is disabled and an offer is exported that contains dynamic properties, however ORBACUS TRADER will always accept offers containing dynamic properties.
Supports proxy offers
If enabled, the trader will consider proxy offers during a query, unless the importer
requests otherwise using the use_proxy_offers policy. If disabled, the trader will not
consider proxy offers, regardless of the importer’s wishes. This setting also determines the
behavior of the proxy_if attribute in the CosTrading::SupportAttributes inter-
ORBacus Trader
69
The Trader Console
face. If enabled, proxy_if will return the reference of the server’s CosTrading::Proxy
object. If disabled, proxy_if will return nil.
Service Type Repository
The IOR of the service type repository currently in use by the trader is displayed in the
text box. In order to change the service type repository, you first need to select a method
for specifying its object reference. Select the IOR toggle if you want to paste the
stringified IOR into the text box. If you want the application to read the reference from a
file, select From file and enter the filename in the text box, or click the Browse... button
to display a file selection dialog box. See “LOCAL_TYPE_REPOSITORY” on page 81
for more information on changing the service type repository.
3.9.2
Import Attributes
Many of the Import attributes have default and maximum values. The default value is used
if an importer does not supply a value for the corresponding importer policy. The maximum value is used as the allowable upper limit for the importer policy. If an importer supplies a policy value that is greater than the maximum value, the importer’s policy value
will be overridden and the maximum value will be used instead.
Search cardinality
The number of offers to be searched during a query. The corresponding importer policy is
search_card.
70
ORBacus Trader
Configuring the Trader Attributes
Match cardinality
The number of matched offers to be ordered during a query. The corresponding importer
policy is match_card.
Return cardinality
The number of ordered offers to be returned by a query. The corresponding importer policy is return_card.
Link hop count
The depth of links to be traversed during a query. The corresponding importer policy is
hop_count.
Link follow policy
The trader’s behavior when considering whether to follow a link during a query. The
default value is used if an importer does not specify a value for the link_follow_rule
policy. The maximum value overrides the policy established for a link as well as the
link_follow_rule policy proposed by an importer.
Maximum list count
The maximum number of items to be returned from any operation that returns a list, such
as the list_offers operation in CosTrading::Admin or the next_n operation in
CosTrading::OfferIterator. This attribute may override the number of items
requested by a client.
ORBacus Trader
71
The Trader Console
3.9.3
Link Attributes
Maximum link follow policy
Determines the server’s upper bound on the value of a link’s limiting follow rule at the
time of creation or modification of a link. The server will raise the
LimitingFollowTooPermissive exception if a link’s limiting follow rule exceeds the
value of this attribute.
3.9.4
Admin Attributes
Request identifier stem
The request identifier stem is used as a prefix by the server to generate unique request
identifiers during a federated query. Although the IDL attribute request_id_stem
72
ORBacus Trader
Executing Queries
returns a sequence of octets, this property is defined in terms of a string, with the characters of the string comprising the octets of the stem. You need to provide a value for this
property only if the server will have links to other traders and you want to ensure that circular links are handled correctly.
3.10 Executing Queries
To execute a query, do the following:
1. Select Tools/Query. The Query dialog box appears as shown below.
2. Select a service type from the drop-down list.
3. Enter a constraint expression in the Constraint text box.
4. (Optional) Enter a preference expression in the Preference text box. If this field is
blank, the trader will use a default preference expression of "first".
5. If you wish to specify which properties are returned in the matching offers, click
Desired properties to activate the text box below and enter the names of the
properties in the text box. Use commas to separate the property names.
6. To include importer policies, click the Policies... button. The Policies dialog box
appears as shown below. Next to each field label is a checkbox. You must check the
box for a policy for it to be included in your query. Click the Defaults button to load
ORBacus Trader
73
The Trader Console
the trader’s default import attributes into the fields of the dialog box. Click OK to
accept your changes.
7. Click Query to execute the query operation. If matching offers were found, the Query
Results dialog box will appear as shown below. You can scroll through the matching
74
ORBacus Trader
Connecting to a New Trader
offers using the < and > buttons. Click Close when you have finished examining the
results.
Note: The Query Results dialog box cannot be used to edit offers.
3.11 Connecting to a New Trader
When the TRADER CONSOLE application is started, the first console window to appear is
already connected to the trader you specified using the command line options. If you are
ORBacus Trader
75
The Trader Console
managing multiple traders, you can connect to a different trader using the Console/Connect command. The Connect dialog appears as shown below.
There are three methods of connecting to the trader.
1. To provide the stringified object reference, select the Trader IOR option and paste the
IOR into the text box.
2. To obtain the stringified object reference from a file, select IOR from file and enter
the filename in the text box, or click the Browse... button to display a file selection
dialog box.
3. To connect to a linked trader, select the Link option and choose the link from the dropdown list.
Click OK to connect to the trader. The contents of the current console window will be
updated to reflect the new trader.
Note: If you want to be connected to two or more traders at the same time, use the Console/New Window command to create a new console window, then select Console/
Connect to connect the new window to another trader.
76
ORBacus Trader
CHAPTER 4
Configuring ORBacus
Trader
ORBACUS TRADER uses a text file (called the properties file) for storing configuration
parameters. This file is named Trader.properties, and the server expects to find the
file in the server’s database subdirectory. If the file does not exist, the server will print a
warning and will create a new properties file using default values. If you wish to use an
existing properties file, you will need to copy that file into the subdirectory prior to starting the server.
Note: To obtain a default set of properties, rename or delete the properties file and
restart the server.
4.1
Format of the Properties File
The properties file has a very simple format:
•
Blank lines and lines beginning with '#' are ignored.
•
All other lines must have the format Trader.name=value. All text after the equals
(=) character is used as the value of the property (excluding leading and trailing
spaces).
The value of a property can be one of several types:
•
boolean - valid values are true and false
•
string
ORBacus Trader
77
Configuring ORBacus Trader
•
•
integer
FollowOption - representing one of the enumerated values of the
CosTrading::FollowOption type, the valid values are local_only,
if_no_local, and always
A sample properties file is displayed below:
# This file is generated automatically by the server.
# Do not edit if the server is running!
Trader.ALLOW_NIL_OBJECTS=true
Trader.DEF_FOLLOW_POLICY=always
Trader.DEF_HOP_COUNT=5
Trader.DEF_MATCH_CARD=2147483647
Trader.DEF_RETURN_CARD=2147483647
Trader.DEF_SEARCH_CARD=2147483647
Trader.LOCAL_TYPE_REPOSITORY=true
Trader.MAX_DYNPROP_THREADS=10
Trader.MAX_FOLLOW_POLICY=always
Trader.MAX_HOP_COUNT=2147483647
Trader.MAX_LINK_FOLLOW_POLICY=always
Trader.MAX_LINK_THREADS=10
Trader.MAX_LIST=2147483647
Trader.MAX_MATCH_CARD=2147483647
Trader.MAX_PROXY_THREADS=10
Trader.MAX_RETURN_CARD=2147483647
Trader.MAX_SEARCH_CARD=2147483647
Trader.REQUEST_ID_STEM=
Trader.SERVER_NAME=TradingService
Trader.SUPPORTS_DYNAMIC_PROPERTIES=true
Trader.SUPPORTS_MODIFIABLE_PROPERTIES=true
Trader.SUPPORTS_PROXY_OFFERS=true
Trader.USE_INTERFACE_REPOSITORY=true
There are two kinds of properties in the properties file:
•
Properties that correspond to IDL attributes accessible via the interface
CosTrading::Admin. These attributes can also be changed while the server is
running using the TRADER CONSOLE application.
•
78
General configuration properties that have no IDL equivalent. These properties
provide additional control over the server's features and behavior.
ORBacus Trader
Modifying the Properties File
4.2
Modifying the Properties File
As indicated by the comment at the beginning of the sample properties file, you should not
modify the properties file while the server is running, as ORBACUS TRADER may update
this file in response to client activities.
The server reads the properties file once at startup, and does not read the file again. Therefore, any manual changes made to the file after the server has started will have no effect.
Furthermore, those changes will be lost the next time the server updates the file.
4.3
Configuration Properties
The list of available configuration properties is provided below. The name of the IDL
attribute that is equivalent to a property is provided where appropriate. For the sake of
brevity, the Trader prefix has been omitted from the property name.
4.3.1
ALLOW_NIL_OBJECTS
Property type:
boolean
Default value:
true
IDL equivalent: None
When exporting a service offer, the server can be configured to accept or reject offers with
a nil object reference. By setting this property to true, offers with nil object references
will be accepted. If the property is set to false, the server will raise the
InvalidObjectRef exception when a client attempts to export an offer with a nil
object reference.
4.3.2
DEF_FOLLOW_POLICY
Property type:
FollowOption
Default value:
always
IDL equivalent: def_follow_policy
Determines the server’s default link-follow behavior. The server will use this value if an
importer does not provide a value for the link_follow_rule policy.
ORBacus Trader
79
Configuring ORBacus Trader
4.3.3
DEF_HOP_COUNT
Property type:
int
Default value:
5
IDL equivalent: def_hop_count
Determines the server’s default upper bound on the depth of links to be traversed during a
query. The server will use this value if an importer does not provide a value for the
hop_count policy.
4.3.4
DEF_MATCH_CARD
Property type:
int
Default value:
2147483647
IDL equivalent: def_match_card
Determines the server’s default upper bound on the number of matched offers to be
ordered during a query. The server will use this value if an importer does not provide a
value for the match_card policy.
4.3.5
DEF_RETURN_CARD
Property type:
int
Default value:
2147483647
IDL equivalent: def_return_card
Determines the server’s default upper bound on the number of ordered offers to be
returned by a query. The server will use this value if an importer does not provide a value
for the return_card policy.
4.3.6
DEF_SEARCH_CARD
Property type:
int
Default value:
2147483647
IDL equivalent: def_search_card
Determines the server’s default upper bound on the number of offers to be searched during
a query. The server will use this value if an importer does not provide a value for the
search_card policy.
80
ORBacus Trader
Configuration Properties
4.3.7
LOCAL_TYPE_REPOSITORY
Property type:
boolean
Default value:
true
IDL equivalent: None
Determines whether the server uses a local service type repository or one from another
trader. If true, the server uses a local repository and writes the IOR of the repository to
the file repository.ref in the server’s database subdirectory. If false, the server
expects the repository.ref file to already exist and to contain the IOR of the repository to be used.
In short, if you want the server to use the service type repository from another trader, simply copy the repository.ref file from the remote trader to the local database subdirectory, and set this property to false. The service types resident in the local repository are
not lost when this property is set to false.
If you wish to return to using the local repository, just change the property back to true.
At start-up, the server always overwrites the repository.ref file when this property is
true.
Note that the service type repository can also be modified using the Trader Console, or by
any client using the CosTrading::Admin::set_type_repos operation. When this
operation is used, the LOCAL_TYPE_REPOSITORY property is set to false, the IOR of the
new repository is written to repository.ref, and the server immediately begins using
the new repository (i.e., there is no need to restart the server).
4.3.8
MAX_DYNPROP_THREADS
Property type:
int
Default value:
10
IDL equivalent: None
Determines the server's upper bound on the number of internal threads to create for evaluating offers containing dynamic properties.
ORBacus Trader
81
Configuring ORBacus Trader
4.3.9
MAX_FOLLOW_POLICY
Property type:
FollowOption
Default value:
always
IDL equivalent: max_follow_policy
Maximum link-follow behavior allowed for all links of the trader. This property overrides
the policy established for a link as well as the link_follow_rule policy proposed by an
importer.
4.3.10 MAX_HOP_COUNT
Property type:
int
Default value:
2147483647
IDL equivalent: max_hop_count
Determines the server’s maximum upper bound on the depth of links to be traversed during a query. This property will override an importer’s value for the hop_count policy.
4.3.11 MAX_LINK_FOLLOW_POLICY
Property type:
FollowOption
Default value:
always
IDL equivalent: max_link_follow_policy
Determines the server’s upper bound on the value of a link’s limiting follow rule at the
time of creation or modification of a link. The server will raise the
LimitingFollowTooPermissive exception if a link’s limiting follow rule exceeds the
value of this property.
4.3.12 MAX_LINK_THREADS
Property type:
int
Default value:
10
IDL equivalent: None
Determines the server’s upper bound on the number of internal threads to create for processing federated queries.
82
ORBacus Trader
Configuration Properties
4.3.13 MAX_LIST
Property type:
int
Default value:
2147483647
IDL equivalent: max_list
The maximum number of items to be returned from any operation that returns a list, such
as the list_offers operation in CosTrading::Admin or the next_n operation in
CosTrading::OfferIterator. This property may override the number of items
requested by a client.
4.3.14 MAX_MATCH_CARD
Property type:
int
Default value:
2147483647
IDL equivalent: max_match_card
Determines the server’s maximum upper bound on the number of matched offers to be
ordered during a query. This property will override an importer’s value for the
match_card policy.
4.3.15 MAX_PROXY_THREADS
Property type:
int
Default value:
10
IDL equivalent: None
Determines the server’s upper bound on the number of internal threads to create for evaluating proxy offers.
4.3.16 MAX_RETURN_CARD
Property type:
int
Default value:
2147483647
IDL equivalent: max_return_card
Determines the server’s maximum upper bound on the number of ordered offers to be
returned by a query. This property will override an importer’s value for the return_card
policy.
ORBacus Trader
83
Configuring ORBacus Trader
4.3.17 MAX_SEARCH_CARD
Property type:
int
Default value:
2147483647
IDL equivalent: max_search_card
Determines the server’s maximum upper bound on the number of offers to be searched
during a query. This property will override an importer’s value for the search_card policy.
4.3.18 REQUEST_ID_STEM
Property type:
String
Default value:
None
IDL equivalent: request_id_stem
The request identifier stem is used as a prefix by the server to generate unique request
identifiers during a federated query. Although the IDL attribute request_id_stem
returns a sequence of octets, this property is defined in terms of a string, with the characters of the string comprising the octets of the stem. You need to provide a value for this
property only if the server will have links to other traders and you want to ensure that circular links are handled correctly.
4.3.19 SERVER_NAME
Property type:
String
Default value:
TradingService
IDL equivalent: None
Some object request brokers support the notion of a named server and/or named objects.
This property specifies the well-known name used for the server.
4.3.20 SUPPORTS_DYNAMIC_PROPERTIES
Property type:
boolean
Default value:
true
IDL equivalent: supports_dynamic_properties
If true, the trader will consider offers with dynamic properties during a query, unless the
importer requests otherwise. If false, the trader will not consider offers with dynamic
properties, regardless of the importer’s wishes. The trading service specification does not
define the behavior of a trader when supports_dynamic_properties is false and an
84
ORBacus Trader
Configuration Properties
offer is exported that contains dynamic properties, however ORBACUS TRADER will
always accept offers containing dynamic properties.
4.3.21 SUPPORTS_MODIFIABLE_PROPERTIES
Property type:
boolean
Default value:
true
IDL equivalent: supports_modifiable_properties
If true, the trader will consider offers with modifiable properties (that is, properties that
are not read-only) during a query, unless the importer requests otherwise. If false, the
trader will not consider offers with modifiable properties, regardless of the importer’s
wishes. This setting also determines the behavior of the modify operation in the
CosTrading::Register interface. If true, the server will allow modification of offers.
If false, the modify operation will raise the NotImplemented exception.
4.3.22 SUPPORTS_PROXY_OFFERS
Property type:
boolean
Default value:
true
IDL equivalent: supports_proxy_offers
If true, the trader will consider proxy offers during a query, unless the importer requests
otherwise. If false, the trader will not consider proxy offers, regardless of the importer’s
wishes. This setting also determines the behavior of the proxy_if attribute in the
CosTrading::SupportAttributes interface. If true, proxy_if will return the reference of the server’s CosTrading::Proxy object. If false, proxy_if will return nil.
4.3.23 USE_INTERFACE_REPOSITORY
Property type:
boolean
Default value:
true
IDL equivalent: None
If true, and if the server is able to resolve the InterfaceRepository initial reference,
then the server will use the interface repository to validate the inheritance relationship of
service types and to confirm that an exported offer’s object reference conforms to the
interface defined by the service type. If false, or if the InterfaceRepository initial
reference cannot be resolved, no validation is performed.
ORBacus Trader
85
Configuring ORBacus Trader
86
ORBacus Trader
Trading Service Reference
APPENDIX A
A.1
Module CosTrading
Contains the major functional interfaces of a trading service.
Aliases
Istring
typedef string Istring;
When internationalized strings are widely supported, this definition will be changed.
TypeRepository
typedef Object TypeRepository;
TypeRepository represents an object reference for a CosTradingRepos::ServiceTypeRepository object. You will need to narrow this reference before you can interact with the ser-
vice type repository.
PropertyName
typedef Istring PropertyName;
Although not explicitly defined in the specification, a property name should start with a letter,
ORBacus Trader
87
Trading Service Reference
may contain digits and underscores, and should not contain spaces.
PropertyNameSeq
typedef sequence<PropertyName> PropertyNameSeq;
PropertyValue
typedef any PropertyValue;
A CORBA::Any containing the value of the property. ORBacus Trader allows arbitrarily complex user-defined types to be used as property values.
PropertySeq
typedef sequence<Property> PropertySeq;
OfferSeq
typedef sequence<Offer> OfferSeq;
OfferId
typedef string OfferId;
An offer identifier is an opaque string whose format is determined entirely by the trading service from which the offer identifier was obtained, and can only be used with that trading service.
OfferIdSeq
typedef sequence<OfferId> OfferIdSeq;
ServiceTypeName
typedef Istring ServiceTypeName;
A service type name can have one of two formats, both representing formats that appear in the
Interface Repository.
• Scoped Name - A scoped name has the form ::One::Two. Other supported variations are
Three::Four and Five.
• Interface Repository Identifier - An interface repository identifier has the form
IDL:[prefix/][module/]name:X.Y. For example, IDL:omg.org/CosTrading/
Lookup:1.0 is a valid interface repository identifier, and you can use the same format for
your service type names.
Note: Although a service type name can appear similar to names used in the interface repository, the trading service never uses the interface repository to obtain information about a service
type.
88
ORBacus Trader
Module CosTrading
Constraint
typedef Istring Constraint;
A query constraint expression. The constraint is used to filter offers during a query, and must
evaluate to a boolean expression.
The constraint language consists of the following elements:
• comparative functions: ==, !=, >, >=, <, <=, ~ (substring match), in (element in sequence)
• boolean connectives: and, or, not
• property existence: exist
• property names
• numeric, boolean and string constants
• mathematical operators: +, -, *, /
• grouping operators: (, )
The following property value types can be manipulated using the constraint language:
• boolean, short, unsigned short, long, unsigned long, float, double, char, Ichar, string, Istring
• sequences of the above types
Only the exist operator can be used on properties of other types.
Notes:
• The constraint language keywords are case-sensitive
• Literal strings should be enclosed in single quotes
• The boolean literals are TRUE and FALSE
LinkName
typedef Istring LinkName;
The name of a unidirectional link from one trader to another. The only restriction on the format
of a link name is it cannot be an empty string.
LinkNameSeq
typedef sequence<LinkName> LinkNameSeq;
TraderName
typedef LinkNameSeq TraderName;
A TraderName represents a path from one trader to the desired trader by following a sequence
of links. The starting_trader importer policy, if specified for a query operation, should
contain a value of this type.
PolicyName
typedef string PolicyName;
ORBacus Trader
89
Trading Service Reference
The name of a policy used to control the trader’s behavior. The only restriction on the format of
a policy name is it cannot be an empty string.
PolicyNameSeq
typedef sequence<PolicyName> PolicyNameSeq;
PolicyValue
typedef any PolicyValue;
PolicySeq
typedef sequence<Policy> PolicySeq;
Structs
Property
struct Property
{
PropertyName name;
PropertyValue value;
};
A name-value pair associated with a service offer or proxy offer. If the property name matches
the name of a property in the offer’s service type, then the TypeCode of the value must match
the property definition in the service type.
Note: ORBacus Trader allows properties to be associated with an offer even if the property
name does not match any property in the service type. These properties can also be used in
query constraint and preference expressions.
Members:
name - The name of the property.
value - A CORBA::Any value containing the value of the property.
Offer
struct Offer
{
Object reference;
PropertySeq properties;
};
The description of a service offer.
90
ORBacus Trader
Module CosTrading
Members:
reference - The object reference associated with this offer. Depending on the configuration of the server, this reference may be nil.
properties - A sequence of properties associated with this offer.
Policy
struct Policy
{
PolicyName name;
PolicyValue value;
};
Exceptions
UnknownMaxLeft
exception UnknownMaxLeft
{
};
The iterator does not know how many items are left.
NotImplemented
exception NotImplemented
{
};
The requested operation is not supported by this trading service.
IllegalServiceType
exception IllegalServiceType
{
ServiceTypeName type;
};
A service type name does not conform to the formats supported by the trader.
UnknownServiceType
exception UnknownServiceType
{
ServiceTypeName type;
};
The service type repository used by the trader does not have the requested service type.
ORBacus Trader
91
Trading Service Reference
IllegalPropertyName
exception IllegalPropertyName
{
PropertyName name;
};
The property name is empty or does not conform the format supported by the trader.
DuplicatePropertyName
exception DuplicatePropertyName
{
PropertyName name;
};
The property name has already appeared once.
PropertyTypeMismatch
exception PropertyTypeMismatch
{
ServiceTypeName type;
Property prop;
};
The property value type conflicts with the property’s definition in the service type.
MissingMandatoryProperty
exception MissingMandatoryProperty
{
ServiceTypeName type;
PropertyName name;
};
No value was supplied for a property defined as mandatory by the service type.
ReadonlyDynamicProperty
exception ReadonlyDynamicProperty
{
ServiceTypeName type;
PropertyName name;
};
A property that is defined as read-only by the service type cannot have a dynamic value.
92
ORBacus Trader
Module CosTrading
IllegalConstraint
exception IllegalConstraint
{
Constraint constr;
};
An error occurred while parsing the constraint expression.
InvalidLookupRef
exception InvalidLookupRef
{
Lookup target;
};
The Lookup object reference cannot be nil.
IllegalOfferId
exception IllegalOfferId
{
OfferId id;
};
The offer identifier is empty or malformed.
UnknownOfferId
exception UnknownOfferId
{
OfferId id;
};
The trader does not contain an offer with the given identifier.
DuplicatePolicyName
exception DuplicatePolicyName
{
PolicyName name;
};
More than one value was supplied for a policy.
Enums
FollowOption
ORBacus Trader
93
Trading Service Reference
enum FollowOption
{
local_only,
if_no_local,
always
};
Determines the follow behavior for linked traders.
Members:
local_only - The trader will not follow a link
if_no_local - The trader will only follow a link if no offers were found locally
always - The trader will always follow a link
94
ORBacus Trader
Interface CosTrading::TraderComponents
A.2
Interface CosTrading::TraderComponents
interface TraderComponents
Each of the five major interfaces of the CosTrading module inherit from this interface. By doing
so, any of the trader components can be obtained using a reference to any of the other components.
A nil value will be returned by an attribute if the trader does not support that interface.
Attributes
lookup_if
readonly attribute Lookup lookup_if;
register_if
readonly attribute Register register_if;
link_if
readonly attribute Link link_if;
proxy_if
readonly attribute Proxy proxy_if;
admin_if
readonly attribute Admin admin_if;
ORBacus Trader
95
Trading Service Reference
A.3
Interface CosTrading::SupportAttributes
interface SupportAttributes
The read-only attributes in this interface determine what additional functionality a trader supports,
and also provide access to the service type repository used by the trader.
Attributes
supports_modifiable_properties
readonly attribute boolean supports_modifiable_properties;
If false, the modify operation of the Register interface will raise NotImplemented.
supports_dynamic_properties
readonly attribute boolean supports_dynamic_properties;
If false, offers with dynamic properties will not be considered during a query.
supports_proxy_offers
readonly attribute boolean supports_proxy_offers;
If false, the proxy_if attribute of the TraderComponents interface will return nil, and
proxy offers will not be considered during a query.
type_repos
readonly attribute TypeRepository type_repos;
Returns the object reference of the service type repository used by the trader.
96
ORBacus Trader
Interface CosTrading::ImportAttributes
A.4
Interface CosTrading::ImportAttributes
interface ImportAttributes
The read-only attributes of this interface provide the default and maximum values for policies that
govern query operations.
Note: Performing a query is also known as importing service offers, therefore these attributes are
called import attributes.
Attributes
def_search_card
readonly attribute unsigned long def_search_card;
The default value for the search_card policy if it is not supplied.
max_search_card
readonly attribute unsigned long max_search_card;
The maximum value for the search_card policy, which may override the value supplied by
an importer.
def_match_card
readonly attribute unsigned long def_match_card;
The default value for the match_card policy if it is not supplied.
max_match_card
readonly attribute unsigned long max_match_card;
The maximum value for the match_card policy, which may override the value supplied by an
importer.
def_return_card
readonly attribute unsigned long def_return_card;
The default value for the return_card policy if it is not supplied.
max_return_card
ORBacus Trader
97
Trading Service Reference
readonly attribute unsigned long max_return_card;
The maximum value for the return_card policy, which may override the value supplied by
an importer.
max_list
readonly attribute unsigned long max_list;
The maximum size of any list returned by the trader. This may override the value supplied by a
client to operations such as query and next_n.
def_hop_count
readonly attribute unsigned long def_hop_count;
The default value for the hop_count policy if it is not supplied.
max_hop_count
readonly attribute unsigned long max_hop_count;
The maximum value for the hop_count policy, which may override the value supplied by an
importer.
def_follow_policy
readonly attribute FollowOption def_follow_policy;
The default value for the follow_policy policy if it is not supplied.
max_follow_policy
readonly attribute FollowOption max_follow_policy;
The maximum value for the follow_policy policy, which may override the value supplied by
an importer.
98
ORBacus Trader
Interface CosTrading::LinkAttributes
A.5
Interface CosTrading::LinkAttributes
interface LinkAttributes
Contains a single attribute that is applied when a link is created or modified.
Attributes
max_link_follow_policy
readonly attribute FollowOption max_link_follow_policy;
Determines the most permissive behavior that will be allowed for any link.
ORBacus Trader
99
Trading Service Reference
A.6
Interface CosTrading::Lookup
interface Lookup
inherits from CosTrading::TraderComponents, CosTrading::SupportAttributes, CosTrading::ImportAttributes
Provides a single operation, query, for use by importers.
Aliases
Preference
typedef Istring Preference;
A query preference expression. The preference is used to order the offers found by a query. The
valid forms of a preference expression are:
• min numeric-expression - Orders the offers in ascending order based on the numeric expression. Offers for which the expression cannot be evaluated (for example, if the offer does not
contain a property that is used in the expression) are placed at the end of the sequence.
• max numeric-expression - Orders the offers in descending order based on the numeric
expression. Offers for which the expression cannot be evaluated (for example, if the offer
does not contain a property that is used in the expression) are placed at the end of the
sequence.
• with boolean-expression - Orders the offers such that those for which the boolean expression are true are included before any of those for which the expression is false, which are
placed before any of those that cannot be evaluated.
• random - Orders the offers in random order.
• first - Orders the offers as they are encountered by the server.
If an empty preference expression is supplied, it is equivalent to a preference of first.
Exceptions
IllegalPreference
exception IllegalPreference
{
Preference pref;
};
An error occurred while parsing the preference expression.
IllegalPolicyName
exception IllegalPolicyName
100
ORBacus Trader
Interface CosTrading::Lookup
{
PolicyName name;
};
The policy name is empty or does not conform the format supported by the trader.
PolicyTypeMismatch
exception PolicyTypeMismatch
{
Policy the_policy;
};
The policy value type does not match the type expected by the trader.
InvalidPolicyValue
exception InvalidPolicyValue
{
Policy the_policy;
};
The policy has an invalid value.
Unions
SpecifiedProps
union SpecifiedProps switch(HowManyProps)
{
case some: PropertyNameSeq prop_names;
};
Determines which properties are to be returned for each matching offer found by the query
operation. The union’s discriminator can meaningfully be set to the other enumerated values
none and all. If set to none, you are indicating that no properties should be returned. If set to
all, then all properties will be returned.
Members:
some - Set this value with a sequence of property names indicating which properties should
be returned
Enums
HowManyProps
enum HowManyProps
ORBacus Trader
101
Trading Service Reference
{
none,
some,
all
};
The choices for indicating how many properties are returned with each offer.
Members:
none - No properties should be returned
some - Some properties should be returned
all - All properties should be returned
Operations
query
void query(in ServiceTypeName type,
in Constraint constr,
in Preference pref,
in PolicySeq policies,
in SpecifiedProps desired_props,
in unsigned long how_many,
out OfferSeq offers,
out OfferIterator offer_itr,
out PolicyNameSeq limits_applied)
raises(IllegalServiceType,
UnknownServiceType,
IllegalConstraint,
IllegalPreference,
IllegalPolicyName,
PolicyTypeMismatch,
InvalidPolicyValue,
IllegalPropertyName,
DuplicatePropertyName,
DuplicatePolicyName);
Allows an importer to obtain references to objects that provide services meeting its requirements.
The importer can control the behavior of the search by supplying values for certain policies.
The trader may override some or all of the values supplied by the importer. The following policies are known by the trader:
102
ORBacus Trader
Interface CosTrading::Lookup
•
•
•
•
•
•
•
•
•
•
exact_type_match (boolean) - If TRUE, only offers of exactly the service type specified
by the importer are considered; if FALSE, offers of any service type that conforms to the
importer’s service type are considered
hop_count (unsigned long) - Indicates maximum number of hops across federation links
that should be tolerated in the resolution of this query
link_follow_rule (FollowOption) - Indicates how the client wishes links to be followed
in the resolution of this query
match_card (unsigned long) - Indicates the maximum number of matching offers to which
the preference specification should be applied
return_card (unsigned long) - Indicates the maximum number of matching offers to
return as a result of this query
search_card (unsigned long) - Indicates the maximum number of offers to be considered
when looking for type conformance and constraint expression match
starting_trader (TraderName) - Specifies the remote trader at which the query starts
use_dynamic_properties (boolean) - Specifies whether to consider offers with dynamic
properties
use_modifiable_properties (boolean) - Specifies whether to consider offers with
modifiable properties
use_proxy_offers (boolean) - Specifies whether to consider proxy offers
Parameters:
type - Specifies the service type in which the importer is interested. The service type limits
the scope of the search to only those offers exported for this type, and optionally any subtype of this type.
constr - Limits the search to only those offers for which this expression is TRUE. The simplest constraint expression is "TRUE", which matches any offer.
pref - Specifies how the matched offers are to be ordered.
policies - Policies that govern the behavior of the query.
desired_props - Determines the properties that are to be included with each offer
returned by the query. This parameter does not affect whether or not a service offer is
returned. To exclude an offer that does not contain a desired property, include " exist
property-name" in the constraint.
how_many - Indicates how many offers are to be returned in the offers parameter.
offers - Holds at most how_many offers. If the number of matching offers exceeds
how_many, the offer_itr parameter will hold a reference to an iterator object through
which the remaining offers can be obtained.
offer_itr - Will hold nil if no matching offers were found or if all of the matching offers
were returned in offers; otherwise, holds a reference to an iterator. The object’s destroy
operation should be invoked when the object is no longer needed.
limits_applied - Holds the names of any policies that were overridden by the trader’s
maximum allowable settings.
ORBacus Trader
103
Trading Service Reference
Raises:
IllegalServiceType - Service type name is empty or has an invalid format
UnknownServiceType - Service type was not found in service type repository
IllegalConstraint - An error occurred while parsing the constraint expression
IllegalPreference - An error occurred while parsing the preference expression
IllegalPolicyName - A policy name is empty or has an invalid format
PolicyTypeMismatch - A policy value type did not match the type expected by the trader
InvalidPolicyValue - A policy has an invalid value
IllegalPropertyName - A property name is empty or has an invalid format
DuplicatePropertyName - A property name appeared more than once in the list of
desired properties
DuplicatePolicyName - A policy name appeared more than once in the list of policies
104
ORBacus Trader
Interface CosTrading::Register
A.7
Interface CosTrading::Register
interface Register
inherits from CosTrading::TraderComponents, CosTrading::SupportAttributes
Provides operations for managing service offers.
Structs
OfferInfo
struct OfferInfo
{
Object reference;
ServiceTypeName type;
PropertySeq properties;
};
A complete description of a service offer.
Members:
reference - The object reference associated with this offer. Depending on the configuration of the server, this reference may be nil.
type - The service type for which this offer was exported
properties - A sequence of properties associated with this offer.
Exceptions
InvalidObjectRef
exception InvalidObjectRef
{
Object ref;
};
The object reference is nil, and the trader is is configured to reject offers with nil references.
UnknownPropertyName
exception UnknownPropertyName
{
PropertyName name;
};
A property was identified for removal that does not exist in the offer.
ORBacus Trader
105
Trading Service Reference
InterfaceTypeMismatch
exception InterfaceTypeMismatch
{
ServiceTypeName type;
Object reference;
};
If the trader is configured to use the interface repository, then it will attempt to confirm that the
interface of the object reference conforms to the interface of the service type. If the trader is
able to determine that there is a mismatch, this exception is thrown.
ProxyOfferId
exception ProxyOfferId
{
OfferId id;
};
The offer identifier actually refers to a proxy offer.
MandatoryProperty
exception MandatoryProperty
{
ServiceTypeName type;
PropertyName name;
};
A mandatory property cannot be removed.
ReadonlyProperty
exception ReadonlyProperty
{
ServiceTypeName type;
PropertyName name;
};
A read-only property cannot be modified.
NoMatchingOffers
exception NoMatchingOffers
{
Constraint constr;
};
106
ORBacus Trader
Interface CosTrading::Register
No matching offers were found matching the constraint expression.
IllegalTraderName
exception IllegalTraderName
{
TraderName name;
};
The trader name was empty, or a component of the name was not a valid link name.
UnknownTraderName
exception UnknownTraderName
{
TraderName name;
};
The trader name could not be correctly resolved to a trader.
RegisterNotSupported
exception RegisterNotSupported
{
TraderName name;
};
The resolve operation is not supported by this trader.
Operations
export
OfferId export(in Object reference,
in ServiceTypeName type,
in PropertySeq properties)
raises(InvalidObjectRef,
IllegalServiceType,
UnknownServiceType,
InterfaceTypeMismatch,
IllegalPropertyName,
PropertyTypeMismatch,
ReadonlyDynamicProperty,
MissingMandatoryProperty,
DuplicatePropertyName);
Creates a new service offer. A client wishing to advertise a new offer is called an exporter.
ORBacus Trader
107
Trading Service Reference
Parameters:
reference - Reference to an object that enables a client to interact with a remote server.
type - Identifies the service type for which this offer is advertised.
properties - List of named values that describe the service being offered.
Returns:
Identifier of new offer
Raises:
InvalidObjectRef - Object reference is nil and the trader has been configured to reject
nil references
IllegalServiceType - Service type name is empty or has an invalid format
UnknownServiceType - Service type was not found in service type repository
InterfaceTypeMismatch - Trader was able to determine that the interface of the object
reference does not conform to the the interface of the service type
IllegalPropertyName - Property name is empty or has an invalid format
PropertyTypeMismatch - Property value type does not match the property definition of
the service type
ReadonlyDynamicProperty - Read-only properties cannot have dynamic values
MissingMandatoryProperty - No value was supplied for a mandatory property
DuplicatePropertyName - Property name appeared more than once in list of properties
withdraw
void withdraw(in OfferId id)
raises(IllegalOfferId,
UnknownOfferId,
ProxyOfferId);
Removes a service offer.
Parameters:
id - Identifier of the offer to be withdrawn
Raises:
IllegalOfferId - Offer identifier is empty or has an invalid format
UnknownOfferId - No offer was found with the given identifier
ProxyOfferId - Offer identifier refers to a proxy offer. Proxy offers must be removed
using the Proxy interface.
describe
OfferInfo describe(in OfferId id)
raises(IllegalOfferId,
UnknownOfferId,
108
ORBacus Trader
Interface CosTrading::Register
ProxyOfferId);
Obtains the description of a service offer.
Parameters:
id - Identifier of the offer of interest
Returns:
OfferInfo struct describing the offer
Raises:
IllegalOfferId - Offer identifier is empty or has an invalid format
UnknownOfferId - No offer was found with the given identifier
ProxyOfferId - Offer identifier refers to a proxy offer. Proxy offers must be described
using the Proxy interface.
modify
void modify(in OfferId id,
in PropertyNameSeq del_list,
in PropertySeq modify_list)
raises(NotImplemented,
IllegalOfferId,
UnknownOfferId,
ProxyOfferId,
IllegalPropertyName,
UnknownPropertyName,
PropertyTypeMismatch,
ReadonlyDynamicProperty,
MandatoryProperty,
ReadonlyProperty,
DuplicatePropertyName);
Modifies an existing service offer to add new properties, and change or delete existing properties.
Parameters:
id - Identifier of the offer to be modified
del_list - Names of properties to be removed
modify_list - Properties to be added or modified
Raises:
NotImplemented - Trader does not support modification of properties
IllegalOfferId - Offer identifier is empty or has an invalid format
ORBacus Trader
109
Trading Service Reference
UnknownOfferId - No offer was found with the given identifier
ProxyOfferId - Offer identifier refers to a proxy offer. Proxy offers must be described
using the Proxy interface.
IllegalPropertyName - Property name is empty or has an invalid format
UnknownPropertyName - Property to be removed does not exist in offer
PropertyTypeMismatch - Property value type does not match the property definition of
the service type
ReadonlyDynamicProperty - Read-only properties cannot have dynamic values
MandatoryProperty - Mandatory properties cannot be removed
ReadonlyProperty - Read-only properties cannot be modified
DuplicatePropertyName - Property name appeared more than once in list of properties
withdraw_using_constraint
void withdraw_using_constraint(in ServiceTypeName type,
in Constraint constr)
raises(IllegalServiceType,
UnknownServiceType,
IllegalConstraint,
NoMatchingOffers);
Withdraws all offers for a particular service type that match a constraint expression. Only offers
that exactly match the given service type are considered. Proxy offers are not considered, and
links are not followed.
Parameters:
type - Identifies the service type for which offers are to be removed.
constr - Limits the search to only those offers for which this expression is TRUE. The simplest constraint expression is "TRUE", which matches any offer and is an efficient way to
withdraw all offers for a service type.
Raises:
IllegalServiceType - Service type name is empty or has an invalid format
UnknownServiceType - Service type was not found in service type repository
IllegalConstraint - An error occurred while parsing the constraint expression
NoMatchingOffers - No matching offers were found
resolve
Register resolve(in TraderName name)
raises(IllegalTraderName,
UnknownTraderName,
RegisterNotSupported);
Resolves a context-relative name for another trader.
110
ORBacus Trader
Interface CosTrading::Register
Parameters:
name - Identifies the trader to be resolved
Returns:
Register interface of the resolved trader
Raises:
IllegalTraderName - Trader name was empty, or a component of the name was not a
valid link name
UnknownTraderName - Trader name could not be correctly resolved to a trader
RegisterNotSupported - Trader does not support this operation
ORBacus Trader
111
Trading Service Reference
A.8
Interface CosTrading::Link
interface Link
inherits from CosTrading::TraderComponents, CosTrading::SupportAttributes, CosTrading::LinkAttributes
Provides operations for managing links between traders.
Structs
LinkInfo
struct LinkInfo
{
Lookup target;
Register target_reg;
FollowOption def_pass_on_follow_rule;
FollowOption limiting_follow_rule;
};
A complete description of a link.
Members:
target - Lookup interface of link target
target_reg - Register interface of link target
def_pass_on_follow_rule - Default link behavior for the link if no link-follow policy is
specified by an importer during a query
limiting_follow_rule - Most permissive link-follow behavior that the link is willing to
tolerate
Exceptions
IllegalLinkName
exception IllegalLinkName
{
LinkName name;
};
The link name is empty or does not conform the format supported by the trader.
UnknownLinkName
exception UnknownLinkName
{
112
ORBacus Trader
Interface CosTrading::Link
LinkName name;
};
Trader does not have a link with the given name.
DuplicateLinkName
exception DuplicateLinkName
{
LinkName name;
};
A link already exists with the given name.
DefaultFollowTooPermissive
exception DefaultFollowTooPermissive
{
FollowOption def_pass_on_follow_rule;
FollowOption limiting_follow_rule;
};
The value for def_pass_on_follow_rule exceeds the value for limiting_follow_rule.
LimitingFollowTooPermissive
exception LimitingFollowTooPermissive
{
FollowOption limiting_follow_rule;
FollowOption max_link_follow_policy;
};
The value for limiting_follow_rule exceeds the trader’s max_link_follow_policy
attribute.
Operations
add_link
void add_link(in LinkName name,
in Lookup target,
in FollowOption def_pass_on_follow_rule,
in FollowOption limiting_follow_rule)
raises(IllegalLinkName,
DuplicateLinkName,
InvalidLookupRef,
DefaultFollowTooPermissive,
LimitingFollowTooPermissive);
ORBacus Trader
113
Trading Service Reference
Adds a new, unidirectional link from this trader to another trader.
Parameters:
name - Name for the new link
target - Lookup interface of the target trader
def_pass_on_follow_rule - Default link behavior for the link if no link-follow policy is
specified by an importer during a query
limiting_follow_rulei - Most permissive link-follow behavior that the link is willing
to tolerate
Raises:
IllegalLinkName - Link name is empty or has an invalid format
DuplicateLinkName - Another link exists with the same name
InvalidLookupRef - Target object reference is nil
DefaultFollowTooPermissive - The value for def_pass_on_follow_rule exceeds
the value for limiting_follow_rule
LimitingFollowTooPermissive - The value for limiting_follow_rule exceeds the
trader’s max_link_follow_policy attribute
remove_link
void remove_link(in LinkName name)
raises(IllegalLinkName,
UnknownLinkName);
Removes an existing link.
Parameters:
name - Name of the link to be removed
Raises:
IllegalLinkName - Link name is empty or has an invalid format
UnknownLinkName - Link does not exist with the given name
describe_link
LinkInfo describe_link(in LinkName name)
raises(IllegalLinkName,
UnknownLinkName);
Obtains a description of a link.
Parameters:
114
ORBacus Trader
Interface CosTrading::Link
name - Name of the link of interest
Returns:
LinkInfo struct describing the link
Raises:
IllegalLinkName - Link name is empty or has an invalid format
UnknownLinkName - Link does not exist with the given name
list_links
LinkNameSeq list_links();
Obtains the names of all trading links within the trader.
Returns:
List of link names
modify_link
void modify_link(in LinkName name,
in FollowOption def_pass_on_follow_rule,
in FollowOption limiting_follow_rule)
raises(IllegalLinkName,
UnknownLinkName,
DefaultFollowTooPermissive,
LimitingFollowTooPermissive);
Modifies the follow behavior of an existing link.
Parameters:
name - Name of the link to be modified
def_pass_on_follow_rule - Default link behavior for the link if no link-follow policy is
specified by an importer during a query
limiting_follow_rulei - Most permissive link-follow behavior that the link is willing
to tolerate
Raises:
IllegalLinkName - Link name is empty or has an invalid format
UnknownLinkName - Link does not exist with the given name
DefaultFollowTooPermissive - The value for def_pass_on_follow_rule exceeds
the value for limiting_follow_rule
LimitingFollowTooPermissive - The value for limiting_follow_rule exceeds the
trader’s max_link_follow_policy attribute
ORBacus Trader
115
Trading Service Reference
A.9
Interface CosTrading::Proxy
interface Proxy
inherits from CosTrading::TraderComponents, CosTrading::SupportAttributes
Provides operations for managing proxy offers.
Aliases
ConstraintRecipe
typedef Istring ConstraintRecipe;
A constraint recipe specifies how the trader should rewrite a constraint before invoking the
query operation of the proxy offer’s Lookup interface. Using a constraint recipe, the exporter
can have the trader rewrite a constraint into a completely different constraint language (one that
is understood by the proxy offer’s Lookup target).
The constraint recipe can include the value of properties using the expression "$(propertyname)". The recipe can also include the entire text of the original constraint using the special
syntax "$*".
For example, assume the property name has the value "Joe", and the property age has the
value 33. The constraint recipe "Name == $(name) and Age <= $(age)" would be rewritten as "Name == ’Joe’ and Age <= 33".
Structs
ProxyInfo
struct ProxyInfo
{
ServiceTypeName type;
Lookup target;
PropertySeq properties;
boolean if_match_all;
ConstraintRecipe recipe;
PolicySeq policies_to_pass_on;
};
A complete description of a proxy offer.
Members:
116
ORBacus Trader
Interface CosTrading::Proxy
type - The service type for which this offer was exported.
target - The target Lookup interface.
properties - A sequence of properties associated with this offer.
if_match_all - If TRUE, type conformance is all that is necessary for this offer to match.
If FALSE, the offer must also match the constraint expression.
recipe - The recipe for rewriting the constraint.
policies_to_pass_on - Policies to be appended to the importer’s policies and passed
along to the target.
Exceptions
IllegalRecipe
exception IllegalRecipe
{
ConstraintRecipe recipe;
};
An error occurred while parsing the recipe.
NotProxyOfferId
exception NotProxyOfferId
{
OfferId id;
};
The offer identifier does not refer to a proxy offer.
Operations
export_proxy
OfferId export_proxy(in Lookup target,
in ServiceTypeName type,
in PropertySeq properties,
in boolean if_match_all,
in ConstraintRecipe recipe,
in PolicySeq policies_to_pass_on)
raises(IllegalServiceType,
UnknownServiceType,
InvalidLookupRef,
IllegalPropertyName,
PropertyTypeMismatch,
ReadonlyDynamicProperty,
MissingMandatoryProperty,
IllegalRecipe,
ORBacus Trader
117
Trading Service Reference
DuplicatePropertyName,
DuplicatePolicyName);
Creates (exports) a new proxy offer.
Parameters:
target - The target Lookup interface.
type - The service type for which this offer was exported.
properties - A sequence of properties associated with this offer.
if_match_all - If TRUE, type conformance is all that is necessary for this offer to match.
If FALSE, the offer must also match the constraint expression.
recipe - The recipe for rewriting the constraint.
policies_to_pass_on - Policies to be appended to the importer’s policies and passed
along to the target.
Returns:
Identifier of new proxy offer
Raises:
IllegalServiceType - Service type name is empty or has an invalid format
UnknownServiceType - Service type was not found in service type repository
InvalidLookupRef - Target object reference is nil
IllegalPropertyName - Property name is empty or has an invalid format
PropertyTypeMismatch - Property value type does not match the property definition of
the service type
ReadonlyDynamicProperty - Read-only properties cannot have dynamic values
MissingMandatoryProperty - No value was supplied for a mandatory property
IllegalRecipe - An error occurred while parsing the constraint recipe
DuplicatePropertyName - Property name appeared more than once in list of properties
DuplicatePolicyName - Policy name appeared more than once in list of policies to pass
on
withdraw_proxy
void withdraw_proxy(in OfferId id)
raises(IllegalOfferId,
UnknownOfferId,
NotProxyOfferId);
Removes a proxy offer.
Parameters:
id - Identifier of the proxy offer to be withdrawn
118
ORBacus Trader
Interface CosTrading::Proxy
Raises:
IllegalOfferId - Offer identifier is empty or has an invalid format
UnknownOfferId - No offer was found with the given identifier
NotProxyOfferId - Offer identifier does not refer to a proxy offer.
describe_proxy
ProxyInfo describe_proxy(in OfferId id)
raises(IllegalOfferId,
UnknownOfferId,
NotProxyOfferId);
Obtains the description of a proxy offer.
Parameters:
id - Identifier of the proxy offer of interest
Returns:
ProxyInfo struct describing the proxy offer
Raises:
IllegalOfferId - Offer identifier is empty or has an invalid format
UnknownOfferId - No offer was found with the given identifier
NotProxyOfferId - Offer identifier does not refer to a proxy offer.
ORBacus Trader
119
Trading Service Reference
A.10 Interface CosTrading::Admin
interface Admin
inherits from CosTrading::TraderComponents, CosTrading::SupportAttributes, CosTrading::ImportAttributes, CosTrading::LinkAttributes
Provides attributes and operations for administrative control of the trading service.
Aliases
OctetSeq
typedef sequence<octet> OctetSeq;
Attributes
request_id_stem
readonly attribute OctetSeq request_id_stem;
The request identifier "stem" is a sequence of octets that comprise the prefix for a request identifier. The trader will append additional octets to ensure the uniqueness of each request identifier it generates.
Operations
set_def_search_card
unsigned long set_def_search_card(in unsigned long value);
Changes the value of the default search cardinality attribute.
Parameters:
value - The new value
Returns:
The previous value
See Also:
CosTrading::ImportAttributes
set_max_search_card
unsigned long set_max_search_card(in unsigned long value);
120
ORBacus Trader
Interface CosTrading::Admin
Changes the value of the maximum search cardinality attribute.
Parameters:
value - The new value
Returns:
The previous value
set_def_match_card
unsigned long set_def_match_card(in unsigned long value);
Changes the value of the default match cardinality attribute.
Parameters:
value - The new value
Returns:
The previous value
set_max_match_card
unsigned long set_max_match_card(in unsigned long value);
Changes the value of the maximum match cardinality attribute.
Parameters:
value - The new value
Returns:
The previous value
set_def_return_card
unsigned long set_def_return_card(in unsigned long value);
Changes the value of the default return cardinality attribute.
Parameters:
value - The new value
Returns:
The previous value
ORBacus Trader
121
Trading Service Reference
set_max_return_card
unsigned long set_max_return_card(in unsigned long value);
Changes the value of the maximum return cardinality attribute.
Parameters:
value - The new value
Returns:
The previous value
set_max_list
unsigned long set_max_list(in unsigned long value);
Changes the value of the maximum list attribute.
Parameters:
value - The new value
Returns:
The previous value
set_supports_modifiable_properties
boolean set_supports_modifiable_properties(in boolean value);
Establishes whether the trader supports property modification.
Parameters:
value - The new value
Returns:
The previous value
set_supports_dynamic_properties
boolean set_supports_dynamic_properties(in boolean value);
Establishes whether the trader considers offers with dynamic properties during a query.
Parameters:
value - The new value
122
ORBacus Trader
Interface CosTrading::Admin
Returns:
The previous value
set_supports_proxy_offers
boolean set_supports_proxy_offers(in boolean value);
Establishes whether the trader supports proxy offers.
Parameters:
value - The new value
Returns:
The previous value
set_def_hop_count
unsigned long set_def_hop_count(in unsigned long value);
Changes the value of the default hop count attribute.
Parameters:
value - The new value
Returns:
The previous value
set_max_hop_count
unsigned long set_max_hop_count(in unsigned long value);
Changes the value of the maximum hop count attribute.
Parameters:
value - The new value
Returns:
The previous value
set_def_follow_policy
FollowOption set_def_follow_policy(in FollowOption policy);
Changes the value of the default link follow attribute.
ORBacus Trader
123
Trading Service Reference
Parameters:
policy - The new value
Returns:
The previous value
set_max_follow_policy
FollowOption set_max_follow_policy(in FollowOption policy);
Changes the value of the maximum link follow attribute.
Parameters:
policy - The new value
Returns:
The previous value
set_max_link_follow_policy
FollowOption set_max_link_follow_policy(in FollowOption policy);
Changes the value of the maximum link follow policy.
Parameters:
policy - The new value
Returns:
The previous value
set_type_repos
TypeRepository set_type_repos(in TypeRepository repository);
Establishes the service type repository to be used by the trader.
Parameters:
repository - The new value
Returns:
The previous value
set_request_id_stem
124
ORBacus Trader
Interface CosTrading::Admin
OctetSeq set_request_id_stem(in OctetSeq stem);
Changes the value of the request identifier stem.
Parameters:
stem - The new value
Returns:
The previous value
list_offers
void list_offers(in unsigned long how_many,
out OfferIdSeq ids,
out OfferIdIterator id_itr)
raises(NotImplemented);
Obtains the identifiers for the service offers in this trader.
Parameters:
how_many - Indicates how many identifiers to return in ids.
ids - Contains at most how_many identifiers. If the number of identifiers exceeds
how_many, the id_itr parameter will hold a reference to an iterator object through which
the remaining identifiers can be obtained.
id_itr - Will hold nil if no identifiers were found or if all of the identifiers were returned
in ids; otherwise, holds a reference to an iterator. The object’s destroy operation should
be invoked when the object is no longer needed.
Returns:
The previous value
Raises:
NotImplemented - Trader does not support this operation.
list_proxies
void list_proxies(in unsigned long how_many,
out OfferIdSeq ids,
out OfferIdIterator id_itr)
raises(NotImplemented);
Obtains the identifiers for the proxy offers in this trader.
Parameters:
ORBacus Trader
125
Trading Service Reference
how_many - Indicates how many identifiers to return in ids.
ids - Contains at most how_many identifiers. If the number of identifiers exceeds
how_many, the id_itr parameter will hold a reference to an iterator object through which
the remaining identifiers can be obtained.
id_itr - Will hold nil if no identifiers were found or if all of the identifiers were returned
in ids; otherwise, holds a reference to an iterator. The object’s destroy operation should
be invoked when the object is no longer needed.
Returns:
The previous value
Raises:
NotImplemented - Trader does not support this operation.
126
ORBacus Trader
Interface CosTrading::OfferIterator
A.11 Interface CosTrading::OfferIterator
interface OfferIterator
Iterates through a list of offers.
Operations
max_left
unsigned long max_left()
raises(UnknownMaxLeft);
Returns the number of offers remaining in the iterator.
Returns:
Number of remaining offers
Raises:
Iterator - cannot determine the number of remaining offers
next_n
boolean next_n(in unsigned long n,
out OfferSeq offers);
Returns the next set of offers.
Parameters:
n - Number of offers to be returned
offers - List of offers containing at most n elements
Returns:
TRUE if more offers are available, FALSE otherwise
destroy
void destroy();
Destroys the iterator object.
ORBacus Trader
127
Trading Service Reference
A.12 Interface CosTrading::OfferIdIterator
interface OfferIdIterator
Iterates through a list of offer identifiers.
Operations
max_left
unsigned long max_left()
raises(UnknownMaxLeft);
Returns the number of offer identifiers remaining in the iterator.
Returns:
Number of remaining offer identifiers
Raises:
Iterator - cannot determine the number of remaining offer identifiers
next_n
boolean next_n(in unsigned long n,
out OfferIdSeq ids);
Returns the next set of offer identifiers.
Parameters:
n - Number of identifiers to be returned
ids - List of offer identifiers containing at most n elements
Returns:
TRUE if more identifiers are available, FALSE otherwise
destroy
void destroy();
Destroys the iterator object.
128
ORBacus Trader
Module CosTradingDynamic
A.13 Module CosTradingDynamic
Defines interfaces and types necessary to support dynamic properties. Dynamic properties allow an
exporter to delegate a property’s value to a third party. For example, rather than exporting an offer
with a value of 54 for the property weight, you can provide a reference to an object that will
dynamically compute the value for weight.
Naturally, there are performance issues when using dynamic properties, and therefore an importer
may elect to exclude any offers containing dynamic properties.
To export an offer (or a proxy offer) with a dynamic property, you need to do the following:
• Define an object that implements the DynamicPropEval interface.
• Create an instance of the DynamicProp struct and insert that into the property’s CORBA::Any
value.
• Ensure that the lifetime of the DynamicPropEval object is such that it will be available whenever dynamic property evaluation is necessary.
Structs
DynamicProp
struct DynamicProp
{
DynamicPropEval eval_if;
TypeCode returned_type;
any extra_info;
};
Description of a dynamic property. This struct is inserted into a property’s CORBA::Any value
and provides all of the information necessary for the trader to accomplish dynamic property
evaluation.
Members:
eval_if - Object reference for evaluation interface
returned_type - Value type expected for the property. The value of returned_type
must match the value type of the property as defined by the service type.
extra_info - Additional information used for property evaluation. ORBacus Trader supports primitive and user-defined types as values for extra_info.
Exceptions
DPEvalFailure
ORBacus Trader
129
Trading Service Reference
exception DPEvalFailure
{
CosTrading::PropertyName name;
TypeCode returned_type;
any extra_info;
};
Evaluation of a dynamic property failed.
Members:
name - Name of the property to be evaluated
returned_type - Value type expected for the property
extra_info - Additional information used for property evaluation
130
ORBacus Trader
Interface CosTradingDynamic::DynamicPropEval
A.14 Interface CosTradingDynamic::DynamicPropEval
interface DynamicPropEval
Defines a single operation for evaluating a dynamic property.
Operations
evalDP
any evalDP(in CosTrading::PropertyName name,
in TypeCode returned_type,
in any extra_info)
raises(DPEvalFailure);
Evaluate a dynamic property.
Parameters:
name - Name of the property to be evaluated
returned_type - Value type expected for the property
extra_info - Additional information used for property evaluation
Returns:
Value of the property
Raises:
DPEvalFailure - Evaluation of the property failed
ORBacus Trader
131
Trading Service Reference
A.15 Module CosTradingRepos
Contains the ServiceTypeRepository interface, which manages information about service
types for the trading service.
A service type represents the information needed to describe a service, including an interface type
defining the computational signature of the service, and zero or more properties that augment the
interface. Each traded service, or service offer, is associated with a service type.
There are several components of a service type:
• Interface - The interface repository identifier for an interface determines the computational signature of a service. If the trading service is configured to use the interface repository, and this
identifier resolves to an InterfaceDef object in the interface repository, then the trading service will ensure that an object in an exported offer conforms to this interface.
• Properties - Any number of properties can be defined for a service type. Properties typically
represent behavioral, non-functional and non-computational aspects of the service.
• Super types - Service types can be related in a hierarchy that reflects interface type inheritance
and property type aggregation. This hierarchy provides the basis for deciding if a service of one
type may be substituted for a service of another type.
When a new service type is added that has one or more super types, the service type repository
performs a number of consistency checks. First, the repository ensures (if possible) that the
interface of the new type conforms to the interface of the super type. Second, the repository
checks for any property that has been redefined in the new service type to ensure that it has the
same type as that of the super type, and that its mode is at least as strong as its mode in the super
type.
132
ORBacus Trader
Interface CosTradingRepos::ServiceTypeRepository
A.16 Interface CosTradingRepos::ServiceTypeRepository
interface ServiceTypeRepository
Contains types and operations for managing the repository.
Aliases
ServiceTypeNameSeq
typedef sequence<CosTrading::ServiceTypeName> ServiceTypeNameSeq;
PropStructSeq
typedef sequence<PropStruct> PropStructSeq;
Identifier
typedef CosTrading::Istring Identifier;
The interface repository identifier of an interface. For example, the identifier of this interface is
IDL:omg.org/CosTradingRepos/ServiceTypeRepository:1.0.
Structs
PropStruct
struct PropStruct
{
CosTrading::PropertyName name;
TypeCode value_type;
PropertyMode mode;
};
A complete description of a property.
Members:
name - Name of the property
value_type - CORBA::TypeCode describing the type of values allowed for the property
mode - Determines whether a property is mandatory, and whether the property can be modified
IncarnationNumber
struct IncarnationNumber
{
ORBacus Trader
133
Trading Service Reference
unsigned long high;
unsigned long low;
};
Represents a unique, 64-bit identifier that is assigned to each service type. This will be replaced
by long long when that type is widely supported.
TypeStruct
struct TypeStruct
{
Identifier if_name;
PropStructSeq props;
ServiceTypeNameSeq super_types;
boolean masked;
IncarnationNumber incarnation;
};
A complete description of a service type.
Members:
if_name - Interface repository identifier for an interface
props - Defines the properties associated with this type
super_types - Service types from which this type inherits property definitions
masked - If TRUE, no new offers can be exported for this type
incarnation - Unique, 64-bit identifier for this type
Exceptions
ServiceTypeExists
exception ServiceTypeExists
{
CosTrading::ServiceTypeName name;
};
Another service type exists with the given name.
InterfaceTypeMismatch
exception InterfaceTypeMismatch
{
CosTrading::ServiceTypeName base_service;
Identifier base_if;
CosTrading::ServiceTypeName derived_service;
Identifier derived_if;
};
134
ORBacus Trader
Interface CosTradingRepos::ServiceTypeRepository
The interface of the new (derived) service type does not conform to the interface of a super type
(base service).
HasSubTypes
exception HasSubTypes
{
CosTrading::ServiceTypeName the_type;
CosTrading::ServiceTypeName sub_type;
};
A service type cannot be removed if it is the super type of any other type.
AlreadyMasked
exception AlreadyMasked
{
CosTrading::ServiceTypeName name;
};
The service type cannot be masked if it is already masked.
NotMasked
exception NotMasked
{
CosTrading::ServiceTypeName name;
};
The service type cannot be unmasked if it is not currently masked.
ValueTypeRedefinition
exception ValueTypeRedefinition
{
CosTrading::ServiceTypeName type_1;
PropStruct definition_1;
CosTrading::ServiceTypeName type_2;
PropStruct definition_2;
};
The definition of a property in the new service type (type_1) conflicts with the definition in a
super type (type_2). This error can result if the value_type members do not match, or if the
mode of the property is weaker than in the super type.
DuplicateServiceTypeName
exception DuplicateServiceTypeName
ORBacus Trader
135
Trading Service Reference
{
CosTrading::ServiceTypeName name;
};
The same service type appeared more than once in the list of super types.
Unions
SpecifiedServiceTypes
union SpecifiedServiceTypes switch(ListOption)
{
case since: IncarnationNumber incarnation;
};
Provides two ways of retrieving the names of the service types managed by the repository. The
union’s discriminator can be set to all if you want to obtain all of the service type names.
Members:
since - Set this value with an incarnation number; only the names of those types whose
incarnation numbers are greater than or equal to this value will be returned
Enums
PropertyMode
enum PropertyMode
{
PROP_NORMAL,
PROP_READONLY,
PROP_MANDATORY,
PROP_MANDATORY_READONLY
};
Each property has a mode associated with it. The property mode places restrictions on an
exporter when exporting and modifying service offers.
Members:
PROP_NORMAL - Property is optional
PROP_READONLY - Property is optional, but once a value has been supplied, it cannot be
changed
PROP_MANDATORY - A value for this property must be supplied when the offer is exported,
but can also be changed at some later time
PROP_MANDATORY_READONLY - A value for this property must be supplied when the offer
is exported, and cannot be changed
136
ORBacus Trader
Interface CosTradingRepos::ServiceTypeRepository
ListOption
enum ListOption
{
all,
since
};
Indicates which service types are of interest.
Members:
all - All service types
since - All service types since a particular incarnation
Attributes
incarnation
readonly attribute IncarnationNumber incarnation;
Determines the next incarnation number that will be assigned to a new service type. This could
be used to synchronize two or more service type repositories, for example.
Operations
add_type
IncarnationNumber add_type(in CosTrading::ServiceTypeName name,
in Identifier if_name,
in PropStructSeq props,
in ServiceTypeNameSeq super_types)
raises(CosTrading::IllegalServiceType,
ServiceTypeExists,
InterfaceTypeMismatch,
CosTrading::IllegalPropertyName,
CosTrading::DuplicatePropertyName,
ValueTypeRedefinition,
CosTrading::UnknownServiceType,
DuplicateServiceTypeName);
Adds a new service type.
Parameters:
name - Name to be used for the new type
if_name - Interface repository identifier for an interface
ORBacus Trader
137
Trading Service Reference
props - Properties defined for this interface interface
super_types - Zero or more super types from which this type will inherit interface and
property definitions
Returns:
Unique incarnation number
Raises:
CosTrading::IllegalServiceType - Service type name is empty or has an invalid for-
mat
ServiceTypeExists - Service type already exists with the same name
InterfaceTypeMismatch - Interface of the new type does not conform to the interface of
a super type
CosTrading::IllegalPropertyName - Property name is empty or has an invalid format
CosTrading::DuplicatePropertyName - Same property name appears more than once
in props
ValueTypeRedefinition - Property definition in props conflicts with a definition in a
super type
CosTrading::UnknownServiceType - Super type does not exist
DuplicateServiceTypeName - Same super type name appears more than once in
super_types
remove_type
void remove_type(in CosTrading::ServiceTypeName name)
raises(CosTrading::IllegalServiceType,
CosTrading::UnknownServiceType,
HasSubTypes);
Removes an existing service type.
Parameters:
name - Name of the type to be removed
Raises:
CosTrading::IllegalServiceType - Service type name is empty or has an invalid for-
mat
CosTrading::UnknownServiceType - Service type does not exist
HasSubTypes - Service type cannot be removed if it is the super type of any other type
list_types
ServiceTypeNameSeq list_types(in SpecifiedServiceTypes which_types);
138
ORBacus Trader
Interface CosTradingRepos::ServiceTypeRepository
Lists the names of some or all of the service types in the repository.
Parameters:
which_types - Specifies which types are of interest
Returns:
List of service type names
describe_type
TypeStruct describe_type(in CosTrading::ServiceTypeName name)
raises(CosTrading::IllegalServiceType,
CosTrading::UnknownServiceType);
Obtains the description of a service type.
Parameters:
name - Name of the type of interest
Returns:
TypeStruct describing the type
Raises:
CosTrading::IllegalServiceType - Service type name is empty or has an invalid for-
mat
CosTrading::UnknownServiceType - Service type does not exist
fully_describe_type
TypeStruct fully_describe_type(in CosTrading::ServiceTypeName name)
raises(CosTrading::IllegalServiceType,
CosTrading::UnknownServiceType);
Obtains the full description of a service type. The super_types member of a full description
contains the names of the types in the transitive closure of the super type relation. The props
member includes all properties inherited from the transitive closure of the super types.
Parameters:
name - Name of the type of interest
Returns:
TypeStruct fully describing the type
Raises:
ORBacus Trader
139
Trading Service Reference
CosTrading::IllegalServiceType - Service type name is empty or has an invalid for-
mat
CosTrading::UnknownServiceType - Service type does not exist
mask_type
void mask_type(in CosTrading::ServiceTypeName name)
raises(CosTrading::IllegalServiceType,
CosTrading::UnknownServiceType,
AlreadyMasked);
Masks a service type so that offers can no longer be exported for it. Masking a service type is
useful when the type is considered deprecated; in other words, no new offers should be allowed,
but existing offers are still supported.
Parameters:
name - Name of the type to be masked
Raises:
CosTrading::IllegalServiceType - Service type name is empty or has an invalid for-
mat
CosTrading::UnknownServiceType - Service type does not exist
AlreadyMasked - Service type is already masked
unmask_type
void unmask_type(in CosTrading::ServiceTypeName name)
raises(CosTrading::IllegalServiceType,
CosTrading::UnknownServiceType,
NotMasked);
Unmasks a masked service type so that offers can be exported for it.
Parameters:
name - Name of the type to be unmasked
Raises:
CosTrading::IllegalServiceType - Service type name is empty or has an invalid for-
mat
CosTrading::UnknownServiceType - Service type does not exist
NotMasked - Service type is not currently masked
140
ORBacus Trader
References
[1]
The ORBACUS Trader Home Page, http://www.ooc.com/trader/, Object-Oriented
Concepts, Inc.
[2]
The ORBACUS Home Page, http://www.ooc.com/ob/, Object-Oriented Concepts, Inc.
[3]
The Common Object Request Broker: Architecture and Specification, Revision 2.0, OMG
Document 97–02–25.1
[4]
IDL/Java Language Mapping, OMG Document 97–03–01.2
[5]
CORBAservices: Common Object Services Specification, OMG Document 97–12-02.3
[6]
Trading Object Service Specification, OMG Document 97–12-23.4
[7]
Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns, Addison-Wesley, 1994.
1.
2.
3.
4.
You can get [3] from ftp://ftp.omg.org/pub/docs/formal/97-02-25.pdf.
You can get [4] from ftp://ftp.omg.org/pub/docs/orbos/97-03-01.pdf.
You can get [5] from ftp://ftp.omg.org/pub/docs/formal/97-12-02.pdf.
You can get [6] from ftp://ftp.omg.org/pub/docs/formal/97-12-23.pdf.
ORBacus Trader
141
References
142
ORBacus Trader