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