WO2000043920A1 - Method and apparatus regarding an extranet - Google Patents

Abstract

In an extranet (10) including a core (12) in which data is stored, a first face (14) communicates with the core (12) to dynamically request and organize data. A second face (18) communicates with the core (12) to obtain some but not all data which can be obtained through the first face (14). The extranet (10) includes first and second access mechanisms (16, 20) which access and connect with respective faces (14, 18). A control mechanism (38) organizes data in the core and identifies data as being relevant for the first and second face (14, 18).

Description

METHOD AND APPARATUS REGARDING AN EXTRANET

FIELD OF THE INVENTION

The present invention is related to a extranet . More specifically, the present invention is related to a personal extranet having a core, a first face which dynamically communicates with the core, and at least a second face which dynamically communicates with the core but which does not access all the same data in the core the first face accesses in the core .

BACKGROUND OF THE INVENTION

The short history of the World Wide Web may be viewed as an ongoing attempt to answer two questions: "How do I draw people to my website?" and "What kind of information will they get once they arrive?" The goal has been to develop interactive formats that mine the Web's commercial, informational, and/or public relations potential. However, even with the vast sums that have already been spent, most of today's Web sites, the much heralded interactive contact point between an organization and its client base, remain little more than an on-line version of a company tour. In fact, with the development of intelligent agents, and push technologies, the battle has been lost, as the transfer of information is now becoming dependent upon the end-user instructions to its agent to go out and find what is desired to receive. The free-standing website, waiting to be visited, has become a passive bystander in the process of information transfer.

Concurrently, corporate America, having early on seen these limitations of their own websites, has retrenched and redirected its resources to embrace the highly efficient administrative Internet tools of the Intranet. In so doing, they have discovered a highly effective means of communicating with their entire corporate environment, mainly because they can control the access and dissemination of information that they wish to communicate to all parts of their enterprise.

From this redirected activity evolved the concept of an Extranet: a private network that uses the Internet and the public telecommunication system to securely share part of a business ' s information or operations wi th mobile workers, suppliers, vendors, partners, customers, or other businesses, thus creating an extended virtual business communi ty over the internet . An extranet can be viewed as part of a company that is extended to users outside the company.

The present invention that reverses the original Internet and latter Extranet paradigm of "build me a website and the people will come", to a system that utilizes the latest Internet tools to transmit the essential elements and functional processes of an actual website directly to those customer/clients and third party individuals or organizations (Constituents) who agree (or are required) to receive it. This personal website contains the information that the Constituent -- whoever the Constituent is and whatever role that Constituent plays -- either should have or would like to have. The personal website also presents the information in a format that is appropriate for that Constituent. By approaching the extranet from the perspective of each individual Constituent, the extranet can (a) be centered around each Constituent, (b) connect each Constituent to every other relevant Constituent and (c) organize all of the Constituents that participate in a segment of an individual Constituent's existence.

Once a personalized Website link resides with the

Constituent, the new world of Internet/lntranet-bases administration and publishing tools can be fully exploited by the sponsoring organization. Within this controlled and channeled environment, personally meaningful and timely interaction can ensue within the organization and the organization and its Constituents.

The present invention allows for the creation of

Personal Websites (PWs) , the hub of a personal Extranet system which is designed, hosted and maintained by a sponsoring organization's database and server. These PWs are customized according to a client/customer profile, and matched with the educational/service needs of the individual. The uniquely formatted Personal Website is created for the end user through scripted graphical and informational templates. Their look, feel, and functionality are determined by the type of client, and goals of the sponsoring organization's vision of that client.

The PW offers interactive communication between organizations and those who communicate with them regularly to send and receive customized information. The PW's front end offers the customized information in a manner that is user friendly and compatible with the culture and needs of the end users. It utilizes "push technology" to remind, offer and contextualize information that the initiating organization believes to be of interest to the end user/client .

It expands information transfer to include interested third parties and associated businesses and service providers in an enterprise. With people sending and receiving the right information in a format that is convenient and useful, we hope to improve communications between professionals in our target industries, reduce their cost of communication and content publishing, while increasing the efficiency and effectiveness of one to one marketing and interaction between the institution and its client/customer base.

The present invention allows for the development, management, and deployment of personalized web sites to present information of interest to its users, or information which the sponsoring organization deems important for the user to have. The personalized web site affords the sponsoring organization a powerful and efficient administrative tool to provide organization and communication efficiencies to their customer/client base. In short, the Personal Website (PW) provides a framework which facilitates:

targeted communication (down to an individual) , administration of group information, and ^• an information collection vehicle

about or between individual (or segmented groups) of members of an organization or enterprise.

This allows companies to apply groupware concepts and technologies to better administer their organization and provide better services to their customers. This allows one- to-one marketing and communication to occur utilizing the administrative functions of a typical Intranet environment. SUMMARY OF THE INVENTION

The present invention pertains to an extranet, and preferably a personal extranet. The extranet comprises a core in which data is stored. The extranet comprises a first face which can communicate with the core through which data in the core can be requested and dynamically obtained and organized. The extranet comprises a first access mechanism which accesses the first face and connects with the first face. The extranet comprises a second face which can communicate with the core through which some data in the core can be obtained which can also be obtained through the first face but not all the data can be obtained that can be obtained through the first face. The extranet comprises a second access mechanism which accesses the second face and connects with the second face. The extranet comprises a controller mechanism which organizes data in the core and identifies data as being relevant for the first and second face, prepares the first and second face and is connected to the first and second access mechanisms.

The present invention pertains to a method for using a personal extranet. The method comprises the steps of obtaining the data in a core through a first face accessed by a first access mechanism. Then there is the step of obtaining some data in the core through a second face accessed by a second access mechanism which can also be obtained through the first face but not all the data can be obtained that can be obtained from the first face.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, the preferred embodiment of the invention and preferred methods of practicing the invention are illustrated in which:

Figure 1 is a schematic representation of the system overview.

Figure 2 is a schematic representation of the HTTP Communication Subsystem.

Figure 3 is a schematic representation of the detailed operation of the HTTP Communication Subsystem.

Figure 4 is a schematic representation of a simplified display class nesting.

Figure 5 is a block diagram of how content and system classes give data to display classes.

Figure 6 is a schematic representation of the functional relationship between DIGs, DisplayFactories and Display Classes. Figure 7 is a schematic representation of the relationship between FormElementDisplays, Attributes, and CGI values .

Figure 8 is a block diagram of members of Contentltem.

Figure 9 is a block diagram of major functions of Contentltem.

Figure 10 is a schematic representation of primary functionality of ContentDBRellnterface .

Figure 11 is a block diagram of SourceSafe Projects and Java Packages Relationships.

Figure 12 is a schematic representation of an extranet of the present invention.

DETAILED DESCRIPTION

Referring now to the drawings wherein like reference numerals refer to similar or identical parts throughout the several views, and more specifically to figure 12 thereof, there is shown an extranet 10. The extranet 10 can be a personal extranet The extranet 10 comprises a core 12 in which data is stored. The extranet 10 comprises a first face 14 which can communicate with the core 12 through which data in the core 12 can be requested and dynamically obtained and organized. The extranet 10 comprises a first access mechanism 16 which accesses the first face 14 and connects with the first face 14. The extranet 10 comprises a second face 18 which can communicate with the core 12 through which some data in the core 12 can be obtained which can also be obtained through the first face 14 but not all the data can be obtained that can be obtained through the first face 14. The extranet 10 comprises a second access mechanism 20 which accesses the second face 18 and connects with the second face 18. The extranet 10 comprises a controller mechanism 22 which organizes data in the core 12 and identifies data as being relevant for the first and second face 18, prepares the first and second face and is connected to the first and second access mechanisms.

Preferably, the controller mechanism includes a core controller which organizes data in the core and identifies data as being relevant for the first and second face, and a face controller 22 which prepares the first and second face .

Preferably, the controller mechanism 22 includes a first presentation mechanism 24 which connects to the first face 14 which organizes data for the first face 14 and a second presentation mechanism 26 which connects to the second face 18 which organizes data for the second face 18. The core 12 is preferably comprised of a first portion 28 in which data is stored and a second portion 30 in which data is stored, and the second face 18 can only obtain data from the second portion 30.

Preferably, the first face 14 can obtain data from any portion of the core 12. The core 12 is preferably comprised of a total of N portions 32 , and including a total of N faces 34, and a total of N access mechanisms each of which communicate with a respective face, where N is an integer greater than or equal to 3 , each of the 3 through N faces 34 in communication with a corresponding portion of the core 12 through which some data in the core 12 can be obtained which can also be obtained through the first face 14 but not all the data can be obtained that can be obtained through the first face 14.

