I'm trying to deploy reporting services in an architecture that has an IIS
server outside of the firewall, a middle tier server running web services and
a backend sql server. I understand I need to have the reporting services on
my sql server and I also understand I need to have the reporting client (iis
portion) installed somewhere.
How do I do this and keep my 3 tier architecture. I cannot install software
on the IIS server that talks directly to my sql server (2 tier).
I am not using the portal to view reports. I'm rendering the reports by
creating a hyperlink to the rdl files. Do I use virtual folders mapped to the
middle tier? Will the report clients get installed on both boxes? Front only?You misunderstand the architecture. SQL Server database is an object store.
You can report off of any database for the data for the report but the
object store must be SQL Server database. Reporting Services is an asp.net
application. It is not the client it is the application. That means that you
have to have IIS installed where you have RS installed. You can integrate
with either URL integration or with SOAP. SOAP is more complicated but it
gives you the most control. RS uses the object store which can reside on
another machine. RS does the queries to the data to report off of it.
By my understanding of 3 tier you have the user (using a browser it one
tier), your app is the second tier and SQL Server is the 3rd tier. Having RS
go against SQL Server data does not make it 2 tier. RS is a middle tier app.
You want to do 4 tiers which makes it more complicated, doable but
complicated.
Here is a great link to understand how this all works:
http://www.microsoft.com/sql/reporting/techinfo/techoverview.asp
Also, you might want to investigate the controls that come with Widbey beta
(a new winform and webform control). They will make this sort of integration
easier.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Leneise44" <Leneise44@.discussions.microsoft.com> wrote in message
news:15A3BF25-1B83-498F-AE11-CC647E3FF058@.microsoft.com...
> I'm trying to deploy reporting services in an architecture that has an IIS
> server outside of the firewall, a middle tier server running web services
and
> a backend sql server. I understand I need to have the reporting services
on
> my sql server and I also understand I need to have the reporting client
(iis
> portion) installed somewhere.
> How do I do this and keep my 3 tier architecture. I cannot install
software
> on the IIS server that talks directly to my sql server (2 tier).
> I am not using the portal to view reports. I'm rendering the reports by
> creating a hyperlink to the rdl files. Do I use virtual folders mapped to
the
> middle tier? Will the report clients get installed on both boxes? Front
only?|||Perhaps I can help with a few general statements. First, you can absolutely
deploy on 3 servers if that is what you want. Doing so requires that you do
some programming to embed reports on your web page.
Next, Reporting Services is implemented with web services, not straight
DLL's. You have to have IIS installed on the server that renders the
reports. Having said that, you can put RS on the SQL Server box or on a
separate server. Also, you can either let users access the server that has
the rendering web services, or you can hide this server from users.
Note that the Reporting Services databases need to be in SQL Server, but
your reports can access data from a different SQL Server, or any other
source. I will omit any further details about this since this thread seems
to be about business logic on a separate server.
Putting this together, the simplest 3-server implementation involves a
public web server with IIS, a middle tier server with IIS running the RS web
services, and a database server with both the Reporting Services databases
and the report data.
As I said in the beginning, this public web site needs programming to either
embed web pages served up from the middle tier using URL access, or to embed
raw HTML, PDF, JPEG, etc. data from the web service. As Bruse said, the 2005
version will ship new controls that will make this embedding process a lot
easier.
Hope this helps,
Ted
"Leneise44" wrote:
> I'm trying to deploy reporting services in an architecture that has an IIS
> server outside of the firewall, a middle tier server running web services and
> a backend sql server. I understand I need to have the reporting services on
> my sql server and I also understand I need to have the reporting client (iis
> portion) installed somewhere.
> How do I do this and keep my 3 tier architecture. I cannot install software
> on the IIS server that talks directly to my sql server (2 tier).
> I am not using the portal to view reports. I'm rendering the reports by
> creating a hyperlink to the rdl files. Do I use virtual folders mapped to the
> middle tier? Will the report clients get installed on both boxes? Front only?|||Having a WebService as Datasources may help you to have the 3-tiers
WebServices Data Processing Extension
http://www.rdlcomponents.com/DTE/default.aspx
Thanks
Jerry
"Ted K" wrote:
> Perhaps I can help with a few general statements. First, you can absolutely
> deploy on 3 servers if that is what you want. Doing so requires that you do
> some programming to embed reports on your web page.
> Next, Reporting Services is implemented with web services, not straight
> DLL's. You have to have IIS installed on the server that renders the
> reports. Having said that, you can put RS on the SQL Server box or on a
> separate server. Also, you can either let users access the server that has
> the rendering web services, or you can hide this server from users.
> Note that the Reporting Services databases need to be in SQL Server, but
> your reports can access data from a different SQL Server, or any other
> source. I will omit any further details about this since this thread seems
> to be about business logic on a separate server.
> Putting this together, the simplest 3-server implementation involves a
> public web server with IIS, a middle tier server with IIS running the RS web
> services, and a database server with both the Reporting Services databases
> and the report data.
> As I said in the beginning, this public web site needs programming to either
> embed web pages served up from the middle tier using URL access, or to embed
> raw HTML, PDF, JPEG, etc. data from the web service. As Bruse said, the 2005
> version will ship new controls that will make this embedding process a lot
> easier.
> Hope this helps,
> Ted
>
> "Leneise44" wrote:
> > I'm trying to deploy reporting services in an architecture that has an IIS
> > server outside of the firewall, a middle tier server running web services and
> > a backend sql server. I understand I need to have the reporting services on
> > my sql server and I also understand I need to have the reporting client (iis
> > portion) installed somewhere.
> >
> > How do I do this and keep my 3 tier architecture. I cannot install software
> > on the IIS server that talks directly to my sql server (2 tier).
> >
> > I am not using the portal to view reports. I'm rendering the reports by
> > creating a hyperlink to the rdl files. Do I use virtual folders mapped to the
> > middle tier? Will the report clients get installed on both boxes? Front only?
Showing posts with label 3-tier. Show all posts
Showing posts with label 3-tier. 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)