Hi,

Like to check concerning EI.

It seems for every step in the integration component in EI, 2 classes, one input class (e.g. customStep$in) and one output class (e.g. customStep$out), are generated.

And when passing data between 2 steps, even if the full data set from step 1 is passed to step 2, the $in in Step 2 is instantiated and populated with the $out from Step 1. A more efficient way would be to simply pass the $out from Step 1 as a ref to $in of Step 2.

This instantiating of objects is very expensive in terms of CPU time and is a likely reason why our adapters are running so slowly.

Is there a reason why EI is doing this and is webMethods looking into changing this?

regards
Kenny

Yes, EI goes a bit overboard with objects. Reminds me of Borland OWL from way back when…

Anyway, you’ll be happy to know that EI is going away–at least from an efficiency standpoint you’ll be happy. You may not be happy about your integrations needing to be migrated/re-worked to take advantage of 6.0 stuff.

is WM6 using WM Developer really much better in terms of code generation?

Kenny,

webMethods will not be changing how the EI operates under the covers. The EI script and its architecture do not live on in webMethods 6.0 so I doubt seriously that webMethods will spend any effort to rearchitect EI.

Yes, it is not the most efficient implementation and is not designed to be extra fast. You do have the ability to multi-thread in some adapters and also parallel process by using multiple adapter instances so you can scale if needed.

As for webMethods 6.0 you won’t be seeing huge increases in efficiency and speed since the EI script is being changed to IS Flow which is not the speediest architecture either.

Steve

Steve Rdzak’s description of what’s happening with EI is much better than mine.

In Developer, there is no code generation. Services are written using FLOW which is interpreted at run-time. Not sure of the specifics of what goes on under the hood but there definitely is no visible Java code like there is with EI.

doesn’t sound good…

Shouldn’t webMethods provide some write-up on how to model flows in EI or developer so that we can get the most optimised codes in order to get the best performace possible

Typically optimization isn’t an issue, unless the volume being processed is large. In this case, the approach to optimization is the same as when coding in virtually any other language: 1) develop the solution the “right” way (maintainable, understandable, etc.); 2) identify bottlenecks through benchmarking; 3) rewrite the bottlenecks to improve performance.

Trying to write FLOW services with optimal performance up front is probably a wasted effort.

webMethods main benefits are the quickness and ease with which you can design, develop and deploy integration solutions not a highly optimised code gen tool.

Of course there are “Best Practices” when designing and coding your integrations that can help you maximize your performance with the product.

You should if you can utilize the knowledge of Professional Services who can help you understand how to maximize performance with the product set.

Also, I believe there are documents in the GEAR methodolgy package which is available on the webMethods Advantage web site which do contain technical white papers on these types of issues.

Steve

Thanks guys!!!