Preferably, each of the three through N faces 34 can obtain some data in the core 12 which can also be obtained through the first face 14 and second face 18 but not all the data can be obtained that can be obtained through the first face 14 and second face 18. At least some of the portions of the core 12 preferably can overlap with other portions of the core 12. Preferably, the data can be provided to the first portion 28 of the core 12 through the first face 14. Data can preferably be provided to each portion of the core 12 through the respective corresponding face. Preferably, each access mechanism communicates with its corresponding face through a telecommunication line 36.

Each access mechanism preferably communicates with its corresponding face through a telecommunication line 36 with the Internet. Preferably, the faces in the core 12 are part of a web extranet 38 connected to the Internet. Each face preferably includes a template 40 that has controls which govern what data can be obtained from or provided to the corresponding portion through the corresponding face.

Preferably, the controls of each template 40 can be changed and the corresponding portion of the core 12 can be changed. The first face 14 preferably can change the controls on any template 40 of any other face. Preferably, the second portion 30 can change the template 40 of some of the interfaces. The face preferably has multiple templates 40, with each template 40 of the multiple templates 40 corresponding to an access mechanism.

The present invention pertains to a method for using a personal extranet 10. The method comprises the steps of obtaining the data in a core 12 through a first face 14 accessed by a first access mechanism 16. Then there is the step of obtaining some data in the core 12 through a second face 18 accessed by a second access mechanism 20 which can also be obtained through the first face 14 but not all the data can be obtained that can be obtained from the first face 14.

Preferably, after the first face 14 obtaining data step there is the step of providing data to the core 12 through the first face 14. After the obtaining some data step there is preferably the step of obtaining some data in the core 12 through a third face and wherein the core 12 is comprised of a first portion 28 in which data is stored, a second portion 30 in which data is stored, and a third portion where data is stored, and the second face 18 and the third face can only obtain data from the second portion 30 and third portion, respectively.

Preferably, after the first face 14 obtaining step there is the step of changing through the first face 14 a template 40 having controls which govern how the third face can obtain data from the core 12. The first face 14 obtaining step preferably includes the step of connecting the first access mechanism 16 to the Internet to access the first face 14. For purposes of discussion of the preferred embodiment, the following definitions are applicable.

Dynamically

Dynamically in this context means that the interactions with the extranet 10 happen differently depending on the state of the extranet 10 and its environment. This interaction can take place at any time, which adds a concept of just-in-time or on-the-fly to the meaning of dynamically.

The state of the extranet 10 is dependant on the information that is currently stored in the extranet 10 and the values associated with the various faces 34, presentation mechanisms, templates, controls, access mechanisms, and controller mechanism 22. The environment is driven by not only who visits the extranet 10 at any give instant but what actions they take when interacting with their respective face 34 and the parameters associated with the above extranet 10 architecture components. For example, if the extranet 10 has a bit of information in the extranet 10 which is stored in a given portion 32, then this information may or may not be presented to a given user. In one case, if the extranet 10 determines that the visitor should use face 1 and whose access mechanism usually asks the controller mechanism 22 for bits of information of this type, but the extranet 10 determines that this specific bit of information is not relevant for this visitor, then this instance of a Personal Extranet Site would ultimately not incorporate the bit in questions. On the other hand, if another visitor who also uses face 1 visits the site, and they are subsequently determined to be a match for this bit of information, then the controller mechanism 22 in the extranet 10 would return the bit and have it be included in the site. Finally, if face 1 provides a control which enables the ability to override the core controller's "relevance mechanism" and the first user executes this option, the bit would be presented. Again, the state of the extranet 10 and the user's action determine what is presented and therefore what is experienced by any given user.

A tangible example of this scenario is where the bit of information is an article about programming in Oracle. If a prospective employee visits the site, the extranet 10 would determine that the US Prospect Face should be used. Here, the templates, controls and the access mechanism contains functionality to list articles for a US Prospect's site. The specific template 40 used by the face 34 has controls which lists articles which are the ones most relevant for the visitor. An extra control provides the face 34 with an option to list all articles regardless, of extranet 10 relevance. If an actual prospect, Joe, does not posses any Oracle skills, then the controller mechanism 22 would not provide the specific article about Oracle. Therefore, when the templates and controls ultimately format the HTML for this person's site, the list of articles would not contain the one in question. However, if he chose to hit the "show all" button (control) , then his profile would be ignored and all articles, including the one in question would be presented. Note that if tomorrow Joe updates his profile to include the fact that he did possess Oracle skills, then the next time he visited his personal site, the article would be presented automatically. This latter scenario is the same as another prospect, Fred, who does contain Oracle skills on the first day and immediately sees the article in question.

Note that Personal Extranet Sites are not physically stored in the extranet 10, but rather the instructions are stored (faces, templates, controls, etc.) When these instructions are executed on demand for a visitor, the site is created at that movement, thus the term dynamically is appropriate.

Site

A Personal Extranet Site is the instantiation of a face 34 for a given user at a given point in time. This site is displayed one segment (template 40) at a time. Each presented segment (in one case a Web Page) contains not only content, but navigational (decision tree) information. So, when on a given point of a face 34, the user has control over which point is presented next. In the cube example (6 faces) , the user starts on the surface of the cube and navigates down into the cube of data (extranet 10) through a network of nodes (web pages) which get presented as the user interacts with the extranet 10.

If the cube is centered about a person's life segment (e.g., healthcare), and each face 34 represents an interested party, a personal extranet surrounding that person exists. Different parties (faces) interact with the extranet 10 directly, but also interact with each other through the extranet 10. This is done by either altering data stored in the extranet 10 (placing a lab test in the extranet 10) or by altering another's face 34 (a nurse adding the procedure video to the patient's face 34).

Who Is Controller (WIC)

This is part of the extranet 10 which determines, for any given visitor, which face 34 to use when building their Personal Extranet Site. There is one Who Is Controller for the Personal Extranet Site.

Face 34 A Face 34 is a logical grouping of a set of face parameters, templates, and controls. A face 34 logically describes the role of any given visitor and has implicit in it a navigation tree for the layout and user navigation of the site. This in turn describes the overall look-and-feel of a Personal Extranet Site for any given visitor who would be determined to use this face 34. The actual content ultimately presented in the HTML rendering of the face 34 will be driven not only by what the face 34 (and template 40) structurally can present, but also by the Core Controller assessing what is appropriate for this visitor. Some examples of faces include: US Based Prospective Employee, India Based Prospective Employee, US Based Recruiter, India Based Recruiter, Guest, Sales Person, IBM Client, AT&T Client.

It is important to note that interaction on one face 34 impact not only the content of another face 34, but also the look-and-feel .

■Template 40

A Face 34 is made up of its parameters, templates and controls, which ultimately determine the specific look- and-feel of the Personal Extranet Site. A template 40 is the specific set of controls that are used, at any given moment in time and for any give point of navigation through the face 34, to construct a Personal Extranet Site. A face 34 can contain many different templates which are connected via the face parameters. Additionally, based upon user profile or user action, conditional branching through the face 34 may be possible. The impact of this is that for a given face 34, a user may utilize templates 1, 2 and 3 at this moment, but later utilize 1, 2 and 4 instead.

An example of a template 40 is the actual collection of controls needed to prepare and present the US Based Prospective Employee's Personal Extranet Site. The first page on the face 34 may utilize template #101 which may have some controls needed to prepare a list of articles, the employer's on-line newsletter, message center, calendar, etc.

Note that other faces have the ability to change, among other things, the template 40 used by a face 34. Here, the administrator face 34 may decide to change the above template 40 used from #101 to #102, there by adjusting the other face's look-and-feel .

Control

A control is the building block which builds template 40. Arguably, a template 40 is really a superset of a control as controls can be nested and called recursively. The template 40 in this case is the root control for any give instance .

A template 40 which contains the visitor's name and a list of articles would use two controls (Visitor's Name control and Synopsis list control) . As controls can be nested, the Synopsis list control would also contain controls needed to present an actual article synopsis. The template 40 would parameterize, for example, this control so that the article's graphic, title, and summary would be displayed. Each of these display components are also examples of controls .

Access Mechanism

In an effort to buffer presentation from content, the access mechanism has been introduced. Here, each control separates the display from data collection. For any given face 34, an instance of a control may use a different access mechanism. For example, the face title US Based Prospective Employee may have a control to display their resume. The access mechanism associated with this control only presents a certain set of information. However, the face titled US Based Recruiter would have a resume control which displays a different set of information.

Presentation Mechanism In an effort to buffer presentation from content, the presentation mechanism has been introduced. This mechanism is solely responsible for formatting the content so that it can be delivered to any give user. Here, the format of information would be substantially different if the user is visiting the site by way of a standard web browser versus via a telephone and fax machine. Once the data has been collected by the Access Mechanism, the Presentation Mechanism works with the controls and template 40 to format the information for delivery. In one case, HTML with imbedded links is presented to the user via their browser, where as in another, a fax file with call-back choices (for navigation) are prepared instead.

Extranet 10

This is the storage system for all content. Here, all objects are considered content. Content examples include users, faces, articles, tags (user characteristics) .

Portion 32

