The OpenText Process Suite ABC Glossary - WS AppServer Package part 2

WS AppServer Package

Finally, you can generate a web service interface on the WS‑AppServer package and thus make the java methods available as web service operations. The SOAP checkbox property of a method defines whether a web service operation will be generated and thus the method will be exposed as a web service operation or not.

By default, for each model (table or view) a single update web service operation is generated to insert a new record into the table, update or delete an existing record or tuple.

In the WS-AppServer package, you can make changes to the models, the attributes, the properties of the attributes, and the methods. In addition to the standard methods that are generated with the package itself, you can define your own methods. You can generate the signature of this method, this will only create the skeleton of the Java method in the extension class file. In this case, you need to add the relevant java source code to implement the method. Or you can refer to any available attribute(s) to automatically generate the associated Java source code in the base class file to implement the method. For example, as a standard method a get operation is already generated for selecting customers by their primary key. In addition, you can generate another method to select the customers for a specific country using the “country of residence” attribute. In this case the method is added to the base class file since the related Java source code is generated by the platform.

The extension class file contains the related Java source code in order to implement the functionality of the additional methods. Typically, the IDE Eclipse is used to modify the Java source code as saved in the extension class. Do not edit or add code in the base class files as the contents of these class files are overwritten any time you regenerate the Java source code of the associated models.

As a good practice, you create a basic WS-AppServer package directly related to the metadata document of the relational database to generate the basic functionality and make that only available as Java methods, while no web service interface is generated on the basic WS-AppServer package methods. The basic java methods are thus not exposed as web service operations. The basic java classes are compiled into a “basic” JAR file.

Next, you create another empty WS-AppServer package to contain your own custom models that will be based on the models defined in the basic WS-AppServer package. The custom models and their methods are implemented by using the generated basic methods of both the basic and custom WS-AppServer package and adding any other Java source code you develop in the extension classes of the custom package. The custom java classes are compiled into a “custom” JAR file. Note that with the “custom” JAR file, you create a dependency to the “basic” JAR file containing the implementation of the set of basic methods. These custom java methods are then made available by generating the web service interface to these methods. For each java method, you can use the SOAP checkbox property to decide whether the method is made available as web service operation.

This effectively creates two layers, the basic layer through which you communicate with the back end application while in the business process models, you only apply the custom web service operations. Using this kind of layering of your methods and web service operations enables you to abstract your process from the actual implemented back end application i.e. the data model of the related data sources. This allows you to easily change the back end application and redefine the basic layer while the business process models are not effected (and do not need to be updated) as these only communicate with the web service operations of the custom layer.

List of abbreviations

Don't miss out on future blog posts! Subscribe to email updates today!