Performing an invocation on an object method requires that one has a reference to the object one wishes to invoke the method of. This presents a "bootstrapping" problem in some cases to obtain the first object reference for performing the first invocation. See How the SOAP action translates into a CORBA service reference. for a discussion of this problem.
It would work to simply use the ORB's object_to_string and string_to_object functions to convert and generate standard CORBA stringified IOR's.
However, this method has some drawbacks:
Therefore we use our own object reference storing mechanism. See the ObjectContextManager interface for more details. Parameter passing, handling and type conversions.
Converting the string based SOAP parameter values to the strongly type CORBA parameters obviously poses some difficulties. Most conversions can be done automatically but some need further specification so that the SoapBridge may handle them as intended. These additional specification are stored in a MySQL database.
We will briefly describe these tables below but generally they will be maintained using the SOAPBridge::TypeConversions interface. Using those functions will also inform a running SoapBridge of any changes made, it is not required to restart to bridge when specifications were altered through the CORBA interface to them.
These are the currently defined conversion specifiers:
convid | Description |
0 | No conversion in effect. |
1 | Reserved for invoking a remote CORBA service to do the conversion. |
2 | Reserved for invoking a remote SOAP service to do the conversion |
3 | Convert a standard 'C' time value to and from "yyyy-mm-dd hh:mm:ss" in UTC (GMT). |
4 | Like code 3 but for localtime. |
5 | For the CORBA type "sequence of octet", do NOT convert using SOAP::Base64 encoding. |
6 | Reserved for doing character set transcodings. |
7 | String limiter. Truncate strings (silently) to the specified number of characters. |
8 | String length verification. Return a SOAP Fault if a string is longer than the specified maximum. |
Here is the format of the specification table which is called irplus. This table will be created by the SoapBridge if it does not exist when it starts up.
+----------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+----------------+ | irplusid | int(11) | | PRI | NULL | auto_increment | | methpath | varchar(255) | | | | | | param | varchar(80) | YES | | NULL | | | convid | int(11) | YES | | NULL | | | convinfo | varchar(255) | YES | | NULL | | +----------+--------------+------+-----+---------+----------------+
The actual contents of the CORBA Interface Repository (IR) is copied to two tables called irmeth and irparm when the Soapbridge is started.
At the same time it scans the irplus table shown above for matching methods and parameters.
The intent is to use the information from the irmeth and irparm tables to build your irplus table. In other words, the prior two tables serve as a reference for the latter. Here are their descriptions:
irmeth: +----------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+----------------+ | methuid | int(11) | | PRI | NULL | auto_increment | | methpath | varchar(255) | | | | | | irplusid | int(11) | YES | | NULL | | +----------+--------------+------+-----+---------+----------------+ irparm: +----------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+-------------+------+-----+---------+----------------+ | methuid | int(11) | | PRI | 0 | | | paramnum | int(11) | | PRI | NULL | auto_increment | | param | varchar(80) | | | | | | irplusid | int(11) | YES | | NULL | | +----------+-------------+------+-----+---------+----------------+
The irplusid fields will refer to the rows in the irplus table that matched.