Limitations

Following is a list of limitations of Remoting and the Remoting code generator. When designing and building remote services with Remoting, knowing the limitations of Remoting is recommended to avoid troubles later on.

• Plain pointers are not supported. The use of Poco::SharedPtr, Poco::AutoPtr or std::shared_ptr is recommended instead.
• Enumerations are supported, with the restriction that enumeration values are serialized as integers. Furthermore, enumeration types are reduced to integers in SOAP/WSDL interfaces.
• Function overloading is not supported. Two (remote) member functions in a service object cannot have the same name, even if they have a different argument list. Note that code generation will succeed, but the generated skeleton class won't compile due to a duplicate class definition.
• Dynamic inheritance is not supported for parameter passing — objects passed as parameters are truncated to the static parameter type (even if passed as pointer or reference).
• All classes used as parameter or return value types must implement value semantics (implement a copy constructor and an assignment operator) and must provide a public default constructor.
• Class templates are not supported with the exception of std::vector, std::set, std::multiset, the other STL container and smart pointer classes supported by Remoting, Poco::AutoPtr, Poco::SharedPtr, Poco::Nullable and Poco::Optional.
• For each non-public data member of a class which needs to be serialized or deserialized, a getter and a setter member function must be provided. Otherwise the proxy/skeleton has no way to access these members.
• Multiple inheritance will work in most cases except for WSDL generation where only the first base class is used.
• Private or protected inheritance is not supported.
• Cyclic graph structures cannot be serialized. An attempt to serialize a cyclic graph structure will result in an endless loop (or endless recursion) in the serializer, as the serializer always passes parameters by value, even if a Poco::SharedPtr or a Poco::AutoPtr is used.
• SOAP: Complex data types should not have an XML namespace (namespace attribute). This is a limitation of the WSDL generator which inlines generated XML schemas and only supports a single schema namespace. By setting the namespace only at service class level it can be guaranteed that the namespace of the service class is used for all other data types.
• SOAP: Inlining of a return parameter will only work with elements, not with attributes. Also the return parameter must be the only value returned by the method, i.e., no output parameters are allowed (otherwise the generated WSDL file will be invalid). Return parameters can be renamed but the order when they are serialized/deserialized cannot be changed. They are always serialized/deserialized first. Also header is not supported for return parameters.
• SOAP: The header attribute can only be specified for parameters that have a complex user-defined type (struct or class).
• Output parameters: only parameters that are passed by non-const reference are serialized back to the caller. This also applies to Poco::SharedPtr and Poco::AutoPtr. Because plain pointers are not supported, use of Poco::SharedPtr and Poco::AutoPtr is mandatory. To be able to distinguish between an output or an input parameter, it is assumed that a non-reference Poco::SharedPtr/Poco::AutoPtr should not be serialized back. See Example 1.
• Use of struct and class keyword in parameter or return value declarations is not supported. This is a restriction of the code generator and can be easily worked around by omitting the keyword (which is superfluous in this case anyway). See Example 2.

Example 1

bool method(Poco::SharedPtr<int> pValue);
    // Although changes to the variable pointed to by pValue would be visible
    // to a local caller, the changed value is not serialized back to a remote caller.

bool method(Poco::SharedPtr<int>& pValue);
    // Non-const reference to Poco::SharedPtr: the changed value for the variable
    // pointed to by pValue will be sent back to the remote caller.

Example 2

The following method declaration will lead to bad code being generated by RemoteGen:

void method(struct MyStruct& s);

To work around this issue, simply omit the (superfluous) struct keyword:

void method(MyStruct& s);