Architecture design question

[Griff]

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]

You can use a single website, custom user controls and css
"Griff" <Ho*****@The.Moon> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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]

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]

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" <Ho*****@The.Moon> wrote in message
news:ud*************@TK2MSFTNGP09.phx.gbl...

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

[Adrian Parker]

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" <[e-mail]> wrote in message
news:uR***************@TK2MSFTNGP09.phx.gbl...

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" <Ho*****@The.Moon> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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]

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" <[e-mail]> wrote in message
news:uR***************@TK2MSFTNGP09.phx.gbl...

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" <Ho*****@The.Moon> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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]

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...