Logically, the extranet 10 can be broken into "buckets" of information which are determined to be relevant for any give user. These buckets or portions 32 can overlap.

An example of this is the US Based Prospective Employee's resume. Here, in portion #1, the resume information would contain the Prospective Employee's name but not the interviewer's notes. Thus, when the Prospective Employee visits the site and is determined to use the face titled US Based Prospective Employee, the information seen only contains the name. However, when a US Based Recruiter visits the site, their portion of the extranet 10 contains both the Prospective Employee's name and interview notes. Thus, when their face (US Based Recruiter) is dynamically instantiated, the portion of the extranet 10 returns both bits of information.

Core Controller

The Core Controller is the part of the extranet 10 which organizes data stored in the extranet 10 and who is responsible for determining if information is relevant for any give user. The data organization component is that which allows database portioning listed above. The relevance component is described in the technical section discussing tagging. Conceptually, however, the Core Controller contains a series of data stores which "tag" each database object with either rules for relevance or specific examples of relevance. For example, the implementation of the Core Controller contains a set of tables which contain object references (e.g., the Article used above which contains information relevant to Oracle skills) and those user tags which should see this object (Skill equals Oracle) . When an access mechanism associated with the face 34 connects to the Core Controller, the extranet 10 uses this mechanism to provide the access mechanism with the article in questions if the user does indeed posses Oracle skills.

In addition to this rule mechanism, the Core

Controller contains an explicit list of users who should see a give object. In this case, another set of tables contain objects references and user references. Again, when an access mechanism associated with the face 34 connects to the Core Controller, the extranet 10 provide the article to those people explicitly contained in the list, regardless of whether they posses Oracle skills or not.

Extranet 10

A system built around resumes of employees who are contracted to customers. The system builds a Personal

Extranet around the "employee" which is loosely defined from the initial point of contact with the company through subsequent placements at various clients. The extranet allows access to the Personal Extranet Site from various people ranging from the employee before they are hired

(prospect) , the employee once hired, the recruiter, the sales person, guest of the prospect, and finally various clients.

Each of these access visit the extranet 10 through their respective face 34. Each interaction is unique and distinct, but yet all access the extranet 10 and the various portions as appropriate.

The following is one example of many possible examples how the personal extranet can be used:

Consultant Scenario using Personal Extranet Sites

Overview of Scenario

