[Up: Java Interface]
[Previous: Anatomy of an operation] [Next: Running the example]

#
A generic DII interface

Just consider if we had an application which allowed the browsing of an interface repository. A user would find a suitable interface at run-time and decide to invoke operations without having to write a specific client object. What would be nice to have is a generic client which could cope with a priori unknown operational interfaces. As we have seen in figure 7.2 and from the discussion of the previous section, an operation invocation consists of the following elements:

- a name of the operation
- a return type
- an ordered list of actual parameters

With this ``anatomy'' of an operation invocation we can assemble a domain-specific conceptual and relational catalogue. We have developed such a catalogue which provides the ``vocabulary'' to express the information needed for the specification of an operation invocation. The conceptual graph depicted in figure 7.3 shows how to translate the operation invocation for `deposit( 100 )` using the DII (again concept nodes are denoted by white rectangles and relation nodes by black rectangles). As can be seen, a meta-notation based on CG provides an easy readable, formal specification of an operation invocation. It should be clear that the CG template can be extended arbitrarily to cover the specifics of the CORBA-IDL like complex type definitions or sequences of arbitrary types.

Figure 7.3: Conceptual graph representing the specification of the operation `deposit()`.

[Previous: Anatomy of an operation] [Next: Running the example]
[Up: Java Interface]