Integration Server and Java

[reamon]

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:

1. Don't write it in Java.
2. Don't write it in Java.
3. 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.

[mcarlson]

Rob,

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!

Mark

[reamon]

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! :-)

[andrejan]

Hi reamon,

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.

[reamon]

Originally Posted by andrejan

I think in general you should avoid java as much as possible, there are only three reasons to use java:
- Performance reasons
...

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.

[Gert Versteeg]

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.
1) IS could not find a java compiler -> I installed a java compiler;
2) then it started to complain about errors in a module I never heard about.
3) 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.

[mcarlson]

Gert,

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.

Mark

[ramchalluri]

As Mark pointed out your questions are toothing issue and can be resolved very easly. Let us know how you go with your project.

[arydewo]

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.

Regards,
arydewo/HP

[Gert Versteeg]

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