It may just be my perception but it seems like there has been an unusual number of questions about how to do things in Java within Integration Server. I thought I’d post a gentle reminder of the three guiding principles of Integration Server development:
Don’t write it in Java.
Don’t write it in Java.
Don’t write it in Java.
Of course that’s an extreme point of view but it’s worth keeping in mind. There have been various discussion threads over the years about the use of Java services. For example, this one from 2002. These threads have generally had several posters (including yours truly) pointing out that use of Java should be the exception, not the rule. Our esteemed founder, Dan Green, stated: “Without sounding melodramatic, Java developers can significantly increase a project’s time-to-market and ruin your ROI.”
It is quite tempting to write things in Java, particularly when one has a Java background but is new to FLOW. Generally speaking, using Java services to accomplish most tasks is not necessary. Processing XML, interacting with databases, manipulating lists and strings, mapping data elements and more can all be done without using Java. As a rule of thumb, all these should be done without using Java.
Using Java makes development and debugging more difficult. It generally takes much more effort to do many things in Java services which can be easily accomplished in a couple of FLOW steps.
Thanks for the words of wisdom. I could not agree more!
On each project, I usually find a need to create few small java services to provide utility-like functions. Other than that, I do all of my work in Flow.
BTW, I can’t believe you used that lame character-based smilie!
Yeah, I do the same. There are some things where Java is a good thing to do but I think the key phrase is “few small java services”. The posts of late have been asking about doing significant parsing work or database interaction, which should always be questioned with a critical eye–“do I really need to do this in Java or am I just doing it cuz it ‘seems’ easier?”
Character-based smilies are so old they’re back in style! Go retro!
I’m one of those people who asked a java question. You responded to it and convinced me that doing it in java was actually almost the same as doing it in flow. I’m not a java programmer, so I know why I should avoid java programming.
I think in general you should avoid java as much as possible, there are only three reasons to use java:
Performance reasons
It can’t be done in the flow language
Need for utilities which are not provided by webMethods, but which can be built using the wM java API (documented and undocumented).
You may have a character-based smilie, at least you have an avatar! “Mine” is lost during the migration.
Yes, writing key services in Java can boost performance. The key to the effectiveness of this is to profile the integration to identify bottlenecks. Then optimize the bottlenecks. One should resist the urge to write a service in Java simply because of a belief that it needs to be fast. There are more considerations at hand than just speed. Readability. Maintainability. Debugging. All these need to be considered. Prematurely writing a service in Java risks reducing all the “-ilities” for marginal or no speed gain. Before negatively impacting the “-ilities”, one should be sure that the speed gain is meaningful.
Joined the forum only yesterday because of my struggle with java during our migration from 4.6 → 6.5.
Problem was I wanted to move a directory from the C to the D drive; but the path is hardcoded in a java service.
IS could not find a java compiler → I installed a java compiler;
then it started to complain about errors in a module I never heard about.
studied the developer documentation and found out that all java services in a package are thrown on a big pile and that the compiler error could be caused by any java service.
Then I decided to get rid of it completely!
Motivation: I can not imagine that it is not possible to rename a file in the file system or to create a subdirectory without using anything but flow.
I will, when needed place questions in the correct forums of cause.
Setting the path to the java compiler is a common one-time only step. That step is covered in the installation guide.
Sounds like you have inheirited a poorly designed application. Java “services” are just methods in a class. Multiple services are stored in the same class only when they are placed in the same folder in the navigation panel. You can place all of the services in one folder, just as you would place multiple related methods in the same class.
Creating simple utility services to interact with the operating system certainly falls within the intended uses of java services.
Writing java services on Integration Server is surely become a problem for some people who usually solve their problem by creating flow services.
Sometimes we need to create java service for these reasons :
Service with complex algorithm. (Performance issue)
Some problems that could not be solved by creating flow service. I.e : accessing back end system using API.
Writing java service we need to see about the library needed. We may put it on the classpath or simply put the library on the packages/[package_name]/code/jars folder.
I usually create java code using external editor (eclipse, jdev) to ensure that my code did not contain any error and working fine and then deploy it to the Integration Server.
Hi all,
I did my job and studied the docs on java. Even borrowed a book in the local library (JAVA 2 Easy computing Guide, Data Becker 2000)
By studying the advantage webside I found out that the service the compiler is complaining about used to be part of the no longer supported wmsamples package. It is a service (wcarddir) that processes directory listings with wild cards.
I did not find a build in flow service that does the same; not even a flow service that returns a directory listing from the local file system.
So I guess a I am convicted to java.
regards
Gert
Thank you very much Mark. This is very helpfull.
It looks like it has been directly derived from the example for usage of the dir$ function in vbasic.
best regards
Gert
Yeah, that’s it. No one knew how to do this in Java, so they looked at Visual Basic examples to figure it out. Good thing we have Bill Gates to show us how to do complicated tasks like list the files in a directory… sorry that’s folder now that we have Windoze.
WMSAMPLES package as it is named should not be used as is. This package contains some sample services for developers to get started. This package is not supported by any means. The same goes for PSUtilities pacakge.
The service you are asking (PSUtilities.file:listFiles) is avialable in PSUtilies. My recomendation is to get an idea of what they are doing and implement your own service in your own utils package.
You can download this package (if you don’t have it) from Advantage.
There’s a common notion about using Java when dealing with “complex algorithm” or “performance bottlenecks”. I think the definition of complex and slow is highly dependant on the developer (with a small ‘d’). There’s so many things easily accomplished with Flow, but not obvious to beginners, that a lot of people feel that it’s “complex”. As for performance, when you’re not using built-in facilities effectively, Flow can be slow. As example:
Extracting data from XML with qualifiers (like IDOC or EDI), or other complex extractions. Slice through the XML with queryXMLNode.
“deep” copy of documents/records. A lot of times “implicit looping” takes care of it.
Lengthy string manipulations. pub.string:replace with RegEx makes mincemeat of strings.
Code conversions with complex patterns. pub.string:lookupTable with, again, RegEx!
Catching exceptions with custom Java wrapper (seen quite frequently). Use Try-Catch blocks.
File I/O. A big can of worms actually, but seems to be a security blanket for a lot of people. Can substitute with FTP’ing to localhost. There’s so many pit holes with file I/O and FTP that it deserves a separate post.
Generating HTML/XML reports. pub.report has decent facilities.
Given the problems I’ve seen from the above list (and a lot more), I’m really skeptical when I see our developers (or others) writing Java codes during implementation. Performance problems is solved most often by effecient coding (in Flow), not writing Java.
OTOH, I make extensive use of two packages (written mainly in Java) provided by wM – PSUtilities and OpenSSH. I just don’t want to write my own! I think I’m averaging one Java service per 3 projects.
Hi ramchalluri,
thanks for your advise.
What the service does is not to complex.
Files are placed is the local file system by a client that ftp’s them in.
(wonder why the developers did not use the standard wm interface for this; but I inherrited the package and the decision is not documented; it is probably related to different applications that use this mechanism at our site)
and those file are processed by the application. In this particular case a webMethods service.
This service interrogates the file sytem for available files in a specified directory and then processes the files one by one. After processing the files are stored in a different place in the local file system.
Interrogation of the fiel system and move of the files is done by a java service.
Both functions could be done by usage of ftp functions to the local host (as mentioned in the next answer).
Hi Ychang,
I cannot agree more. Usage of Java can never be a sollution for inefficient code. Years ago I programmed a PDP11 (an old computer system of a company called DEC ) mainly in Fortran IV. Sometimes we had performance problems (eveything should fit in 64 Kb of memory ) We choose assembly language (Macro 11) you win some; but you loose some to escpecially in maintainability.
With todays giga machines it should never be neccessary to use non-native tools like java in a flow inviromment.
Of course I know that java is the engine in webMethods, but usage of java for programming functionality thould not be neccessary.
By the way: if you reconsider the usage of the one java service that you wrote: was there really no other way?
It does seem ironic that we’re talking about Java execution being faster than something else given the history of concern about the relative slowness of Java due to it being an interpretive run-time (JIT compilers and speedy CPUs have largely allayed those concerns). Java services are faster because FLOW services are more or less interpreted on the fly. Basically, an interpretive run-time is running on top of an interpretive run-time. Another speed advantage is gained by Java services if the JVM compiles them to native code.
Flow services are interpreted and at the bottom line converted to java code. So basically coding in Java will always be faster than coding in flow. My belief and my experience is coding in flow is suited for developers who do not have java background expertise. Any real java programmer will always code faster a service in java than in flow (that at the end result in java code). About readiness and debugging facilities, we do all of our coding, testing and debugging directly within eclipse IDE. Debugging is easier (and faster!) using eclipse using Developer IDE. Code is faster inline documented in Java code than using the Developer. You can badly code Java or code it the correct way, as you can “code” badly flow services or in the correct way. Handling exceptions in Java is way easier using Java than using TRY CATCH blocks in Flow (that are anyway handling underlying Java ServiceException).
In what I read in this thread I can buy no real arguments that would convince me to use Flow rather than Java, except if you cannot or do not know how to code Java efficiently.
I think I’m averaging one Java service per 3 projects.