Maintaining localization in a distributed environment

  • Thread starter Thread starter TS
  • Start date Start date
T

TS

Hi, I have a windows app that is installed all across the state. Each site
has its own database server that must be separately updated when schema or
data changes are needed. Each site has several client machines that use the
server as a service to manage it's client app's data. There is a central
admin app that maintains all the master content used in each one of these
databases. Updates to this content are then pushed out to the remote sites'
server where the database resides. Currently i am using resource files that
are used as a key value pair to retrieve text in diff. locals. The files are
of course xml, though to use them you make updates to the text in this file,
then compile the project to make a locale specific dll file. ex: es-mx.dll.
These resource files are used by the client app at the remote sites.

What is the best way to maintain this culture specific data using my current
business process? If i mimick the way i do it in my dev environment, i would
have to have my admin app update the xml resource file, then compile it &
send it out & install it on each client machine at the remote site. Someone
else suggested using a a table in a db that mimicks the key value pair like
the resource file. This would allow the database content to have this
modified locale specific data pushed out with the rest of the database
changes to the database server only, instead of having to have complicated
build scripts and post data to each client machine.

if anything needs explained, let me know

thanks
 
Hi TS,

Thanks for your posting!

After reading your post for several times, I think I get a somewhat
understanding of your issue. Based on my understanding, you have many child
sites(servers) all across the state, which are all maintained by a central
server. Also, there are a lot of client machines connecting to certain
child site(server) at their district. Now, you need to update certain
database content of the child site through the central server, so you want
to get a good practise for this. If there is anything I misunderstand you,
please feel free to tell me.

This is seldom a winform related issue, normally, this is somewhat a design
and pattern issue.

First, how do you implement the remote connection between the client
winform app and the child site(server)? What architecture do you use, B/S ,
C/S or something like smartclient. Or maybe your client winform app just
simply connects to the remote child server's database and manipulating the
data without any server side app on the child server?

Also, what is the architecture between the child server and the central
server? Using webservice, remoting or some other things?

Generally, based on my experience, I think it is not a good idea to just
store the content information data in resource file, this will break the
module separate rule. Just as you stated, any modify to the content data
will result in a new build. We have a lot of choice for this issue, such as
storing information in a XML file, database table, etc. Each choice has its
advantage based on your like.

After storing the updated content a chosing medium in certain format, the
central server can query the updating location information and notify the
updated child sites(servers) that they need to update.

This is just one thought. For your information.
============================================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
First, how do you implement the remote connection between the client
winform app and the child site(server)?
Also, what is the architecture between the child server and the central
server? Using webservice, remoting or some other things?
Click to expand...
We have a smart client that connects through web services to the child site
server
After storing the updated content a chosing medium in certain format, the
central server can query the updating location information and notify the
updated child sites(servers) that they need to update.
Click to expand...
We don't have a connection between the central server and the child sites
servers, so all updates have to be done through installing off a cd.

So it seems that a DB or xml file would be the best fit for this scenario.
Can you please outline a few adv./disadv. of using DB vs. XML (i've always
had a hard time determining which one is most appropriate for a situation-i
usually pick the DB because it seems easier from a development point of
view)

Thanks for your post!

"Jeffrey Tan[MSFT]" said:
Hi TS,

Thanks for your posting!

After reading your post for several times, I think I get a somewhat
understanding of your issue. Based on my understanding, you have many child
sites(servers) all across the state, which are all maintained by a central
server. Also, there are a lot of client machines connecting to certain
child site(server) at their district. Now, you need to update certain
database content of the child site through the central server, so you want
to get a good practise for this. If there is anything I misunderstand you,
please feel free to tell me.

This is seldom a winform related issue, normally, this is somewhat a design
and pattern issue.

First, how do you implement the remote connection between the client
winform app and the child site(server)? What architecture do you use, B/S ,
C/S or something like smartclient. Or maybe your client winform app just
simply connects to the remote child server's database and manipulating the
data without any server side app on the child server?

Also, what is the architecture between the child server and the central
server? Using webservice, remoting or some other things?

Generally, based on my experience, I think it is not a good idea to just
store the content information data in resource file, this will break the
module separate rule. Just as you stated, any modify to the content data
will result in a new build. We have a lot of choice for this issue, such as
storing information in a XML file, database table, etc. Each choice has its
advantage based on your like.

After storing the updated content a chosing medium in certain format, the
central server can query the updating location information and notify the
updated child sites(servers) that they need to update.

This is just one thought. For your information.
============================================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Click to expand...
 
Hi TS,

Thanks for your feedback!!

I am glad my reply makes sense to you.

For database, I think it is more suitable for mass data storage, and
database is an efficient storage if your concern is performance. Also, we
may leverage all the function exposed by ADO.NET to access the database
table etc.

For xml, it is suitable for configuration storage, actually, it is a good
substitution for legacy .ini file. Also, we may leverage System.Xml classes
to access xml file data.

Furthermore, for security reason, xml is not suitable to store private
data. These data should be encrypted and store in database. Also, you can
design your application architecture as distributed with the database
accessing, but xml can not design like this.

Hope this information helps you.
==============================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Back
Top