Java® services on steroids for the ESB
Are you unhappy with the Java capabilities in Software AG’s webMethods Integration Server? Do you want to avoid proprietary Software AG classes and long, unreadable generated code that wraps IData structures? Do you want debugging and testing with standard tools and frameworks? All of this is now available with the webMethods Application Platform.
| Issue 1, 2017 |  Download PDF |
Why do I need an application platform?
Application Platform or App Platform, as I like to call it, is a relatively new component of the webMethods suite. App Platform, introduced with webMethods 9.8, is fully featured and ready to use since version 9.10. The aim of App Platform is to create and host Java applications so they can easily interact with webMethods Integration Server (IS). This integration is bi-directional—IS services can be consumed and native Java methods can be exposed as IS services.
App Platform is not a standalone server—it runs inside the Software AG Common Runtime—a common infrastructure layer beneath IS and My webMethods Server (MWS). Its design time is delivered as part of webMethods Designer.
App Platform comes free of charge with the purchase of webMethods IS or My webMethods Server—there are no additional license costs required.
Note – The App Platform components have to be explicitly selected from the Command Central Installer or the Software AG standalone installer.
Get your hands dirty
Set up environment
Start Software AG Designer and connect to webMethods IS. Disable the WmTomcat package because it conflicts with App Platform.
From Window->Preferences->Server->Runtime Environments in Designer, add a new runtime environment of type Application Platform Integration Server (remote) as shown in Figure 1.
Figure 1: Add a new runtime environment.
Navigate to the App Platform Perspective and add a server of type webMethods Integration Server(remote) in the Server view.
Expose service to IS
From the new wizard, create a Java project of type App Platform. Assign an IS facet to the project as shown in Figure 2.
Figure 2: Assign an IS facet.
Create a class with public method(s) containing your business logic. This can also be static or stateful. App Platform will take care of the class instance creation.
Annotate the class with an @Service and @ExposeToIS(package=”your_package_name_here”). Annotate every method of the class you want to expose as a service with @ExposedMethod.
Figure 3: Annotate your services.
Deploy your Java product to the target server and check for the package defined in the annotation. If the package exists, check inside for a path equal to the Java class namespace.
Call the exposed service as any other integration service to test it, as shown in Figure 4.
Figure 4: Call exposed services.
Consume IS Services in the App Platform
Select a project in the Project Explorer. In the context menu, as shown in Figure 5, select App Platform -> IS Tools -> IS Service Wizard.
Figure 5: Launch IS Service Wizard.
Select the service that has to be consumed from IS. The code for using it will be generated in the genSource folder of the selected project. These generated classes are wrappers of the service and the Plain Old Java Objects (POJO) classes for the service input and output.
Calling the service is simply populating the input POJO, calling the wrapper .invoke(). Return values can be obtained from the output POJO via getters.
Figure 6: Populate the Input POJO.
Debugging
Debugging is made easy in an App Platform project by leveraging the standard Java remote debugging capabilities.
First, the remote debugging on the server has to be enabled. The easiest way to do this is to first stop the Integration Server, then navigate to ${SAG_Installation}/profiles/${IS_Instance_Name}/bin and start the server with the startDebugMode.bat. The debug port of the server can be found inside the script – default is 9191.
In Eclipse™ set a breakpoint in the App Platform project. Navigate to Debug Configurations. Under Remote Java Applications, create a new debug configuration. As project, choose the App Platform project that contains the breakpoint and give the debug port. Click on the Debug button and observe in the Debug perspective how Eclipse is connected to the IS.
Figure 7: Debug application.
Trigger the logic that is the selected App Platform project and debug through it with the standard Java debugging capabilities.
Testing
Unit testing
Java logic can be tested with standard jUnit tests. Those tests run in isolation in Designer in an Ant environment. To mock dependencies, use industry standard tools like jMock or EasyMock.
Server side testing
Additionally, App Platform gives a wrapper framework around the standard jUnit framework that allows you to run server side tests. These tests have two components:
- Test project itself, that has to be deployed on server
- Test runner in either Eclipse Designer or Ant incorporated in Jenkins
jUnit test and additional annotations
To create a standard jUnit test, use @TestBundle(symbolicName=”bundle_name”) and add the name of the bundle where the test is developed. This can be seen in the assetBuild.properties file in the root directory of the project. Look for the value of the component.name property.
In Figure 8, the command @RunOnServer(host=”localhost”, jmxPort=8075, username=”Administrator”, pwd = “manage”) defines:
- Host – host of the IS
- jmxPort – jmx port of the server that can be seen from the server definition in the Servers view
- Username, pwd - credentials for the server
The test will be triggered locally from the jUnit framework, but will connect to the server via the data provided in this annotation. It will execute the test on the server side and will later return the result to the test runner. That is why the test project has to be first deployed on the server.
Also, in Figure 8, you will see that the command @RunWith(IntegrationTestRunner.class) points to the test runner nature.
Figure 8: Setting Up a jUnit Test
If the annotations are set correctly, the test assertions will be executed on the server side and the result will be shown in a standard jUnit report. If some test setting is wrong, like target host, ports, credentials, this will result in test failure with a proper message such as “Cannot connect to server.”
Summary
App Platform as a container for Java applications gives developers a lot of flexibility. There is almost no learning curve for experienced Java developers and it gives them the freedom to use the tools and frameworks they choose.
Figure 9: App Platform as a container for Java applications gives developers flexibility.
App Platform may host both Java web and Java core projects that can call integrations orchestrated in Integration Server.
Figure 10: Host Both Java web and Java core projects.
The ability to expose the same project inside My webMethods Server and IS runtimes aim to support the development of reusable technical components like common libraries, exception handling and constants that can later be deployed to both runtimes.
App Platform is a developer-centric tool that helps you rapidly create new applications on a known platform. It comes free of charge and is fully integrated with the asset delivery lifecycle. Give it a try.
For more information, check the official Empower documentation for the project and the Software AG Tech Community Application Platform section