Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space IceMaster and version 3.7.1

Znav
nextParameter Passing in Java Compat
prevServer-Side Slice-to-Java Compat Mapping

The server-side mapping for interfaces provides an up-call API for the Ice run time: by implementing member functions in a servant class, you provide the hook that gets the thread of control from the Ice server-side run time into your application code.

On this page:

Table of Contents
maxLevel3

Anchor
skeleton
skeleton

Skeleton Types in Java

On the client side, interfaces map to proxy types. On the server side, interfaces map to skeleton types. A skeleton is a class or interface that defines a method for each operation on the corresponding Slice interface. For example, consider our Slice definition for the Node interface:

Code Block
languageslice
titleSlice
module Filesystem
{
    interface Node
    {
        idempotent string name();
    }
    // ...
}

The Slice compiler generates the following definition for this interface:

Code Block
languagejava
titleJava Compat
package Filesystem;

public interface _NodeOperations
{
    String name(Ice.Current current);
}

public interface _NodeOperationsNC
{
    String name();
}

public interface Node extends Ice.Object, _NodeOperations, _NodeOperationsNC
{
    public static final String ice_staticId = "::Filesystem::Node";
    public static final long serialVersionUID = ...;
}

public abstract class _NodeDisp extends Ice.ObjectImpl implements Node
{
    // Mapping-internal code here...
}

The important points to note here are:

  • As for the client side, Slice modules are mapped to Java packages with the same name, so the skeleton class definitions are part of the Filesystem package.
  • For each Slice interface <interface-name>, the compiler generates Java interfaces _<interface-name>Operations and _<interface-name>OperationsNC (_NodeOperations and _NodeOperationsNC in this example). These interfaces contain a method for each operation in the Slice interface. (You can ignore the Ice.Current parameter for now.)
  • For each Slice interface <interface-name>, the compiler generates a Java interface <interface-name> (Node in this example). That interface extends Ice.Object as well as the two operations interfaces, and defines the constant ice_staticId with the corresponding Slice type ID.
  • For each Slice interface <interface-name>, the compiler generates an abstract class _<interface-name>Disp (_NodeDisp in this example). This abstract class is the actual skeleton class; it is the base class from which you derive your servant class.

Ztop
Anchor
servant
servant

Servant Classes in Java

In order to provide an implementation for an Ice object, you must create a servant class that inherits from the corresponding skeleton type. For example, to create a servant for the Node interface, you could write:

Code Block
languagejava
titleJava Compat
package Filesystem;

public final class NodeI extends _NodeDisp
{
    public NodeI(String name)
    {
        _name = name;
    }

    public String name(Ice.Current current)
    {
        return _name;
    }

    private String _name;
}

By convention, servant classes have the name of their interface with an I-suffix, so the servant class for the Node interface is called NodeI. (This is a convention only: as far as the Ice run time is concerned, you can choose any name you prefer for your servant classes.)

As far as Ice is concerned, the NodeI class must implement only a single method: the name method that it inherits from its skeleton. This makes the servant class a concrete class that can be instantiated. You can add other member functions and data members as you see fit to support your implementation. For example, in the preceding definition, we added a _name member and a constructor. (Obviously, the constructor initializes the _name member and the name function returns its value.)

Ztop

Normal and idempotent Operations in Java

Whether an operation is an ordinary operation or an idempotent operation has no influence on the way the operation is mapped. To illustrate this, consider the following interface:

Code Block
languageslice
titleSlice
interface Example
{
               void   normalOp();
    idempotent void   idempotentOp();
    idempotent string readonlyOp();
}

The methods for this interface look like this:

Code Block
languagejava
titleJava Compat
void normalOp(Current current);
void idempotentOp(Current current);
String readonlyOp(Current current);

Note that the signatures of the member functions are unaffected by the idempotent qualifier.

Ztop

See Also

Znav
nextParameter Passing in Java Compat
prevServer-Side Slice-to-Java Compat Mapping