Differences between EAI and B2B part 3 (epilogue)

, , ,
1

(Sidenote: Active Versus webMethods)
The good news is that while the main solution structure for EAI is as elusive today as it was back when people started building ETL systems, the webMethods pipeline structures are extremely time efficient to construct and use. For example, here are three different techniques to create ten thousand simple fields for a document type (and an old active BrokerEvent). I used ten thousand as an arbitrarily large number that is way beyond good taste. I built a java class to create the BrokerEvent, a java service in wM developer to do the same thing with a document type, and a flow service that again builds a document type. The timing results were then reported back to me using an appropriate mechanism.

Here is the java class code for the old BrokerEvent:

import COM.activesw.API.client.BrokerEvent;

public class BrokerEventCreateTime extends Object {

public static void main(String[] arguments) {

try {
long startTime = (new java.util.Date()).getTime();
BrokerEvent event = new BrokerEvent(null,“sw::simpleTimingTest”);
for (int index = 0; index < 10000;index++) {
event.setStringField(“values” + index,“” + index);
}
long endTime = (new java.util.Date()).getTime();
System.out.println(“total time to process was " + (endTime - startTime) + " milliseconds”);

} catch (Exception exception) {
exception.printStackTrace();
}

}

}

And the wM developer java service code:

IDataCursor cursor = pipeline.getCursor();

long startTime = (new java.util.Date()).getTime();
for (int index = 0; index < 10000;index++) {
cursor.insertAfter(“values” + index,“” + index);
}
long endTime = (new java.util.Date()).getTime();

cursor.insertAfter("total time to process was “, “” + (endTime - startTime) + " milliseconds”);
cursor.destroy();

And the flow service
The flow service was a two step flow with a repeat 10000 on success, and an append $retries to value[].

The timing results:
java class for BrokerEvent: 6 seconds
flow service: 2 seconds
java service: 30 milliseconds

Regardless of the tractability of the solution (which doesn’t change no matter what EAI or B2B tool you are using), webMethods does have some advantages over the old ActiveWorks tools. Of course, a real discussion of the advantages and disadvantages of each, while fun, would be well beyond the scope of this thread.

Enough! This post obviously isn’t the final word on this subject, in fact, it is a starting point, and seven pages is more than enough to start. Please, feel free to disagree with me, replies and retorts are always welcome: that is how we all learn!

-greg

2

I think its unwise to compare with such a simple use case!! Working with a large organization in the very start of my career where everything needed to be accounted for, I believe, its imprudent to compare run-times between flow/java/brokerevent; There are many other factors to consider few among those being maintainability costs,availability of resources etc.

The results can certainly be tweaked in favor of any of these depending on the use case chosen!!

As you said, this is beyond the scope of this thread/discussion, but no conclusions should be drawn based on the result set quoted.

3

My only conclusion is that some things are more efficient. In this case, document construction vis a vis performance efficiency. Should we do an overall effectiveness comparison between the old and new? I dunno, it isn’t like anyone is still using the old stuff are they? I keep flirting with the idea, but i am not sure i want to invest the effort into comparing a current product against an “obsolete” one…

4

Greg: Thanks for starting these threads. I’m sure we’ll all get something out of them.

For the sample comparison, the Java service and the FLOW service don’t create a BrokerEvent at all so I wonder if the comparison is valid. The Java code using the Broker API can publish the created event directly. The Java and FLOW services cannot–the IS document they create will need to be translated first to a BrokerEvent (under the covers) before they can be published to a Broker. So I’m not sure the conclusion is valid since the 3 samples don’t all come to the same point in processing–e.g. create a ready to publish BrokerEvent.

5

Great point! The operating unit in IS is the document, whereas in the old active world it was the BrokerEvent. That is why i chose building them as relatively comparable tasks. In IS, you normally wouldn’t publish the document, you would just use it in flows - i wasn’t thinking about comparing old publish performance versus new, only construction of the working document/event.

In fact, when i built the sample, it was to show how much more efficient the event creation was than the document creation. I was stunned to see that IS was faster. What i had failed to realize was that the relative slowness of IS is primarily due to the flow interpreter, not the underlying IData object - but even my flow based document construction was faster than the old BrokerEvent. Taught me a lesson about presuming the old stuff was better (you know, ahhh the good old days…)!

-greg