we wish to use broker as our load balance gatekeeper . Used this kind of interface using JMS and TIB RV environment

Question is lets say 5 IS clients sub to a particular document how to ensure only one picks the document …ie when IS1…n picks the document then it should be removed from the broker

or is there anything like lock , for eg: which means untill IS1 finished processing the document is locked and removed and for some reason IS1 had errors lock should be removed and other ISn can pick it up and process

any idea …also is this a good approach

Thx in advance

Bob

Any Takers on this …

Bob

I not sure about your design yet, please clarify a bit. Are you saying you would like to interface Tibco via JMS to a webMethods broker which in turn is connected to 5 Integration Servers acting in a clustered environment? If so I’m not sure about that design. Different JMS Providers do not natively talk to each other(you would need a bridge). Plus your broker is a single point of failure and work if it is indeed the entry point.

Another way might be to use the webMethods jms adapter and have your IS servers in a cluster. The adapter can pull in the messages into a load balanced environment all connected still to the single broker if needed.

No just webMethods Broker and 5 IS clients . All i want to know how we do load balance .

Gatekeeper IS publishes the document to broker which in turn should be picked by 5 Prd IS clients …at a time only one client should process the document .

hope now its clear

thx

Bob

Don’t think that is going to work. You can’t load balancing the broker at all and your can’t load balance clients residing inside a single integration server instance. Your can have multiple IS servers load balanced together and connected to the same broker using the IS cluster feature. This will maintain the only once processing. Each Integration server would have the exact configuration as the other and all would present the same client prefix to the broker.

Mark is right (unless I missed something), wM Broker can not be load balanced like wM IS (using cisco, big ip, Resonate, ect).

Broker #1 – wM IS (A)
| wM IS (B)
| wM IS (C)
|
Broker #2 – wM IS (D)
Etc …

We might use the broker territory concept to « hook » broker together. But again this will not load balancing broker among them self. It will use the pub-sub model to send doc to all brokers in the territory.

You need to either (if you go to Broker first and asked Broker to send your doc to the first available wM IS) write a client stub that is broker aware (know how many brokers that exist in your landscape) and sort of send the doc to the least occupied one. Again this is not an easy talks to identified which broker is less occupied Or use a third party component (proxy server) in front of your broker.

At my client, we will use the AIX HACMP to cluster broker together (again is does not give us the ability to load balance)

A+

i guess i failed to give the picture , apologies

------------------------------------------------DMZ
One GateKeeper Integration Server
------------------------------------------------Inside
Broker Server

5 Integration Servers

All 5 Integration Servers listen to one broker . All i want to know is at a time only one IS server should pick the published document

so if IS1 picks the document , that document should not reside in broker unless IS1 failed to process and release the document so that other 4 IS get into the race again

Thanks a lot guys …if this won’t work we have to think something else

Bob

Yes you can use broker to loadbalance your 5 ISs on the documents basis. You do not need any teritory for this. Single broker is enough to create such a scenario. If you have territory you can use that as well. But single broker is simplest case. In order to get what you described in your 1st posting you must use WM Broker Shared State queue feature. This means that all your 5 ISs must connect to broker using same Client prefix. By default its some long random string. you must change this to be same. This will force all your ISs to use same queue on broker. This way only single IS will be able to get the document and all your ISs will loadbalance from 1 broker.

Now regarding using TIBCO and other JMS porviders that is likely not to work.

I hope this helps.

Thx a lot Igor …

as per my second part of question …when for some reason while processing the document if IS(n) fail or crashes can it release back the document to broker so that other 4 IS can pick it up

once again thx a lot

NB : does any one know how the product GLUE doing in the market ( US & Worldwide )…we kind of interested in webservices

Bob

We did this using WebSphere MQ. One queue, multiple IS boxes pulling from the queue. Works just dandy. Haven’t done it using Broker but it should work. Igor is dead on with the shared state queue stuff. If you don’t set that up you’ll get unable to connect errors for servers 2-5. I think you could indeed do this with other JMS providers too, though I know that’s not what you were asking for.

For the error condition, you’ll need to make sure that your IS service always releases the lock on the message (basically, commit or rollback) so you’ll need to use a try/catch construct somewhere unless the interaction with Broker is such that you can just toss an exception/error and the IS/Broker interaction automatically takes care of it. This won’t help you on a crash though. There may be some server-side settings you can use to timeout the lock but I’m not sure.

HTH

RobertTim,

TME’s Glue was widely used for initial web services prototypes and projects before the acquisition by webMethods and I am sure that continues to be the case today.

webMethods Fabric addresses the needs of companies who have moved beyond their first efforts and now need to solve problems that arise when organizations have hundreds or thousands of web services in their portfolio.

Mark