Interwoven, Inc.

1195 Fremont Ave., Ste. 2000

Sunnyvale, CA 94087

Tel: 408-774-2000

Fax: 408-530-2002

www.interwoven.com

TeamSite Integration Series

IBM WebSphere and WebSphereStudio with Interwoven TeamSiteVersion 1.0

This white paper discusses the strategic benefits and high-levelintegration scenario in coupling IBM WebSphere Application Serverand WebSphere Studio with Interwoven TeamSite. TeamSite may beeasily integrated with the WebSphere server to provide a completeenvironment for Web asset management, including application codeand content authoring, testing and deployment. WebSphere Studiomay also be used in conjunction with TeamSite as the end-user toolfor Web site design and Java development.

IBM WebSphere and WebSphere Studio with TeamSite 1

I. Introduction

Interwoven provides a complete Web Content Management (WCM) and Enterprise Web Production(EWP) solution for mission-critical Web sites. Interwoven TeamSite can facilitate the contentmanagement, workflow, and application development of large Web operations built using IBMWebSphere Studio and delivered via IBM WebSphere Application Server.

TeamSite is positioned to enable the application development team, including code developers, pagedesigners and graphic artists, to design, build, test, manage and deploy WebSphere applications. Inaddition, TeamSite provides the environment for the extended Web team, including content contributorsand business professionals, to collaborate to produce large, complex Web sites. The TeamSiteinfrastructure allows the Web development team to build and deploy a WebSphere-served Web site faster,with higher quality and with complete change management. It then becomes the foundation to maintainand further extend the site over time.

Interwoven TeamSite provides the following high-level benefits for the creation and production of Web-based solutions developed using IBM WebSphere Studio and served by the WebSphere ApplicationServer:

• Content Management, Site Staging, and Parallel DevelopmentInterwoven TeamSite provides advanced content versioning, staging, testing, and deployment withoutforcing users to change the way they work with WebSphere Studio. TeamSite enables each Webdeveloper to work simultaneously yet independently to build and test different versions of aWebSphere application. TeamSite’s site staging and parallel branching capabilities enable users tocreate a higher quality WebSphere site that may be updated, revised, and redesigned frequently toimprove site functionality and drive more Web business.

• Project Management, Project Workflow, and Project QAInterwoven TeamSite enables users to track the development efforts of any number of developmentprojects. TeamSite’s audit trails, comparisons, visual differencing, and the Global Report Centerallow project managers to track project development and status to improve communication andcoordination, ensuring that the project deliverables are correct and on schedule. The sophisticatedworkflow capabilities provide a method for ensuring the completion of the WebSphere developmentprocess across the entire Web team.

• Seamless Roll-out and Deployment of ContentWebSphere applications that have been developed and tested and are ready for production can beeasily, securely, and transactionally deployed to one or multiple production servers. This may includethe synchronous deployment of both file-system assets and database content. Also, in the unfortunateevent that errors are detected in the production environment, TeamSite can quickly roll-back the Website to any previous error-free version.

II. WebSphere Application Server Integration with TeamSite

TeamSite supports IBM WebSphere Application Server (Standard, Advanced and Enterprise Editions) bymanaging the following content as it is developed and tested within the TeamSite environment:

IBM WebSphere and WebSphere Studio with TeamSite 2

• Application code (e.g., servlets, JavaBeans, EJBs) and scripts (e.g., Java Server Pages, HTML withembedded JavaScript) created by a Web application developer

• HTML/DHTML content created by a Web publisher or content contributor• Media assets created by a graphics artist or other media professional• Meta-data content created by Web publishers, content contributors and business professionals

Interwoven TeamSite will manage and version the WebSphere application code, template, HTML contentand media file-system assets, along with all other related content and assets. Meta-data may be stored,versioned and managed in TeamSite and then used to populate a relational database, such as DB2.TeamSite can then deploy all of this content, including meta-data stored in the database, to one or moreproduction servers. TeamSite also integrates with external data repositories, such as IBM Digital Library,as well as any user’s preferred content editing tools, for example, Adobe Photoshop or MacromediaDreamweaver.