Prospective Employees (Faces #1 and #2)

A prospect reviewing their ABC Consulting PW

A prospect entering resume information

Recrui ter (Faces #3 and #4)

A recruiter setting up a Personal Website for a Prospect

A recruiter reviewing a prospect ' s Personal Website (i.e., resume) and then activating it for "pushing" to clients

A recruiter publishing an article to a group of prospects

Guest of the Prospective Employee (Face #5)

A guest of the prospective employee viewing a version of prospect's resume A guest printing the resume

A guest viewing information about ABC Consulting

A guest's key-stokes and location being tracked

Sales Person (Face #6)

A sales person seeing their client's selected consultants (both hired and ones for an interview)

^• A sales person updating a client's profile

A sales person sending a message to the client

Clients (Faces #7 and #8)

A client logging into their Personal Website and navigating to a list of "available" (consultants on the bench, consultant 2 weeks out, and prospects) consultants which match their profile and perusing the resulting Consultant Personal Websites .

• A client searching for a specific skillset and as above, peruse through the results

A client selecting some consultants for immediate hire and some others for an interview

A client reading marketing materials pushed from ABC Consulting (based upon their demographics)

A client updating their profile A client reading a message from their sales person

Employee (Face #9)

An employee performing performance reviews

^• An employee updating their resume/on-line profile

An employee interacting with ABC Consulting' s back-office functions such as time tracking, expense tracking, and benefits

- An employee viewing the portion of ABC

Consulting' s Knowledge Base relevant to their current project and/or skills

Face #1 - US Based Prospective Employee

This face contains the templates and controls needed to allow a prospective employee (prospect) from the US to interact with extranet 10 and have both information from the prospect be collected as well as marketing information be presented to the prospect. In this instance, the first template presents a message to all prospect's telling them about the site and sets the expectation of the prospect in interacting with it. Next, the prospect is promoted to choose their current geographic location.

Based upon their location, one of two template are instantiated and displayed, each one differing in which demographic questions are asked based upon whether the prospect is actually in the US or not. Next, another template 40 is instantiated which asked the prospect to enter their skills and education information (resume) . When complete, the Core Controller stores the information in a portion centered about the prospect which include, among others, their Primary Skill.

After the prospect completes this data entry, the face uses one of two templates which are tied to the prospect's Primary Skill. Here, if the prospect had a Primary Skill of a programming language, the template 40 which contained the control for technical marketing information would be used. If not, the control for general marketing information would be used instead. In either case, after interacting with the respective marketing page of the face, the prospect would be prompted to answer some interactive interview questions. Again, based upon answers, the next template 40 used may be different.

It is interesting to note that the actual page layout of the interview questions would be different based upon the profile of the user. For example, a control on the template 40 would be responsible for displaying a graphic. Here, if the prospect was possessed programming skills, then graphic #1 would be used, but if they did not, graphic #2 would be used instead. This interaction would be continue until the prospect had completed an entire interactive interview. When complete, the prospect would be give the instructions for re- connecting with the extranet 10. Now, however, they would connect through another face! The distinction here is that the first face "New US Based Prospective Employee" contains the interactive interview and marketing, but the second face "US Based Prospective Employee" contains the facility to edit only the resume information and does not contain any information from the interactive interview.

In addition to the edit capabilities, this face may also contain marketing information such as reasons to join the company, employee testimonials, or job opportunities. Finally, administrative functionality may also be presented including, scheduling (of interviews) and messaging (to the recruiter who will be accessing the extranet 10 through another face) .

Some examples of the navigation controls on a extranet 10 include:

1. Why should I work for ABC Consulting

This is the opportunity for the recruiter to market

ABC Consulting to the prospective employee. This section would include information about the ABC Consulting facilities, the work environment, the company etc. It is important to show that the information presented here is based upon the prospect. Perhaps we have two screens (e.g., templates) , one for a JAVA programmer in Pittsburgh and another for a COBOL programmer in Singapore. The template 40 would be regional and the skillset would drive the actual content .

2. Contact my Recruiter

Part of the extranet 10 contains a messaging facility - this is really just a class of content which are bits of information which are explicitly relevant to the recipient. Messages bound for the recruiter as well as those bound for the prospect are shown here.

3. Update my Resume

This allows the prospect to update the various sections of their resume.

4. Interactive interview - Pre-qualification, on-line survey, test, etc.

This is the on-line questionnaire used to test the knowledge of the prospect . 5. Joining ABC Consulting - The Logistics

This area contains information used to coordinate the process of relocating to the client sites. This would a of articles that are published to the prospect, which review the process of starting with ABC Consulting.

Face #2 - India Based Prospective Employee

This face is similar to the above except that the exact flow, questions, and marketing messages are different. The extranet 10 is still the same, but as the templates, control and face are not. The Personal Extranet Site which is created for an Indian recruit is substantially different than for a US based recruit.

Face #3 - US Based Recruiter

This face contains the templates and controls needed to allow a recruiter from the US to interact with extranet 10 and have information about prospect be presented so that they can manage the recruiting process . The US Based Recruiter face begins with a list of prospect which are appropriate to that recruiter. Relevance of content (i.e., prospect resumes) is controlled by various rules, including such prospect characteristics as skill, geographic preference, or previous experience.

Once the recruiter visits the site and is presented with the HTML from the face's instantiation, they are presented with a summary list of prospects. From this list, they can view resumes (via assigned templates) as well as enter information into the extranet 10 from off-line conversations with the prospect. Additionally, the recruiter has the availability to change the face of the Prospect by publishing specific marketing content to the recruit, as appropriate .

In addition to having one of the face's templates provide a list of relevant prospects, the one template 40 contains the necessary controls needed to allow the recruiter to perform an ad-hoc search of prospects by various criteria, not limited to those characteristics that the prospect controls (e.g., skills) but also by internal work-flow characteristics such as whether the company has filed a work permit for the new hire.

Finally, part of the face includes reports that summarize activity performed by various participants to the Personal Extranet Site including usage statistics (what interactions various people have with their instantiated faces) as well as data mining reports which assess the state of the extranet 10 and the various portions (e.g., how many prospects are currently stored in the extranet 10) .

Some examples of the navigation controls on the extranet 10 include:

1. Home Page

List of my consultants with their phone numbers (Office, client site, home, pager)

Update my information (i.e, phone number, email address)

2. Validate consultant resume information

Select a Personal Consultant Website (PCW) to review - This screen list the PCW of the consultant's which are assigned to the recruiter. The list of PCWs should be sortable by: name, prospect/employee, available, Not approved. Each row of the table should look something like:

CW

Hanse Primary I Employee Ava&fcfe Approved

Bill Loderman Oracle Θ Bench Θ

Peter Swartz Java O Immediate o Brad Perelman Cobol Θ 4/15 Θ The recruiter should also be able to search (by name) for a specific consultant.

3. Edit a Personal Website

This is the recruiter's view of the PCW. The recruiter should be able to see everything that the consultant sees (with the option to edit the information) plus :

Billable rate - Three different rate tiers Employment status - Prospect or Employee ^• Availability - This is either "Bench, "

"Immediate," or a date (dd/m )

Phone numbers - The contact phone numbers for the consultant (Office, client site, home, pager) ^• Change status - The recruiter can change the status of the fields that are presented on the CPW synopsis list. This includes employment status, availability, and whether the CPW has been approved.

4. Publish articles to subset of consultants

Publish articles to a subset of consultants. The recruiter selecting the tags for which the article is appropriate would accomplish this. Note that a "tag" in this context could also be a consultant.

5. Coordinate interviews

This will allow the interview process (client interview) to be coordinated and monitored by the PWT system. No screens should be developed behind this button.

6. Review Client Activity

Interviewed Consultants - By client, see which consultants have been selected for interviews -

On this page, the sales person can review their client's activity by viewing a list of consultant PWs which have been selected for interviews. This page should be sortable by both client and by date.

Electronically Contracted Consultants - By client, see which consultants have firm start dates - On this page, the sales person can review their client's activity by viewing a list of consultant PWs which have had firm start dates entered. This page should be sortable by both client and by date.

7. Search for Consul tant Status - The recruiter should also be able to search (by name) for a specific consultant. The result table will show, listed by date or by client, the client searches or "recommended consultants" hits that had this consultant appear on the result table.

Face #4 - India Based Recruiter

This face is similar to the above except that the exact work-flow, back-office information, prospects, etc. are different. The extranet 10 is still the same, but as the templates, control and face are not. The Personal Extranet Site which is created for an Indian recruiter is substantially different than for a US Recruiter which reflects the different way business is conducted in different parts of the world.

Face #5 - Guest

If a prospect so chooses, he can enable one of his guests to visit their Personal Extranet Site. The face which they are granted access to is, by design, limited to the only allowing them to view part of the portion surrounding the prospect. The intent is that the prospect effectively has an on-line resume which they may wish to share with others. The guest face contains a template 40 which assembles a sub-set of the prospects resume and presents it . One of the controls, in conjunction with the presentation mechanism, allows the guest to see a version of the resume which is suitable for printing from a browser. In addition, the host of the Personal Extranet Site may include portions of the Personal Extranet Site which markets its services to the guest. Finally, a control is usually included to allow the Guest's location to be tracked (e.g., store their IP address) . This may or may not be supplemented with a "guest book" template 40 which allows the Guest to explicitly enter their information and directly communicate with the host organization.

Face #6 - Sales Person

Some examples of the navigation controls on the extranet 10 include:

1. Home Page

List of my clients

2. Review Client Activity

Login Activi ty:

Detail - Shows a list of dates/times a clients logged into the extranet 10 (selectable/viewable one client at a time) ^• Summary - Shows a list of clients with the # of times they logged into the extranet 10 and the dates/times of their most recent visit. This should be sortable by "most recent visit", "# of time logged in", and "by client . "

Interviewed Consultants - By client, see which consultants have been selected for interviews - On this page, the sales person can review their client's activity by viewing a list of consultant PWs which have been selected for interviews. This page should be sortable by both client ^'and by date. ^• Electronically Contracted Consul tants - By client, see which consultants have firm start dates - On this page, the sales person can review their client's activity by viewing a list of consultant PWs which have had firm start dates entered. This page should be sortable by both client and by date.

Review client searches - On this page, the sales person can review the queries that the client has run. ^• Recommended consul tants Hi ts- The shows the dates and time a client hit the recommended consultant button (once per login) :

Summary - This page shows which clients (and number of times) that each has hit the recommended consultants' button. Detail - For a specific client, this show the date and results (# listed, # start dates, # interview)

Ad-hoc queries Run - The screen lists the queries that the client has initiated plus a summary of the result. For each client, the following information should be presented:

By skill - Lists the queries a client runs by primary skill (if the query contained this skill) .

By hardware - Lists the queries a client runs by hardware (if the query contained this choice of hardware)

By operating system - Lists the queries a client runs by operating system (if the query contained this choice of hardware)

3. Update Your Client's Profile

Update client viewable stuff (e.g., key contacts, skills usually used, etc.) ^• Update ABC Consulting viewable stuff

(Intelligence information, rate structure, etc.)

4. Communicate with Your Client

Publish article to subset of clients

Face #7 - IBM Client Some examples of the navigation controls on the extranet 10 include:

1. Recommended Consultants

This screen shows the list of Personal Consultant

Websites that the extranet 10 feels is appropriate for the client. These are the consultants which ABC Consulting wants to push and is based upon the client profile (the types of skills that they typically use) plus those consultants which ABC Consulting wants to push regardless of a client's profile .

Each entry of the Personal Consultant Websites synopsis list has the person's name, their primary skill, experience level, and billable rate. For each consultant, the client should be able to:

1. Set a firm start date (dd/mm) ,

2. Flag them for an interview, or

3. Remove them from the "potential candidates" list.

Two actions that affect the list are: 1. "Send to ABC Consulting" which commits the list of consultants (those flagged with a firm start date or interview requested) to the extranet 10.

2. "Update list" which refreshes the Potential Candidate List by removing those PCWs which the client flagged as "to be removed"

Two other buttons used for navigation include:

Back to skillset search which takes the user to the search screen where they can run their own ad- hoc query

Cancel which return the user to their home-page

2. Client's view of the consultant's Personal website (i.e., resume)

This screen shows client's view of the Consultant's personal website. In this domain, this is really the consultant ' s resume .

3. Search by skillset

A query should allow them to search by such criteria as: primary skill, other skills, industry experience, experience level, billable rate, language, etc. Once the query is executed, the synopsis list from above should be presented.

4. Update my company' s profile

Allow the client to update certain pieces of information about themselves and the types of skillsets that they normally procure. Portions of the client profile should only be viewed/modified by the ABC Consulting IT, however some information should be editable/viewable by the client

(e.g., key contacts, skills usually used, etc.).

5. News from ABC Consulting

This is a typical synopsis list that lists articles relevant to a client. This "relevance" done the traditional PWT way with the content appearing based upon the "mixing and matching" of the content's tags with a client's profile.

6. Contact my ABC Consulting Salesperson

This invokes a standard Internet e-mail (not a PWT message) .

Face #8 - AT&T Client This face is similar to the above except that the exact flow, questions, and marketing messages are different.

The extranet 10 is still the same, but as the templates, control and face are not . The Personal Extranet Site which is created for this client is different than for a another.

Face #9 - Employee

1. Home Page

Performance reviews Time sheets ^■ Expense reports

Calendar/Schedule ^• ABC Consulting Knowledge Base (e.g., access to the ABC Consulting library of technical information)

The general structure of Extranetics may be divided into the following subsystems:

HTTP Communication Subsystem Session Subsystem Display Subsystem ^• Content Subsystem

Database Subsystem Customization Subsystem

Figure 1 shows the basic relationships between these subsystems and, when they are not part of the same process, the method used for communication between them. The

HTTP server (IIS) is the main entry point. The HTTP

Communication Subsystem is used to transfer data between the HTTP server and the Web Subsystem Server. This server uses the Session Subsystem to re-establish the user's session and the Display Subsystem to construct the web page that must be sent to the user. The content in the web page is derived with the help of the Content Subsystem, which serves as an interface to the Database Subsystem, which is used to maintain the content. A File Server which is accessible from all subsystems is used to maintain file based content. The Customization Subsystem (not shown) is used to customize Extranetics for various sponsors.

Each of these major subsystems will be summarized below.

The HTTP Communication Subsystem serves to isolate the primary Web Subsystem process, the Web Subsystem Server, from the third part HTTP server. It also controls the creation of threads for each URL request.

The Session Subsystem establishes the Session environment and initiates web page retrieval. To do this, it must do the following things:

Extract all information from the URL and put it in a meaningful form.

Validate that the user is logged in properly. Initiate the creation of the desired web page by invoking the proper Display Subsystem methods. The Display Subsystem consists of classes that will generate HTML to be displayed on a browser. The Display

Subsystem itself is broken up into two major subsystem: the

Display Class Subsystem and the Display Instantiation Subsystem.

The Display Class Subsystem consists of a hierarchy of classes. Each class attempts to encapsulate a parameterized HTML template 40. When a Display class's parameters have been fully specified, it may be used to generate HTML text.

The Display Instantiation Subsystem is responsible for creating instances of Display classes and filling in their parameters properly.

The Content Subsystem provides a systematic way to access the database subsystem. It maintains a set of classes that do the following:

Provide high-level functions for database retrieval .

Controls the creation of Java objects and attributes that correspond to database objects and attributes.

Implement a variety of caching and on-demand retrieval mechanisms to increase performance while simplifying object and attribute access. Content persistence is implemented within a relational database with several object and attribute meta-data tables to augment the standard relational tables. Objects may be selected on the basis of their own attributes or targeted to other objects (people in particular) on the basis of their attributes. Some specialized auxiliary tables exist to efficiently implement this latter targeting function, which is an important feature of Extranetics web sites .

It is also possible to filter and/or augment the targeted items by intersecting and/or unioning them with a standard selection clause on the content item's attributes.

Customization plays a central role in Extranetics. The base system, while having many functions, is not meant to be a deliverable product; rather it is its ability to customize itself to various markets that is its primary selling_, point . Thus the organization of the customization process has been carefully designed.

There are two main parts to the customization subsystem:

There is a library of groups of Display class instances (web pages and pieces of web pages) and content items, organized into logical groups. For example, there is a "calendar" library that stores all web pages and content items relating to date and calendar event storage. Another example is the "message" library that maintains all information needed to create, display and store mail messages between users .

There is a hierarchically organized set of customizations. Each of these defines the actual pages and content items included in the customization. It does this by choosing from the library of web pages as well as by defining any new pages or page variations outside the context of the library. The hierarchy is organized by customization type: a general "Car" customization can be extended to a specific car manufacturer, for example.

More specifically, the HTTP Communication Subsystem serves to isolate the primary Web Subsystem process, the Web Subsystem Server, from the third part HTTP server.

Figure 2 shows the major parts of the HTTP

Communication Subsystem and the subsystems it interfaces with. The HTTP server sends the HTTP Communication Client HTTP information. This includes the URL, system environment variables, and HTTP header information.

Information in the URL will indicate to the HTTP Communication Client whether or not this is a personalized web page request or a standard web page request. If it is a standard request, the URL is simply returned to the HTTP server, which then processes the request in the standard fashion.

If it is personal web page request, the HTTP

Communication Client will process the URL. First it augments the URL with information it derives from session environment variables and the HTTP header information. This variation of the URL will be called the Aug entedURL . It then opens a socket to the HTTP Communication Server and sends the AugmentedURL to the server through the socket connection. TCP-IP will be used as the socket transport protocol.

The HTTP Communication Server receives this request and creates a thread to handle it. The thread will get a Session instance from the SessionManager based on the AugmentedURL . This Session instance will return the HTML that defines the desired web page, which in turn is passed back to the HTTP communication client. On receiving the HTML from the HTTP Communication Server, the HTTP Communication Client simply sends this information back to the HTTP server, which in turn sends it to the user's browser in the standard way.

There are three main parts of the HTTP Communication Subsystem. The URLRedirector packages a user URL into one that can be handled by the HTTPCommunicationClient class. This in turn uses the URL Processor to create the AugmentedURL needed by the Session Subsystem.

For Ml, Microsoft IIS is the HTTP server, so the way these classes interact with the HTTP server will be discussed in terms of IIS.

URLRedirector

This is an ISAPI filter that catches all personal web site URLs and redirects them to the HTTPCommunicationClient class. If the URL is not a personal web site URL, it will simply pass it back to IIS for normal processing. If it is a personal web site URL, it will create a new URL corresponding to the HTTPCommunicationClient entry point. The original URL will be given an argument to the new URL in the standard URL argument format . The original URL will be called the OriginalURL, while the new URL will be called the RedirectedURL. The URLRedirector is necessary because we want to channel all personal web site URLs to the HTTPCommunicationClient class.

HTTPCommunicationClient

This class provides an entry point for servicing personal web page requests. It uses the URLProcessor class to create an appropriate AugmentedURL for use by the Session subsystem, and then opens a socket to the HTTP Communication Client subsystem. It sends the AugmentedURL through the socket and then waits for the HTML page text which is sent back in response. This text is then given back to IIS, which relays it to the user.

This class, as well as its URLProcessor collaborator, will be implemented either in C++ as an ISAPI extension DLL or as a Java COM object which is called from a stub ASP page .

The HTTP Communication Server Subsystem is responsible for communication with the HTTP Communication Client and the start and initialization of the thread which is responsible for creating the final web page. The HTTPCommunicationServer class creates a SessionThread each time it receives a request from the HTTPCommunicationClient. The SessionThread is then responsible for getting a Session from the SessionManager, passing it the Augmented URL it gets from the HTTPCommunicationClient. It then calls the Session. GetPage () method, and relays the HTML received from this method back to the HTTPCommunicationClient.

HTTPCommunicationServer

This class simply listens on a ServerSocket . When a connection is received, it creates a SessionThread with the resulting data Socket.

SessionThread

The SessionThread is responsible for encapsulating the thread that is used to generate an HTML page and return it to the HTTP server. It does the following:

Receives the AugmentedURL from the HTTPCommunicationClient .

^■ Get a Session from the

SessionManager .getSession (URL) method using the AugmentedURL as an argument .

Calls the Session. generate ( ) function. This establishes all the information the Session class needs to create the web page, and is discussed in more detail in the next section.

Calls the Session. GetPage ( ) function, which returns an HTMLElement.

^• Uses HTMLElement .toStringO to get the HTML text, which it returns over the Socket connection to the HTTPCommunicationClient.

Closes the Socket and stops the thread.

Now that the classes have been introduced, it is possible to summarize the detailed system operation. Before diving into this, it is necessary to discuss the various incarnations of a URL that exist within the HTTP

Communication Subsystem.

URL Details

The URL goes through three stages.

OriginalURL - This is the URL sent from the user's browser.

RedirectedURL - This URL will contain the

OriginalURL as an argument, but will specify a path that will redirect processing to the HTTPCommunicationClient .

AugmentedURL - This is similar to the OriginalURL but has additional information in it that may be needed by the Session Subsystem.

OriginalURL

The OriginalURL will be of the form: _<Sponsor Domain>/<Personal Site Keyword>/<User Account>/<Page Name> For example: www.UJF.org/personal/SeanOGrady/mail where UJF is the sponsor, "personal" is the keyword we decide to use to denote a personal web page, the web site belongs to Sean 0 Grady, and this is his mail page.

RedirectedURL

The RedirectedURL will always reference the same path and will contain the OriginalURL as an argument :

<SponsorDomain>/<HTTPCommunicationClientPath>?OriginalURL==< OriginalURL>

For example: www.UJF . org/Extranetics/Extranetics . asp?OriginalURL=www .UJF . org/personal/SeanOGrady/mail

In this example, we are assuming the HTTPCommunicationClient is called from an asp page in the Extranetics virtual directory named Extranetics . asp . In the current system, an small ASP page is used to call the HTTPCommunicationClient, and helps in the maintenance of the Session ID and the augmentation of the URL.

AugmentedURL The AugmentedURL restores the OriginalURL from its position as a RedirectedURL argument and tacks on some additional information. This information will come from HTTP POST variables and other information in the HTTP header. In particular, particular, the browser type can be extracted from the HTTP header. In addition, the Session ID which is maintained by the ASP page is added to the URL.

The general form will be:

<OriginalURL>?<POST Variables>&<HTTP Header Info>&<Session ID> For example: www.UJF.org/personal/SeanOGrady/mail?SessionID=3245&Browser =Netscape3 The real values of SessionID and Browser might not be so readable, but this is meant to convey the idea.

Sequence of Operation

Figure 3 show the typical sequence of operation of the HTTP Communication Subsystem.

1) The OriginalURL comes to the URLRedirector class from the HTTP Server.

2) If this is a personal web site URL, the URLRedirector will create a RedirectedURL from the OriginalURL and send it back to the HTTP server.

3) The RedirectedURL will now be sent to the HTTPCommunication client, along with other HTTP information (not shown) .

4) The RedirectedURL and the other HTTP information is sent to the URLProcessor.

5) The URLProcessor knows how to create an AugmentedURL, appropriate for the Session Subsystem, from this information. In the current implementation most of this work is done trivially in a small ASP page with a somewhat different call structure than is shown in this diagram.

6) The HTTPCommunicationClient establishes a Socket connection with the HTTPCommunicationServer . 7) The HTTPCommunicationServer creates a SessionThread, using the established Socket connection as a constructor argument .

