Data processing: financial – business practice – management – or co – Electronic negotiation
Reexamination Certificate
1999-08-12
2003-05-27
Elisca, Pierre E. (Department: 3621)
Data processing: financial, business practice, management, or co
Electronic negotiation
C705S064000, C705S067000
Reexamination Certificate
active
06571222
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a trading system and in particular to a trading system which supports dynamic communications between software units called objects in a distributed object oriented environment based on the CORBA method.
The CORBA (Common Object Request Broker Architecture) method is a standard architecture of the distributed object oriented environment which is provided by OMG (Object Management Group) for realizing the distributed object oriented environment. Equipments of the distributed object oriented environment are to be presented by each vendor according to this standard.
In the distributed object oriented environment in conformity to the CORBA method, processing requests can be transferred between objects and the processings can be realized by the cooperation of the objects without worrying about the differences of architectures and operating systems of computers or of programming languages.
Requests/responses between clients and servers in the CORBA method are mediated by an object request broker (ORB). In the CORBA method, functions such as naming service or trader service which are generally required in a distributed object environment are defined besides the broker. Efficiency in construction of the distributed system can be further improved by using such services as common facilities.
In the CORBA method, a concept corresponding to an object in the object oriented method is called an interface and a concept corresponding to a method is called an operation, so that a client is required to obtain an interface reference (a reference type for object in C++) in order to call a server.
When an operation in an interface reference is called, a corresponding method in a remote server is called automatically. Namely, for the processing of the CORBA method, the interface reference of a desirable server to be called should be obtained in the first place. In the CORBA method, for clients to obtain interface references, several common facilities are supposed as mentioned above. The naming service is a service in which the server name and the server entity correspond to each other, e.g. a service corresponding to searching a telephone number of a person to be called in white pages. On the other hand, the trader service corresponds to a service for searching a telephone number of a person to be called in yellow pages, which is expected as a trading system where the server name and the server entity need not correspond to each other.
2. Description of the Related Art
Such a trading system corresponds to a broker ORB shown in
FIGS. 31A and 31B
, comprises a plurality of clients
4
and
5
and a trader
1
as shown in
FIG. 31B
, and performs (1) service type registration processing and (2) service import/export processing as described below:
(1) Service Type Registration Processing (see FIG.
31
A)
a) A client
3
, which may be any client, requesting the registration of a service type gives a service type name and its super type name, a property definition which defines a property name, type, and mode, and an interface name to the trader
1
, thereby requesting the registration of a new service type.
(2) Service Import/export Processing (see FIG.
31
B)
a) The server client
4
which is called an exporter gives the service type name, a property value, and its own interface reference to the trader
1
, thereby requesting the registration of the service. In response, the trader
1
maintains the correspondence between the service type and the interface reference of the server.
b) The client
5
which is called an importer gives a necessary service type name, a constraint, and the like to the trader
1
, thereby requesting the offer of service information. The trader
1
selects services which conform to the service type, conditions of the constraint, and the like.
c) The trader
1
returns the information of a service group selected in the procedure b) to the client
5
.
d) The client
5
uses the interface reference received from the trader
1
to call an object of the server
4
.
Processings between the trader
1
and its clients (hereinafter collectively referred to with a symbol “
7
”) will now be described referring to FIG.
32
.
For each type of the above-mentioned service type registration processing (1) and service import/export processing (2), and the like, the trader
1
comprises an interface
11
and a processing portion
12
. The service type information saved by the trader
1
is saved in a service type repository
13
in the trader
1
, and the service information is saved in a service offer repository
14
in the trader
1
.
Receiving a processing request from the client
7
at the corresponding portion within the interface
11
, the trader
1
transfers the processing to the corresponding portion of the processing portion
12
. Each processing portion
12
takes out suitable information from the service type repository
13
, the service offer repository
14
, or an interface repository
6
which is located outside of the trader
1
to perform the processing. The processing result is returned to the client
7
of the trader
1
through the interface
11
.
Next, details of internal processing of such a trading system will be described below:
(1) Service Type Registration Processing (see FIG.
33
A)
When newly registering a service type, the service type registration requesting client
3
calls a service type registration interface
131
of the trader
1
.
Extracts from a CORBA.IDL definition for the service type registration are given as follows:
IncarnationNumber add_type (
in CosTrading::ServiceTypeName name,
in Identifier if_name,
in PropStructSeq props,
in ServiceTypeNameSeq super_types
):
Having received a registration request from the service type registration interface
131
, a service type registration processing portion
132
takes out super type information corresponding to a super type name in the registration request from a service type repository
13
. The processing portion
132
also takes out interface definition information of the service in the registration request from the interface repository
6
which is located outside of the trader
1
.
The trader
1
examines the correspondence between a super type-sub type relationship in the service type repository
13
and a successional relationship of the interface definition in the interface repository
6
, confirms the validity in case both relationship correspond mutually, and saves a new service type in the service type repository
13
.
When the processing ends normally, the service type registration interface
131
allots an incarnation number to the registration processing and returns the processing to the service type registration requesting client
3
.
(2.1) Service Export Processing (see
FIG. 33B
)
In the export processing of a service, the exporter
4
calls an export interface
141
of the trader
1
. Extracts from a CORBA.IDL definition for this are given as follows:
OfferId export (
in Object reference,
in ServiceTypeName type,
in PropertySeq properties
);
Having received an export processing request from the export interface
141
, an export processing portion
142
takes out service type information designated in the request from the service type repository
13
. If a property type in a parameter coincides with the property type in a service type definition and if a property value of an mandatory mode is given in the export processing request, the request is valid, so that the trader
1
stores the service in a service offer repository
14
.
When the processing ends normally, the export interface
141
returns an offer ID to the exporter
4
.
(2.2) Service Import Processing (see
FIG. 33C
)
In the import processing of a service, the importer
5
calls an import interface
151
of the trader
1
. Extracts from a CORBA.IDL definition for this are given as follows:
void query (
in ServiceTypeName type,
in Constraint constr,
in Preference pref,
in PolicySeq policies,
in SpecifiedProps desired_props,
in unsigned lo
Ide Toshihiro
Matsumoto Shin-ichi
Seguchi Yoshiyuki
Takeshita Ken-ichi
Elisca Pierre E.
Fujitsu Limited
Katten Muchin Zavis & Rosenman
LandOfFree
Trading system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Trading system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Trading system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3019590