Integration Server and Java

[reamon]

This has been debated many times on the forums. Please use the search to find those threads.

My opinion: 95+% of your services should be FLOW; use Java for specific and relatively narrowly focused needs. Some folks may state that you should use FLOW for "simple" translation and use Java for "complex" translation. I strongly disagree.

There may also be some that will argue for using Java because it is inherently more efficient at run-time. While the efficiency notion is accurate, that is but one of many characteristics that you'll want to consider--debugging, modifiability, maintainability, etc. are other aspects to consider. Run-time efficiency is best approached through profiling and optimizing areas that will provide the most positive impact. For many integrations, run-time efficiency is immaterial.

[ioan]

I am very familiar with Java and WebMethods and I find that it is easy to use either option. For IS Java Service, I wrote some ant scripts that automatically synchronizes Eclipse projects with WebMethods jars directory and java sources for java flows (fragging/compiling). Usually I use Developer to create the IS java service; Eclipse is instructed to automatically pick up new java files (using a Linked Source Directory) and from there on Eclipse is used to write the rest of code, of course you have to pay attention to not screw the formatting. Also, I could debug using Remote Debugging starting the flow from Developer (IS has to be started with some extra flags) and then pass the control to Eclipse Debugger where you can go step by step.
One way to design Java Services, is to write Java modules that are not dependent on Wm jars and use Java Services just to wrap those modules. This way you can test w/o depending on WebMethods using well defined tools like JUnit/JMock/DynaMock etc. Also you can keep under SCM (Source Control Management) your java code.

Is IS Java Service more error prone than IS Flow Service? No if you are doing the right things (aka proper Unit Testing); it may depend if you are more familiar with one or other.
One issue I have with Flow Services, is hard to merge two different versions and SCM is a nightmare specially when you have many different versions in Production and you have to support all of them, branches etc.

Saying this, I rarely choose to use Java Services for Production packages; mostly for design time to generate automatically IS Doc Type, Flow Services for mappings etc. If this gives me troubles, all I have to do is change the “generator” to create Java Services instead of Flow Services but I never had yet this problem.

[borizm]

Originally Posted by ioan

I am very familiar with Java and WebMethods and I find that it is easy to use either option. For IS Java Service, I wrote some ant scripts that automatically synchronizes Eclipse projects with WebMethods jars directory and java sources for java flows (fragging/compiling).

Yes ! I too.

Originally Posted by ioan

One way to design Java Services, is to write Java modules that are not dependent on Wm jars and use Java Services just to wrap those modules. This way you can test w/o depending on WebMethods using well defined tools like JUnit/JMock/DynaMock etc. Also you can keep under SCM (Source Control Management) your java code.

Yes ! Yes ! We also doing this in another project, and we have 100% WM independent services with our own Spring based flow and dynamic approach (Map, List insted of generated POJO), and we can run any test scenario directly orchestrating selected services without touching WM IS. And our services are agent-like - we can deploy them into ordinary web container or even applet client.

Originally Posted by ioan

Is IS Java Service more error prone than IS Flow Service? No if you are doing the right things (aka proper Unit Testing); it may depend if you are more familiar with one or other.
One issue I have with Flow Services, is hard to merge two different versions and SCM is a nightmare specially when you have many different versions in Production and you have to support all of them, branches etc.

Yes ! Yes ! Yes ! I'm in middle of "optimization" only few from over 9000 flow services on the platform. It's nightmare ! It's very hart to find something in flow (f.e.: scope and places of variables utilization), to analyse anything (I must use "HTML view", and switching between windows - I'm talking about 3-10 MB in size flow.xml's !).

Originally Posted by ioan

Saying this, I rarely choose to use Java Services for Production packages; mostly for design time to generate automatically IS Doc Type, Flow Services for mappings etc. If this gives me troubles, all I have to do is change the “generator” to create Java Services instead of Flow Services but I never had yet this problem.

My own generator getting dust, but it will be back

[ukslim]

Now it could be that our project is particularly unsuited to Flow, or it could be that nobody in our team is sufficently skilled in Flow.

But my observation is that Flow services to do fairly simple tasks end up being very complex and difficult to follow. You can completely change the behaviour of a flow by unchecking a box deep in the UI (for instance, 'substitute variables'). An undeclared output can knock you for six. In two years we've developed a number of packages where I'd rather rewrite them from scratch than try to understand them.

I don't believe for a second that a non-technical businessman could write Flow without falling into all kinds of pitfalls.

For this reason, my view is that if it can't be done in 10 steps of Flow, break out Java.

Incidentally, the best way to do this is to write your logic in a Java IDE. Unit test it within the IDE. Build a Jar file and put that in your WM Package. The Java services written in Developer can then be very brief - corral the input IData, create an object, call its methods, corral the output IData. Finish.

It's OK, and often quite effective, to include server.jar in your Java project, and write methods that directly manipulate IData.

[borizm]

Originally Posted by ukslim

Now it could be that our project is particularly unsuited to Flow, or it could be that nobody in our team is sufficently skilled in Flow.

More, almost nobody agile in Flow like to write in Flow. But our Clients have requirements to write in Flow, and we do it.

Originally Posted by ukslim

But my observation is that Flow services to do fairly simple tasks end up being very complex and difficult to follow.

