The system I have discussed so far allows you to call any COM
component over standard HTTP with simple client-side script code. You
can extend the system functionality even further with just a little
more coding. First, this system does not include the ability to make
asynchronous calls. Adding this would be straightforward because the
XMLHTTP component provides the ability to submit asynchronous
requests and raises an event to notify you of request completion. You
would just have to set the async flag when you call the Open
method.
A more involved feature to add is support for ByRef parameters.
This type of parameters is usually frowned upon when used in server
methods called by clients. You probably already know this but using
DCOM, each ByRef parameter must be marshaled from client to server
then back again. ByVal parameters are only marshaled from client to
server but not back. Furthermore, if you develop server components in
ATL, you may have some methods with [out] parameters (VB cannot have
out parameters except for the return value of a function). The
discussed implementation of XIR does not support ByRef (i.e. [in,
out]) or [out] parameters. You could add this support by adding a
parameter direction attribute to the request XML document and having
the server return all ByRef and [out] parameters as part of the
response document.
You may also need to implement the XIR client as a Java applet or
directly in script. I used an ActiveX control because that works for
my application. If your application has different requirements, there
is no reason to stick to an ActiveX control.
Finally, if you do not want the server to be constantly performing
lookups on the service catalog, you can distribute this catalog to
your clients and have the XIR client perform the lookup and send the
progid, method name, call type and return type as part of the request
XML. This distributes some of the processing load on the clients
slightly offloading the server.
Email TopXML