Hello,
I currently have a database set up for replication on 3 servers as
follows:
Pub - users connect and update database
Sub1 - database is accessed for local application
Sub2 - database is accessed for local application
The subscriptions are set up for both immediate and queued updating, so,
in theory, if Pub goes down, the users can re-connect to Sub1 to update
the database, and when Pub comes back, the queued updating will apply
the changes to Pub. Also, during the time Pub is down, the local
application on Sub1 will have access to current data.
However, as I understand it, Sub2 will not have access to the latest
data while Pub is down, since the only way those changes make it to Sub2
is through Pub. So, Sub2 will be accessing "old" data as long as Pub is
unable to send the changes.
Do I have this right ? Is there a simple way to get Sub1 to update Sub2
when Pub is down ? As it is now configured, it's kind of a pain in the
neck to manage the replication when we have to make a change to the
database definition, and I also want people to be able to update at Sub2
and have the changes propagate to Sub1 and Pub, in the event that
becomes necessary. But I don't want to create a structure that is a
nightmare to manage.
Any suggestions ?
Thanks,
Patrick
No, there is no simple way to do this.
Replication requires a publisher which figures out what goes where.
What you could do is have Pub publish to Sub1, and then have Sub1 publish to
Sub2. I would use merge replication for this.
Why are you using immediate updating?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Patrick Johnson" <PJohnson_TechnoScope@.nospam.com> wrote in message
news:PJohnson_TechnoScope-09A593.15383717022005@.msnews.microsoft.com...
> Hello,
> I currently have a database set up for replication on 3 servers as
> follows:
> Pub - users connect and update database
> Sub1 - database is accessed for local application
> Sub2 - database is accessed for local application
> The subscriptions are set up for both immediate and queued updating, so,
> in theory, if Pub goes down, the users can re-connect to Sub1 to update
> the database, and when Pub comes back, the queued updating will apply
> the changes to Pub. Also, during the time Pub is down, the local
> application on Sub1 will have access to current data.
> However, as I understand it, Sub2 will not have access to the latest
> data while Pub is down, since the only way those changes make it to Sub2
> is through Pub. So, Sub2 will be accessing "old" data as long as Pub is
> unable to send the changes.
> Do I have this right ? Is there a simple way to get Sub1 to update Sub2
> when Pub is down ? As it is now configured, it's kind of a pain in the
> neck to manage the replication when we have to make a change to the
> database definition, and I also want people to be able to update at Sub2
> and have the changes propagate to Sub1 and Pub, in the event that
> becomes necessary. But I don't want to create a structure that is a
> nightmare to manage.
> Any suggestions ?
> Thanks,
> Patrick
|||In article <uHp4mjTFFHA.1264@.TK2MSFTNGP12.phx.gbl>,
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote:
> No, there is no simple way to do this.
> Replication requires a publisher which figures out what goes where.
> What you could do is have Pub publish to Sub1, and then have Sub1 publish to
> Sub2. I would use merge replication for this.
> Why are you using immediate updating?
Hi Hilary,
Thanks for your reply.
I have all of the users updating at Pub right now, so conceivably I
could get away without immediate updating, but the intent is that local
updates can be made at Sub1 and Sub2 and propagated immediately through
the system.
In practice it is a rare event for an update to happen someplace other
than at Pub.
Is immediate updating a bad idea ?
It's been a while since I set it up, but I remember there was some
reason I didn't want to use merge. Of course, now I can't remember what
it was.
Thanks,
Patrick
Showing posts with label accessed. Show all posts
Showing posts with label accessed. Show all posts
Saturday, February 11, 2012
3-tier deployment
I'm looking into deploying Reporting Services on a new project. The reports
in question would be accessed from the Internet. We have a requirement to
separate the HTTP server from the application logic, but all of the RS
deployment examples I have seen show the RS server on the same box as the
HTTP server. Is it possible to separate the two functions and set a firewall
in between, or does RS have to be on the same machine as the HTTP server?The Web part of RS goes on the same Box as IIS, it is a web app... The
database can be somewhere else... The article below is just what you need.
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/rsdepgd.mspx#EEAA
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Web Mayfield" <WebMayfield@.discussions.microsoft.com> wrote in message
news:22618170-C83F-489B-8AE5-52ADE0C124A4@.microsoft.com...
> I'm looking into deploying Reporting Services on a new project. The
reports
> in question would be accessed from the Internet. We have a requirement to
> separate the HTTP server from the application logic, but all of the RS
> deployment examples I have seen show the RS server on the same box as the
> HTTP server. Is it possible to separate the two functions and set a
firewall
> in between, or does RS have to be on the same machine as the HTTP server?|||I had found that but I don't think it's what I'm talking about. I need to
separate the IIS that runs the publicly accessible website from the machine
that's running RS and put a firewall between them. If the RS machine needs
IIS (and I think it does) that's fine, but the public webserver needs to be
separated from RS if possible.
"Wayne Snyder" wrote:
> The Web part of RS goes on the same Box as IIS, it is a web app... The
> database can be somewhere else... The article below is just what you need.
> http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/rsdepgd.mspx#EEAA
>
> --
> Wayne Snyder MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> (Please respond only to the newsgroup.)
> I support the Professional Association for SQL Server ( PASS) and it's
> community of SQL Professionals.
> "Web Mayfield" <WebMayfield@.discussions.microsoft.com> wrote in message
> news:22618170-C83F-489B-8AE5-52ADE0C124A4@.microsoft.com...
> > I'm looking into deploying Reporting Services on a new project. The
> reports
> > in question would be accessed from the Internet. We have a requirement to
> > separate the HTTP server from the application logic, but all of the RS
> > deployment examples I have seen show the RS server on the same box as the
> > HTTP server. Is it possible to separate the two functions and set a
> firewall
> > in between, or does RS have to be on the same machine as the HTTP server?
>
>|||To do this you have to have your own asp.net app that controls what report
runs, its parameters, etc. I.e. you can not use the portal that ships with
RS (Report Manager) and have to create your own. Note that you can have RS
outside your firewall but have the data inside your firewall (since really
what the goal is protecting your data). Assuming you create your own front
end to the reports then you have a choice between URL integration and web
services. With RS 2005 you will have the option of a webform and winform
controls for integration.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Web Mayfield" <WebMayfield@.discussions.microsoft.com> wrote in message
news:428106E8-EE5E-41F2-AC8E-70DAC03FBD3B@.microsoft.com...
> I had found that but I don't think it's what I'm talking about. I need to
> separate the IIS that runs the publicly accessible website from the
machine
> that's running RS and put a firewall between them. If the RS machine
needs
> IIS (and I think it does) that's fine, but the public webserver needs to
be
> separated from RS if possible.
> "Wayne Snyder" wrote:
> > The Web part of RS goes on the same Box as IIS, it is a web app... The
> > database can be somewhere else... The article below is just what you
need.
> >
> >
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/rsdepgd.mspx#EEAA
> >
> >
> > --
> > Wayne Snyder MCDBA, SQL Server MVP
> > Mariner, Charlotte, NC
> > (Please respond only to the newsgroup.)
> >
> > I support the Professional Association for SQL Server ( PASS) and it's
> > community of SQL Professionals.
> > "Web Mayfield" <WebMayfield@.discussions.microsoft.com> wrote in message
> > news:22618170-C83F-489B-8AE5-52ADE0C124A4@.microsoft.com...
> > > I'm looking into deploying Reporting Services on a new project. The
> > reports
> > > in question would be accessed from the Internet. We have a
requirement to
> > > separate the HTTP server from the application logic, but all of the RS
> > > deployment examples I have seen show the RS server on the same box as
the
> > > HTTP server. Is it possible to separate the two functions and set a
> > firewall
> > > in between, or does RS have to be on the same machine as the HTTP
server?
> >
> >
> >|||I just want to follow up because this is exactly the question I had (thanks
Web Mayfield whoever you are).
We deploy our web-based application on three physical servers. The web
server has no access to data and very little business logic. Incoming web
requests are forwarded to our business logic server via .NET remoting. The
business logic server has access to the DB server. For security reasons
neither the business logic server nor the DB server have IIS installed.
It looks like RS requires me to either (a) put a database on my web server
box, or (b) put IIS on either my business logic box or my database box. I
don't like either one of these alternatives. Am I correctly understanding
that there are no other possibilities?
Thanks
Jeff Berkowitz
Serveron
Hillsboro (Portland), OR
"Bruce L-C [MVP]" wrote:
> To do this you have to have your own asp.net app that controls what report
> runs, its parameters, etc. I.e. you can not use the portal that ships with
> RS (Report Manager) and have to create your own. Note that you can have RS
> outside your firewall but have the data inside your firewall (since really
> what the goal is protecting your data). Assuming you create your own front
> end to the reports then you have a choice between URL integration and web
> services. With RS 2005 you will have the option of a webform and winform
> controls for integration.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services|||No, you are incorrect. Note that licensing is different than deployment
options. Licensing requires a SQL Server license every place that RS is
installed. RS requires SQL Server for an object store. It does not require
that object store be on the same physical server as RS. As a matter of fact,
this is how web farms are implemented, they all share the same SQL Server
database. RS requires IIS, it is an asp.net application.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Jeff Berkowitz" <Jeff Berkowitz@.discussions.microsoft.com> wrote in message
news:10CBA5E3-4FC8-406D-B0D7-6CBBF327FF06@.microsoft.com...
>I just want to follow up because this is exactly the question I had (thanks
> Web Mayfield whoever you are).
> We deploy our web-based application on three physical servers. The web
> server has no access to data and very little business logic. Incoming web
> requests are forwarded to our business logic server via .NET remoting.
> The
> business logic server has access to the DB server. For security reasons
> neither the business logic server nor the DB server have IIS installed.
> It looks like RS requires me to either (a) put a database on my web server
> box, or (b) put IIS on either my business logic box or my database box. I
> don't like either one of these alternatives. Am I correctly understanding
> that there are no other possibilities?
> Thanks
> Jeff Berkowitz
> Serveron
> Hillsboro (Portland), OR
>
> "Bruce L-C [MVP]" wrote:
>> To do this you have to have your own asp.net app that controls what
>> report
>> runs, its parameters, etc. I.e. you can not use the portal that ships
>> with
>> RS (Report Manager) and have to create your own. Note that you can have
>> RS
>> outside your firewall but have the data inside your firewall (since
>> really
>> what the goal is protecting your data). Assuming you create your own
>> front
>> end to the reports then you have a choice between URL integration and web
>> services. With RS 2005 you will have the option of a webform and winform
>> controls for integration.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>|||I need to do the same thing as the people in this post. I do not quite
understand the thread of "solutions" posted here. What exactly is the
solution?
Create an asp.net or vb.net app on the middle tier box? What does it do?
Call this app from the iis server outside of the firewall? How do you do
this? Virtual folder? How does it get rendered to the client?
What does the .net app do in on the middle tier box that calls the report?
I am not using the portal. I have an asp.net app that runs on front end iis
box (outside of the firewall), but it connects to the database. I need it to
connect to the middle tier box. We cannot have the iis server accessing the
database server directly (2 tier).
"Bruce L-C [MVP]" wrote:
> No, you are incorrect. Note that licensing is different than deployment
> options. Licensing requires a SQL Server license every place that RS is
> installed. RS requires SQL Server for an object store. It does not require
> that object store be on the same physical server as RS. As a matter of fact,
> this is how web farms are implemented, they all share the same SQL Server
> database. RS requires IIS, it is an asp.net application.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Jeff Berkowitz" <Jeff Berkowitz@.discussions.microsoft.com> wrote in message
> news:10CBA5E3-4FC8-406D-B0D7-6CBBF327FF06@.microsoft.com...
> >I just want to follow up because this is exactly the question I had (thanks
> > Web Mayfield whoever you are).
> >
> > We deploy our web-based application on three physical servers. The web
> > server has no access to data and very little business logic. Incoming web
> > requests are forwarded to our business logic server via .NET remoting.
> > The
> > business logic server has access to the DB server. For security reasons
> > neither the business logic server nor the DB server have IIS installed.
> >
> > It looks like RS requires me to either (a) put a database on my web server
> > box, or (b) put IIS on either my business logic box or my database box. I
> > don't like either one of these alternatives. Am I correctly understanding
> > that there are no other possibilities?
> >
> > Thanks
> > Jeff Berkowitz
> > Serveron
> > Hillsboro (Portland), OR
> >
> >
> >
> > "Bruce L-C [MVP]" wrote:
> >
> >> To do this you have to have your own asp.net app that controls what
> >> report
> >> runs, its parameters, etc. I.e. you can not use the portal that ships
> >> with
> >> RS (Report Manager) and have to create your own. Note that you can have
> >> RS
> >> outside your firewall but have the data inside your firewall (since
> >> really
> >> what the goal is protecting your data). Assuming you create your own
> >> front
> >> end to the reports then you have a choice between URL integration and web
> >> services. With RS 2005 you will have the option of a webform and winform
> >> controls for integration.
> >>
> >>
> >> --
> >> Bruce Loehle-Conger
> >> MVP SQL Server Reporting Services
> >
>
>|||I must be dense but I'm not getting it.
You do understand that our web head has no database access at all, correct?
It only has access to our "proprietary" business facade via .NET remoting.
We do not want to implement any kind of direct DB access from the web head to
our existing SQL Server installation for any purpose whatsoever. Our
remoting facade provides auditing and other services that we would lose if we
did this.
Assuming you understood this from my original post, you must be suggesting
that RS should be installed in our business layer. We do not have IIS
installed at this layer and do not want to.
So my misunderstanding must be that I don't understand how to get API-style
access to RS in response to incoming requests without installing IIS on the
business layer.
I appreciate your help and If I'm just being dense you can be blunt about
it. ;-)
Jeff
"Bruce L-C [MVP]" wrote:
> No, you are incorrect. Note that licensing is different than deployment
> options. Licensing requires a SQL Server license every place that RS is
> installed. RS requires SQL Server for an object store. It does not require
> that object store be on the same physical server as RS. As a matter of fact,
> this is how web farms are implemented, they all share the same SQL Server
> database. RS requires IIS, it is an asp.net application.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Jeff Berkowitz" <Jeff Berkowitz@.discussions.microsoft.com> wrote in message
> news:10CBA5E3-4FC8-406D-B0D7-6CBBF327FF06@.microsoft.com...
> >I just want to follow up because this is exactly the question I had (thanks
> > Web Mayfield whoever you are).
> >
> > We deploy our web-based application on three physical servers. The web
> > server has no access to data and very little business logic. Incoming web
> > requests are forwarded to our business logic server via .NET remoting.
> > The
> > business logic server has access to the DB server. For security reasons
> > neither the business logic server nor the DB server have IIS installed.
> >
> > It looks like RS requires me to either (a) put a database on my web server
> > box, or (b) put IIS on either my business logic box or my database box. I
> > don't like either one of these alternatives. Am I correctly understanding
> > that there are no other possibilities?
> >
> > Thanks
> > Jeff Berkowitz
> > Serveron
> > Hillsboro (Portland), OR|||Have you looked at the link I provided previously. It has very good diagrams
on how it all works. The architecture requires IIS somewhere. RS does not
exist without it. RS is an asp.net application. Also it requires SQL Server
as an object store somewhere.
So, let's say you have your server facing the internet. It calls your
business objects on another server. If you want to use RS then you have two
choices, either you install IIS on your server with your business objects OR
you have a third server with RS. Your business objects can use web services
to integrate with RS. If you don't want IIS running somewhere AND where it
is running it has to have access to SQL Server at a minimum for an object
store. The SQL Server used can be on another server. It is also possible to
write your own data extension that RS would use your business objects.
My feeling is that with the architecture you have and your design goals you
should not use RS at this time. What you should consider are the new
controls that have just come out with Widbey (the lastest beta for the next
version of Visual Studio). The web control allows you to hand a dataset to
the control and the report to the control. In local mode it does not require
any server at all.
My suggestion is to first closely read this link:
http://www.microsoft.com/sql/reporting/techinfo/techoverview.asp
My feeling is that it will be a whole lot of work for you to do what you
want to do.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Jeff Berkowitz" <JeffBerkowitz@.discussions.microsoft.com> wrote in message
news:39953487-5243-4857-B42D-86C255C5ABCC@.microsoft.com...
>I must be dense but I'm not getting it.
> You do understand that our web head has no database access at all,
> correct?
> It only has access to our "proprietary" business facade via .NET remoting.
> We do not want to implement any kind of direct DB access from the web head
> to
> our existing SQL Server installation for any purpose whatsoever. Our
> remoting facade provides auditing and other services that we would lose if
> we
> did this.
> Assuming you understood this from my original post, you must be suggesting
> that RS should be installed in our business layer. We do not have IIS
> installed at this layer and do not want to.
> So my misunderstanding must be that I don't understand how to get
> API-style
> access to RS in response to incoming requests without installing IIS on
> the
> business layer.
> I appreciate your help and If I'm just being dense you can be blunt about
> it. ;-)
> Jeff
> "Bruce L-C [MVP]" wrote:
>> No, you are incorrect. Note that licensing is different than deployment
>> options. Licensing requires a SQL Server license every place that RS is
>> installed. RS requires SQL Server for an object store. It does not
>> require
>> that object store be on the same physical server as RS. As a matter of
>> fact,
>> this is how web farms are implemented, they all share the same SQL Server
>> database. RS requires IIS, it is an asp.net application.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Jeff Berkowitz" <Jeff Berkowitz@.discussions.microsoft.com> wrote in
>> message
>> news:10CBA5E3-4FC8-406D-B0D7-6CBBF327FF06@.microsoft.com...
>> >I just want to follow up because this is exactly the question I had
>> >(thanks
>> > Web Mayfield whoever you are).
>> >
>> > We deploy our web-based application on three physical servers. The web
>> > server has no access to data and very little business logic. Incoming
>> > web
>> > requests are forwarded to our business logic server via .NET remoting.
>> > The
>> > business logic server has access to the DB server. For security
>> > reasons
>> > neither the business logic server nor the DB server have IIS installed.
>> >
>> > It looks like RS requires me to either (a) put a database on my web
>> > server
>> > box, or (b) put IIS on either my business logic box or my database box.
>> > I
>> > don't like either one of these alternatives. Am I correctly
>> > understanding
>> > that there are no other possibilities?
>> >
>> > Thanks
>> > Jeff Berkowitz
>> > Serveron
>> > Hillsboro (Portland), OR
>|||Jeff,
I think your question is very reasonable. The difficulty here is that the
SQL Server 2000 version of Reporting Services doesn't work the way you want
it to.
You want a public web server running IIS, but for security reasons, little
logic and no database access. Makes perfect sense. You want a middle tier
server running your business logic. This server will be allowed database
access, but for security reasons it will not run IIS. Once again, that's
exactly how I would recommend securing public web sites.
Here's the problem. Reporting services is implemented as web services. It
is not a straight DLL and can not be accessed via .NET Remoting. You have to
have IIS to run these (or any other) web services.
If you don't want logic on your public web server, and you don't want IIS on
your business logic server, you have two somewhat unattractive choices.
First, you could put IIS on your database server. The big downside is that
this exposes IIS bugs on your SQL Server, but at least it's 2 steps removed
from your public web server. Second choice is to install the RS web services
on a fourth server. The downside is that it requires a fourth server and
does still put an IIS presence on your network. But, at least it's as secure
as you're going to get.
Here's what that 4-tier solution would look like. Your public web server is
limited to hitting your business server. The business server runs a custom
DLL you write, and can be accessed via .NET remoting. The Reporting Services
server has IIS and is accessed by your DLL via SOAP. Finally, the Reporting
Services server accesses SQL Server for it's store. This is ugly, but it's
fairly secure.
I recommend you look at using the SQL Server 2005 version of Reporting
Services, which is due out at the end of the year. In that version, you will
be able to render reports without running a web service, so you can simply
have the same vanilla 3-tier architecture that you have for everything else.
If you have to implement now and don't want to use Beta 2, you will have to
sacrifice some security or use a fourth server.
Hope this clears things up.
Ted
"Jeff Berkowitz" wrote:
> I must be dense but I'm not getting it.
> You do understand that our web head has no database access at all, correct?
> It only has access to our "proprietary" business facade via .NET remoting.
> We do not want to implement any kind of direct DB access from the web head to
> our existing SQL Server installation for any purpose whatsoever. Our
> remoting facade provides auditing and other services that we would lose if we
> did this.
> Assuming you understood this from my original post, you must be suggesting
> that RS should be installed in our business layer. We do not have IIS
> installed at this layer and do not want to.
> So my misunderstanding must be that I don't understand how to get API-style
> access to RS in response to incoming requests without installing IIS on the
> business layer.
> I appreciate your help and If I'm just being dense you can be blunt about
> it. ;-)
> Jeff|||Thanks (very much) both Ted and Bruce. We may choose to put IIS on one of
our backend boxes and go with the current version of RS. At least we are not
religiously opposed to the idea; I just wanted to make sure I understood the
situation clearly. You've both been extremely helpful.
Jeff Berkowitz
"Ted K" wrote:
> Jeff,
> I think your question is very reasonable. ...
in question would be accessed from the Internet. We have a requirement to
separate the HTTP server from the application logic, but all of the RS
deployment examples I have seen show the RS server on the same box as the
HTTP server. Is it possible to separate the two functions and set a firewall
in between, or does RS have to be on the same machine as the HTTP server?The Web part of RS goes on the same Box as IIS, it is a web app... The
database can be somewhere else... The article below is just what you need.
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/rsdepgd.mspx#EEAA
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Web Mayfield" <WebMayfield@.discussions.microsoft.com> wrote in message
news:22618170-C83F-489B-8AE5-52ADE0C124A4@.microsoft.com...
> I'm looking into deploying Reporting Services on a new project. The
reports
> in question would be accessed from the Internet. We have a requirement to
> separate the HTTP server from the application logic, but all of the RS
> deployment examples I have seen show the RS server on the same box as the
> HTTP server. Is it possible to separate the two functions and set a
firewall
> in between, or does RS have to be on the same machine as the HTTP server?|||I had found that but I don't think it's what I'm talking about. I need to
separate the IIS that runs the publicly accessible website from the machine
that's running RS and put a firewall between them. If the RS machine needs
IIS (and I think it does) that's fine, but the public webserver needs to be
separated from RS if possible.
"Wayne Snyder" wrote:
> The Web part of RS goes on the same Box as IIS, it is a web app... The
> database can be somewhere else... The article below is just what you need.
> http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/rsdepgd.mspx#EEAA
>
> --
> Wayne Snyder MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> (Please respond only to the newsgroup.)
> I support the Professional Association for SQL Server ( PASS) and it's
> community of SQL Professionals.
> "Web Mayfield" <WebMayfield@.discussions.microsoft.com> wrote in message
> news:22618170-C83F-489B-8AE5-52ADE0C124A4@.microsoft.com...
> > I'm looking into deploying Reporting Services on a new project. The
> reports
> > in question would be accessed from the Internet. We have a requirement to
> > separate the HTTP server from the application logic, but all of the RS
> > deployment examples I have seen show the RS server on the same box as the
> > HTTP server. Is it possible to separate the two functions and set a
> firewall
> > in between, or does RS have to be on the same machine as the HTTP server?
>
>|||To do this you have to have your own asp.net app that controls what report
runs, its parameters, etc. I.e. you can not use the portal that ships with
RS (Report Manager) and have to create your own. Note that you can have RS
outside your firewall but have the data inside your firewall (since really
what the goal is protecting your data). Assuming you create your own front
end to the reports then you have a choice between URL integration and web
services. With RS 2005 you will have the option of a webform and winform
controls for integration.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Web Mayfield" <WebMayfield@.discussions.microsoft.com> wrote in message
news:428106E8-EE5E-41F2-AC8E-70DAC03FBD3B@.microsoft.com...
> I had found that but I don't think it's what I'm talking about. I need to
> separate the IIS that runs the publicly accessible website from the
machine
> that's running RS and put a firewall between them. If the RS machine
needs
> IIS (and I think it does) that's fine, but the public webserver needs to
be
> separated from RS if possible.
> "Wayne Snyder" wrote:
> > The Web part of RS goes on the same Box as IIS, it is a web app... The
> > database can be somewhere else... The article below is just what you
need.
> >
> >
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/rsdepgd.mspx#EEAA
> >
> >
> > --
> > Wayne Snyder MCDBA, SQL Server MVP
> > Mariner, Charlotte, NC
> > (Please respond only to the newsgroup.)
> >
> > I support the Professional Association for SQL Server ( PASS) and it's
> > community of SQL Professionals.
> > "Web Mayfield" <WebMayfield@.discussions.microsoft.com> wrote in message
> > news:22618170-C83F-489B-8AE5-52ADE0C124A4@.microsoft.com...
> > > I'm looking into deploying Reporting Services on a new project. The
> > reports
> > > in question would be accessed from the Internet. We have a
requirement to
> > > separate the HTTP server from the application logic, but all of the RS
> > > deployment examples I have seen show the RS server on the same box as
the
> > > HTTP server. Is it possible to separate the two functions and set a
> > firewall
> > > in between, or does RS have to be on the same machine as the HTTP
server?
> >
> >
> >|||I just want to follow up because this is exactly the question I had (thanks
Web Mayfield whoever you are).
We deploy our web-based application on three physical servers. The web
server has no access to data and very little business logic. Incoming web
requests are forwarded to our business logic server via .NET remoting. The
business logic server has access to the DB server. For security reasons
neither the business logic server nor the DB server have IIS installed.
It looks like RS requires me to either (a) put a database on my web server
box, or (b) put IIS on either my business logic box or my database box. I
don't like either one of these alternatives. Am I correctly understanding
that there are no other possibilities?
Thanks
Jeff Berkowitz
Serveron
Hillsboro (Portland), OR
"Bruce L-C [MVP]" wrote:
> To do this you have to have your own asp.net app that controls what report
> runs, its parameters, etc. I.e. you can not use the portal that ships with
> RS (Report Manager) and have to create your own. Note that you can have RS
> outside your firewall but have the data inside your firewall (since really
> what the goal is protecting your data). Assuming you create your own front
> end to the reports then you have a choice between URL integration and web
> services. With RS 2005 you will have the option of a webform and winform
> controls for integration.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services|||No, you are incorrect. Note that licensing is different than deployment
options. Licensing requires a SQL Server license every place that RS is
installed. RS requires SQL Server for an object store. It does not require
that object store be on the same physical server as RS. As a matter of fact,
this is how web farms are implemented, they all share the same SQL Server
database. RS requires IIS, it is an asp.net application.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Jeff Berkowitz" <Jeff Berkowitz@.discussions.microsoft.com> wrote in message
news:10CBA5E3-4FC8-406D-B0D7-6CBBF327FF06@.microsoft.com...
>I just want to follow up because this is exactly the question I had (thanks
> Web Mayfield whoever you are).
> We deploy our web-based application on three physical servers. The web
> server has no access to data and very little business logic. Incoming web
> requests are forwarded to our business logic server via .NET remoting.
> The
> business logic server has access to the DB server. For security reasons
> neither the business logic server nor the DB server have IIS installed.
> It looks like RS requires me to either (a) put a database on my web server
> box, or (b) put IIS on either my business logic box or my database box. I
> don't like either one of these alternatives. Am I correctly understanding
> that there are no other possibilities?
> Thanks
> Jeff Berkowitz
> Serveron
> Hillsboro (Portland), OR
>
> "Bruce L-C [MVP]" wrote:
>> To do this you have to have your own asp.net app that controls what
>> report
>> runs, its parameters, etc. I.e. you can not use the portal that ships
>> with
>> RS (Report Manager) and have to create your own. Note that you can have
>> RS
>> outside your firewall but have the data inside your firewall (since
>> really
>> what the goal is protecting your data). Assuming you create your own
>> front
>> end to the reports then you have a choice between URL integration and web
>> services. With RS 2005 you will have the option of a webform and winform
>> controls for integration.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>|||I need to do the same thing as the people in this post. I do not quite
understand the thread of "solutions" posted here. What exactly is the
solution?
Create an asp.net or vb.net app on the middle tier box? What does it do?
Call this app from the iis server outside of the firewall? How do you do
this? Virtual folder? How does it get rendered to the client?
What does the .net app do in on the middle tier box that calls the report?
I am not using the portal. I have an asp.net app that runs on front end iis
box (outside of the firewall), but it connects to the database. I need it to
connect to the middle tier box. We cannot have the iis server accessing the
database server directly (2 tier).
"Bruce L-C [MVP]" wrote:
> No, you are incorrect. Note that licensing is different than deployment
> options. Licensing requires a SQL Server license every place that RS is
> installed. RS requires SQL Server for an object store. It does not require
> that object store be on the same physical server as RS. As a matter of fact,
> this is how web farms are implemented, they all share the same SQL Server
> database. RS requires IIS, it is an asp.net application.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Jeff Berkowitz" <Jeff Berkowitz@.discussions.microsoft.com> wrote in message
> news:10CBA5E3-4FC8-406D-B0D7-6CBBF327FF06@.microsoft.com...
> >I just want to follow up because this is exactly the question I had (thanks
> > Web Mayfield whoever you are).
> >
> > We deploy our web-based application on three physical servers. The web
> > server has no access to data and very little business logic. Incoming web
> > requests are forwarded to our business logic server via .NET remoting.
> > The
> > business logic server has access to the DB server. For security reasons
> > neither the business logic server nor the DB server have IIS installed.
> >
> > It looks like RS requires me to either (a) put a database on my web server
> > box, or (b) put IIS on either my business logic box or my database box. I
> > don't like either one of these alternatives. Am I correctly understanding
> > that there are no other possibilities?
> >
> > Thanks
> > Jeff Berkowitz
> > Serveron
> > Hillsboro (Portland), OR
> >
> >
> >
> > "Bruce L-C [MVP]" wrote:
> >
> >> To do this you have to have your own asp.net app that controls what
> >> report
> >> runs, its parameters, etc. I.e. you can not use the portal that ships
> >> with
> >> RS (Report Manager) and have to create your own. Note that you can have
> >> RS
> >> outside your firewall but have the data inside your firewall (since
> >> really
> >> what the goal is protecting your data). Assuming you create your own
> >> front
> >> end to the reports then you have a choice between URL integration and web
> >> services. With RS 2005 you will have the option of a webform and winform
> >> controls for integration.
> >>
> >>
> >> --
> >> Bruce Loehle-Conger
> >> MVP SQL Server Reporting Services
> >
>
>|||I must be dense but I'm not getting it.
You do understand that our web head has no database access at all, correct?
It only has access to our "proprietary" business facade via .NET remoting.
We do not want to implement any kind of direct DB access from the web head to
our existing SQL Server installation for any purpose whatsoever. Our
remoting facade provides auditing and other services that we would lose if we
did this.
Assuming you understood this from my original post, you must be suggesting
that RS should be installed in our business layer. We do not have IIS
installed at this layer and do not want to.
So my misunderstanding must be that I don't understand how to get API-style
access to RS in response to incoming requests without installing IIS on the
business layer.
I appreciate your help and If I'm just being dense you can be blunt about
it. ;-)
Jeff
"Bruce L-C [MVP]" wrote:
> No, you are incorrect. Note that licensing is different than deployment
> options. Licensing requires a SQL Server license every place that RS is
> installed. RS requires SQL Server for an object store. It does not require
> that object store be on the same physical server as RS. As a matter of fact,
> this is how web farms are implemented, they all share the same SQL Server
> database. RS requires IIS, it is an asp.net application.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Jeff Berkowitz" <Jeff Berkowitz@.discussions.microsoft.com> wrote in message
> news:10CBA5E3-4FC8-406D-B0D7-6CBBF327FF06@.microsoft.com...
> >I just want to follow up because this is exactly the question I had (thanks
> > Web Mayfield whoever you are).
> >
> > We deploy our web-based application on three physical servers. The web
> > server has no access to data and very little business logic. Incoming web
> > requests are forwarded to our business logic server via .NET remoting.
> > The
> > business logic server has access to the DB server. For security reasons
> > neither the business logic server nor the DB server have IIS installed.
> >
> > It looks like RS requires me to either (a) put a database on my web server
> > box, or (b) put IIS on either my business logic box or my database box. I
> > don't like either one of these alternatives. Am I correctly understanding
> > that there are no other possibilities?
> >
> > Thanks
> > Jeff Berkowitz
> > Serveron
> > Hillsboro (Portland), OR|||Have you looked at the link I provided previously. It has very good diagrams
on how it all works. The architecture requires IIS somewhere. RS does not
exist without it. RS is an asp.net application. Also it requires SQL Server
as an object store somewhere.
So, let's say you have your server facing the internet. It calls your
business objects on another server. If you want to use RS then you have two
choices, either you install IIS on your server with your business objects OR
you have a third server with RS. Your business objects can use web services
to integrate with RS. If you don't want IIS running somewhere AND where it
is running it has to have access to SQL Server at a minimum for an object
store. The SQL Server used can be on another server. It is also possible to
write your own data extension that RS would use your business objects.
My feeling is that with the architecture you have and your design goals you
should not use RS at this time. What you should consider are the new
controls that have just come out with Widbey (the lastest beta for the next
version of Visual Studio). The web control allows you to hand a dataset to
the control and the report to the control. In local mode it does not require
any server at all.
My suggestion is to first closely read this link:
http://www.microsoft.com/sql/reporting/techinfo/techoverview.asp
My feeling is that it will be a whole lot of work for you to do what you
want to do.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Jeff Berkowitz" <JeffBerkowitz@.discussions.microsoft.com> wrote in message
news:39953487-5243-4857-B42D-86C255C5ABCC@.microsoft.com...
>I must be dense but I'm not getting it.
> You do understand that our web head has no database access at all,
> correct?
> It only has access to our "proprietary" business facade via .NET remoting.
> We do not want to implement any kind of direct DB access from the web head
> to
> our existing SQL Server installation for any purpose whatsoever. Our
> remoting facade provides auditing and other services that we would lose if
> we
> did this.
> Assuming you understood this from my original post, you must be suggesting
> that RS should be installed in our business layer. We do not have IIS
> installed at this layer and do not want to.
> So my misunderstanding must be that I don't understand how to get
> API-style
> access to RS in response to incoming requests without installing IIS on
> the
> business layer.
> I appreciate your help and If I'm just being dense you can be blunt about
> it. ;-)
> Jeff
> "Bruce L-C [MVP]" wrote:
>> No, you are incorrect. Note that licensing is different than deployment
>> options. Licensing requires a SQL Server license every place that RS is
>> installed. RS requires SQL Server for an object store. It does not
>> require
>> that object store be on the same physical server as RS. As a matter of
>> fact,
>> this is how web farms are implemented, they all share the same SQL Server
>> database. RS requires IIS, it is an asp.net application.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Jeff Berkowitz" <Jeff Berkowitz@.discussions.microsoft.com> wrote in
>> message
>> news:10CBA5E3-4FC8-406D-B0D7-6CBBF327FF06@.microsoft.com...
>> >I just want to follow up because this is exactly the question I had
>> >(thanks
>> > Web Mayfield whoever you are).
>> >
>> > We deploy our web-based application on three physical servers. The web
>> > server has no access to data and very little business logic. Incoming
>> > web
>> > requests are forwarded to our business logic server via .NET remoting.
>> > The
>> > business logic server has access to the DB server. For security
>> > reasons
>> > neither the business logic server nor the DB server have IIS installed.
>> >
>> > It looks like RS requires me to either (a) put a database on my web
>> > server
>> > box, or (b) put IIS on either my business logic box or my database box.
>> > I
>> > don't like either one of these alternatives. Am I correctly
>> > understanding
>> > that there are no other possibilities?
>> >
>> > Thanks
>> > Jeff Berkowitz
>> > Serveron
>> > Hillsboro (Portland), OR
>|||Jeff,
I think your question is very reasonable. The difficulty here is that the
SQL Server 2000 version of Reporting Services doesn't work the way you want
it to.
You want a public web server running IIS, but for security reasons, little
logic and no database access. Makes perfect sense. You want a middle tier
server running your business logic. This server will be allowed database
access, but for security reasons it will not run IIS. Once again, that's
exactly how I would recommend securing public web sites.
Here's the problem. Reporting services is implemented as web services. It
is not a straight DLL and can not be accessed via .NET Remoting. You have to
have IIS to run these (or any other) web services.
If you don't want logic on your public web server, and you don't want IIS on
your business logic server, you have two somewhat unattractive choices.
First, you could put IIS on your database server. The big downside is that
this exposes IIS bugs on your SQL Server, but at least it's 2 steps removed
from your public web server. Second choice is to install the RS web services
on a fourth server. The downside is that it requires a fourth server and
does still put an IIS presence on your network. But, at least it's as secure
as you're going to get.
Here's what that 4-tier solution would look like. Your public web server is
limited to hitting your business server. The business server runs a custom
DLL you write, and can be accessed via .NET remoting. The Reporting Services
server has IIS and is accessed by your DLL via SOAP. Finally, the Reporting
Services server accesses SQL Server for it's store. This is ugly, but it's
fairly secure.
I recommend you look at using the SQL Server 2005 version of Reporting
Services, which is due out at the end of the year. In that version, you will
be able to render reports without running a web service, so you can simply
have the same vanilla 3-tier architecture that you have for everything else.
If you have to implement now and don't want to use Beta 2, you will have to
sacrifice some security or use a fourth server.
Hope this clears things up.
Ted
"Jeff Berkowitz" wrote:
> I must be dense but I'm not getting it.
> You do understand that our web head has no database access at all, correct?
> It only has access to our "proprietary" business facade via .NET remoting.
> We do not want to implement any kind of direct DB access from the web head to
> our existing SQL Server installation for any purpose whatsoever. Our
> remoting facade provides auditing and other services that we would lose if we
> did this.
> Assuming you understood this from my original post, you must be suggesting
> that RS should be installed in our business layer. We do not have IIS
> installed at this layer and do not want to.
> So my misunderstanding must be that I don't understand how to get API-style
> access to RS in response to incoming requests without installing IIS on the
> business layer.
> I appreciate your help and If I'm just being dense you can be blunt about
> it. ;-)
> Jeff|||Thanks (very much) both Ted and Bruce. We may choose to put IIS on one of
our backend boxes and go with the current version of RS. At least we are not
religiously opposed to the idea; I just wanted to make sure I understood the
situation clearly. You've both been extremely helpful.
Jeff Berkowitz
"Ted K" wrote:
> Jeff,
> I think your question is very reasonable. ...
Subscribe to:
Posts (Atom)