KCML can act as a server for methods exposed through the COM and Corba protocols. The methods can be invoked by either another KCML acting as a client or an application written in some other programming language that conforms to the appropriate protocol.
KCML 6.20 & 6.40 also used a similar method to export SOAP server methods, however KCML versions after 6.60 implement SOAP servers using formal SOAP server definition.
COM servers are special in that they are started by the COM subsystem in Windows and the name of the program to load is specified in the registry. CORBA servers run as daemons with the program to run passed on the command line with a -p switch. In all cases the specified program is loaded and execution continues until a $BREAK ! statement is reached whereupon the instance of KCML blocks awaiting the first method call. The methods available for the interface must be visible in the foreground of the program that has blocked.
The exported methods are grouped together under an interface name. The 'KCMLObjectExport() function is used to define the interface. The first argument is always the type of the object, "COM" or "Corba" , the second argument is the interface name and any subsequent arguments depend on the type of server. These two arguments are not case sensitive.
The only methods that can be called in the server program must be prefixed with the interface name and an underscore. Thus in the following example the interface is time and the method is .getTime(). The name of the function is not case sensitive. Methods returning strings must have their DEFSUB name ending in $ but the $ is not used in the method name.
REM do any necessary initialization here
'KCMLObjectExport("COM", "time")
REM Wait for requests
$BREAK !
REM do any tidy up code here
$END
DEFSUB 'time_getTime$()
REM return time as string "CCCC-MM-DD HH:MM:SS"
LOCAL DIM t$24
CONVERT DATE #DATE TO t$
CONVERT TIME #TIME TO STR(t$,LEN(t$)+2)
RETURN t$
$DECLARE 'KCMLObjectExport(STR(), STR())