webMethods 10.2 | Application Platform User Guide | Developing with Application Platform in Designer | About Using Services in Application Platform | Calling Integration Server Services from Application Platform Projects | Coding Considerations
 
Coding Considerations
There are some architectural differences between coding with Java and coding with IS services. You must keep the following points in mind when you call IS services from your Application Platform projects:
*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.
The following table shows the data type mapping between Java and Integration Server:
Java Data Type
Integration Server Data Type
java.lang.String
String
Primitives; int, float, …
Object->Primitive Wrapper; Integer, Float, …
Primitive Wrappers;
java.lang.Integer,
java.lang.Float, …
Object->Primitive Wrapper; Integer, Float, …
java.util.Date
Object->Primitive Wrapper; Date
Java Bean class
Document
A map of property name => property value, where String and primitive properties are represented as described here, and other types are represented as nested Documents.
*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.

Copyright © 2017-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release