Deployment options - Indy???
If I have an application which is it's own web server (using the Indy
components) - such as applications built using ESP from RemObjects
(which mine is), can I imbed a Report Builder Server into that
application???
What I have not is one application/NT service, that exposes a web
interface, a SOAP interface and I would like to add to the the Report
Builder reports interface... possible or no???
Best Regards,
James Crosswell
Software Engineer
Microforge.net Limited
http://www.microforge.net
components) - such as applications built using ESP from RemObjects
(which mine is), can I imbed a Report Builder Server into that
application???
What I have not is one application/NT service, that exposes a web
interface, a SOAP interface and I would like to add to the the Report
Builder reports interface... possible or no???
Best Regards,
James Crosswell
Software Engineer
Microforge.net Limited
http://www.microforge.net
This discussion has been closed.
Comments
This is going to best be answered by downloading the RB Server trial
Edition and spending a few hours working thru the tutorials in the
Server Developers Guide and running the examples.
I have provided an overview of the architecture below. I recommend that
you consider partitioning the application rather than trying to
integrate everything into a single application. I believe this will
provide you with a more flexible, high performance solution.
RB Server Edition provides a multi-tier solution (see diagram below).
report server
|
|----- web tier
| |
| |----- web browsers
| |
| |----- windows thin client
|
|
|----- windows thin client
1. Report Server
Typically runs within the context of a Windows service. The Server
component encapsulates the functionality of a multi-thread socket server
that can process requests to view a catalog of reports and generate
report pages. It uses SOAP to communicate with the the ClientReport and
WebTier components.
The report server can run on the same machine as the web tier or on a
different machine. You can also configure the web tier to manage a farm
of report servers, each running on a separate machine.
We recommend running your report server application within the context
of a Windows Service that we call ReportBuilder Services. This is very
simple and provides automatic restart of the report server, should it
encounter a fatal exception.
2. Web Tier
The WebTier is typically incporporated into a web application. RB Server
includes examples of ISAPI, ASP, and Apache applications, built using
Delphi's web broker. You might also be able to incorporate the WebTier
component into your custom server. Typically all that is required is one
line of code to pass the HTTP request parameters to the web tier and it
will respond by generating appropriate content. We have also developers
a very high performance ISAPI Thread Pool that is optimized specifically
for managing report sessions.
3. Web Browser
Web Browser clients can communicate with the web tier.
4. Thin client applications can communicate either directly with the
report server, or via the webtier.
-----------------------------------------------------------
R B S E R V E R E D I T I O N
-----------------------------------------------------------
Live Demo!
----------
http://www.digital-metaphors.com/RBServerLive
Trial Edition
--------------
http://www.digital-metaphors.com/server/TrialEdition.html
Server Edition Overview
------------------------
The Server Edition makes it easy to create and deploy report
applications to the web. Using basic component configuration you can get
a Windows service-based report server application up and running, a web
application up and running, and have users previewing reports in a web
browser in no time. And you can do it all without having to master
multi-threaded programming, Windows Services, Windows Sockets, Windows
System Tray applications, COM, I/O Completion Ports/Worker Thread Pools,
XML, SOAP Services, ISAPI Thread Pools, XHTML, or JavaScript. Sound
interesting? Then read on...
1. ReportBuilder Services
ReportBuilder Services is a Windows service designed to act as a host to
a report server application. This two-piece architecture isolates a
report server application in its own process, allowing it to be started
and stopped from the service. By default, the service is configured to
start automatically each time the server machine boots. Once the service
is started, it launches the report server application. The service is
also configured to automatically restart the report server application
in the event of a crash.
To install ReportBuilder Services, you simply run the included
RBWinService.exe installation program. The program installs and starts
the Windows service and deploys a server management application,
accessible from both a system tray icon and a Start menu item. You can
then access the management application and point the Windows service to
the location of your report server application.
2. Report Server Component
The Report Server component implements a multi-threaded report server
that can execute reports and deliver report pages to clients. You build
a report server application by dropping a ReportServer component on a
Delphi form, creating data modules which contain ReportVolume components
(explained next) and compiling the application. And that's it; you can
build an entire server application without writing any code. Once the
application is built you can then use ReportBuilder Services to quickly
and easily designate it as the official report server.
The Report Server is implemented using an I/O completion port/worker
thread architecture that optimally manages persistent report sessions to
maximize performance and throughput. The server can generate reports
incrementally (that is, page-by-page) in order to optimize response
time. Pages are cached on the server and on the client to minimize
network traffic. The amount of time that passes before a session expires
(and the cache is cleared) can be controlled via the TimeOut property.
3. Report Volume Components
Report Volume components are used to register a collection of reports
with the server. The server uses a report catalog to build and store the
tree structure which forms as the various reports are registered.
There are several types of report volume components, one for each of the
ways that reports are most commonly deployed. For report templates
stored in file directories or database tables, there is the
ReportTemplateVolume. For reports stored in the Explorer database
structure (i.e. RB end-user reports), there is the
ReportExplorerVolume. For report archives stored in file directories or
database tables, there is the ReportArchiveVolume. For reports stored
on a Delphi form, there is the "behind-the-scenes" report volume
object. The bottom-line: wherever or however your reports are deployed,
there is a simple way to register them with the server, usually without
writing a single-line of code.
Report volumes are also dynamic; as you add reports to a designated file
directory or database storage medium, the report server will
automatically add or remove those reports from the catalog. Yes, this
does mean that you can deploy reports to the server without bringing the
server down.
4. Windows Rich Client Components
With one ClientReportExplorer, one ClientReport, and one line of code,
you can build a full-featured Delphi reporting application which
provides access to reports on a remote server. The ClientReportExplorer
uses a Windows Explorer style interface to display a folder tree
structure of available reports. The ClientReport makes it easy to
preview and print. When previewing a report that requires search
criteria, the AutoSearch dialog is automatically displayed and any
search values entered are returned to the server. The report is then
generated and pages are returned.
5. WebTier Component
When compiled as part of a web application, the web tier acts as a
middle tier, providing access to a report server application from a web
browser. A user may select reports from a folder tree structure, enter
search criteria when applicable and preview report pages from the web
browser. All of these capabilities are made possible via a zero-client
application (100% JavaScript/XHTML) generated by the web tier. The
zero-client is compatible with Netscape 4, Netscape 6, and Internet
Explorer (5 and 6.)
Designed to integrate seamlessly with Delphi's various web technologies,
the web tier requires only a single line of code to compile successfully
as part of an ISAPI DLL or Apache Shared Module. ASP is also a snap, as
a single COM interface (easily generated with the help of Delphi's
ActiveX support) is all that is needed to deploy the web tier as part of
an Active Server Page.
The web tier implements a sophisticated concept of "session", grouping
all of the communications received from a single web browser under a
single session object. In order to optimize performance, both the state
of the session, and any report output generated for the session are
cached. For example, assume a user previews report A, then report B,
then returns again to report A. The web tier would manage all of this
activity as a single session, and whenever possible, would return pages
from the session cache, instead of re-requesting them from the report
server application. The amount of caching which occurs, the TimeOut for
a session and the frequency with which garbage collection is performed
on expired sessions are just a few of the configuration options
available on the web tier.
Implemented as a set of Delphi classes, the WebTier consists primarily
of objects which descend from TrsWebContentProvider. Web content
providers communicate with the report server application, converting the
response from SOAP/XML to native Delphi objects to XHTML/JavaScript,
suitable for consumption by a web browser. The content providers
included in the Server Edition make it easy to provide a complete,
robust, and professional web reporting solution right out of the box.
You can customize the HTML created by the web tier by creating your own
content provider descendants.
6. RB ISAPI Thread Pool
The Server Edition includes a custom ISAPI thread pool, implemented
using an I/O completion port/worker thread architecture designed to
optimally manage incoming requests. The thread pool queues requests
based on session, and can eliminate redundant requests. This greatly
improves both throughput and performance, as the web tier passes only
relevant requests through to the report server application.
7. Server Farm
The web tier can be configured to utilize any number of report servers
to maximize scalability. This allows the web tier to scale gracefully as
a greater number of users access reports. There are two load balancing
options provided: Round Robin and Minimum Load. Round Robin simply
steps through a list of servers, each time returning the next server in
the list. Minimum Load checks the CPU usage of each server (based on a
sixty second moving average), and returns the server with the minimum
usage.
8. Documentation, Help & Examples
The Server Edition Developer's Guide is provided in PDF format. The
concepts behind the web server are covered, along with numerous
step-by-step tutorials that guide you through everything from creating a
report server application to deploying the web tier with a server farm.
The online help is a reference for all of the components and major
classes which make up the product. The help is integrated with the
Delphi help and is accessible via the help menu or the F1 key. Numerous
examples of report server applications, web applications and client
applications are also provided.
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
like you, I came to the conclusion that I'd be better off going with a
partitioned solution...
So, I spent all of last night converting my nt service to an ISAPI
application and finally got everything going... so amped and primed to
get my teeth stuck into the Report Builder Server stuff.
Cheers. Looks like a cool technology (I'm already familiar with Report
Builder Pro).
Best Regards,
James Crosswell
Software Engineer
Microforge.net Limited
http://www.microforge.net