The "branch office wan" best practice...


Performance and scalability: The "branch office wan" best practice...

  1. The "branch office wan" best practice... (1 messages)

    What are the best practices for designing a system with the following restrictions/attributes?

    A central office is linked with a number of branch offices over a 56k frame relay. Each office collects a manageable volume of data (say, sales transactions) and must send those to a central server. The central server, in turn, delivers a manageable amount of data (say, inventory lists) to the branches in addition to program updates. Configuration is locally managed, and globally overridden. Security management (users, passwords, rights, etc...) is distributed across the WAN. UI, etc... will be web-based with roughly 20 terminals per branch. A provision must be made for off-line autonomous operation at each branch.

    At first glance, I want to centralize business operations into a big clustered AS and deliver web pages over the WAN. That would break off-line operations however.

    So, the second plan would be to use a big replicating database (SQL Server, Oracle, ... ) to handle the transactional synchronization, and then keep the branch code simple and unaware of the central server. I could even handle code updates by overriding the classloader to hit the database for the mutable code. But, I am afraid that good database replication may cost a fair amount and there may be other pitfalls.

    A third plan would be a good application framework and embedded database that have some built-in replication capabilities. I just don't know of any frameworks that do this. Borland's embedded java database claims to support replication, are there any opensource alternatives? How about updates, is there a Webstart for application servers?

    Has anyone had any luck designing a similar system?
    Am I missing anything?


    Ryan Groth
  2. The "branch office wan" best practice...[ Go to top ]

    I would use Spring/ORM(hibernate,etc.)/JMS.

    if you want to keep cost down just use an open source JMS provider.

    the branch offices, will be JMS clients(publish, and scribers) to the Central Office JMS provider

    database alone will not handle transaction synchronization, u will need global transaction Tx provided by Spring, or JTA(if u have an app server.) wrapped around your operations(JMS messenging,business calls to DB,etc.)

    u could use MySql to do all that u mentioned, it supports clustering,etc..