Figure 1 depicts the content and assets utilized by IBM WebSphere Application Server and managed byInterwoven TeamSite. TeamSite manages all the file-system content types noted above, as well as legacyapplications and code to support back-end systems.

Content Layer

Content andapplication logicthat defines thesite

Navigation Layer

Users are presentedwith content which isdetermined by theapplication logic

Welcome toour site!

Users

Back-end/LegacyAssets

Meta-dataDatabase

files

Web Assets

files

ApplicationCode/Scripts

files

• JavaBeans,EJBs, servlets

• JSPs, forms,etc.

• HTML/DHTML• Multimedia assets• Meta-data attributes

• Database access• CICS interface• Legacy apps.

Versioning, rollback

Parallel development

In-context QA

Staging & Deployment

Workflow

Figure 1

IBM WebSphere and WebSphere Studio with TeamSite 3

III. WebSphere Application Server Integration Technical Considerations

By default, TeamSite can manage all of the Web assets utilized and served by a WebSphere ApplicationServer. These assets are accessed by individual users within their TeamSite workareas. The workareaprojects a virtual view of all the Web content. Users (e.g., business professionals, content contributors,developers, graphic artists) can simply configure their editing and authoring tool of choice, includingWebSphere Studio (see below), to point into their specific workarea. In this manner a user may createand edit content as if he or she is working in a typical file-system hierarchy.

Applications developed in TeamSite workareas may be built or compiled as necessary and run fromwithin the workarea for testing and QA. This includes applications that are served by the WebSphereApplication Server, which may utilize combinations of servlets, Java Server Pages, JavaBeans andEnterprise JavaBeans. To enable running and testing a WebSphere application within a TeamSiteworkarea, WebSphere must be configured to access the content and code directly from the workarea.This is called virtualization.

Virtualizing a WebSphere Application Server enables individual workareas to run independent sessions,and involves creating independent HTTP Web server (e.g., Netscape Enterprise Server, Apache, IIS)virtual hosts or servers. Each host, running on a separate port, contains virtual directories or aliases thatpoint to the appropriate directories necessary for the WebSphere application (e.g., servlets). TeamSiteproxy remaps are then configured for each user’s workarea so that running the WebSphere applicationfrom within the workarea results in the designated virtual host being accessed through the designated port,which directs WebSphere to access the appropriate workarea directories.

This virtualization process may also be accomplished by running multiple WebSphere sessions on onemachine and configuring each session to independently access the appropriate workarea or Staging Area.The capability for starting multiple, simultaneous WebSphere sessions is planned in a future release ofWebSphere Application Server. A TeamSite mechanism to automate the assignment and configuration ofa WebSphere server session for a specified workarea is under development.

Virtualization of all other non-WebSphere-specific directories is handled in the normal way via theTeamSite proxy.

IV. WebSphere Studio Integration with TeamSite

Interwoven TeamSite supports the IBM WebSphere Studio development tools by managing the Web sitecontent produced by Studio. WebSphere Studio manages the application development process and theapplications themselves via Wizards, link management features, visual authoring, etc. WebSphere Studiomay be started in TeamSite, as with any authoring or development tool, by selecting the Edit operation onthe appropriate file type (.WAO project file). The code developer, page designer or graphics artist maythen utilize the appropriate tools within WebSphere Studio, such as PageDesigner or WebArt Designer, tobuild the application, including the creation of JSP files, HTML files, etc. Studio’s link managementfeatures are also operable under TeamSite.

A WebSphere application built using WebSphere Studio within the TeamSite environment can bedeveloped and tested in an individual TeamSite workarea, independently from other projects. The filescreated with Studio are versioned by TeamSite, and may be reverted to any previous version if desired.Application files, including Java class files and JavaBeans, may then be submitted to the Staging Area for

