Hello all,
I have been tinkering with creating a translator/compiler to convert IS flows (XML) to Java code. Does anyone have any interest in this and if so, I am happy to share the tool with you, once it is complete.
If its crazy, let me know, but I think this could useful in various situations and I know webMethods will never build it.
You feedback welcome,
Serge
Serge,
Given the oft-expressed opinion here of “don’t write it in java”, perhaps you could share some of your “various situations” in which generating java from Flow would be valuable?
Mark
Hi,
the first issue about flow is performance, I know many cases, where first we’ve developed a flow service, and than we had to rewrite it to java, because of performance. The java service was sometimes 15 to 20 times faster, and because most of the services that we had rewrite were, let say a bottle neck of our solution, the whole system was much faster.
And for sure that would be good to have a tool, that would automatically create java service from flow.
Unfortunetly, when you use java, you have to use some externall tool (like eclipse) to develop and debug your services and this is paintfull, because using 2 separate IDE for the same project is not easy. That would be good to hava an option to develop your own plugins for Developer, the plugins that I’m missing are:
CVS/SVN integration,
Java ADVANCED:) editor and debugger,
and some tools for refactoring of flow services,
Kasper
Kasper has mentioned one example, and I also agree with Mark. The intent for translating from flow to Java I think is quite narrow. I would only consider if there is legacy code which should not have been written in flow, and there was low skill levels in webMethods or if the entire system was being migrated off webMethods.
The practical difficulties of translating are considerable, depending on the how far the ‘porting’ has to go. A simple translator which gets it mostly right would not be impossible, but migrating a lot of logic (including adaptor logic, use of IS specific functionality) would be challenging.
IMO, it is.
The CVS integration might be nice, though many places get along fine without it–indeed several places don’t use a CVS at all.
I’m conflicted on the Java editor/debugger. On the one hand, it would be nice to have a better editor in Developer. And it would be nice to be able to step through Java services from time to time.
On the other hand, if I want to do Java development, I’ll use a Java development environment. IS is not a Java app server. It’s not a WebSphere or a WebLogic or a JBoss or whatever. IMO, there should not be any significant Java development when creating a solution for IS. The strength of IS is how quickly integration solutions can be built using FLOW. If one wants to use predominantly Java to create integration solutions, then IS is not the tool to use.
I argree with you, but if it’s needed to develop something in java because of performance, then lack of one IDE to develop and debug flow and java services is getting inconvenient.
Dont you think, that a real strength of WM is large number of adapters to diff. systems, and SOA?? not a FLOW by it self??. Maybe I’m wrong, but the most important thing is to design good services, with very well defined inputs and outputs, so that they can be reuse when needed. Than it’s not so important how those services are implemented. FLOW is very good language to do an orchestration of services and for mapping purposes, but if you need to develop a service with more advanced logic than FLOW is not so good any more.
Best regards,
Kasper
Kasper,
I agree with Rob,using Flow is the way to go in IS for faster development/debugging/logical diagam view/maintainence etc…
Ofcourse Javaservice is widely used for advanced logic,utilities (when no built-in flow functions available),So Java/Flow are sticky both have equal importance and if possible Developer plugin’s feature with (Eclipse/Java) most of folks waiting for it.
HTH,
RMG
This is my point of view, as well.
But I dont think that WM will provide anything like that in future, because of company policy:) The FLOW can work only on IS:) but Java services can work on any server:)…and from WM point of view, this is very important reason why they won’t do anything like advanced Java plugin.
BTW, can you list features that, in your opinion, make FLOW much better than Java??
Best regards,
Kasper
Some features are robust UI,debugging(step/trace) makes easier,visual diagram view,flow html view(sample documentation purpose),breakpoints,mapping maintainence
(support,new developers) etc…
Also ultimately JS helps a lot in creating misc utilities,advance errorhandling etc…
HTH,
RMG
As I mentioned, being able to step through a Java service from time to time would be useful. But the amount of Java to debug is usually minimal and relatively easy to deal with.
The number of adapters certainly contributes to the strength of IS. OnRamps, modules, etc. are all very good things to have. Does one choose IS over other solutions because of the adapters? Not anymore. Not often anyway. All the main integration products have plentiful adapters.
Good design is a good thing regardless of the underlying technology. IMO, services with explicitly declared inputs and outputs are a must whether an IS service is written in FLOW or Java. FLOW is easier to work with in almost all cases.
Define “advanced logic.” I truly have not come across an integration case where the logic could not be implemented using FLOW. Yes, sometimes I use Java, for things like containers, linked lists, etc. but those are almost always simply wrappers for core Java objects. And then I use those services within FLOW services that do the logic work.
Don’t get me wrong. Java code has a place in IS. But IMO, it shouldn’t be front and center.
I think save/restorePipeline is the best things about Flow. If you think about it, it’s ultra-cool being able to save and restore the state of your method call between any 2 arbitrary statements.
It’s so useful, I’m surprised mainstream IDEs / languages don’t offer similar functionality in an easy to use manner.
webMethods IS already implements a Flow to Java convertor… so maybe your translator lets them do it faster.
Or…
It would be ultra cool if your translated code could run independent of webMethods – with input/output signatures auto-converted to SOAP WSDLs, calls to pub.* services either replaced with native calls (eg: pub.math:addInts replaced with “+” ) or automatically calling more complex webMethods Fabric services (eg: pub.edi:*) via SOAP. This would let a company use webMethods programmers and the simplicity and debugging power of webMethods developer to implement a unified service development environment.
Rmg, but in my opinion, those are not features of FLOW, but WM Developer.
Best regards,
Kasper
I think that Sonam got to the point. When building solutions using FLOW, unfortunattly You have to stick with Wm IS, you (or company) doesnt have any possibility of switching to some other environment. That is why, a converter to more open language (i.e. Java) can be sometimes usefull.
To be honest, I dont recall a situation that one of my client would like to switch their existing WM solutions to some other platform, but maybe because there is no possibility.
This is interesting. If Java is really 15-20 times faster, then I think a better solution would be to compile your flow service right into a class file, but keep the source in flow for debugging/enhancements/documentation. I know that we don’t currently have the tools for that. It would require a behind the scenes process that would translate the flow to java, then invoke the java compiler. This is similar to some of the old CASE/code generation tools that were so popular in the 80’s and 90’s.
Where is this tool? Can you elaborate?
I think that Sonam thought about that flow is implemented in java. But it’s not the same as flow to java translation.
Best regards,
Kasper
Thanks for discussion Reamon,
From my expierience, there are 2 ways that you can develop services and solutions with WM:
or
either
2) you “DO IT IN JAVA” - then you write everythink in Java, in this case a programmer DO NOT USE Wm Developer to develop services, but a IDE like Eclipse is used.
The worst case is when one tries to mix those two. Then it’s very hard to maintance/test or debugg the code.
Best regards,
Kasper
This is indeed an interesting discussion. I’m revisiting many long-standing notions I’ve held about “proper” IS development.
Interesting. I’ve never come across an installation that took this approach. Why not use an environment that would more directly support this approach–e.g. WebSphere or WLS? If using IS, wouldn’t one need to do at least some work in Developer?