No, Updating Subscribers and bi-directional replication are similar in concept, but radically different in implementation.
Updating subscribers are implemented in "one way" replication using RPC calls. The subscriber is 100% dependant on the publisher. Triggers on the subscriber tables force an update on the publisher table via an RPC call to the publisher. This is conceptually easy, guarantees correctness without user intervention, but it uses lots of bandwidth and CPU.
Bi-directional replication effectively has two (or N) publishers... Each updates and publishes. This gives maximum autonomy, but it can requires LOTS of manual intervention when the publishers get into a "fight" due to simultaneous updates to the same row.
This is a question that is WAY too complex for a simple answer. There are literally thousands of options that can be applied in some unholy number of combinations, and there are often more than one combination that will work well for a given situation.
I'd investigate merge replication to see if that will do what you need. Be sure that you understand what replication conflicts are, and how they are resolved in different scenarios... They can kill you if you are caught unprepared!
Replication is an area where I almost always recommend professional advice. You need someone that understands replication to come in and analyze your scenario. There are many choices to be made, and some of them can be critically important to your long-term sanity. While a knowledgable person isn't going to be cheap, the consequences of serious mistakes can be expensive in ways that you can hardly imagine at the outset!
Tks for the reply Pat. I understand what u mean. I had tested merge replication on my app and the latency of merge is a factor which cannot be accepted at this moment. Thats why i decided to research on bi-directional transactional replication.
Here's a description of the requirements.
I have server A and server B. server A will be the main server and B the backup. Data will be process at server A under normal settings and B will just get updates from A. However when A goes down, B will become the main server. Now the data will be process at B. When server A goes live again, data will need to be process at A again and with all data in-sync with B. And all these has to be automated, except for making A live again.
What u think of bi-directional trans repl for this?