Frequently Asked Questions

Technical Issues

The questions below are deemed to be somewhat technical. Questions of more general interest are addressed elsewhere.

I have already written an application. How can I use it with FARGOS/VISTA?
There are a few ways:
  1. Use the application programming interfaces provided by the C++ OMEapi classes and connect to a FARGOS/VISTA Object Management Environment. This approach is the most natural if your application either predominately makes use of services provided by others or only exports a small number of services.
  2. Code by hand the necessary class and method definition tables and link against the OMEcore library. As a side-effect, this extends your application with the full capabilities of the FARGOS/VISTA Object Management Environment.
  3. Write an OIL2 class whose methods call relevant functions provided by your application and link everything against the OMEcore library to create a customer FARGOS/VISTA Object Management Environment executable.
Can I access Web-based Services?
Sure. There is even a FARGOS/VISTA-based application class that compiles a Web Services Description Language (WSDL) file directly into OIL2 source code, which in turn implements the interface to the remote SOAP-based service. See the Web Services Description Language compiler sample for details. That said, was not the ridiculous complexity for little gain a reason why this approach failed to gain much enthusiasm?
What's the penalty for using Web-based Services instead of exploiting the transparently distributed nature of FARGOS/VISTA?
Overhead, overhead, overhead. After implementing a web-based service, the service provider needs to provide a Web Services Description file that corresponds to the exposed application programming interface. This is an XML document whose size is typically measured in hundreds of lines. Ideally, a client stub is generated automatically by feeding the WSDL file into WSDL-aware program. The end result is, again typically, hundreds of lines of code that are responsible for marshalling arguments, formatting them into an XML document (a SOAP envelope) and shipping them off to the remote service via a transport protocol such as HTTP. The client stub code is also responsible for the inverse: await a response from the service provider, parse the resulting XML response document (which is another SOAP envelope) and convert the XML text into native data types where appropriate (such as integers and floating point numbers). Thus programmers must maintain the WSDL file that describes the interface as well as the machine-generated client code used to access the remote service.
The conversion of data back and forth between native data types and XML consumes CPU cycles and memory.
It's also hard to conceive of a less efficient encoding than XML for on-the-wire transmission of data, so overhead is introduced in the amount of network bandwidth consumed.
How about some concrete numbers regarding this alleged overhead?
OK, as a concrete example consider the Google search service API made available as a downloadable example. The WSDL file describing the service requires almost exactly 200 lines. The WSDLtoOIL2 class generates an OIL2 source file that is a little over 300 lines in length. An application wishing to make use of the service needs to create an interface object (in this case, of class GoogleSearchService). For example:
acl = makeDefaultACL();
obj = send "createObject"("GoogleSearchService", acl)
        to ObjectCreator;
answer = send "doSpellingSuggestion"(MY_GOOGLE_KEY, "maintanence")
        to obj;
Communication overhead in bytes transmitted
Request Method SOAP FARGOS/VISTA Difference
Request Reply Request Reply
GetCachedPage 760 5153 436 3732 70%
GoogleSearch 1076 11733 500 6388 54%
SpellingSuggestion 766 647 436 388 58%
What would be required of a native FARGOS/VISTA-based solution?
First off, the need for a WSDL file goes away, thus the 200 lines of XML describing the API disappear. That takes with it the 300 some lines of automatically generated source needed for a client-side stub. Since there is no longer a client-side stub, one won't need to be created. So, it pretty much distills down to one line:
answer = send "doSpellingSuggestion"(MY_GOOGLE_KEY, "maintanence")
Note: the above incorrect spelling of "maintenance" as "maintanence" is intentional—the purpose of doSpellingSuggestion is to perform spelling correction.