Hi, Jason This was one very detailed answer, I must admit. However there's two corrections that I feel is necessary.
1. Witango service doesn't need to have access to Application files, it needs to have a valid Data Source. Application Files must be visible to IIS with Witango Plugin. That plugin will in turn connect to Witango Services specifed in clients.ini either randomly or by following directions supplied as arguments of the URL. 2. You can't have a mapped drive functioning, while there's no user logged in to the server. This option would only be valid for a testlab, where developer is always logged and drive is always mapped. Sincerely, Andre Rekhtine IS Consultant Moveable Online Inc. > Each Witango service will need to see the location of the files in > the same way. > > There are two and a half ways to do this. > > A) Copied Code (the half method). > > On each Witango server, copy the code to the same location (eg, c: > \inetpub\wwwroot\). Configure IIS to share one of these as the > website. You will need to manually maintain consistency between the > copies (think customer file uploads, etc). > > Pros: > Good Witango load sharing. > Good for read only sites > Quick and dirty. > > Cons: > Manual work involved to ensure code is consistent between all Witango > instances. > No Witango service redundancy (they 'see' different copies of the > files). > > B) Mapped Drive. > > Share wwwroot, and map a drive (eg, 'K:\') against it on _all_ > Witango servers. > Configure IIS to share drive K as the website. > > Pros: > Good redundancy across application elements. > Good load sharing. > Easy to update code. > Code is consistent between all Witango instances. > Simple to configure > > Cons: > Only works for a single site (you need a new drive letter for each site) > If the mapped drive fails for any reason, manual intervention is > required to restore the connection. > > C) Share Point > Have your code in a shared directory, eg., \\Host\wwwroot\code.taf > > Configure IIS in the 'Home Directory' tab so that 'the content for > this resource should come from [X] A share located on another > computer', and point it at \\Host\wwwroot\ > > Ensure that the privileges required to access \\Host\wwwroot are > available to the account that Witango is running under. > > With the above configuration, you can have single or multiple IIS > front ends, with single or multiple Witango services. The share point > could be served from any one of them, or an unrelated server (such as > a NAS box). > > Pros: > Good redundancy across application elements. > Good load sharing. > Easy to update code. > Code is consistent between all Witango instances. > Single hardware installation can support multiple sites > > Cons: > Pain to get going. > More to go wrong. > More to look after. > > Regards, > > Jason. > > > > On 04/10/2007, at 3:32 PM, Fogelson, Steve wrote: > >> Andre and others, >> >> I have done some testing with the following setup >> >> Server A will run one Witango service and the databases will reside >> here. >> Server B will run IIS, Witango Client and one Witango service >> >> I assumed you had to have copies of all the taf, tml, tcf, images >> and html >> files on both servers. Is this true or do you only have to have the >> files on >> the IIS and Witango Client server (B)? > > > > WITH IMAGINATION > Planning, Implementation and Management of Web Applications > > Level 1, 44 Miller Street North Sydney NSW Australia 2060 > phone + 612 9929 9229 fax + 612 9460 4770 > web - www.wi.com.au email - [EMAIL PROTECTED] > > > > -- > This message has been scanned for viruses and > dangerous content by ESVA, and is > believed to be clean. > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
