Is anyone using just IS (6.x) without BROKER for medium to large numbers of real-time JDBC connection transactions to Oracle via some sort of web-based application?
webMethods has not been able to provide any customer references which do similar business, and I am turning to the wider community for support.
Basically, today, our company uses webMethods IS and ES (4.6 / 5.01 + broker) to send realtime web transactions from a Broadvision engine to backend internal Oracle databases. We are exploring the option of using 6.1 + JDBC (no broker) to do the same thing, and have transactions simly run as a thread in the JVM (no broker).
Is anyone doing this or something similar?
David Yates
Xerox Corporation
Rochester New York (USA)
(585) 423-6399 Work David.Yates@usa.xerox.com
Actually the broker and the whole concept of queuing document requests is what we are trying to get away from, and instead, use a running JVM thread in IS (since the adapter is local anyway - JDBC). And for GD transactions, IS has a good mechanism for that using publish local using local triggers and a local document store.
Broker has been difficult in our environment, and seems like a series of extra steps which are not really needed when all we are trying to do is execute stored procedures in a backend oracle system. These transactions, by the way, are all Volatile.
“Actually the broker and the whole concept of queuing document requests is what we are trying to get away from…”
“…and seems like a series of extra steps which are not really needed when all we are trying to do is execute stored procedures in a backend oracle system.”
This begs the question–why not just hit the DB from BV directly? Using IS is a set of extra steps too. (Not trying to be a smart aleck, but interested in what’s driving the integration philosophy–what drove the solution to use pub/sub in the first place?)
But to your original question, can IS be used without broker? Yup. The only projects I’ve worked on that used both was at companies that already had broker and added IS later. Projects I’ve worked on that are new to wM have only used IS, not broker.
Will performance be similar to what you’ve seen with broker? Have to make a couple of assumptions about your current environment:
BV on box A talks to IS on box B
IS talks to ES on box C via B2B Package
ES talks to wM’s Oracle adapter which is also on box C
If you’re eliminating box C and consolidating activity on box B, you may see a decrease in performance as the different threads/processes compete for box B memory/CPU.
Good question, not sure the specific reasons for why Broker and IS in the first place here at our group.
The interesting thing is BV is a ‘single-threaded’ engine, and we aonly have a limited number of BV app engines to generate new load traffic (~70 total). And in addition, the backend oracle system we are connecting to has a limited number of connections with which to send simultaneous transactions (~50 in our case). All of this, coupled with the fact that these high volume transactions to oracle are all ‘volatile’, why would we ever use broker? Why not just scale by adding IS engines and cut the BV app server load and balance that load across multiple independent IS engines instead of cluster or IS+broker.
Does anyone have a customer reference which is using IS only (+ JDBC) to oracle under medium to heavy loads?
So far, no-one has claimed they are doing this and unless I can find one customer doing this, Broker in our oracle volatile world seems to be the way management will go.
I have seen several implementations of IS and JDBC adapter and no broker or simply broker not involved in the process even though it is installed.
Although none of those use BroadVision. For one customer reference, Internal Project at BearinPoint that is doing DB to DB trasport and transformation using this method. There is broker also but not all processes use the broker. Basic pattern Applications places data on Oracle table. JDBC driver pics up the data, publishes locally to IS then IS transforms data and inserts to another DB table in another database set of tables as one pattern. This project was actually preseneted at 2004 IntegrationWorld on one of the sessions.
Cheers.