IBM WebSphere and WebSphere Studio with TeamSite 4

inclusion with Web content from other workareas and for final integration testing. InterwovenOpenDeploy can then be used to replicate the appropriate assets from the development system toproduction. TeamSite’s advanced workflow can be used throughout these operations to manage theprocess and to provide control and approval at each step as necessary.

Figure 2 depicts the high-level flow of content and applications through TeamSite, starting withdevelopers utilizing IBM WebSphere Studio (or their choice of authoring tool) to create application codeand Web assets in their individual workareas. In addition, content contributors may use TeamSiteTemplating to enter meta-data and content, which is versioned within TeamSite and may be written to arelational database such as DB2 or to an XML file. The final applications and related assets are thenreplicated to production via OpenDeploy. This entire process may be managed by TeamSite workflow.

V. WebSphere Studio Integration Technical Considerations

To enable in-context WebSphere Studio preview and debugging within TeamSite, a WebSphereApplication Server needs to be configured for a specific workarea as noted above. This will allow theWebSphere server to access the code (e.g., servlets, JSPs, EJBs) and assets (e.g., HTML, images) createdby Studio within the workarea. The following configuration parameters can then be set for optimumWebSphere Studio operation within TeamSite:

TeamSiteTemplating

Figure 2

DevelopmentIBM DB2 DB

WorkareasStaging

AreaEditions

InterwovenOpenDeploy

Workflow Process

ProductionIBM DB2 DB

IBMWebSphere

Servers

IBMNet.Commerce

Servers

Web Operations

E-mailnotify

approvers

IBM WebSphereStudio

WebArt Designer

GraphicArtists

Non-TechnicalContent

Contributors

WebSphereStudio

CodeDevelopers

WebSphere StudioPageDesigner

PageDevelopers

InterwovenTeamSite

IBM WebSphere and WebSphere Studio with TeamSite 5

• Configure Studio for local publish (as opposed to ftp publish) so that the servlets are placed in theappropriate TeamSite managed directory for the WebSphere Application Server

• Configure the Studio temporary checkout directory outside of the TeamSite managed directories• Use the Studio publish operation to publish the final application from Studio into an appropriate

TeamSite directory (The Studio publish step is the equivalent of generating the application.)• Studio autopublish is recommended, but not required• If using repositories outside of the file system (e.g., VisualAge for Java, Team Connection) then

configure those repositories as usual; the repository assets (for example, the Java source and classfiles) won’t be stored in TeamSite but the assets required for application execution will be publishedfrom Studio into the TeamSite managed directories in the same way that Studio publishes thesekinds of assets when working with a standard file system publishing target

• Use the TeamSite autoprivate feature to prevent temporary project files from being submitted to theStaging Area; the autoprivate feature can be configured to prevent any file type (for example a .tmpfile) from being submitted

Note that Studio project files (.WAO) cannot be merged with the Merge Tool; therefore applicationscannot span TeamSite workareas. If multiple users wish to work on the same project, TeamSite filelocking should be set to edit locking. Projects should be submitted and a “Get Latest” performed toupdate the other workarea before editing with Studio.

Also, all assets that are part of the Studio application must be checked in and out for editing through theStudio workbench. This allows Studio to manage the relationships between the assets within the Studioapplication. Therefore, if a user wants to edit an HTML file that is part of a Studio application, the usershould not invoke the HTML editor from TeamSite directly, but rather should invoke Studio and theninvoke the HTML editor from within the Studio workbench.

VI. Conclusion

Interwoven TeamSite and OpenDeploy provide the ideal platform for developing, testing and deployingWebSphere applications. TeamSite provides an enterprise-scale solution for supporting an increasednumber of developers, designers and content contributors with an increased number of assets that makeup the site. TeamSite provides content management for all Web assets created by WebSphere Studio, aswell as any additional Web code or content authoring tool. TeamSite workflow can then manage andtrack the development and approval process to ensure the highest quality production application.