While Java is Object-Oriented, IS services are stateless operations on a pipeline. When you generate a Java class to represent an IS service, the class has a single method to represent service invocation. The IS pipeline is essentially a collection of name/value pairs, or a map.

While Java methods are defined in classes which are in packages, IS services are defined in folders and in Integration Server packages. Java packages and Integration Server packages are different concepts. A class's Java package path uniquely represents the class in the Java class namespace. An Integration Server package is a unit of packaging but it is not part of the service namespace. In the Integration Server namespace, the folder and service name uniquely identify a service. The folder name in the Integration Server namespace is usually a dot-separated list of words, for example: this.is.my.folder.name. Also, it is not uncommon that Integration Server folders include capital letters, while Java packages are almost always lowercase. Application Platform combines the Integration Server folder and service names to create a Java package name.

Java and Integration Server use different data types. Java's data type system is very rich, it includes primitive types and every class ever created. Integration Server has a much smaller data type system. Integration Server supports String and Java primitive wrapper types. However, complex structures in IS services are typically modeled using the Document data type. A Document is essentially a map where each element associates a name with a value. The values can be String, primitive wrapper, or Document. An IS document with nested Document elements is similar to a map that represents properties in a Java Bean. Application Platform takes advantage of this similarity. The input and output classes it generates are simple Java Beans with a property that represents each input or output value. If the IS service input signature includes a Document type, then a Java (Bean) class is generated to represent the Document structure.

Application Platform and Integration Server use different class loaders, so object references are not transferred between them. Only String, Date, primitive wrappers, and arrays of these elements have the same representation in both Integration Server and Java. More complex object structures are represented by Java Beans in Java and by IS documents in Integration Server. The list of elements with similar representation includes a byte array, so you can pass serialized objects if you handle serialization in Application Platform and ensure that appropriate classes are available on both sides.

Java and Integration Server recognize different words as having special meaning. For example, an IS service can have an input parameter named class but class is a reserved word in Java. Also, a reserved word in Java may be a valid IS service or folder name. The Application Platform code generator adds PLS_ or pls_ in front of generated class and property names. However, there still can be cases when the generated code does not compile properly. In such cases, try to use flow mapping in Application Platform in order to change parameter or service names.

Java and Integration Server recognize different sets of characters as having special meaning. An IS service and parameter names can use @, *, or other characters that are not allowed in Java class names and variable names. You should avoid such conflicts by changing service names and property names in Integration Server.

The Application Platform code generator relies on the IS service to have an explicit service signature that defines all input and output elements. Such a signature is not required in Integration Server. If you want to call an IS service without a signature from Java and it is not possible to add a signature to this IS service, you must create a flow wrapper that has an appropriate signature and invokes the service.