Cofax Overview

Revised December 29, 2000

2

Cofax Development Overview Developed by Philly.com as Web Publishing system Designed from the ground up to serve Knight Ridder’s

needs including multiple publications. Java Component based system, now J2EE compliant Windows NT / SQL Server / Apache Tomcat server Deployed as remote publishing system in June for

Grand Forks Herald– Publishes full newspaper content– Remote administration in St. Paul

Currently being deployed to 23 smallest markets– All administration is consolidated in nine offices

Migration to stable, scalable environment by March 2001– Oracle / Unix / ATG Dynamo – All sites hosted at Infinet

3

Cofax Development Strategy

Cofax 2.0 development within Market Leader Focus on content management – edit, schedule, assemble Integrate with ATG Dynamo Product development around supporting media partners

Migrate functionality to OTS packages at component level Buy time as CMS space evolves

– How will vendors react to application server development?– NSPs could provide outsourced alternative for whole or part– Cofax represents our user requirements– Cofax is paid for and will be deployed across the network by June

Push Cofax as a co-operative effort to create “barrier to exit” for network partners

4

Addressing Concerns about Cofax

A. Why wasn’t the system assembled using only off-the-shelf software?

B. Can we sustain in-house software development? Should we?

C. What makes us confident about the architecture of Cofax?

D. Migration Issues (MS SQL to Oracle,Windows NT/2000 to Solaris)

5

Why did we develop several of the Cofax modules in-house?

They meet our business needs better than any third-party system currently available or known to be under development.

They provide our core business-logic. It is best for us to own this piece and direct its future.

Since Cofax is the part of our digital platform that our site producers and newsroom people interact with, this allows us to provide a layer of abstraction between our people and the rest of our system.

6

Why did we develop several of the Cofax modules in-house?

Having our Cofax as the layer of abstraction between our people and the various components of our digital platform, we are able to swap other “back-end” components without having to change the workflow and processes our staffs are trained in.

This also means we can develop our workflow and processes to meet the requirements of our online and newsroom staffs. Our digital platform serves our staffs and users, not vice-versa.

7

One Set of Simple Tools for Everyone

To Cofax, every human that interacts with it, is a user with a given set of properties.

What differentiates user A user from user B is one or more of these properties (e.g. The permission to write or edit stories in a given section.)

A visitor to the web site may have access to post an article to a public discussion board type section using the same tools an Inquirer sports writer uses to post to the Inquirer Sports section. (The visitor may not have all the all the same options, but the tools are the same.)

8

Our digital platform will incorporate approximately80% off-the-shelf components and 20% of our own development.

Our developmentOff-the-shelf components

from vendors

80%

20%

The Composition of our Digital Platform

9

80% of the superiority of our digital platform comes fromour development which is about 20% of the digital platform.

80%

20%

Edge gained from our development

Edge gained fromoff-the-shelf components

Importance of our development

10

Provides Integration

Our development, the glueware of our digital platform is important because it :

Integrates the different commercial off-the-shelf components and makes them live and work well together.

Synchronizes the different modules and components and makes each one

(and their outputs) compatible and usable across the entire platform. Allows addition, removal, and replacement of components with low-risk of

breaking the system.

Creates an over-all platform to produce the best output for our organization and our affiliates.

11

What off-the-shelf software we are using

– XML Modules from IBM & The Apache Software Foundation

– Text Processing Modules from ORO Inc (Now developed & maintained by the Apache Software Foundation)

– Internetworking modules from ORO Inc (Now developed & maintained by the Apache Software Foundation)

– Relational Database related modules from Ashna, Inc.– JSP (Template Processing) modules from Oracle, The

Apache Software Foundation, GNU Software.

12

We do have licenses to redistribute these modules as a part of Cofax

– The modules we got from IBM, The Apache Software Foundation, ORO Inc, and GNU can be redistribute with Cofax free of charge.

– The Oracle-JSP Template Processor can be used without additional charge with a license to the Oracle database.

– The modules from Ashna, Inc. cost us less than $500 per each server we install Cofax on.

13

Who else is doing custom development?

– Our competition– Others in our industry– Others with similar needs

14

