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:
- 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.
- 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.
- 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")
to"/GoogleSearchService;Note: the above incorrect spelling of "maintenance" as
"maintanence" is intentional—the purpose of doSpellingSuggestion is to perform spelling correction.
