Resilient connections to EIS

Question

Hi all,
I've got a question regarding designing a weblogic-based solution that needs to talk to an EIS.
Basically we have a new system that also needs to keep an old system up to date for an interim period. In order to do this the new system is placing messages representing transactions onto a queue to be processed asynchronously. We are currently considering 3 options:
- Message driven beans using JCA
- WLI process using JCA
- Writing our own message consumer which manages threads to write to the backend (the reason for this will become clear below)
Basically the worry we have is that the backend may become unavailble (planned or unplanned) and we're worried that an MDB or WLI solution has no way of automatically stopping processing and then automatically picking it up again once the EIS comes back. We bascially don't want to get into a situation where we have a pool of MDBs (for instance) continually trying and failing to connect to the backend (filling the logs and wasting resources). The roll-your-own solution was therefore to enable us to control the number of threads that were attempting to connect by recognising failures and closing down all but one polling thread until we got a response again.
This RYO approach feels really wrong, though, and it seems that WLI must have something in it to cope with this kind of failure situation. I have seen some stuff in the docs about automatically suspending and then restarting processing but am unsure if any adapters support this model. For information we are currently looking to connect to an Adabas/Natural backend via either 3270, CICS or direct natural connections.
Hope someone can help on this !
Thanks
Ian

Answer 1

Andy
It depends.
I was assuming they had area 0 at both DCs as you mentioned that.
You should really use two areas and then they would need to filter your routes because you would be injecting them into one area on one link and then they would be sending them to you on the other link.
The problem arises if each of their DCs is using different areas.
So say the main DC is area 0 and the backup DC is area 1.
All OSPF areas need to be directly connected to area 0 and obviously this wouldn't happen on the link to the area 1 DC if you use your own area.
You can use virtual links but you should avoid these if possible.
If you simply use their existing areas at your end then that means you are going to receive type 1 and type 2 LSAs as well.
I don't think I can give you a definitive answer because there are too many variable in terms of OSPF areas, summarisation etc.
Are the subnets within your main and backup DC different and the same question for their DCs ?
Depending on the answers to the above it may make more sense to run EIGRP across those links using summary addresses at your end for the subnets and let them do the redistribution because EIGRP does not have the same issues with areas.
I cannot see how that would affect their VRFs and even if it did they can always create a non VRF interface for the exchange of routes
I'm happy to help out further when you get more information but I think you need to talk with the other network guy especially about how the OSPF connections are going to work.
Jon