Architecture design question

Discussion in 'ASP .Net' started by Griff, Oct 8, 2004.

  1. Griff

    Griff Guest

    Hi

    I'm after some advice about the architecture to employ for a web front-end.

    First, I'll describe the system. We host several customers' back-office
    systems (which are identical) and which are accessed by our customers'
    employees by remote connection. Our customers now wish us to host an
    eCommerce front-end to their back-office systems on which *their* customers
    will place orders.

    By and large, the business rules for all our customers will be identical.
    So, my thought was to build a single n-tier system to handle this.

    The bottom tier is obviously our customers back-office systems.
    The next vertical tier would be a data-services tier that knows which
    back-office system to query.
    The next would be the business tier.
    And then we get to the UI.

    It's the UI tier that I'm most confused about.

    Each of our customers will require a unique look and feel - some may want a
    frames solution, another may want a tabular display, some may want the
    navigation buttons along the top whilst another will want them down the
    side. Yes, I'm sure that I could program this in to a system, but I'm not
    sure the best approach to take. Any/all suggestions most welcome.

    Also, I don't know yet whether to employ a single web site with virtual
    directories for each of our customers or to employ a separate web site for
    each customer. (A single web site seems sensible just in terms of
    incorporating SSL security). Either way, my guess is that I'd like all
    customers sites to use as much common code as possible. Could anyone talk
    me through ideal architectures for this?

    Alternatively, if anyone has any great book suggestions that will help me in
    this venture, I'd be really glad to hear of them.

    Many thanks in advance

    Griff
    Griff, Oct 8, 2004
    #1
    1. Advertising

  2. Griff

    Freddy Guest

    You can use a single website, custom user controls and css


    "Griff" <> wrote in message
    news:%23$...
    > Hi
    >
    > I'm after some advice about the architecture to employ for a web
    > front-end.
    >
    > First, I'll describe the system. We host several customers' back-office
    > systems (which are identical) and which are accessed by our customers'
    > employees by remote connection. Our customers now wish us to host an
    > eCommerce front-end to their back-office systems on which *their*
    > customers
    > will place orders.
    >
    > By and large, the business rules for all our customers will be identical.
    > So, my thought was to build a single n-tier system to handle this.
    >
    > The bottom tier is obviously our customers back-office systems.
    > The next vertical tier would be a data-services tier that knows which
    > back-office system to query.
    > The next would be the business tier.
    > And then we get to the UI.
    >
    > It's the UI tier that I'm most confused about.
    >
    > Each of our customers will require a unique look and feel - some may want
    > a
    > frames solution, another may want a tabular display, some may want the
    > navigation buttons along the top whilst another will want them down the
    > side. Yes, I'm sure that I could program this in to a system, but I'm not
    > sure the best approach to take. Any/all suggestions most welcome.
    >
    > Also, I don't know yet whether to employ a single web site with virtual
    > directories for each of our customers or to employ a separate web site for
    > each customer. (A single web site seems sensible just in terms of
    > incorporating SSL security). Either way, my guess is that I'd like all
    > customers sites to use as much common code as possible. Could anyone talk
    > me through ideal architectures for this?
    >
    > Alternatively, if anyone has any great book suggestions that will help me
    > in
    > this venture, I'd be really glad to hear of them.
    >
    > Many thanks in advance
    >
    > Griff
    >
    >
    >
    Freddy, Oct 8, 2004
    #2
    1. Advertising

  3. Griff

    Griff Guest

    Thanks Freddy

    Any suggestions for reading matter, particularly w.r.t. custom user controls
    and css.

    Presumably, there would be one CSS per customer (of ours). And, if our
    customers wanted specific fonts/colours then they'd have their own end-user
    style sheets?

    Thanks

    Griff
    Griff, Oct 8, 2004
    #3
  4. Griff

    Freddy Guest

    You can use asp.net Wrox press books as well as refer to msdn. For CSS
    Google it and you can find many free tutorials.


    "Griff" <> wrote in message
    news:udv$...
    > Thanks Freddy
    >
    > Any suggestions for reading matter, particularly w.r.t. custom user
    > controls
    > and css.
    >
    > Presumably, there would be one CSS per customer (of ours). And, if our
    > customers wanted specific fonts/colours then they'd have their own
    > end-user
    > style sheets?
    >
    > Thanks
    >
    > Griff
    >
    >
    Freddy, Oct 8, 2004
    #4
  5. Griff

    clintonG Guest

    ASP.NET 2.0 solves the problem but is not targeted for
    commercial release until Q2 2005. Regardless, I suggest
    you study its membership and theming capabilities.

    --
    <%= Clinton Gallagher, "Twice the Results -- Half the Cost"
    Architectural & e-Business Consulting -- Software Development
    NET
    URL http://www.metromilwaukee.com/clintongallagher/



    "Griff" <> wrote in message
    news:%23$...
    > Hi
    >
    > I'm after some advice about the architecture to employ for a web

    front-end.
    >
    > First, I'll describe the system. We host several customers' back-office
    > systems (which are identical) and which are accessed by our customers'
    > employees by remote connection. Our customers now wish us to host an
    > eCommerce front-end to their back-office systems on which *their*

    customers
    > will place orders.
    >
    > By and large, the business rules for all our customers will be identical.
    > So, my thought was to build a single n-tier system to handle this.
    >
    > The bottom tier is obviously our customers back-office systems.
    > The next vertical tier would be a data-services tier that knows which
    > back-office system to query.
    > The next would be the business tier.
    > And then we get to the UI.
    >
    > It's the UI tier that I'm most confused about.
    >
    > Each of our customers will require a unique look and feel - some may want

    a
    > frames solution, another may want a tabular display, some may want the
    > navigation buttons along the top whilst another will want them down the
    > side. Yes, I'm sure that I could program this in to a system, but I'm not
    > sure the best approach to take. Any/all suggestions most welcome.
    >
    > Also, I don't know yet whether to employ a single web site with virtual
    > directories for each of our customers or to employ a separate web site for
    > each customer. (A single web site seems sensible just in terms of
    > incorporating SSL security). Either way, my guess is that I'd like all
    > customers sites to use as much common code as possible. Could anyone talk
    > me through ideal architectures for this?
    >
    > Alternatively, if anyone has any great book suggestions that will help me

    in
    > this venture, I'd be really glad to hear of them.
    >
    > Many thanks in advance
    >
    > Griff
    >
    >
    >
    clintonG, Oct 8, 2004
    #5
  6. Griff

    Colin Young Guest

    In addition to the good suggestions already made, I'd like to add that one
    way to reduce complexity in this sort of situation is to limit the options
    in changing the site layout. That's actually less restrictive than it sounds
    with decent CSS coding skills. As long as all pages have the same components
    on them you should be able to use CSS to lay them out almost any way the
    customer wants. You don't want to get into providing a frames solution for
    some customers and a single page for others. You'll end up with too much
    duplicated code.

    If you go with the single-site solution, you need a good method to ensure
    that the sites don't bleed into each other (e.g. if you are browsing company
    A's site, there shouldn't be products or services from company B showing up,
    even if they do appear in the style of company A's site). You will also need
    a way to distinguish which site the user has requested. Do you want to use
    www.hostcompany.com/?custid=A or www.companya.com? Either way, you'll want
    to encapsulate all the code to detect which site the user has requested into
    one area.

    To handle your customers' business rules, if you haven't already done so,
    consider using a rules engine to implement them. Inevitably somebody will
    need a different rule, and with a good engine you can even let your
    customers manage their own rules (if you so desire).

    Colin

    "Griff" <> wrote in message
    news:%23$...
    > Hi
    >
    > I'm after some advice about the architecture to employ for a web

    front-end.
    >
    > First, I'll describe the system. We host several customers' back-office
    > systems (which are identical) and which are accessed by our customers'
    > employees by remote connection. Our customers now wish us to host an
    > eCommerce front-end to their back-office systems on which *their*

    customers
    > will place orders.
    >
    > By and large, the business rules for all our customers will be identical.
    > So, my thought was to build a single n-tier system to handle this.
    >
    > The bottom tier is obviously our customers back-office systems.
    > The next vertical tier would be a data-services tier that knows which
    > back-office system to query.
    > The next would be the business tier.
    > And then we get to the UI.
    >
    > It's the UI tier that I'm most confused about.
    >
    > Each of our customers will require a unique look and feel - some may want

    a
    > frames solution, another may want a tabular display, some may want the
    > navigation buttons along the top whilst another will want them down the
    > side. Yes, I'm sure that I could program this in to a system, but I'm not
    > sure the best approach to take. Any/all suggestions most welcome.
    >
    > Also, I don't know yet whether to employ a single web site with virtual
    > directories for each of our customers or to employ a separate web site for
    > each customer. (A single web site seems sensible just in terms of
    > incorporating SSL security). Either way, my guess is that I'd like all
    > customers sites to use as much common code as possible. Could anyone talk
    > me through ideal architectures for this?
    >
    > Alternatively, if anyone has any great book suggestions that will help me

    in
    > this venture, I'd be really glad to hear of them.
    >
    > Many thanks in advance
    >
    > Griff
    >
    >
    >
    Colin Young, Oct 8, 2004
    #6
  7. What I've done is to have generic pages in one area and then seperate
    directories for each customer, and in there put some html pages that I open
    and read and then output them to the screen. Can't do aspx page that way,
    but you can


    "Colin Young" <> wrote in message
    news:uR%...
    > In addition to the good suggestions already made, I'd like to add that one
    > way to reduce complexity in this sort of situation is to limit the options
    > in changing the site layout. That's actually less restrictive than it
    > sounds
    > with decent CSS coding skills. As long as all pages have the same
    > components
    > on them you should be able to use CSS to lay them out almost any way the
    > customer wants. You don't want to get into providing a frames solution for
    > some customers and a single page for others. You'll end up with too much
    > duplicated code.
    >
    > If you go with the single-site solution, you need a good method to ensure
    > that the sites don't bleed into each other (e.g. if you are browsing
    > company
    > A's site, there shouldn't be products or services from company B showing
    > up,
    > even if they do appear in the style of company A's site). You will also
    > need
    > a way to distinguish which site the user has requested. Do you want to use
    > www.hostcompany.com/?custid=A or www.companya.com? Either way, you'll want
    > to encapsulate all the code to detect which site the user has requested
    > into
    > one area.
    >
    > To handle your customers' business rules, if you haven't already done so,
    > consider using a rules engine to implement them. Inevitably somebody will
    > need a different rule, and with a good engine you can even let your
    > customers manage their own rules (if you so desire).
    >
    > Colin
    >
    > "Griff" <> wrote in message
    > news:%23$...
    >> Hi
    >>
    >> I'm after some advice about the architecture to employ for a web

    > front-end.
    >>
    >> First, I'll describe the system. We host several customers' back-office
    >> systems (which are identical) and which are accessed by our customers'
    >> employees by remote connection. Our customers now wish us to host an
    >> eCommerce front-end to their back-office systems on which *their*

    > customers
    >> will place orders.
    >>
    >> By and large, the business rules for all our customers will be identical.
    >> So, my thought was to build a single n-tier system to handle this.
    >>
    >> The bottom tier is obviously our customers back-office systems.
    >> The next vertical tier would be a data-services tier that knows which
    >> back-office system to query.
    >> The next would be the business tier.
    >> And then we get to the UI.
    >>
    >> It's the UI tier that I'm most confused about.
    >>
    >> Each of our customers will require a unique look and feel - some may want

    > a
    >> frames solution, another may want a tabular display, some may want the
    >> navigation buttons along the top whilst another will want them down the
    >> side. Yes, I'm sure that I could program this in to a system, but I'm
    >> not
    >> sure the best approach to take. Any/all suggestions most welcome.
    >>
    >> Also, I don't know yet whether to employ a single web site with virtual
    >> directories for each of our customers or to employ a separate web site
    >> for
    >> each customer. (A single web site seems sensible just in terms of
    >> incorporating SSL security). Either way, my guess is that I'd like all
    >> customers sites to use as much common code as possible. Could anyone
    >> talk
    >> me through ideal architectures for this?
    >>
    >> Alternatively, if anyone has any great book suggestions that will help me

    > in
    >> this venture, I'd be really glad to hear of them.
    >>
    >> Many thanks in advance
    >>
    >> Griff
    >>
    >>
    >>

    >
    >
    Adrian Parker, Oct 12, 2004
    #7
  8. What I've done is to have generic pages in one area and then seperate
    directories for each customer, and in there put some html pages that I open
    and read and then output them to the screen. Can't do aspx page that way,
    but you can load specific aspx pages from there.

    "Colin Young" <> wrote in message
    news:uR%...
    > In addition to the good suggestions already made, I'd like to add that one
    > way to reduce complexity in this sort of situation is to limit the options
    > in changing the site layout. That's actually less restrictive than it
    > sounds
    > with decent CSS coding skills. As long as all pages have the same
    > components
    > on them you should be able to use CSS to lay them out almost any way the
    > customer wants. You don't want to get into providing a frames solution for
    > some customers and a single page for others. You'll end up with too much
    > duplicated code.
    >
    > If you go with the single-site solution, you need a good method to ensure
    > that the sites don't bleed into each other (e.g. if you are browsing
    > company
    > A's site, there shouldn't be products or services from company B showing
    > up,
    > even if they do appear in the style of company A's site). You will also
    > need
    > a way to distinguish which site the user has requested. Do you want to use
    > www.hostcompany.com/?custid=A or www.companya.com? Either way, you'll want
    > to encapsulate all the code to detect which site the user has requested
    > into
    > one area.
    >
    > To handle your customers' business rules, if you haven't already done so,
    > consider using a rules engine to implement them. Inevitably somebody will
    > need a different rule, and with a good engine you can even let your
    > customers manage their own rules (if you so desire).
    >
    > Colin
    >
    > "Griff" <> wrote in message
    > news:%23$...
    >> Hi
    >>
    >> I'm after some advice about the architecture to employ for a web

    > front-end.
    >>
    >> First, I'll describe the system. We host several customers' back-office
    >> systems (which are identical) and which are accessed by our customers'
    >> employees by remote connection. Our customers now wish us to host an
    >> eCommerce front-end to their back-office systems on which *their*

    > customers
    >> will place orders.
    >>
    >> By and large, the business rules for all our customers will be identical.
    >> So, my thought was to build a single n-tier system to handle this.
    >>
    >> The bottom tier is obviously our customers back-office systems.
    >> The next vertical tier would be a data-services tier that knows which
    >> back-office system to query.
    >> The next would be the business tier.
    >> And then we get to the UI.
    >>
    >> It's the UI tier that I'm most confused about.
    >>
    >> Each of our customers will require a unique look and feel - some may want

    > a
    >> frames solution, another may want a tabular display, some may want the
    >> navigation buttons along the top whilst another will want them down the
    >> side. Yes, I'm sure that I could program this in to a system, but I'm
    >> not
    >> sure the best approach to take. Any/all suggestions most welcome.
    >>
    >> Also, I don't know yet whether to employ a single web site with virtual
    >> directories for each of our customers or to employ a separate web site
    >> for
    >> each customer. (A single web site seems sensible just in terms of
    >> incorporating SSL security). Either way, my guess is that I'd like all
    >> customers sites to use as much common code as possible. Could anyone
    >> talk
    >> me through ideal architectures for this?
    >>
    >> Alternatively, if anyone has any great book suggestions that will help me

    > in
    >> this venture, I'd be really glad to hear of them.
    >>
    >> Many thanks in advance
    >>
    >> Griff
    >>
    >>
    >>

    >
    >
    Adrian Parker, Oct 12, 2004
    #8
  9. Griff

    Griff Guest


    > To handle your customers' business rules, if you haven't already done so,
    > consider using a rules engine to implement them.


    Could you define a "rules engine" please...
    Griff, Oct 12, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Muhammad Khan
    Replies:
    4
    Views:
    1,223
    Mike Treseler
    Jul 10, 2003
  2. Replies:
    3
    Views:
    508
    Malcolm
    Sep 29, 2005
  3. rashmi
    Replies:
    2
    Views:
    457
    Grumble
    Jul 5, 2005
  4. Replies:
    3
    Views:
    422
    Malcolm
    Sep 29, 2005
  5. Replies:
    4
    Views:
    659
    Malcolm
    Sep 29, 2005
Loading...

Share This Page