8) The SessionThread receives the AugmentedURL from the HTTPCommunicationClient.

9) The SessionThread gets a Session instance from the SessionManager, using the AugmentedURL as an argument to the SessionManager .getSession (URL) method.

10) The SessionThread then calls the generate () and getPageO methods of this Session object. GetPage () returns an HTMLElement.

11) The toString method of the HTMLElement is used to get the text of the web page. This is sent back, over the Socket, to the HTTPCommunicationClient. The SessionThread then closes the Socket connection and destroys itself.

12) The web page is sent back to the HTTP Server, from which it goes to the user.

The Session subsystem establishes the Session environment and initiates web page retrieval. To do this, it does the following things:

It must see if the current URL request is associated with an existing Session class; if so, this class is found; otherwise a new Session class instance is created. It must extract all information from the URL and put it in a meaningful form.

Given the page and web site of the URL, the Session must collaborate with the Display Subsystem to instantiate the Display Class that will create the proper web page for the URL .

It must call the Display routine of that Display Class and return the resulting HTMLElement to the HTTP Communication Server.

The Session and SessionManager classes the HTTP

Communication Server subsystem to the rest of the Extranetics server.

The SessionManager maintains a list of all existing Session classes. The SessionThread first asks the SessionManager for a Session. If the URL request is from a new user (there is no associated SessionID among current Sessions) a new Session instance is created and returned. Otherwise the Session corresponding to the SessionID is retrieved.

