In this implementation, passing the SOAP call from the front-end (for instance a HTTP or a SMTP server) to the SOAP bridge is done by using a CORBA call.
This method has advantages and drawbacks.
Drawbacks:
Advantages:
As the actual front-end code can be implemented in a variety of ways, amongst which CGI programs, Apache modules or in the case of an SMTP server a Delivery Agent, we find that the advantages far outway the drawbacks.
The actual call is kept very simple: the front-end just extracts the SOAP action from the incoming request and forwards all of the SOAP request as binary data to the SOAP bridge. In turn it receives fully formatted XML data again as binary data which it can return verbatim to the caller. The supplied SBCGI program.
There is a sample CGI-bin implementation called SBCGI. If your platform supports AutoConf you can build it by typing "make check". To get your HTTP server to actually return its output as Content-type: text/xml you might have to rename it to SBCGI.xml or something simular.
Place this program in the CGI-bin directory of your Web Server and make sure it can access any required shared libraries. Also, it tries to read and write a small file called sbcgi.cfg with some configuration settings at its startup location. Make sure it has the right to do so when executed by the Web Server. Alternatively, your might want to alter the source and specify an alternative location (/tmp/sbcgi.cfg for instance). How CORBA types are represented using SOAP.
See also: Source codes notes on handling unions <\p>
There are a few special cases to consider when translating a CORBA interface definition to SOAP. XML wide character data.
Frankly this whole subject is rather confusing for me. I'd be interested in working with a "Wide Character Guru" to sort this out. Basic support should be in place so it should be a fairly simple matter to get it working correctly.
SOAP "Polymorphic Accessors" and/or CORBA Unions.
The way CORBA defines a Union makes it necessary to always include the discriminator in the SOAP call. See the example below.
The reason for this is that it is possible in CORBA to define default cases in a Union. Omiting the discriminator would therefore introduce an uninitialized value when constructing the CORBA type.
Example:
union Wheels switch (short) {
case 0: pedestrian;
case 1: monocycle;
case 2: bicycle;
case 3: threeWheeler;
case 4: car;
default: truck;
};
This example would be encoded in SOAP as:
<Wheels>
<short>2</short>
<bicycle>Mountainbike</bicycle>
</Wheels>
Or for the default case:
<Wheels>
<short>16</short>
<truck>Combi</truck>
</Wheels>
Unspecified SOAP element names.
The above example (SOAP "Polymorphic Accessors" and/or CORBA Unions.) shows another special consideration when translating CORBA IDL to SOAP. In this case, the element <short> has an arbitrarily chosen name which happens to be the type name.
The SOAP bridge handles this case by allowing ANY name for an element it cannot find a name for in the CORBA IDL. In the above example therefore, the element could also have been called <numWheels> or any other chosen name.
How the SOAP action translates into a CORBA service reference.
SOAPBridge::SOAPCall::invoke, implemented by SOAPBridge_SOAPCall_i::invoke, will look for a # sign in the SOAP action. This is required as per the SOAP specification, if no # sign can be found a SOAP Fault will be returned.
This function normally calls the object passed to it in the SOAP Header as the LL:ObjRef element.
If there is no LL:ObjRef element then the SOAP action will be queried at the CORBA Naming Service. The function will attempt to resolve the part before the # sign by calling the CORBA ORB function on the string "corbaname:rir:#first_part_of_the_soap_action". Hopefully this will return a valid object reference from whatever CORBA Naming Service is available to the SOAP bridge. Also see Supplying a specific object to call. below.
In any case, the object found must support the method placed after the # sign. Furthermore, there must be in the Interface Repository a CORBA operation with the ID "IDL:SOAPAction:1.0" where the # sign has been replaced by a slash (/). Finally, the outer scope of the SOAP body must have the same name as the method being invoked.
Supplying a specific object to call.
The mapping of a SOAP action to an object instance above naturally omits to take into consideration that an interface can be instantiated by more than one object. This issue can only be resolved by the front-end server by applying some kind of URL (or SMTP recipient) to object reference translation.
Such a front-end server can then use the SOAPBridge::SOAPCall::invokeInstance, implemented by SOAPBridge_SOAPCall_i::invokeInstance function instead of invoke() and pass the obtained object reference.
Internally, invokeInstance() simply stores the supplied object reference and sets a flag. It then calls invoke() and returns the result.
Specification of SOAP Faults as generated by the SOAP bridge.
Any CORBA Exception, including System and User exceptions, that are raised during the invocation of the CORBA method will be returned as SOAP Faults. The detail section of the SOAP Fault will contain the actual exception that occured.
Several other conditions can return SOAP Faults, see SOAPBridge_SOAPCall_i::Fault for a list of these conditions.
This documentation is part of the "SOAP to CORBA bridge" project