I heard some where that it is not a best practice to make java services in webMethods developer.
If it is right, what are the reasons for that ?

Making JavaService in developer is when you have custom/complex logic needed its easiest way using this,otherwise always coding flowservice will helps all the team who doesnt know much of java (non java techinical folks etc…like analyst,support personal etc…)

HTH,
RMG

There are quite a few threads on this forum on this topic. Search for java and flow and you’ll encounter some good hits.

My 3 rules of thumb (to go along with the 3 rules of optimization) for Integration Server-based solutions:

1. Write it with FLOW, not Java.
2. Write it with FLOW, not Java.
3. Write it with FLOW, not Java.

I’d go one step further with RMG’s suggestion: write a Java service when it’s the only way it can be done or if profiling indicates that the service would benefit from optimizing. “Custom/complex logic” can just as well be done using FLOW. Using Java 1) prevents those who don’t know Java from understanding/modifying the service; 2) makes debugging using Developer more difficult. The IS environment is structured around the use of FLOW. The use of Java should be very, very limited.

“Consider using java instead of flow, especially for CPU-intensive logic involving looping or frequent invocations. Write transformer logic using Java services instead of Flow services to be used in transformers. Individual transformers can run 5-15x faster in Java than in Flow.”

Reference: GEAR 6 Performance Tuning White Paper

I only use java services when:

1. a small efficient, java service can avoid a large, cumbersome FLOW service (e.g. hundreds of Flow statements []I need to create a utility to work with java objects or to programmatically build an input needed by a WM built-in service such as pub.xml:queryXMLNode []A well-conducted performance analysis has identified a bottleneck in a Flow service that could be addressed with a small, tight java service

Many developers who are new to webMethods IS, jump into java services much, much too quickly. This leads to confusion, poor leverage of the strengths of the WM built-in services and higher maintenance costs.

While I acknowledge that there are times that java services are useful, a new developer should follow Rob’s three rules of thumb until a mass of evidence suggests that it may be time to create a java service.

Mark

I create java services when I cannot find a method or utility available in the built-in services reference.

Alternatively, look in WmSamples because there are a number of java utilities coded in there.

And lastly, look for the latest PSUtilities package from Advantage. As a “best” practice, always copy the java or flow service from PSUtilities to your codeset. The reason is that PSUtilities package changes over time and you cannot be reasonably sure that the PSUtilities that is installed on a system is the one that you need.

And of course, a final word on best practices. GEAR is a good start, but is not direct or complete enough.

Best Practice is really defined as what will work for your enterprise. Writing to a file log is a very consuming process, but for some entities, it is the defacto standard and therefore a best practice.

Companies that spend the time to create processes and standards around a center of excellence or integration competency center (insert buzzword here) define their best practices.

Gear provides the templates, you provide the answers.

Hello,

Yemi Bedu

This is sound advice–after one has determined which services have “CPU-intensive logic involving looping or frequent invocations” through profiling. There is no point in tuning a service that is a small part of the overall execution footprint.