After the proper Session is retrieved, the

SessionThread calls its generate method. This does a number of things : The URLProperties class is called upon to parse the URL. The URLProperties class will now contain all parts of the URL in easily retrievable form.

^• A Website class is created. This, along with an associated SiteTemplate and Sponsor class, stores a variety of information about this user's web site.

The SessionData class is used to validate whether or not the user has logged on. This class is also used to store arbitrary data which must persist for this Session between URL requests, such as the intermediate information stored for a multi -part form before its data is submitted to the database.

The Display subsystem is called to create the Display class instance that will (in the next step) generate the HTML which is sent to the browser.

Finally, the SessionThread calls the getPage method of Session. This will use the Display class just created to generate an HTMLElement, which in turn contains a StringBuffer containing the HTML text to be sent to the browser.

The display subsystem is divided into two major parts :

^• Display classes, which generate HTML. Each

Display class embodies an HTML template that is parameterized by the properties of the Display class. There is a Display superclass; all Display classes extend it.

^• DisplayFactory classes, which retrieve content from the content subsystem and use it (as well as other customized information) to create Display class instances and fill their properties .

In addition, there are some smaller class groups that help augment the Display subsystem:

HTML classes which help the Display classes generate HTML at the lowest level .

DisplaylnstanceGroup (DIG) classes which organize Display instances into logical groups . Customization classes, such as SiteTemplate and Sponsor, which store information which is always necessary (such as web site colors, fonts, the Sponsor's name) but which are usually customized. Some of these classes are part of the Session subsystem but are heavily used (as are many Session subsystem classes, such as URLProperties) by the Display subsystem.

At the lowest level of the display system are classes that deal directly with HTML text. The primary class here is HTMLElement. It maintains a Java StringBuffer which stores the actual HTML which will be sent to the browser and has a large number of simple methods for adding HTML tags, checking HTML validity, and formatting the output .

Display classes always write HTML through HTMLElement methods. Some auxiliary classes, such as HTMLColor, also help deal with HTML tag attributes, though Display classes often have direct knowledge of these.

Display classes organize the HTML output. They server a variety of functions, but they all attempt to encapsulate HTML display information and formats^' that will be re-usable both within a specific customization and across customizations .

It is crucial to understand that Display classes are often nested within each other; the properties of one Display class are often other Display classes. A typical HTML page is usually composed of dozens of nested Display classes. This is such a common requirement that the Display superclass maintains a Vector of nested Display classes and a set of convenience methods for dealing with it simply because so many Display classes have a set of nested Display classes as one of their properties.

Every Display class has a display method that returns an HTMLElement whose buffer contains an HTML string representing the rendered output of the Display class. In the actual implementation, only one HTMLElement is used per URL request; it is effectively passed down to nested Display classes so that each nested display method call actually concatenates its output HTML into the buffer representing that page.

Display classes fall into a few general categories :

Low level classes - These embody very primitive HTML concepts, such as tables, rows, data cells, frames, form elements, etc. They are very closed related to HTML tags and are only a notch higher on the Display chain than HTMLElement . They typically use HTMLElement directly to render their output HTML. Most commonly, these are the only classes that call HTMLElement directly; most other Display classes used a nested hierarchy of low level Display classes to control their rendering methods. This adds another level of encapsulation above HTMLElement and has been found to improve the robustness of the generated HTML.

Layout classes - These are general -purpose classes for laying out other Display classes in specific formats. For example, a VerticalLayoutDisplay class knows how to render its nested Display classes in a variety of vertically oriented formats; a similar HorizontalLayoutDisplay is very good at displaying rows of Display classes.

Specialized container classes - There are some classes whose main job is to organize specific types of nested Display classes in certain ways. A LinkListDisplay class, for example, is very good at organizing a set of HTML anchor links. An EntryFormDisplay class knows how to organize a set of FormElementDisplay classes into a form.

^• Special purpose high level classes - These classes perform specialized formatting tasks. For example, there are a set of classes which control the general layout of frames which the user interface designers have decided will dictate the look and feel of most Extranetics web site pages. These classes may be used across customizations, but are very specific to a certain page layout . Other high level classes might be used to display reports a certain way, or specific content items, such as articles or messages, in an appropriate manner .

Figure 4 tries to illustrate, in a schematic and very oversimplified way, a sample Display class hierarchy that might be used to draw a web page. The WholePageDisplay class generates the overall page structure. Three inner Display classes are nested within it: TitleDisplay, LinkListDisplay, and ContentAreaDisplay. TitleDisplay nests two Display classes, GraphicsLinkDisplay and GraphicDisplay. LinkListDisplay nests a set of LinkDisplay classes, while ContentAreaDisplay nests an ArticleDisplay class.

In terms of the previous categorizations,

WholePageDisplay, TitleDisplay, ContentAreaDisplay, and ArticleDisplay are high level classes, LinkListDisplay is a container class, and LinkDisplay, GraphicLinkDisplay, and GraphicDisplay are low level classes.

DisplayFactory classes create the instances of

Display classes which actually form the pages the web site contains. In particular, there are a set of named display instances which map strings to DisplayFactory subclass methods. These in turn generate a Display class instance, with all properties filled, which can generate the HTML corresponding to that named instance .

Typically, a named display instance corresponds to a page name; this may be the web page as a whole or a subset of it . Any part corresponding to an HTML frame must be named as well. As a rule, any part of a page which is referenced in an external URL will have a named instance. This will define the page name in the URL that references it. The DisplayFactory superclass maintains a hash table that is used to map a name to the DisplayFactory subclass method which creates the Display class instance corresponding to that name. The process of creating the proper HTML for a page may then be summarized as follows:

Get the page name from URLProperties.

Call the DisplayFactory subclass method this name maps to in the DisplayFactory hash table.

This method returns a fully instantiated Display class instance.

Call the display method on this class to get the HTMLElement representing the page. A StringBuffer in this class contains the actual HTML text.

Most Extranetics web pages actually consist of a set of related named Display instances; typically, the page as a whole and some frames within it are all tightly related. And it may be necessary to redraw the page as a whole or some subset of it . DisplayFactory has some special methods for easily representing and adding pages of this kind (know as info style pages in Extranetics terminology) . At a higher level, the DisplayFactory classes may be viewed as the glue which combines content items from the Content and Database subsystems with the Display classes . Typically a DisplayFactory method will retrieve content from the database through the Content subsystem, and map it to properties in Display classes.

Figure 5 shows how data flows from the database and style customization classes to fill in properties of Display classes. Retrieval from the database is done by DisplayFactory classes through the Content Subsystem, and the DisplayFactories or their helper classes use this content to set Display class properties. The special customization classes, Sponsor and SiteTemplate, are used both by DisplayFactory classes and directly by Display classes to fill in graphics and style (i.e. color and font) information which is not necessarily stored in the database .

Because it may be useful to reuse a set of web pages across many Extranetics customizations, Display instances are organized into Display Instance Groups, or

DIGs. For example, there might be a MessageDIG which groups all Display instances used for generating web pages relating to messaging, or a NewsDIG for grouping all pages used for displaying news. These grouping make it easier to include web pages created for one customization in another customization when required.

Display classes tend to be highly reusable; Display class instances, and thus DisplayFactories, less so. But sometimes a related set of Display instances may play a role in different customizations (news, mail, calendar, or shopping web pages, for example) and DIGs help enable this.

A web site is defined by the named display instances stored in the DisplayFactory hash table.

Typically, DIG class methods are called to fill this table out with the display instances required for a given customization.

Figure 6 shows the basic relationship between the major parts of the Display subsystem. The DIGs are used to associate names with DisplayFactory method invocations and group these names logically. These DisplayFactory method invocations, in turn, will (when called) create the Display class instances which will generate the web page.

There are some complex relationships between content and display which require the use of some utility classes that help the DisplayFactory classes do their work. The most important of these are a set of classes that help with form creation and submission. HTML forms are used for many purposes. But very often an HTML form element corresponds directly to a column of a database table, and is meant to represent that value both in display and on submission.

On the server, the Display classes that represent these HTML elements are all subclassed from a FormElementDisplay class. Similarly, a row in the database is represented by a Contentltem and a column in that row by an Attribute (this is discussed in more detail in the next section) .

It has thus been very useful to create a set of classes for relating both Form Display classes to Contentltems and FormElementDisplay classes to Attributes. Such classes can perform such tasks as transferring data between the Display classes, Attributes, and the CGI values input from the user when the HTML form elements are submitted. They can also simplify the validation of those values according to FormElement, Contentltem, and Attribute requirements and, when necessary, can create and insert the proper error messages automatically.

Figure 7 illustrates the basic relationship that the form helpers are concerned with. They put the value of an Attribute (a database value) into a FormElementDisplay. This creates an HTML form element, which is shown on the user's web page. When the form is submitted, the (possibly new) form element value is sent back to the server as a CGI value. This is validated for correctness by the helper. If it is correct, the helper sets the Attribute value properly. If not, it must reset the value of the FormElement for redisplay to the user (with a proper error message) so that the user will see what was typed in.

These helper classes greatly simplify the burden on the DisplayFactory methods when pages contain forms that represent database content .

Other helper classes exist to ease the use of forms which generate database queries. Helpers are also available to ease synopsis list generation.

The Content subsystem attempts to simplify the mechanism by which the DisplayFactory classes get data from the database. DisplayFactory methods do not deal directly with the database or SQL; rather, they go through a set of classes that do the following:

Give an easy to use interface for complex queries involving the database's targeting tables . Access database table rows as if they were Java object instances, and column values using simple access functions on those instances.

Dereference various types of foreign key references very simply.

Insulate the higher levels from such issues as transactions, record locking, and content caching.

Provide "synchronization" methods that allow a customized database to be easily created.

The Content subsystem is divided into two main parts: the higher content subsystem and the lower content subsystem. The higher content subsystem is the high level interface the Display subsystem sees when dealing with database objects, while the lower content subsystem is the low level interface the higher content subsystem uses to coordinate database retrieval and update. The division between these two subsystems may be clarified by the following rules:

• The only Content subsystem methods which may be called by any other subsystems are the public methods of the higher content subsystem. These are the only means by which the rest of the system can have database access .

The only methods that the higher content subsystem can use to access the database are its own public methods and those of the lower content subsystem. In particular, all JDBC references are encapsulated within the lower content subsystem; the higher content subsystem has no knowledge of JDBC, and thus does not access the Database subsystem directly. That is solely the province of the lower content subsystem.

The higher content subsystem consists of a set of classes through which all DisplayFactory references are made. Its main role is to provide a simple interface with which to retrieve and update database information.

The most important classes in this subsystem are:

Contentltem - A Contentltem instance represents one row from a database table.

Contentltems contain an AttributeList , which contains a set of Attributes, and a Contentltemld, which contains the Attributes composing the row's primary key.

Attribute - Each Attribute represents one column in the row the Contentltem represents. Each Attribute contains an AttributeType and an AttributeValue.

AttributeType - This represents the general column information for the Attribute.

AttributeValue - This is an interface which the values of an Attribute must implement.

Contentltemld - This is the set of Attributes which form the primary key of a Contentltem.

HContentltem (Heterogeneous Content Item) - This is similar to Contentltem in that it represents row information as a set of Attributes, but is different in that the row may span multiple tables. This is used to return the result of a "join" SQL query in which columns from more than one table are returned. The individual Contentltems (each representing the columns from an specific table) can be extracted from this. XnetQuery - This is a high level representation of an SQL select statement.

ContentDbRelInterface - This is a general purpose class for using XnetQueries to generate Contentltems and HContentltems .

Figure 8 shows the containment relationship of Contentltem, Contentltemld, and Attribute. The Contentltem contains all Attributes (columns) of an object that have been read in. The Contentltemld only references those Attributes that are a part of the primary key of the table. AttributeType contains column information such as the column name, while AttributeValue is the actual value of the column in the row represented by the Contentltem.

Figure 9 shows some of the more fundamental methods of Contentltem.

The first method gets the Contentltem by its primary key.

The second gets another Contentltems that this Contentltem may point to in a foreign key.

The third gets other Contentltems which may point to this Contentltem in their foreign keys. Not pictured in the figure is the submi t () method, which is used both for inserting new rows into database tables and updating existing rows with new information.

Figure 10 shows indicates the main function of

ContentDBRelInterface. It takes XnetQueries, which represent SQL queries, and returns Contentltems, which represent the rows returned by those queries . When the query is a join returning columns from more than one table, HContentltems are returned instead of regular Contentltems.

The higher content subsystem also handles Contentltem caching, so that repeated retrieval of unchanged Contentltems need not go back to the database.

The lower content subsystem handles all of the actual database contact using JDBC. Its most important classes are:

XnetProc - This is relatively high level interface to the higher content subsystem for processing database queries and updates.

^■ XnetMap - This performs a variety of useful mapping functions for tables and columns. It performs all primary to foreign key mapping, and is also used to map column and table names to the Contentltem and Attribute classes that they correspond to.

XnetFun - This very low level class encapsulates all actual JDBC SQL statement execution calls.

XnetConnection - This class represents a database connection at a slightly higher level than the JDBC Connection class.

^• XnetDatabase - This class is responsible for connection pooling. One connection is maintained for each SessionThread, which in turn represent one URL request .

The Database subsystem is divided into the following sections:

The customized database, which is the schema that is totally particular to the data needed for a customization.

A set of meta-data tables to help the content subsystem do its work. A set of auxiliary tables for storing information about content published by the Sponsor and targeted to users either directly or based on their profiles.

The customized portion of the database typically consists of a set of tables completely idiosyncratic to the customization and a set of tables used to implement some of the more generic extranetics features, such as user login, messaging or event handling. Exactly what tables are used depends very much on the exact customization.

The meta-tables for aiding the content subsystem help it know a variety of information about the database. In particular, there is information stored about tables, columns, and keys that helps the automatic dereferencing of foreign keys at the higher level, as well as information about what Java classes will be used to represent specific information in the database.

The targeting system is quite complex, and is described in a separate document .

There are three main parts to the customization subsystem: There is a library of DIGs and the classes they use. Much of a customization may be put in this library, where it will be available to any other customization. For example, there is a "calendar" library which stores all web pages and content items relating to date and calendar event storage. Another example is the "message" library which maintains all information needed to create, display and store mail messages between users.

There is a hierarchically organized set of customizations . Each of these defines the actual pages and content items included in the customization. It does this by choosing from the library of web pages as well as by defining any new pages or page variations outside the context of the library. The hierarchy is organized by customization type: a general "Car" customization can be extended to a specific car manufacturer, for example.

In general, it is preferable to put customized items in the DIG libraries, rather than in the hierarchical customization levels. They are just more accessible there. But much of a customization must be finely tuned, so different methods of subclassing in the hierarchical customization levels have been devised. This section describes these means of specific subclassing into the hierarchical customization tree.

There is an arbitrary hierarchy of customization levels. The root level is the most general ; each step down the hierarchy represents a more specific form of customization .

There are two important rule regarding customization levels:

1) A level must never refer to a more specific level .

