Hi Rob - no tool as such… 
just Flow code must, at some level, be ultimately translated to Java bytecodes.
Regards,
Sonam
I see. I have no idea about the underlying code and what it does but I’d venture to say that FLOW is not translated to Java byte code explicitly. Rather, my guess is that FLOW steps are interpreted to run methods that are already in byte code. FLOW is pretty much just about execution path control, copying variables and comparing them from time to time. I wouldn’t be surprised if FLOW is explicitly converted to Java, just betting that it probably isn’t.
Hi,
To be more clear, the second approach (“do it in java”), is quite new, but i’ve seen successful installation of such system.
There are at least few reasons for that:
-
the installation was part of a bigger Integration solution, and all of its functions, had to be sean as WM services (some other systems invokes “java wm services”). This is main reason for not using JBoss, WLS, etc…
-
the system was written in java because of some FLOW features : ) ( You know this:“it’s not a bug it’s a feature:)”):
- lack of simple and clear scope handling (I know that there are walkarounds for that, but none of them is perfect)
- the situations when everything looks fine but something doesnt work (i mean, the situations when you have to remap a step, to make it work:/)
- it’s much easier to manage Java code (have You ever tried to merge a FLOW code in SVN or CVS??
possible to do , but not so funny:/) -
there is a lack of many refactoring functions like:
- Developer doesnt give you any warnings about that your code it’s not good, i.e. your are using not “declared” variable; there is a variable on exit which is not declared, etc…
- it’s not possible to rename one variable in many places, (i.e. You change the name of input var, then you have to change it manually in the flow)
- lack of many search capabilities, (you can not find a string in a FLOW, (not even saying about many services:( ) )- etc…
OK, so that’s it for now:)
Best regards,
Kasper
Hate to keep harping on this in all my posts, but…there are no such things as “WM services”. webMethods is a company, not a product. There are couple of wM products that provide “services” (Servicenet, Glue, IS) so “WM services” is ambiguous.
This would seem to be a poor reason to implement IS services in Java. Why should “other systems” care whether or not a service is written in Java? If those other systems are using the IS API then I can see why they would care that the services were hosted on IS (services could be implemented using FLOW or Java) but if they were doing HTTP posts then they shouldn’t care about that either.
Can you elaborate on the scoping issue? Is this a pipeline management concern?
I’ve never tried to merge package contents at all. That’s because it’s difficult and in my opinion, unnecessary. Having multiple people change a package at the same time is a bad idea. I also feel it’s a bad idea for multiple people to be changing a Java class at the same–people do it because they can but IMO, this is a sign of relatively poor design where the scope of the package/class is too wide. Merging code should be avoided IMO.
Decent things to have for sure. Taken in their entirety, this was enough for your project to avoid using FLOW altogether?
I have to say that the “all Java” approach gives me great concern. My first reaction is that you’re using the wrong platform and should switch to WS or WLS. Writing services primarily in Java in IS is a fundamental mistake IMO. There should be relatively little Java in an IS-based integration solution. To quote Dan Green from a post years ago: “Without sounding melodramatic, Java developers can significant increase a project’s time-to-market and ruin your ROI…It is my belief that a Java developer will never excel with the webMethods Platform until he can let go of the Java mentality.”
First of all, the project and solutions that I’ve described it’s not main! I have not done it, (all solutions that i’ve done were almost totally in FLOW ), but I had opportunity to see it, and I was positively surprised.
You are totaly right, that was a shortcut for me which describes a service that can be INVOKED (using FLOW INVOKE, or Service.doInvoke) within IS.
Other system and solutions hosted on IS doesnt care how services are implemented, they just have to be hosted:) on IS (this is client request).
Yes, exactly.
Merging code should be avoided, but in larger project it’s hardly possible to be done.
As I said at the beginning it’s not main project but I could talk to people that have done it. And there was many small or larger issue (some of them I’ve pointed out in previous post) that made them use Java.
If you would ask me about using java in IS few months ago, I would say the same, but right now I’m a little bit confused. And the idea of my posts was that I wonted to see if there are some others that did/saw something like that. And if yes, what made them do this (switch from FLOW to Java and some other IDE then Developer).
Best regards,
Kasper
Interesting thoughts and interesting discussion. Thanks for sharing your points. A stronger developer environment for FLOW, implementing many of the items you pointed out, would definitely be a welcome change!
I think IS more than make up for this in its ability to validate input and output pipelines, very easily. And “there is a variable on exit which is not declared” is not at all a problem. It’s desirable as a matter of fact from a code-reuse perspective.
Thank ychang for reply,
but can you elaborate more, how leaving not decalred variable on exit can impact reusability of code??
IMO, using not declared variable can have very bad impact on code readability and managment, and on code reusability as well, because only a developer that did a service which returns some unspecified variables can reuse it:)
I know that in some cases it can be desirable to use unspecified variables, but a programmer should be awere of it (he/she is doing this intentionally). That’s why I’m saying only about a WARNINGS that a WM Developer would generate, not a runtime rule .
Best regards,
Kasper
Can you share some of those cases? IMO, it is never “desirable” to use undeclared variables across services. A service should always, IMO, declare its inputs and outputs and should never leave work variables in the pipeline. TN used to be one of the worst offenders of this and still continues today to use undeclared variables, which can be very confusing especially for new developers.
Most of the cases that I know were related to, let say “design mistakes”, and were some kinds of bad patches that had to be done:( i.e: the interface, from some reasons, couldnt be changed but the service had to use some variable that were on pipe but not declared.
I REALLY TRY TO AVOID those situations.
There is another situation which I know some people are using, but I’m not sure should it be done this way. I’m talking about services which are created by Modeler and correspond to process steps. In this case adding “technical variables”(which doesnt have any influence upon process logic) to steps can black out the process flow. In this case(especially if the variables are always on pipe and are not used in conditions or transitions) using not specified variables when implementing those services can be excused.
Best regards,
Kasper
A service should always, IMO, declare its inputs and outputs and should
never leave work variables in the pipeline. TN used to be one of the worst
offenders of this and still continues today to use undeclared variables,
which can be very confusing especially for new developers.
Very true Rob.
Not that this contradicts what you just said, but in rare cases it is necessary to have ‘unknown’ variables in the pipeline - generally when the variable names aren’t known at design time:
One example: a generic protocol handler service receives a document. It then may pass the pipeline to an arbitrary custom handler service (depending on the doc & partner profile ). Only custom services “know about” the custom fields – those fields transparently “pass through” the generic service’s pipeline at runtime.
Another example: in a service to update an array of TN extended fields from a webpage, the cleanest approach was posting in an array of name value pairs that looked like this:
‘TN_field_ID_1’ = ‘TN_field_value_1’.
‘TN_field_ID_2’ = ‘TN_field_value_2’.
However, ‘TN_field_ID’ are internal TN GUIDs which obviously are not known at design time. So I could not access them in FLOW unless I wrote some Java service that stepped through the IData pipeline. I eventually worked around this by passing in duplicate variables that looked like:
name=‘TN_field_ID_1’
value= ‘TN_field_value_1’.
name=‘TN_field_ID_2’
value= ‘TN_field_value_2’.
First, let’s make one thing clear webMethods Integration Platform is based on Java. The Built-in services it provides are java classes. So, if you write a code to add two numbers in a flow service, you would need to invoke a flow step called addInts. This step is actually a java class.
The webMethods Integration Platform is evolved from the early days and its flow language can handle any task you through at it. The only thing is how you approch the problem. Of course if someone is a Java Developer then it is natural to feel more comfortable in writing Java services.
The notion “DON’T CODE IN JAVA” should be followed until there is no choice but to write java services. One of the reasons to not to write java services is that webMethods (organization) does’nt support custom java services. So if your organization prefer to use java in IS then it should be able to support it.
On variables in pipeline is that if you declare a variable in the actual pipeline and not the Input/Output, WM Developer will automatically drop it. Try it yourself just create a variable and dont initialize it.
And anyone who claims that java drops unused variables automatically is mistaken but the matter of the fact is that the garbage collector is responsible for that. But when you are talk about variables in the pipeline, they are a static representation of the variable. They are already destoyed when a service completes execution. But they are visible in the pipeline (a static black box) for debuging purposes.
Agreed. The key word in that phrase is rare.
Kasper,
I’m sorry, I think I totally misread the section regarding undeclared outputs. No, it definitely is not desirable. 
Somehow I doubt that having “migratability” in an EAI/B2B environment like wM is even desirable. If the environment is any good (like wM IS is), then obviously it provide services (API, foundation classes, what not) and supporting architecture (security, auditing, error-handling) that’s fairly unique to that environment.
If I were to write a service/code with an eye toward migrating later to say WebLogic, then that means I’d have to avoid using any component(s) specific to wM IS. Then all the reasons for using wM IS in the first place just disappeared – IS becomes just another Java AP server, and a fairly weak one at that.
I was talking about variables that are initialized, then regardless of that if variable is declared on output or not, it’s not dropped at the end of service.
IMO, you are mixing two things, memory management, and pipeline management, those are two separate things!.
Best regards,
Kasper
Kasper,
When you are working in wM Developer that is design time. And when the service is invoked on a IS that is Run-Time. In the run-time enviornment memory management including the data coming from the pipeline is done by a Java Garbage Collector. So in design time the variable you see are local to your pipeline. Pipeline management is closely tied to Memory management. Because what you put in the pipeline will be in the memory during run-time. And as I mentioned earlier the pipeline is static. So you have to populate un-populate(drop) it according to you requirement.
And the one most important reason for not droping variables automatically from the pipeline is that if you want to use the same value again in the flow. Or they are going to be used. As the pipeline is static the developer should know where to use a variable and where not to.
Hi Netcivilian,
unfortunately I cannot agree with you, because:
memory management - specifies how memory is allocated and when and by who is cleared.
The most common ways to do that are: explicit memory management (the developer is responsible for allocating and freeing memory like in : c++, c) and
implicit memory management, the programmer doesnt free memory, but there is something like Garbage Collector which frees it when it’s not used anymore like in Java, C#
pipeline management - specifies who have the access to variable, who and when can modifies it, and when the variable can be marked as unused.
These are the reason why the relation between those 2 things is very week. The pipeline management can be changed without the impact upon memory management and vice versa.
Best regards,
Kasper
For sure, it is not converted to java class. You can try to investigate a stack trace attached to an exception which is thrown from a Flow service - there are no classes there which can indicate that Flow had been precompiled.
Probably one of reasons why this is not precompiled is to make a particular flow service execution more secure and manageable.
Hello,
I like the idea of the translator. I would love to see it as part of a larger toolset to do on the fly java code generation. You could have a pane for the FLOW you were developing and next to it was another pane that showed a read-only view of the java that would generated. This would allow your FLOW developers to quickly come up with solutions and then do a copy and paste to a dedicated java service wrapper or have a “Save As Java Service” option.
Also, it would be nice to have interwoven functionality of java put back into the FLOW line of view. Things like other loop constructs are all that remain in the FLOW that I miss not working with. That is the only reason for some of my java services. Loop and Repeat don’t make the grade in that regard without enough complexity that can have you crying for it to stop.
I guess that the translator is not my main love as it would only pull me back to the dark side. But it could be helping if had things that can work in reverse to reseed the FLOW.
So a FLOW-JAVA-FLOW translator would be really great. It that scenario I could have:
Integer one = new Integer(1);
Integer two = new Integer(2);
Integer three = one.add(two);
IDataCursor idc = pipeline.getCursor();
idc.first("three");
idc.setValue(three);
idc.destroy();Would translate into a simple service with two assignments in a map and one invoke of addInts. That is a possibility. That could also lead to having a “Save as Flow” option just like mentioned above going in the other direction. This will probably be forgotten before next week, but I just wanted to share for a moment. Good day.
Yemi Bedu