Integration Server and Java

Yes - this will become an endless and not very fruitful discussion. Probably i was somewhat hasty to open this can of worms again - in one of my first posts.

What i meant to say was the following: Flow.xml is read and parsed. Then some instances of readymade classes are instantiated and connected. The resulting object tree will then run (meaning the assembly of pre-generated fragments of bytecode) and do whatever flow.xml said (past tense!).

There is no interpreter going over the DOM for flow.xml every time a service is executed, but there is also no specific Java or Byte code generated for a flow service.

I once thought about transforming flow.xml to java code, compile and call this instead. after some thinking, I came to the conclusion, that the advantage will be neglectable. The generated java code will do exactly what the assemblage does, it might use some fewer classes though.

The real performance gain comes in, if a seasoned java programmer writes service code, that does not depend on the pipeline model of storing data.

But flow is pretty fast and in most situations it is fast enough. And you can always throw money (hardware) at the problem.

I dont want to sound rude, but lets finish the discussion here, as i think all has been said about the matter…

Thomas

I think we are in complete agreement as to what happens (with possible quibbles over the details of the object tree and an “interpreter”). I’ll take the blame for creating the minor debate with my original brief and not-very-helpful answer of a simple “No.” :slight_smile:

I agree too with “flow is pretty fast and in most situations it is fast enough”.