2) Changes should be made to the most general level possible.

Each customization level has its own package.

Each level has its own main.

Subclassing of more general levels is supported as a significant means of customization.

Subclassing is supported by two methods : There is a compile time "proxy" method in which differing proxy classes which subclass the true customized classes are checked out for a given customization level.

^• There is a run-time instance creation method in which the correct customized subclass is created by a CustomFactory class .

There are arbitrary levels of customization. They form a hierarchy from more general to more specific. For Mastech, we will have the Consul tingFirm level and the

Mastech level. We will call the core engine that we've been working on the base level. A testing level has been added for things that are needed for testing, but should not be in the base level .

The fundamental idea is that we should have to customize as little as possible for a given customer. Thus if another consulting firm company wants to be become a website sponsor, we can quickly tune the consulting firm customization level for them.

This leads to an introduction of the two golden rules of customization: 1) A level must never refer to a more specific level .

2) Changes should be made to the most general level possible.

Rule (1) is necessary to ensure that a given level needs to include only its descendants for a given delivery, and just makes sense in principle.

Rule (2) is important to ensure that general improvements to one level will occur in all more specific levels.

It should be noted that in general, customization additions should be done in DIGs, and not in the hierarchical levels at all.

Every level of customization has its own package. They are grouped as sub-packages of an extraneticscustom package. A consul tingfirm subpackage of extraneticscustom will be created, and it in turn will have a mastech subpackage. Every subpackage below extraneticscustom will be referred to as a customization package or customization level.

The extraneticscustom package itself exists on the same level as the extranetics package; it is not be a subpackage. This is a purely pragmatic consideration it will make it easy to check out the extranetics package as a whole without grabbing all the customization packages, of which only one or two may be needed, extraneticscustom will hold the following classes:

A set of proxy classes which are specifically checked out for a given customization level. These classes do no real customization work, but allow classes at the base level to effectively extend classes in a more specific level without directly referencing them.

