Re: Architectural feedback

From: Bob Milton (bmilton_at_adelphia.org)
Date: 01/10/05 

Date: Mon, 10 Jan 2005 10:50:02 -0800

John,
    Just to muddy the water some more - do you care what happens when the
server goes down? (They do). That can influence your design. For example,
bank branches absolutely must be able to function with a failed server (or
connection to same). This means a lot of functionality is duplicated on the
clients just for this case. (But upgrades are done rarely - sometimes years
apart - because of the pain of upgrading).
    Basically, there aren't any good guidelines as to when you use which
approach since that can be so dependent on the specific situation.
    BTW, trying to foresee future growth and features in your application
(being more "large company like") is a good practice in my experience.
    Bob Milton

"John Spiegel" <jspiegel@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:%23wQDPUz9EHA.3980@TK2MSFTNGP11.phx.gbl...
> Hi all,
>
> I'm in the early stages of designing a system that we'll use in-house and
> am
> looking for opinions and suggestions for further reading on which
> directions
> to take.
>
> Background: Though we're a small company, I'd like to design this with
> the
> mindset of a larger company from the start. This will be an ongoing
> project
> to encompass a lot of needs, which will generally be variations on
> standard
> themes: Customer account management, billing, reporting and other fairly
> common business functions. Most functionality will be accessed from our
> LAN
> with WinForms-based apps (assume all client machines are Windows running
> at
> least 2000). There will be some limited Web access for employees, e.g.,
> order forms for sales staff. While we may eventually want to build some
> Web
> services for sharing informtion, the general pulic website will remain
> fairly autonomous.
>
> The nature of the company and application is that there will be fairly
> frequent releasing of the system, or components thereof.
>
> Current leanings: Most of the functionality will probably APPEAR to be
> (from user standpoint) unified under a single app. There are a number of
> underlying components into which this apparent monolith will actually be
> broken. Aside from various departmental boundaries that will make for
> nice
> conceptual breaks. Utilities, e.g., common dialogs, data access and
> account
> calculations, will be broken into various solutions. I'm thinking that
> there will be a skeleton client app that provides the system navigation,
> security and user preferences then uses the appropriate other resources to
> provide actual functionality.
>
> A lot of my uncertainties are in determining what forms and in what
> locations the pieces should be. For example, I'm not clear on whether the
> core app must reside on the client or may be run from the server. Is it
> better to leave the individual dll's on the server, or install in each
> client's GAC? My guess is that deploying all components to individual
> clients will give notably better performance. On the downside, that would
> imply updating a number of machines every time we add a new or function.or
> want to release bug fixes.
>
> I've read a fair amount on remoting, serviced components, and related
> functional divisions (a 70-320 prep book, mainly), but have seen little
> that
> really ties together when the best situations to use each are.
>
> TIA,
>
> John
>
>

Relevant Pages

  • Re: suid bit files + securing FreeBSD (new program: LockDown)
    ... I found the design maybe LockDown or your IDS could use ... So you need at least one CFC server, ... the client boots, it will just use the files it already have and update ... The multicast address the client is a member of. ...
    (FreeBSD-Security)
  • Re: VB connection to SQL server
    ... > the client machine begins to lose its relevance and accuracy as soon as it ... > aware that the data is probably out of date, a client sided cursor might ... > design minimises the possibility that records will have changed in the ... >> The Database server is in the office, and people use the Vb program from ...
    (microsoft.public.vb.database)
  • Re: Distributed applications and OOD
    ... On the server-side, client ... > still it is the only working design for distributed applications. ... implementing an OOA model in an EJB/J2EE environment, ... in the client, in the DB, or in the server. ...
    (comp.object)
  • Re: client -server interaction over XML supporting multiple protocols
    ... > NETBEUI to access the server to access the functionalities exposed. ... > server doesnot know in advance which client is using what protocol. ... size of the XML and Xfunctionality will determine the demands ...
    (comp.lang.cpp)
  • Re: Architectural feedback
    ... > bank branches absolutely must be able to function with a failed server (or ... This means a lot of functionality is duplicated on ... >> core app must reside on the client or may be run from the server. ...
    (microsoft.public.dotnet.general)