Following is a list of limitations of Remoting. 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 or Poco::AutoPtr 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, Poco::AutoPtr and Poco::SharedPtr.
• 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 must 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. 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 @soapHeader is not supported for return parameters.
• SOAP: The @soapHeader 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. Example:

bool method(Poco::SharedPtr<int> i)
    // Although changes to i are visible outside this is not serialized back.

bool method(Poco::SharedPtr<int>& i)
    // Non-const reference: this will be serialized back to the caller.