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.

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")
        to"/GoogleSearchService;

Note: the above incorrect spelling of "maintenance" as "maintanence" is intentional—the purpose of doSpellingSuggestion is to perform spelling correction.

Copyright © 1999-2003 FARGOS Development, LLC Last Modified: Wednesday, January 01, 2003 Suggestions regarding this site may be sent to the webmaster@fargos.net; information regarding the design goals of this site is provided on the Site Design page.