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.
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.
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.
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 !).
My own generator getting dust, but it will be back
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.
More, almost nobody agile in Flow like to write in Flow. But our Clients have requirements to write in Flow, and we do it.
… 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.
It also benefit. You can correct error in a split seconds … without compiling, deployment. MAP step is strongest point of Flow.
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.
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.
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.
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 !!!
[/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).
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().
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.
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).
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:
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 .
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).
The rule for us is we never use Java for data/protocol mapping and transformation ever.
However, we do use Java for business data validation, i.e. when we get data from external providers/partners and there are known industry standard rules on some data validation. These business rules are never coded in Flow because we cannot reuse this code easily in other internal systems.
So we always code these in Java, and we can easily reuse it in other internal systems.
Now, the unique thing for us is, we never write ANY Java services in Developer or even in eclipse. We merely annotate our Java business logic and our build will generate wrapper Java services with all the necessary jcode comments. Then we run another ant target to deploy and invoke the necessary compilation of the jcode tagged Java wrapper services to deploy to IS.
The downside here is, we have to enforce a standard way inputs and outputs are handled. But really its a plus for us because it helps us enforce a standard way Java services are deployed in IS.
We’re also gonna use an IS to host web services, by reusing some of our existing/legacy java business code and annotating them to generate Java Services to be deployed to an IS and wrapping a Flow layer on top and exposing them as HTTP + XML services. Now we just need IS to be able to expose RESTful URLs…
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."
Any flow services that are created will generate a flow.xml file internally…
The same rule is applied to custome java services…?
If yes, does this process of having a flow.xml slows down the execution…
No. Java service source is saved to a fragment file. The Java source for all Java services in a particular folder are merged together to a single source file which is then compiled to byte code.
It’s been my experience that speed of execution is rarely an issue. And it is rarely due to something being coded in FLOW vs. Java. Indeed, IME it’s never been the case that something is too slow because a service is coded in FLOW. The bottleneck is usually communication with other systems.
Hello people,
I am working on a scenario, where Inbound and Outbound operations are carried. In Inbound, I am taking data from file poller, to flat fiile schema, then converting to canonical and then saving to DB.
Outbound is the reverse process for it, but instead of giving a debugLog, I want to print the string in a file, which I can use it as acknowledgement given to customer, if taken an e.g. of order request and providing an acknowledgement.
My whole scenario is almost complete, but facing problem in writing to a file, so as to give acknowledgement.Please help me.
“If flow services are not converted to java classes…”
The implication with “converted” is that FLOW is somehow changed/compiled into Java byte code. It is not.
Instead, Java byte code is interpreting FLOW and performing the work needed. So yes, ultimately FLOW steps end up being run by Java byte code (which itself is interpreted and run by native machine instructions, or compiled to native machine code) but it isn’t quite accurate to say FLOW is “converted” to Java. It is interpreted by Java.
Use for utility services or API glue, don’t use for transformation/invoking other services etc.
You can’t get away with just using flow usually, need some utility services to make life easier (best tool for the job really… If flow code is blowing out or ugly and can be done in java: then do it)…
As for performance: well, if you need to append to a string in a loop you will need to write some java util services to create a StringBuffer and to append to it and then to toSting() it. If you don’t you’ll fall into the trap java developers do with String concat… So using java in that instance is far better performing that using flow (which there’s no effective way to avoid the problem).
The problem is when people start writing massive amounts of mapping etc in java services…
I think this is wrong. The answer should be a careful YES. As flow.xml is read, a bunch of java classes gets instantiated and woven together, that implement the functionality requested by flow.xml. They pass around control and do all the mapping etc accordingly. It’s not always reread and reinterpreted.
We’re simply debating the meaning of “converted.” Yes, flow.xml steps causes Java objects to be instantiated and run. But those classes already exist in the .jar files. FLOW services do not create new classes nor byte code (as far as I can tell, since I have no insight into the implementation).
As I mentioned earlier in the thread, “converted” seems to imply some sort of compilation to create new byte code somewhere. Maybe it does but I’ve never seen evidence of such.
I would welcome any information that shows that FLOW steps is turned into new byte code, rather than simply interpreted and executed by a “FLOW execution engine” written in Java.
p: