Microsite setup

Generally, I'd say yes you can do this. What confuses me about your requirement is this: if you *must* have distinct docroots on the front-end, how does the same requirement not essentially push you in a direction of splitting these sites into distinct branches?

Anyway, the foo.com routing is all done on the webserver, so it doesn't matter if it goes to LSDS instance X over here, or LSDS instance Y over there. Whether you put all this stuff in a single branch or distinct ones, the easiest way to accomplish this is by configuring the heck out of OpenDeployWebRoot.xml with filters that send the right files to the right places.

However, if you're using LSCS and/or your targets are on distinct servers (or you want that flexibility in the future), you'd be better off splitting this into different branches and different PLC targets. One additional thing to consider with the single-branch model, is that you open the door for authors of Foo to reference static assets of site Bar, which would render fine in preview but wouldn't on the runtime. Thus, you'd need to have possibly simple / possibly intricate permissions at the folder level within your WA. One more: editions lose some power/meaning because you won't be able to rollback an entire site without rolling back all the others.

...the more I think about this, the more I'm wondering why you'd want a single branch for all your microsites.. The only reason I can think of is to easily share "common" assets, but that would almost require pushing to the same docroot, not distinct ones... and there would be better ways to accomplish this anyway.

That's a great insight from Rick and reasanable questions on why sharing the same branch for two sites when there there two apps going to setup. As mentioned already you can have all filters in your OD config files for deploying right assets to right servers.

In addition I can confirm that mentioned approached worked well for us and we have tens of such sub domain/micro sites.

i) In webserver main conf file have your distinct entries of virutual hosts for each site
ii) configure your websphere plugin to redirect your for ex. .jsp's requests to your app server (I personally didn't do this stuff as it is web admins job) but I know most of the implementation.
iii) Add the config for applications extendedDocroot in your websphere's ibm-web-ext.xmi mostly WebAppExtension
iv) configure your load balancer to redirect all requests to your webserver farm

To respond to some of the questions (as best I can, the task was kind of handed to me without detailed information)...

So - taking all of the above with the proverbial grain of salt - we're planning to implement these as "microsites" within TeamSite - what I'm trying to understand is how you then support / use them from the front-end.

•My assumption about the distinct doctument roots (at least for the virtual web servers to point to) is that I'd think you would need to have distinct locations for things like home.page - which would be different for each site - right?

that's correct, you need to have distinct locations at the document base root level if you have decided to run these in two separate web applications.

•I'm thinking that most of these sites are in the neighborhood of 1-to-5 pages - and creating an entire branch for each one of them (not sure of the number but I've heard hints of anywhere from 4 to 20) doesn't seem reasonable when so much of the asset base would be shared.

Not to mention, having separate branch helps in designating proper role/groups to the users. It could be just a sub branch if client is running out of main level branches licensing. point to be taken here if you are running on lsds with .page model then it would conflicts if you have same file names for ex. .index.page unless you create two sites from S.P which I don't see you mentioned or planned for it.

•Most of the web assets (images, JS, CSS) will, I imagine, be shared (though there will likely be some CSS customizations for high-level look-and-feel stuff)
•Most of the content-types (page-templates, DCTs, etc.) would be identical across all the sites.

page templates, dct's are sharable across branches, so this should not be the reason, I agree that you will have more static resouces which are designed for brand site but you can always refer all static (css,js,img) from your prod. main brand site. You might need to find grind if customers wants to preview content before approving/publishing to these micro sites then you need to duplicate those assets with in these branches but remember this is the same scenario even when you create a single micro site and try to access main brand site resources from a different branch.

we're planning to implement these as "microsites" within TeamSite - what I'm trying to understand is how you then support / use them from the front-end.

I'm not sure I get it what you said but since assuming this is going to be with in teamsite and whether lscs plays the role or not here you will have more control over any promos/brand updates or complete shutdown of one site next to running another.

IMO, the branch-to-runtime relationship should be N-to-1... meaning either
* branch X goes to runtime X and branch Y goes to runtime Y; or
* branches X and Y both go to runtime Y
The scenario where a single branch gets split to multiple (non-mirrored) runtimes just gets ugly real fast. (You mentioned DCTs.. can you imagine trying to filter those at deployment time? yuck)

Given your requirements, I think you're right in saying that multiple branches would be a bit heavy for 5-page sites. But with the one branch model, I'd recommend a single docroot for all of these microsites. It'll simplify your life a LOT, especially since they're all public info and cross-usage of assets is intended.

My assumption about the distinct document roots (at least for the virtual web servers to point to) is that I'd think you would need to have distinct locations for things like home.page - which would be different for each site - right?

Nope, not a problem. Remember that your folder structure will end up looking like this:
/data/lsds_root/images/hello.png
/data/lsds_root/sites/microsite1/home.page
/data/lsds_root/sites/microsite2/home.page
/data/lsds_root/templatedata/cat/type/data/foobar.xml

Using ootb default.site functionality, you can have www.microsite1.com/ => sites/microsite1/home.page. However, the way $PAGE_LINK[] works, any link off that homepage to other pages within microsite1 will lead to this:
www.microsite1.com/microsite1/blah.page
This means that even though www.microsite2.com/ will read from sites/microsite2/home.page, a savvy user could go to www.microsite2.com/microsite1/blah.page and see microsite1 content on the microsite2 domain.

The URL structure can't be changed without a bit of Java customization to the $PAGE_LINK token, regardless of whether you're using a common or distinct runtimes. If your users are going to be picky about URLs, then you'll have to get your hands dirty anyway and you can put in a servlet filter (or rules in Apache) to 404/301 that kind of cross-site URL mixing.

My assumption about the distinct doctument roots [...] need to have distinct locations for things like home.page[...]
that's correct, you need to have distinct locations at the document base root level if you have decided to run these in two separate web applications.

When you say "two separate web applications" does that mean two separate instances of LSDS?
Is it possible to host multiple [micro] sites with one instance of LSDS? (details welome)

I'm thinking [...] 1-to-5 pages - creating an entire branch for each one of them [...] doesn't seem reasonable when so much of the asset base would be shared.
Not to mention, having separate branch helps in designating proper role/groups to the users. It could be just a sub branch if client is running out of main level branches licensing. point to be taken here if you are running on lsds with .page model then it would conflicts if you have same file names for ex. .index.page unless you create two sites from S.P which I don't see you mentioned or planned for it.

"Not to mention" makes it sound like you're agreeing with me, when the rest of your comment is in opposition to what I was saying.
However, I can handle file system access rights as needed and, at least for now, the number of individuals working on this sites is likely to be pretty small (or so I've been led to believe).

[...shared web assets...]
[...shared content-types...]
page templates, dct's are sharable across branches, so this should not be the reason

Good point.

I agree that you will have more static resouces which are designed for brand site but you can always refer all static (css,js,img) from your prod. main brand site. You might need to find grind if customers wants to preview content before approving/publishing to these micro sites then you need to duplicate those assets with in these branches but remember this is the same scenario even when you create a single micro site and try to access main brand site resources from a different branch.

I think the plan would be to provide the web assets in the microsite-branch to facilitate selection of them where needed without having to write custom cross-branch browsers for DCTs and componenets. But it is a good point, and perhaps it's worth spending some time writing those utilities to eliminate lots of redundant data being versioned in TeamSite and deployed to the servers... regardless of the approach taken for handling the microsites (single or multiple branches).

we're planning to implement these as "microsites" within TeamSite - what I'm trying to understand is how you then support / use them from the front-end.
I'm not sure I get it what you said but since assuming this is going to be with in teamsite and whether lscs plays the role or not here you will have more control over any promos/brand updates or complete shutdown of one site next to running another.

You're saying I'll have more control with separate branches and separate application instances - right? If so, yes - I agree.

However I'm puzzled: Is nobody using this SP/LS-provided multiple-site-in-one-branch feature?

(obligatory post, since you replied seconds after me and I'm sure you'll miss my post!)

However I'm puzzled: Is nobody using this SP/LS-provided multiple-site-in-one-branch feature?

I have before. The issue is not so much different sites in a same branch; the issue is that you want to fork a single branch to multiple docroots. See my post above.

Originally Posted by ghoti
My assumption about the distinct document roots (at least for the virtual web servers to point to) is that I'd think you would need to have distinct locations for things like home.page - which would be different for each site - right?

This is not true for SP assets which are in their own sites folder but all other common resouces out side of sites folder are sharable by two sites and each change corresponding to one site will have obvious reflections to another.

Originally Posted by ghoti
When you say "two separate web applications" does that mean two separate instances of LSDS?
Is it possible to host multiple [micro] sites with one instance of LSDS? (details welome)

Rick has already mentioned his experience.. Definetely, you can have multiple sites on same LSDS instance.

[...]Nope, not a problem. Remember that your folder structure will end up looking like this:
/data/lsds_root/images/hello.png
/data/lsds_root/sites/microsite1/home.page
/data/lsds_root/sites/microsite2/home.page
/data/lsds_root/templatedata/cat/type/data/foobar.xml

This is what I was talking about. - and a similar setup for the web server - right:

Hmm - not sure about that part, I guess I'll figure that out once I managed to get a POC done (involves other folks to do the web server setup, so I can't just whip it up myself).Thanks!

This is not true for SP assets which are in their own sites folder but all other common resouces out side of sites folder are sharable by two sites and each change corresponding to one site will have obvious reflections to another.

Assuming that the multiple sites do not expect to have different versions of the same non-site-based asset (which might be a big assumption) - this should be okay. I can take this as given and document it as a caveat - useful to know, thanks.

[QUOTE=ghoti]This is what I was talking about. - and a similar setup for the web server - right:

Given that, I don't see a point in having separate www docroots.