Yahoo! Inc., (http://www.yahoo.com)

A large proportion of the software that powers Yahoo!’s web operations is developed in-house by Yahoo! Programmers.

Source: http://docs.yahoo.com/info/misc/contributors.html(Read the section about their use of Perl, Python, GCC, etc.)

Case #1

15

America Online Inc., (http://www.aol.com/)

The entire web-application-server and majority of the applications that enable AOL’s web operations are developed by AOL Programmers and Contractors.

Source: http://www.aolserver.com/

Case #2

16

Companies like Tribune, Belo, Gannett and others lack the products developed by our programmers and so they are very excited about our development.

If they (other companies) could buy everything off the shelf and implement it a 100% out of the box then they would have done so by now. Their interest in our product makes for their requirement of it.

Our development makes our platform unique andcontributes a lot to its superiority over those madeby others.

Why our development?

17

The Architecture is designed be evolved

One of the premises of the software development methodology we use (it is called XP) is that the product’s architecture itself is improved and grown throughout the development process.

The ability to change our architecture allows us to mold our product to meet tomorrow’s business needs without knowing them today.

This evolution of a useful product is possible due to object-oriented software design along with a software development practice called XP.

Migration Concerns

19

Migration from MS SQL to Oracle

This is a valid concern and a concern to us too. Here is why we believe we will be able to successfully migrate to Oracle.

Migration from MS SQL to Oracle is a common undertaking that most professional services organizations have a lot of experience with. We can get help from them, if needed

20

Migration from MS SQL to Oracle To make the Cofax core modules use Oracle as the data store only

one module (SQLDataStore) will need to be replaced No other module will need any modification. A one-line change in an

XML configuration file will tell the other modules to start using OracleDataStore instead. This is due to Cofax’s plug-and-play framework and published APIs

InfiNet is developing the OracleDataStore module for Cofax This is also an example of how Cofax’s open architecture allows third-

parties to develop modules for Cofax

21

Migration from Windows to Solaris

The Cofax Editor’s Tools are currently deployed using the Microsoft .NET Platform.

They were developed using Microsoft’s Active Server Pages technologies along with their partner ActiveState Corp’s ActivePerl engine.

These technologies work well, but we are committed to the J2EE platform.

Work is in progress to convert these tools to the J2EE platform and make them a part of the Cofax core modules …

22

Migration from Windows to Solaris

We are confident about this migration from Microsoft’s .NET platform to J2EE because:

The J2EE based tools will be able to use the already written and tested Cofax core modules. (The current tools duplicate this code written for the MS platform.) This will mean less code for us to maintain.

We have plenty of Java expertise in-house, both in Philadelphia and in San Jose. The staff is excited about doing this migration. If need be, we can call upon several outside contractors with J2EE expertise to do this for us. This is possible due to Cofax’s open, plug-and-play architecture and published APIs.

23

Migration from Windows to Solaris

Absolutely no work at all is required to migrate any Cofax core module from Windows to Unix.

All Cofax core modules are pure Java components. All Cofax core modules have been functionally-tested

and stress-tested on both Windows NT/2000 and Solaris Unix since the first month of development.

On our live-production/public sites, all the core modules have been running in parallel on a mix of Windows NT/2000 and Solaris for months.

24

Our choice of J2EE over Microsoft’s .NET

Both are good technologies. Both have a future. Both help in reaching the same goals: Development

of software applications that meet evolving business needs by taking advantage of the Internet, distributed systems and integrating modern technologies with legacy systems. They encourage modular architectures that can adapt to change.

Either choice would have been a good one. We evaluated both. For us, J2EE was a better fit.

We keep up to date on developments on both fronts. We are MSDN members and we serve on the J2EE

standards committees.

25

Our choice of J2EE over Microsoft’s .NET

Cofax is designed for J2EE. However, its various modules that contain the business logic can be fitted in a .NET architecture.

The entire Cofax system can run in the .NET platform with the addition of a few new modules, some “wrapper modules” and some connectors. This has been tested as a proof-of-concept, but not yet made deployment-ready.

Certain individual Java modules of Cofax have already been used in other .NET based applications specific to the Philly.com web site.