Re: Architectural feedback

From: John Spiegel (jspiegel_at_YETANOTHERSPAMHATERc-comld.com)
Date: 01/10/05 

Date: Mon, 10 Jan 2005 12:58:56 -0700

Hi Bob,

Thanks for jumping in! I would like to factor in multi-server and reduncy
considerations (clusters/failover). On a scale of on-line gaming to
financial and medical apps, we're somewhere in the middle. My light reading
has indicated that (not meaning to trivialize this but) once the servers
themselves are configured, the applications themselves, if planned for, are
no where near as excruciating to run and stay up in such an environment than
was the case not so long ago.

- John

"Bob Milton" <bmilton@adelphia.org> wrote in message
news:%234uX0U09EHA.1084@tk2msftngp13.phx.gbl...
> 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: Using kerberosSecurity Throws Security Exception
    ... I am experiencing this error while trying to use a Windows XP client ... application to access a web service located on a W2k3 server. ... client app on the server, ... > Account with a Custom Principal Name using SetSPN.exe utility. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Questions about Remoting, objects, threading. lease lifetime and object cleanup, and a couple of
    ... so long as the Client app is ... always refering to the same server object. ... it sets its ClassOne object to nothing and goes away. ... >>The client app at some point is going to become an ASP.Net app also. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Remoting or windows service
    ... Thanks for writing up such a decent overview of the remoting dev process ... the client and the server. ... > 2) Implement this class in the server app and say that it can be accessed ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Schannel and Session Renegotiation
    ... Schannel does not support the server sending app ... We are discussing the option of providing support for the client blowing off ...
    (microsoft.public.platformsdk.security)
  • Re: Getting Events, for Windows Service
    ... else tries to run my client app he gets an timeout error. ... The server application has a public object called logger, ... So it seems that the logger is properly instantiated and works. ...
    (microsoft.public.dotnet.framework.remoting)