|
dCS Product Overview
| |||
 |
 |
 |
 |
|
|
||||||||
Chapter 1
Overview
Customers use divine Content Server (dCS) in a variety of ways. Many customers use dCS to build, manage, and deliver complex web sites. Large corporations often use dCS to generate a large set of web sites, sharing the same data across multiple web sites. Some use dCS as an enterprise content management (ECM) system, helping to author, collect, classify, and control data. Other corporations go beyond web sites, using dCS to deliver a range of output material, including Quark or PDF files.
Whatever the use, dCS is a practical, professional J2EE-based platform.
Figure 1: Use dCS to develop web applications, manage content, and deliver content.
This book is for a technical person--an engineer, an architect, or a CTO--who is either evaluating content management systems or who is about to start implementing a project with dCS. This book provides an overview of dCS and its components. As you implement and use the product, you can refer to other dCS manuals and the online help for more details.
Develop Web Applications
To manage a small static web site, you might create a few HTML pages. To create some dynamic pages for a small web site, you could write some JavaScript or a few CGI programs. As your web site grows, however, you need something more powerful.
You use dCS to create one or more large web sites, such as financial service web sites or product catalogs. Trying to develop one of these large web sites without dCS is like trying to power a cruiseship with a pair of oars.
Figure 2: Use dCS to build web applications.
J2EE Support
All products in the dCS product family conform to the JavaTM 2 Platform, Enterprise Edition (J2EE) standard. J2EE is an industry standard for developing scalable, fault-tolerant, high-performance, multi-tier, enterprise web applications.
dCS works in combination with other J2EE components, including J2EE application servers. In addition, many vendors create J2EE-based products, which dramatically simplifies integration with dCS.
J2EE provides a programming platform to create commercial web applications. The components of this platform include the following:
- A Java toolkit
- Various languages, including XML and JSP
- The infrastructure for creating and running servlets
- A well-defined connection between web applications and DBMS
J2EE provides an excellent platform, but its accompanying toolkits are insufficient for programmers who develop large web sites. To support such programmers, dCS provides extensive additional toolkits. These toolkits are useful for developers who want to do the following:
An element is a file that defines the logic for a portion of a dCS site. Most dCS sites contain hundreds of elements, each defining a small piece of the site. You can code elements in pure HTML, XML, or JSP.
Code Elements in JSP
JSP is an important part of the J2EE standard. Elements coded with JSP can contain a combination of HTML, Java, and JSP tags. The HTML defines the layout of a web page and the Java and JSP tags can populate the content or execute business logic. dCS provides a JSP tag library to simplify coding.
Many web designers are more comfortable with HTML than with Java. In such instances, Content Server lets you separate the HTML and Java parts of JSP. Thus, web designers can write the HTML and let programmers write the Java.
Figure 3: A JSP element can contain a mixture of HTML, Java code, and JSP tags.
Code Elements in XML
HTML is rather limited. With HTML alone, you cannot call databases, evaluate expressions, or create loops. Although you can extend HTML through JavaScript, HTML by itself is a text markup language, not a programming language.
XML overcomes many of the shortcomings of HTML. Because XML is a subset of HTML, the code looks very much like HTML code. And that's why you can still use all the familiar
<TABLE>,<LI>, and<H2>tags in your XML code. In addition, the XML toolkit in dCS lets you create and evaluate variables, access databases, check a user's security credentials, and lots more.dCS provides an extensive XML tag set.
Content Server contains an XML parser that processes XML elements and converts all results to HTML. So, even though you code in XML, browsers still receive HTML.
Figure 4: An XML parser converts XML to HTML.
Extend XML with Java
XML is a big step up from HTML, but XML is still somewhat limited. You can use XML tags to gather and display data from a database, but you cannot use Content Server XML tags to perform extensive analysis on the gathered data. For example, you could use XML tags to gather salary data from a database but XML tags could not determine the median salary.
You can use Content Server's Java classes to extend XML. In other words, you can write Java code to provide business logic that is not found in Content Server's XML tags. Extending XML through Java provides a simple division of labor. Designers can use XML and leave the business logic to Java programmers.
You can call Content Server Java code in either of two ways:
- You can call Java code from a Content Server XML tag named
<CALLJAVA>.- You can define custom XML tags implemented by your Java code.
The latter method--defining custom XML tags--means that you can extend the set of XML tags that come with Content Server. In other words, you can create your own XML tags. Furthermore, you can pass variables or data gathered from previous XML tags as input parameters to the Java code. For example, you can make a custom tag named
<mult>that calculates the product of two input integers.Figure 5: You can use Java to create customized XML tags.
Code with ASP
dCS provides a COM interface. Through this interface, web site developers can access dCS resources from an Active Server Pages (ASP) program.
Manage Content
dCS is more than just a way to generate a dynamic web site. It is also a platform that organizations can use to acquire, control, and deliver content. With Content Server, you can control the flow of content through your organization and then outside your organization.
Figure 6: Use dCS to manage the flow of content.
With dCS, you can work with digital content by using the same processes that companies use to work with more traditional media. For example, consider a traditional newspaper company. In this company, journalists create articles and then send them to editors for review. The editors can send the article back to a journalist for revisions. Ultimately, the editor will approve the article and send it off to a publisher for publication. With dCS, you can control the article's flow through the organization, allowing appropriate users to control the article's content at the appropriate stage. In this way, you can ensure that content does not get published until it has been approved by the appropriate person or people. In addition, dCS tracks this workflow and alerts the appropriate users of pending work.
In dCS, your organization creates and manipulates practical, manageable chunks of content called assets. For example, a press release is a kind of asset. dCS stores information about the press release such as who wrote it, when it was written, what it is about, and of course, the text for the press release itself. The asset is the discrete unit of content manipulation in the dCS world, the unit that passes through workflows and ultimately gets published.
With dCS, you can publish assets when you want to and as often as necessary. In fact, if you are managing multiple sites, you can easily publish the same asset to different sites.
Deliver Content
In addition to helping you develop web applications and manage content, dCS can help you deliver that content as well--by providing the following capabilities:
- Separate content from format
- Personalize content
- Improve delivery performance through caching
- Share data among multiple web sites
Figure 7: Use dCS to deliver content.
Separate Content from Format
One of the tenets of good web design is to separate content from format. dCS provides an excellent way to do just that. Consider an online newspaper. Using dCS, web designers lay out the format for each page, describing where the weather map should appear, where the horoscope should go, and so on. The content consists of the weather maps, horoscopes, and so on. When the content is published, dCS renders the appropriate content on to the specified format. As
Figure 8 illustrates, the format rarely changes, but the content typically changes frequently.Separating content from format lets people concentrate on their strenghts. Thus, web designers can focus on designing formats and journalists can focus on writing content.
Figure 8: From Sunday to Monday, the content changes but the format does not.
Personalize Content
By using dCS as your delivery system, you can provide personalized web pages. Each visitor to a site could theoretically see a different web page. The information could cater to that person's demographics or interests. Furthermore, dCS can provide an interactive experience, allowing customer input to influence future visits.
Figure 9: Even when viewed simulatenously, Rachel's content (left) differs from Jenny's (right).
Improve Performance
In
Figure 8 andFigure 9 , you saw each newspaper page divided into approximately five discrete sections. We refer to each section as a pagelet.dCS can separately cache each pagelet. Caching improves performance, often dramatically. The web site developer decides which pagelets can be cached and the site administrator decides how long each pagelet can be cached. For example, the cache schedule for the Gloopy Times pagelets might be something like the following:
- The banner is cached indefinitely.
- The headlines are cached for an hour.
- The weather forecast is cached for six hours.
- The weather map is cached for a day.
- The highly-personalized section with the reader's name doesn't get cached at all.
When a visitor requests a page, dCS constructs only those pagelets that are not cached. Then, dCS builds the complete page out of the newly constructed pagelets and the cached pagelets. On many complex sites, well over 90% of the page can be cached, leading to vastly superior performance over sites that have to reconstruct the entire page each time a visitor requests it.
Pagelets can be cached on the host running Content Server or on remote hosts running CS-Satellite. (See
"Cache Pages Remotely" on page 28 for more details.Share Data Among Multiple Web Sites
With dCS, the same piece of data can be delivered to multiple web sites. For example, suppose a company publishes not only the Gloopy Times but also the Gloopy Herald. The two web sites could have completely different formats but could share some subset of data from a common repository of data. For example, both web sites could share the same weather map.
Hardware Environments
Because dCS lets you develop, manage, and deliver content, organizations typically provide three distinct hardware environments:
- development environment -- where web site developers and programmers design and code the site. This is typically a Windows or small UNIX system.
- management environment -- where writers, editors, reviewers, graphic artists, and others develop content and manage its flow. This environment tracks changes to revisions of content. You can preview pages. When the content is ready for publication, you can publish the pages to the delivery environment.
- delivery environment -- where outsiders can visit your web site to view content.
Some organizations also provide a testing environment to evaluate performance and other features before moving content to the delivery environment.
Each environment consists of a discrete set of hardware, with each environment typically consisting of multiple hosts. dCS relies on a web server, application server, and DBMS, each of which can run on a different host. The application server can be clustered to provide failover and load balancing. dCS runs on the same host(s) as the application server.
Because each dCS site has different requirements, it is difficult to specify a typical hardware configuration. Nevertheless, the following figure shows the hardware for a large, dynamic, delivery environment. Note that many sites use significantly less hardware than the site illustrated here. For example, the system shown contains clustering at every level, though many customers choose to run their systems without clustering:
Figure 10: A typical, high-availability dCS delivery environment
The dCS Product Set
The divine Content Server product set consists of the following products:
Figure 11: The main dCS products
The dCS products are arranged hierarchically, with products built on the foundation of those underneath.
Content Server is the base product--all the other dCS products depend on it. Content Server provides the infrastructure and an extensive programmer's toolkit. It is particularly important for content delivery. CS-Satellite lets you cache pages and images on remote machines. You use CS-Satellite to reduce the load on the Content Server host machine and to deliver pages faster. As your needs increase, use CS-Satellite to scale volume.
CS-Direct runs on top of Content Server, providing a valuable GUI and many content management features, such as workflow controls. This level enables content authors to enter and edit text in a variety of ways, including through Microsoft Word or other simple WYSIWYG text editors.
CS-Direct Advantage runs on top of CS-Direct. It manages all forms of data, including data hierarchies. It also provides a very sophisticated search mechanism. CS-Direct Advantage helps you create and manage a complex product catalog or document repository.
Beginning with dCS 5.0, Content Server, CS-Direct, and CS-Direct Advantage are no longer sold separately. Thus, all dCS 5.0 customers will own all these products.
CS-Engage runs on top of CS-Direct Advantage. Marketers use CS-Engage to create and run promotions on different products. Analysis Connector is a tool that allows you to capture web site events, such as visitor activity and clickstream data, that can provide additional valuable information to CS-Engage.
Underneath dCS
The divine products in divine Content Server are themselves layered on top of the cornerstones of the J2EE environment:
Web servers respond to browser requests by serving HTML pages.
The DBMS stores your web site's content. For example, the DBMS for a financial services company stores information about each user's account and the details of various financial products.
Application servers run servlets. Servlets are server-side web applications, similar in purpose to CGI programs; however, unlike CGI programs, servlets are persistent.
Many dCS sites run application servers on clustered hosts. Clustered application servers provide fault tolerance and a failover mechanism. Content Server makes extensive use of the underlying application server and DBMS.
A JDBC driver provides an efficient connection between servlets and the DBMS.
Because of the reliance on J2EE, the dCS code that you develop generally does not depend on the type of web server, application server, or DBMS at your site. For example, if you switch to a different application server, your dCS code should require few if any modifications.
The list of supported web servers, DBMS, and application servers grows and evolves with each new release of dCS.
Localized User Interface
The dCS version 5 user interface is available in the following languages:
In addition to the user interface, help files and other documentation for content providers are available in all of the preceding languages. Other languages may be available; contact your divine sales representative for details.
Note that one dCS installation can support multiple languages.
Summary
divine dCS is a suite of products to help you develop web applications, manage content, and deliver content. The following chapters detail each of the products in dCS.
|
|
||||||||||||||
