Is making java services best practice in webMethods

[Talha_Khan]

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 ?

[gupta_r.17495]

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

[reamon]

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.

[mitul1 (mitul *)]

“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

[wMusers.Com1 (wMusers.Com)]

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

[raymoser]

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.

[Yemi_Bedu]

Hello,

You may want to look at the design of the operating service first over the elements that make it up for optimizing. A better design at the top level can lead to better utilization of low-level components. I would say that writing a java service would be slower than writing a C service (you don’t here about them that much) in some instances. But most would prefer to do a java service over C because of easier design and maintainance. Since in C you can inline Assembly for a particular architecture, one may want to wrap an assembly utility with C to call.

So I would choose to use:

1. Modeler when possible
2. if no service pre-exists, make it one if flow use as much that pre-exists.
3. create a new java-service to provide new utility or object reference (UDP socket, AU sound access).
4. create a C-service to create semi-portable machine critical logic (new MP3 library, Java-C bridge library to a old dll or so)
5. create a c-service soft wrapping assembly to work out cpu register mapping of a space telescope.

I hope to never go past 3. Most should be interested in working at 2 as a new comer working their way up to 1. Good day.

Yemi Bedu

[reamon]

@mitul

“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

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.