I was wondering what’s your opinion regarding the different services we have at our disposal and which ones you prefer to use or if you use all of them, but in different scenarios:
Application Platform;
Java conventional services;
Flow services.
Basically, as per your experience, which ones do you like to work with? In which situations would you use one, over the other one? What kind of benefits vs consequences each one of the above services have? Do you see any major performance impact on your services if you decide to use the Application platform, instead of a Flow? What about in terms of time effort to develop them?
I’m a BE developer, so I definitely go with Java. However, sometimes I’m not certain when should I use PLS or simply Java conventional services. My thumb of rule is that I find a lot easier to implement design patterns and OOP principles through Application platforms (good for bigger projects), where I use Java conventional services for quick solutions.
Let me know what’s your opinion, since this I think this is quite an open subjective topic.
we are currently not yet using Application Platform.
When ever possibly we are using Flow Services and when it is neccessary we are switching to Java Services.
Most cases where we are using Java Services is when it goes to certain transformations which are difficult to construct as Flow Services by using Built-In Services, but are written as a Java Service much more easier.
As a thumb rule, go with the out-of-the-box features/services provided by the product (flow services) if it meets your requirement and leverage the product fully.
Write your custom java services class only if there is are no services to support the need.
I believe development using flow is much faster. Based on your experience, what is % saving in effort when using flow compared to Java for same service (say REST interfaces with simple validations and JDBC adapter for DB interaction). Any advise is much appreciated.
I have never tested but some colleagues have made an extensive POC where they found the effort of refactoring FLOW applications in “full Java” would only gain up to 5% increased performance in almost all cases.
The cases where performance gains was above that threshold were restricted to very specific code-intensive algorithms or extremely large transformations with hundreds of fields (but in that case you could be left with a big monolith of indecipherable Java code).
Here are some guidelines on when to use Flow and when to use Java:
Advantages of FLOW SERVICES:
Easier to learn versus Java. Good for companies that do not have Java developers (or not many)
Easier to transition “legacy” developers to webMethods Integration Platform service development
You can quickly develop and debug services (using drag/drop, wizards, graphical mapping, etc…)
They can be used for most of your integration solution services
“Disadvantages” to Flow Services:
You are limited to the existing Flow Steps
Limited to capabilities and properties available using the service development plug-in
Advantages to JAVA SERVICES:
Can write more complex / advanced logic (one example: solve complex mapping challenges)
Performance edge (pipeline is not cloned like it is with Flow Services)
Accessing APIs not already exposed by built-in services (e.g. from WmPublic package)
Best for utility services (Parent flow services can then call Java utility services that require a performance edge)
“Disadvantages” of using Java Services:
Requires developer(s) with Java experience to create/debug services
More complex for beginners to learn and be productive
Some people can name other advantages and disadvantages, but this is what we cover in our webMethods Integration Platform training (which I recommend for anyone who is a developer, architect and/or admin for webMethods)
Regards
Wayne Leishman
Principal Instructor at Software AG (for webMethods Integration Platform)
For Big Mappings, when you do not want to do them in Flow Services, you might want to check for the WmXSLT package to do the transformation with a XSLT transformation descriptor.
I agree with Gerardo that when you do the mappings in Java this will result in code which will be difficult to read.
DB Adapter interaction will be easier to integrate into Flow services than into Java Services.
Useful responses from all of you. Much appreciated. One more question -
How do you take care of source version control, unit testing and implementing CI/CD process for flow services which are stored as XML documents as compared to Java services.
You can diff/merge flow services in designer, and commit to source control as you would java. This commits the XML, NDF files, etc. into source control and this is important to be able to understand commits/etc (i.e. don’t commit a zip of a package).
There’s also a unit test framework available for designer (based on JUnit) that also provides code coverage information.
Any CI/CD process would need to do some of the following:
Typically pull the package and unit tests from source control
Use the Asset Build Environment and Deployer [ webMethods Deployer Help (softwareag.com) ] to take the source, create a deployable asset (equivalent to a compile if you wanted to compare to java).
Store this asset in any sort of repository (nexus, artifactory, even the filesystem if nothing else is avail).
Use Deployer to deploy the asset into a target integration server
Use the Unit Test Framework CLI to execute the developed unit tests (also from source control) in the deployed target.
This may differ slightly depending on deployment architecture, e.g. if you’re deploying a MicroService based pattern using containers, the CI/CD process would typically build containers and store these as the deployable asset for downstream environments to use, and can even control the deploy into docker or kubernetes (or equivalent) to provide blue/green zero downtime style deployments for example.
I totally agree with your statement. I think Java services tend to be more customizable than Flow services.