Proxy Generation

Proxy Generation is the automatic generation of a client proxy class that mirrors the registered Service type.

Think of the Service as a binding to a virtualized Web Service that can process asynchronous requests in parallel. Additionally, because the proxy does not expose any DataSynapse classes, it provides a standards-compliant approach to integrating applications in a vendor non-specific way.

The following rules apply to the generated proxy:

•

The use of the proxy class is completely independent of the DataSynapse API. Client code that uses the proxy class does not need to import or reference any DataSynapse classes.

•

If the Service has an initMethod, the proxy constructor takes any arguments to that method.

•

All Service methods produce synchronous and asynchronous versions of the method on the proxy.

•

Each update method has a corresponding update method on the proxy.

•

The cancelMethod and destroyMethod are called implicitly and thus do not generate methods on the proxy.

•

The targetPackage field identifies the package (in Java) or namespace (in .NET) in which to place the generated classes. Its default value is the name of the Service.

•

If you use xmlSerialization, classes are generated for all non-primitive types, which must be interop types. If you do not use xmlSerialization, classes can be any serializable type, they are not generated, and the client must have access to those same classes (by a JAR/Assembly.)

•

When generating proxies, a Java Calendar object is represented by a DateTime object in a .NET proxy, and vice-versa.

The proxy is generated using the Services > Services > Service Types page. The proxy is generated on an Engine, so successful proxy generation requires an available idle Engine.