... and You can't simply use the best approaches and well known (to good Java developers) patterns, but You must follow primitive logic of Flows. But simple Flow XML gramatic can be better than Java gramatic for further purposes, like documentation generation, transformation to whatever, etc.

Originally Posted by ukslim

You can completely change the behavior of a flow by unchecking a box deep in the UI (for instance, 'substitute variables'). An undeclared output can knock you for six.

It also benefit. You can correct error in a split seconds ... without compiling, deployment. MAP step is strongest point of Flow.

Originally Posted by ukslim

In two years we've developed a number of packages where I'd rather rewrite them from scratch than try to understand them.

Our Client have 1.4 GB (!!!!) of Flows source code in six layers, because his cooperators haven't enough time or patient to look into well written existing reusable services and modify it slightly. They prefer to write additional and makes it harder to maintain.

Originally Posted by ukslim

I don't believe for a second that a non-technical businessman could write Flow without falling into all kinds of pitfalls.

SEQUEL/SQL was primary designed for non-technical stuff. Flow follows this idea (from markering perspective for sure). For simple task it's simple. Once written works fine, little changes are ok, but do not try to refactorize it - it's better to enforce some patterns, layout of services, layers, common document model first.

Originally Posted by ukslim

For this reason, my view is that if it can't be done in 10 steps of Flow, break out Java.

Flow standardizing many things by itself, but also makes it complicated-looking. Java is too powerful, feature-full - without some constraints/checkstyler, it's not good language for a big project.

Originally Posted by ukslim

Incidentally, the best way to do this is to write your logic in a Java IDE. Unit test it within the IDE. Build a Jar file and put that in your WM Package. The Java services written in Developer can then be very brief - corral the input IData, create an object, call its methods, corral the output IData.

Yes, but it's better to take particular service signature (name + io/out documents) as a pattern to auto-generating strong typed Java service skeleton class with not-IData signature with in/out document wrapper classes. Using this approach, no IData manipulation is needed, only set/get/add/remove on document wrappers, and simple implementation of service skeleton, and there is no need of WI IS for testing - code like this is fully WM independent !!!!

Originally Posted by ukslim

It's OK, and often quite effective, to include server.jar in your Java project, and write methods that directly manipulate IData.

[/quote]
Yes, we are using Maven2, therefore we simply add dependency on server.jar in pom.xml (we have all WM jars in our Maven2 private repository).

[holden]

Originally Posted by borizm

Yes ! Yes ! We also doing this in another project, and we have 100% WM independent services with our own Spring based flow and dynamic approach (Map, List insted of generated POJO), and we can run any test scenario directly orchestrating selected services without touching WM IS. And our services are agent-like - we can deploy them into ordinary web container or even applet client.

That's interesting approach but why use webMethods in such architecture? Can you please tell more about advantages of such marriage?

Regards.

[ukslim]

Originally Posted by ioan

One way to design Java Services, is to write Java modules that are not dependent on Wm jars and use Java Services just to wrap those modules. This way you can test w/o depending on WebMethods using well defined tools like JUnit/JMock/DynaMock etc. Also you can keep under SCM (Source Control Management) your java code.

I think there's a lot of mileage in including WM's client.jar in your project, and writing Java that understands IData. That way you can exercise your IData manipulation routines within jUnit (etc.) tests.

I tend to write classes with individual getters and setters, and alongside these a setFromIData() and a toIData().

[chandrasoumyajit]

can you please provide me "wmSamples" package,l that's required for file-writing.

[ukslim]

Not sure what this request is doing in this thread.

But wm-samples can be found on Advantage.

[sonam]

Some inputs:

Now it could be that our project is particularly unsuited to Flow, or it could be that nobody in our team is sufficently skilled in Flow.

As for "sufficiently skilled in Flow", the opposite is meant to be true. Its meant to be easier to learn and use Flow than to possess strong Eclipse, Spring, and Ant skills, etc. If you have strong Java skills but feel less comfortable in Flow, perhaps its a matter of spending a little more time getting acquainted with Flow programming.

But my observation is that Flow services to do fairly simple tasks end up being very complex and difficult to follow. You can completely change the behaviour of a flow by unchecking a box deep in the UI (for instance, 'substitute variables').

The same issue of 'small changes breaking a program' exists for other programming languages. The only way to combat this is having an automated regression test framework. I prefer manually unit testing Flow services, with the regression framework testing higher-level services (what folks call system or integration testing).

I don't believe for a second that a non-technical businessman could write Flow without falling into all kinds of pitfalls.

Absolutely - you need to be a programmer to be a Flow programmer. However, Flow programming's primary benefit is ease of coding and ease of debugging -- delivered by these mechanisms:

1. Coding: Flow programs display stack variable structures at both **design** time and run-time. In contrast, the Java IDE debuggers graphically display data structures (and their values) only at run time .

2. Debugging -- The webMethods save/restorePipeline services are pretty powerful tools. The Java equivalent would be a static method that serialized all current stack variables into a file. This would not too difficult to write. Some years ago, I recall reading about a test framework (a Java one I think). When invoked by a production exception handler, a method call would serialize the stack variables into a file, and generate a unit testcase (with the serialized stack attached) to replicate the bug on a QA environment.

To be sure, there are disadvantages to Flow - lack of diff/merge tools, lackluster refactoring support. Also, webMethods have not focused on adding features to their development environment as they should have. (Imagine multi-point/multi-touch support for Flow programming... it'd halve the time it took to map major data structures).