A CustomFactory class. This will be used to encapsulate the names and construction of the proxy classes.

These classes are discussed in much more detail in the following sections.

Each customization package will have its own main, which will be subclassed from HTTPServerMain. The main will create a CustomFactory subclass appropriate to its customization level.

Whenever a class is subclassed using runtime differentiation, it is retrieved from the CustomFactory. The constructor is never called directly. Thus if we wish to subclass Person with CFPerson (an extension of Person specific to the consul ting firm customization level) any methods creating a new Person must retrieve that person via CustomFactory . get () . getPe son () instead.

CustomFactory. get () retrieves the correct CustomFactory at run-time, while getPerson ( ) will get the correct person subclass .

This outlines a more complex method of subclassing which is, luckily, only rarely needed. It is necessary when we need to extend a class from the base level in a customized level, but that class is already extended in the base level .

We want to take advantage of subclassing when creating new customization levels. Since each level represents a more specific version of other levels, subclassing offers a natural way to implement customization. Yet we will need to create and extend specific customized subclasses in more general customization levels without breaking customization rule

(1) , which says that a level may never directly reference a more specific level.

The method we will use implements differential subclassing at check-out time. For each customized subclass, a "proxy" class is created which extends it. References to the subclass made in a more general customization level are made to the proxy subclass instead of the real subclass. At check out time, a specific check out sequence must be followed to ensure that the correct proxy subclass is in place.

The proxy class is always the original class name prefixed by "Custom". The actual specific customized subclass is the original class name prefixed by something uniquely identifying the customization level.

Let us use a subclass of the base level class Person as an example. Let's assume we wish to customize this for the Consul tingFirm customization level, which we will uniquely identify by the prefix CF. The proxy class is called CustomPerson, while the subclass of Person specific to Consul tingFirm is CFPerson . In the base customization level, the version of CustomPerson which extends Person will be checked out; when running the Consul tingFirm customization level, the version of CustomPerson which extends CFPerson will be checked out.

All proxy files (i.e. CustomPerson _ are checked into a subproject of the extraneticsproxy SourceSafe project corresponding to their customization level. Thus CustomPerson extends Person is checked into extraneticsproxy/Base , while CustomPerson extends CFPerson is checked into extraneticsproxy /Base /Consul tingFirm . These projects all check out there files into the same Java package: extranetics custom . They must all have the same working folder because there goal is to replace each other, properly, at check-out time. (See Figure 11.)

This replacement is done by checking out each project, from Base to the leaf customization level, along one customization branch, in order. Thus the Base version of CustomPerson { CustomPerson extends Person) , will be replaced by the Consul tingFirm version of CustomPerson

( CustomPerson extends CFPerson) , in the normal course of extraneticsproxy check-out. Proxy classes extending more specific subclasses should always replace the corresponding proxy class extending a more general class, which is why the order of check-out progresses from most general to most specific .

As an example, let us assume we want to check out the Mastech customization level from extraneticsproxy. Make sure the SourceSafe Working Folder from every subproject of extraneticsproxy is exactly the extraneticscustom package (not a subpackage of extraneticscustom) . First check out the extraneticsproxy/Base project, then the extraneticsproxy /Base /Consul tingFirm project, and then finally the extraneticsproxy /Base /Consul tingFirm/Mastech project. Make sure each check out is non-recursive. Do not check the recursive check box.

Let us reiterate the most important points of this check-out procedure: ^• All extraneticsproxy SourceSafe subprojects are linked to the same Java package: extraneticscustom. They are not linked to sub-packages of extraneticscustom. When checking out a given customization level, first check out the extraneticsproxy/Base project non-recursively. Then check out each subproject in the path from Base to the desired customization level, in order, non-recursively.

While this procedure holds for all the proxy classes in extraneticsproxy, it does not hold for the actual customized subclasses themselves, which are checked out in a more traditional fashion.

Each of the actual customized subclasses (i.e. CFPerson extends Person) is checked into a subproject of extraneticscustom. This project is linked to packages in the normal manner: the extraneticscustom SourceSafe project has as its working folder the extraneticscustom package, and each of its subprojects links to the corresponding subpackage. In other words, the default working folders for the subprojects will be correct and should not be explicitly set.

In our example, the extraneticscustom/ 'consul ting firm project uses the extraneticscustom/ 'consul ting irm package as its working folder, and likewise for all other subprojects and subpackages .

Figure 11 shows the basic relationship between SourceSafe projects and Java packages during customization. The top row shows the extraneticsproxy projects. These are all checked out into the extraneticscustom package, in order from most general to most specific. The more specific proxy files overwrite the more general files.

The CustomFactory class always returns the proxy classes. Because of the check-out procedure, the proxy class which extends the correct customized class will be in place in the extraneticscustom package.

The subclass which really does the customization work ( CFPerson in the example in the figure) is checked out into the specific customization subpackage in a more conventional manner. Although the invention has been described in detail in the foregoing embodiments for the purpose of illustration, it is to be understood that such detail is solely for that purpose and that variations can be made therein by those skilled in the art without departing from the spirit and scope of the invention except as it may be described by the following claims.

Claims

WHAT IS CLAIMED IS:

1. An extranet comprising:

a core in which data is stored;

a first face which can communicate with the core through which data in the core can be requested and dynamically obtained and organized;

a first access mechanism which accesses the first face and connects with the first face;

a second face which can communicate with the core through which some data in the core can be obtained which can also be obtained through the first face but not all the data can be obtained that can be obtained through the first face;

a second access mechanism which accesses the second face and connects with the second face; and

a controller which organizes data in the core and identifies data as being relevant for the first and second face, prepares the first and second face and is connected to the first and second access mechanisms.

2. An extranet as described in Claim 1 wherein the controller mechanism includes a core controller which organizes data in the core and identifies data as being relevant for the first and second face, and a face controller which prepares the first and second face.

3. An extranet as described in Claim 2 wherein the controller includes a first presentation mechanism which connects to the first face which organizes data for the first face and a second presentation mechanism which connects to the second face which organizes data for the second face.

4. An extranet as described in Claim 3 wherein the core is comprised of a first portion in which data is stored and a second portion in which data is stored, and the second face can only obtain data from the second portion.

5. An extranet as described in Claim 4 wherein the first face can obtain data from any portion of the core .

6. An extranet as described in Claim 5 wherein the core is comprised of a total of N portions, and including a total of N faces, and a total of N access mechanisms each of which communicate with a respective face, where N is an integer greater than or equal to 3, each the 2 through N faces in communication with a corresponding portion of the core through which some data in the core can be obtained which can also be obtained through the first face but not all the data can be obtained that can be obtained through the first face.

7. An extranet as described in Claim 6 wherein each of the three through N faces can obtain some data in the core which can also be obtained through the first face and second face but not all the data can be obtained that can be obtained through the first face and second face.

8. An extranet as described in Claim 7 wherein at least some of the portions of the core can overlap with other portions of the core.

9. An extranet as described in Claim 8 wherein the data can be provided to the first portion of the core through the first face.

10. An extranet as described in Claim 9 wherein data can be provided to each portion of the core through the respective corresponding face.

11. An extranet as described in Claim 10 wherein each access mechanism communicates with its corresponding face through a telecommunication line.

12. An extranet as described in Claim 11 wherein each access mechanism communicates with its corresponding face through a telecommunication line with the Internet.

13. An extranet as described in Claim 12 wherein the faces in the core are part of a web extranet connected to the Internet.

14. An extranet as described in Claim 13 wherein each face includes a template that has controls which govern what data can be obtained from or provided to the corresponding portion through the corresponding face.

15. An extranet as described in Claim 14 wherein the controls of each template can be changed and the corresponding portion of the core can be changed.

16. An extranet as described in Claim 15 wherein the first face can change the controls on any template of any other face .

17. An extranet as described in Claim 16 wherein the second portion can change the template of some of the interfaces .

18. An extranet as described in Claim 17 wherein the face has multiple templates, with each template of the multiple templates corresponding to an access mechanism.

19. A method for using a personal extranet comprising the steps of:

obtaining the data in a core through a first face accessed by a first access mechanism; and

obtaining some data in the core through a second face accessed by a second access mechanism which can also be obtained through the first face but not all the data can be obtained that can be obtained from the first face.

20. A method as described in Claim 19 including after the first face obtaining data step there is the step of providing data to the core through the first face.

21. A method as described in Claim 20 including after the obtaining some data step there is the step of obtaining some data in the core through a third face and wherein the core is comprised of a first portion in which data is stored, a second portion in which data is stored, and a third portion where data is stored, and the second face and the third face can only obtain data from the second portion and third portion, respectively.

22. A method as described in Claim 21 including after the first face obtaining step there is the step of changing through the first face a template having controls which govern how the third face can obtain data from the core .

23. A method as described in Claim 22 wherein the first face obtaining step includes the step of connecting the first access mechanism to the Internet to access the first face.