WO2002069541A2 - Procede et systeme permettant de generer et de gerer des contenus et des services sur un reseau - Google Patents

Procede et systeme permettant de generer et de gerer des contenus et des services sur un reseau Download PDF

Info

Publication number
WO2002069541A2
WO2002069541A2 PCT/US2002/001582 US0201582W WO02069541A2 WO 2002069541 A2 WO2002069541 A2 WO 2002069541A2 US 0201582 W US0201582 W US 0201582W WO 02069541 A2 WO02069541 A2 WO 02069541A2
Authority
WO
WIPO (PCT)
Prior art keywords
content
present
xml
page
template
Prior art date
Application number
PCT/US2002/001582
Other languages
English (en)
Inventor
Thomas C. Kwon
Ronald B. Caganello
Masimillian Ekstrom
Original Assignee
Dmind
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dmind filed Critical Dmind
Publication of WO2002069541A2 publication Critical patent/WO2002069541A2/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces

Definitions

  • the present invention relates generally to software for enabling e-
  • the present invention relates to software that provides an extensible platform for content management, Enterprise Application Integration (“EAI”), and Enterprise Information Portals (“EIP”) for businesses operating over the Internet.
  • EAI Enterprise Application Integration
  • EIP Enterprise Information Portals
  • Web sites are now the central repository for much richer and business-critical content including business processes and rules, software components, data sources, transactional components, visitor profiles, product catalogs, and other data.
  • Such varied content types require very different skill sets among the content managers, many of whom have specialized knowledge that cannot be transferred outside of the organization. Hence it has become infeasible to outsource content management in most modern, business-critical Web sites.
  • Table A compares the features within the present invention with two prior art devices, Interwoven's Teamsite and Vignette's V/5.
  • Integration portal-like portal Add-on managed through functionality, wrap templating engine any external data in XML for presentation and management
  • Java application assets package comprises 6 servers and separate applications. databases
  • SDK message interface exists functionality handler, XML for staging and schema, directory deploying pool and XSL content, source handlers, plus level differencing
  • the Web site would act as the portal or console through which content and application services are deployed.
  • the creation, deployment and management of disparate content types would be consolidated in one unified Web-based interface.
  • the management platform associated with the unified Web-based interface offered an easy extension of internal services while at the same time simplifying integration with external services.
  • the present invention responded to this need to manage, create and provision complex transactional Web-based services by developing a unified content and transaction management platform.
  • No prior art solution utilizes Extensible Markup Language (“XML”) along with Extensible Stylesheet Language (“XSL”) and the architectural purity of Java and "EJB” to create a unified Web- based content and application management platform.
  • XML Extensible Markup Language
  • XSL Extensible Stylesheet Language
  • EJB architectural purity of Java and "EJB”
  • Some objectives of the present invention include, but are not limited to: providing a unified Web interface to access, enable, manage and personalize enterprise data, legacy systems, applications and content; creating a seamless and standardized Web gateway for delivering varied content to any channel; empowering organizations to Web-enable information that was previously inaccessible; modernizing existing business methods and improving existing business methods that can benefit from efficiencies introduced by Web technologies; reducing Web operational and labor costs; and expanding revenue and market opportunities.
  • the present invention provides an open architecture module deployment platform and a rich set of Application Programming Interfaces ("APIs").
  • APIs Application Programming Interfaces
  • the present invention's module deployment platform allows third-party systems to extend basic application behavior in at least three ways: outsourcing content creation and maintenance, outsourcing lookup and retrieval of pages and outsourcing the handling of application events.
  • Prior art systems can not harness and orchestrate distributed information management as easily and as seamlessly as the present invention.
  • the present invention reduces Internet operational costs by sixty percent and enables a ninety percent reduction in labor and time by provisioning Internet services. For example, the present invention can enable a conglomerate servicing over 1,200 contributors to manage its global Intranets and Extranets with only 2 employees.
  • the modules of the present invention are built on top of a rich set of APIs that the application exposes through Enterprise Java Beans ("EJBs”), the industry-standard for distributed transactional components. These APIs are backed by comprehensive secu ⁇ ty and highly scalable performance. Leveraging these APIs, each module can focus on the specifics of its business logic and on meeting application goals. With its painless deployment process, robust and convenient APIs and strict adherence to leading industry standards, the present invention offers an open-ended rapid development platform unmatched in any prior art product.
  • EJBs Enterprise Java Beans
  • the present invention uses industry standard technologies rather than closed, proprietary conventions. These industry standard technologies include, but are not limited to J2EE, XML, XSL, EJB, JNDI, JMS, and JDBC. By implementing industry standard technologies, functionality can be easily extended, flexibility in selecting software and hardware platforms such as Windows NT, UNIX, LINUX, Oracle, SQL Server, etc. can be allowed, and integration with other applications and data sources using modular design is easily enabled.
  • EAI Enterprise Application Integration
  • the present invention centralizes management of a company's existing software and data. EAI enables message queuing, publish-and-subscribe, XML bridging, as well as leveraging with existing company applications, databases, and systems.
  • the Enterprise Information Portals (“EIP”) functionality of the present invention personalizes and merges information sources. EIP modules access and enable external resources while still providing a user-friendly interface for personalizing information.
  • the present invention allows content access from PDA, cell phone and other wireless and wire line devices.
  • the present invention enables users to dynamically load stylesheets appropriate to the devices as well as can create mobile user profiles.
  • the system requirements for the present invention are summarized in Table B.
  • Table B At a high level, the present invention has been designed as a 4-tier system.
  • Some benefits of the four tier architecture include, but are not limited to the ability to isolate the effect of code changes thereby increasing the ease of updates and extensibility; to define stable and standardized Web interfaces, to group functions into coherent modules, and to partition work among team members.
  • Figure 2 illustrates the broad functions of each tier in the present invention's four tier system.
  • Figure 2 depicts the technologies supporting the function in each tier.
  • the four tiers include the Database Tier 210, the API Tier 212, the Application Tier 214, and the Presentation Tier 216.
  • the API Tier 212 and Database Tier 210 comprise the "backend" of the present invention, and are accessed only indirectly by licensed users via the Presentation Tier 216 and Application Tier 214.
  • the content management toolset that accompanies the software of the present invention is an example of an application developed in the Application Tier 214 that was built upon the API Tier 212.
  • Applications developed using the API set access the Database Tier 210 through the API calls.
  • Site designers work within the Presentation Tier 216 to develop layouts for the information exposed through the Application Tier 214.
  • the present invention is a method for integrating content and application delivery over a distributed computer network in a single open architecture program.
  • the method comprises entering a URL to a user machine connected to the distributed computer network.
  • a prescribed template is retrieved on the received URL.
  • the present invention receives over the distributed computer network content and an application.
  • the present invention parses the content into a plurality of XML fragments.
  • Each XML fragment is identified by an element type and an element style.
  • the element type indicates a type of XML fragment.
  • the element style indicates a style presentation of the XML fragment.
  • the present invention assembles a XML document in accordance with the template.
  • the present invention transforms the assembled XML document using XSL into a page for display in a browser operating on the user machine.
  • the present invention displays the page in a browser operating on the user machine.
  • FIGURE 1 depicts an overview of the present invention
  • FIGURE 2 depicts the four tier architecture of the present invention
  • FIGURE 3 depicts the external application functionality of the present invention
  • FIGURE 4 depicts an exemplary user login Web page for the present invention
  • FIGURE 5 depicts an exemplary Java applet Web page in accordance with the present invention
  • FIGURE 6 depicts how a Java applet constructs the content and applications Web pages through the XML template in accordance with the present invention
  • FIGURE 7 further depicts the process in Figure 6;
  • FIGURE 8 depicts attribute selection in accordance with the method of the present invention.
  • FIGURE 8A depicts an exemplary group edit Web page in accordance with the method of the present invention.
  • FIGURE 8B depicts an exemplary user edit Web page in accordance with the method of the present invention.
  • FIGURE 9 depicts the overview of the user administrator method in accordance with the method of the present invention.
  • FIGURE 10 depicts a further exemplary user edit Web page in accordance with the method of the present invention
  • FIGURE 11 depicts a further exemplary group edit Web page in accordance with the method of the present invention
  • FIGURE 12 depicts the overview of the site architect method in accordance with the method of the present invention.
  • FIGURE 12A depicts an elements edit screen
  • FIGURE 13 depicts an exemplary element edit Web page in accordance with the method of the present invention.
  • FIGURE 14 depicts a further exemplary element edit Web page in accordance with the method of the present embodiment
  • FIGURE 15 depicts a further exemplary element edit Web page accessed from Figure 14;
  • FIGURE 16 depicts an exemplary template edit Web page in accordance with the method of the present embodiment
  • FIGURE 17 depicts an exemplary XML edit Web page in accordance with the method of the present embodiment
  • FIGURE 18 depicts the overview of the site developer method in accordance with the method of the present invention.
  • FIGURE 18A depicts an exemplary edit Web page utilized by site developers
  • Figure 19 depicts a further exemplary site developer edit Web page
  • FIGURE 20 depicts a further exemplary site developer Web page
  • FIGURE 21 depicts an exemplary Message Handler edit Web page
  • FIGURE 22 depicts an exemplary Directory Pool edit Web page
  • FIGURE 22A depicts an exemplary Directory Pool edit Web page
  • FIGURE 23 depicts an overview of the content manager method in accordance with the method of the present invention.
  • FIGURE 23A depicts an exemplary content manager edit Web page
  • FIGURE 24 depicts an exemplary Deployment parser Web page
  • FIGURE 25 depicts an overview of the parser process
  • Figure 1 illustrates an overview of the present invention 100.
  • the present invention 100 supports both content delivery 104 and the technology integration 102 in an open architecture platform 106 that supports data management, business processes, as well as a number of distributed computer network applications.
  • Figure 3 illustrates the capacity of the present invention to access and present data from many external data sources, through an Extensible Markup Language (“XML") interface 320.
  • Elements of a Web page 324 called functional plug-ins in the diagram are actually mini-applications that retrieve data from databases and external applications, and format the results as XML.
  • a template combines the XML fragments from each Web page element 324 into a single XML document.
  • XSL Extensible Stylesheet Language
  • the elements of the Web page 324 can be applications developed specifically for system using the API set or the elements of the Web page 324 can be calls to existing Enterprise Java Beans ("EJBs") that encapsulate business logic developed outside of the system or from external data sources.
  • EJBs Enterprise Java Beans
  • HTML separate Web page content form Web page layout, because HTML embeds Web page layout within the Web page content. For example, HTML to display a book title could look like this:
  • the XML command indicates that the Web page content "To Kill a Mockingbird" is a book title.
  • the Web page layout will be determined.
  • the XSL stylesheet will describe how to display the book title within a browser or other device accessing the content.
  • FIG. 4 depicts an exemplary user login Web page 400. Once the user has been authenticated, the Java applet of the present embodiment is loaded.
  • Figure 5 depicts an exemplary Java applet Web page 500.
  • Figure 6 depicts how the Java applet constructs the content and applications Web pages through the XML template.
  • the Java applet depicts both the main control panel 670 and the content frame 672.
  • the two main folders are Docroot, where the content (text and data) is stored, and nGia, where users, groups, templates and elements are accessed.
  • the main control panel 670 of the Java applet is populated with the structure (directories) of the Web content and application functionality.
  • the main control panel 670 accesses the DirectorySession Bean 674 using Remote Method Invocation ("RMI") to "mount” the entry points into the application and content.
  • RMI Remote Method Invocation
  • the content frame 672 is responsible for data templating.
  • the screen is populated from the PageServlet 676, which calls TemplateSession 678 and associated parsers to load the appropriate XML data.
  • a Web site served by the present embodiment looks like any other to the end user. Behind the scenes, however, there are many complex operations that result in a Web page. These are the same operations that populate the main control panel 670 of the Java applet interface described above.
  • Accessing a Web site hosting the present invention triggers the following events depicted in Figure 6.:
  • TemplateSession 678 is a stateful session bean - each entity bean instance represents a single template and its elements and parsers.
  • the session information is passed to the TemplateSession 678 parse method, which queries the database to determine which elements are associated with the template.
  • the Java embedded classes, the "parsers,” 660 associated with each element are executed, returning data wrapped in XML in accordance with the XML schema that defines the element. Data returned can originate from the internal database 664 or any external database or system 664.
  • Elements are populated by the output of the Java classes, becoming in the process "fields" in the Web page. Fields are defined as instances of elements. The data returned by the parser is validated against the XML schema for the element.
  • the results of all parser outputs 660 are aggregated by the TemplateSession 678 into a single XML document.
  • the resulting page can be thought of as an instance of the template.
  • Individual pieces of data are stored in the field table of the database, referenced by the pagelD.
  • the final output is created by transforming the XML page with the XSL stylesheet that has been associated with the template.
  • the XSL stylesheet itself is actually one of the elements in the template.
  • Figure 7 further illustrates the initial request depicted and described in Figure 6 to the PageServlet 776.
  • the callback of PageServlet 676 with the doProcess method doProcess calls the parse method of TemplateSession to get elements and parsers as described above).
  • PageServlet 676 the main controlling servlet:
  • Every component is an object with a set of properties.
  • the present embodiment adheres to this standard, and therefore everything in the system is an object with properties. Every object has permissions and actions that can be performed on it.
  • the Java applet interface of the present embodiment embraces the object orientated approach.
  • Each piece of data has an attribute.
  • the user accesses the data attributes with a right mouse button click and with a choice of the appropriate option. For example, selecting "new" with the Groups folder adds a new group whereas selecting "new" with the Templates folder creates a new template.
  • Figure 8 illustrates the pull down menu 896 illustrating the attributes that would appear with a right mouse button click or any other actuating action. As can be seen in Figure 8, the user has actuated the nGia folder. The attribute highlighted in that attributes list pull down menu 896 is as can be seen the "new" attribute.
  • FIG. 8A An example of a group edit screen can be seen in Figure 8A.
  • Groups are added to the system for security and access purposes. Users can be in multiple groups and can have different roles within different groups. As shown in Figure 8A, there is a user's list 840 and a group list 842 In addition, the present invention enables groups to be nested within one another with the groups within groups list 846.
  • the users and groups to which they belong, along with objects and permissions comprise the security model of the present embodiment.
  • the security model is based on users and groups who have permissions on objects. Users must belong to a group, and the group in turn has permissions on objects. There are 3 axes which must be considered when determining the rights on an object: the object itself, the group, and the permissions.
  • Some examples of valid permissions include, but are not limited to read, write, create, and destroy.
  • Each object created in the system has an owner, and only the owner can change the permissions of the object.
  • When a new object is created it is given all permissions for its owner group, and no permissions for anyone else.
  • members of that group will inherit the capability of changing the permissions on an object it owns. For example, if the Content Manager group is set-up as the principle that owns all new pages added to the Web site, then any member of that group may change permissions on a new page, provided that that user is not in a subgroup whose write permission has been revoked for that object.
  • Users do not have individual permissions; groups do. Users are individuals having access to various functions within the system. User access rights are associated with the groups to which a user belongs.
  • a group can have one or more users, and up to 3 levels of nested groups (groups within groups).
  • groups are groups that are associated with the groups to which a user belongs.
  • a group can have one or more users, and up to 3 levels of nested groups (groups within groups).
  • groups are considered members of the group everyone and assigned permissions accordingly.
  • An example of a users edit screen 848 can be seen in Figure 8B.
  • the user administrator is responsible for setting up and administering the users and groups.
  • the process flow for user administrators in the present invention is depicted in Figure 9.
  • the objects the user administrator can access are the users and groups objects.
  • User administrators add and modify users of the system using the user edit screen 1048 shown in Figure 10. Users are objects like everything in the system, and have permissions associated with them as well. When right-clicking on the users folder and selecting "new", the user edit screen 1048 appears with blank data fields, provided the user administrator has permissions to add another user. When opening the user folder, selecting a user (in this case GREENROCKET), and selecting "edit” from the pull down menu, the user edit screen results 1048 with populated data fields for editing.
  • Groups are set-up similarly using an groups edit Web page as shown in Figure 11. On this screen users are placed into the selected group, and groups can also be placed within the selected group, if desired. In addition, as discussed above users can be in more than one group, and have different roles within different groups. There are 9 predefined groups with already set permissions: everyone, Content Manager, Directory Administrator, Message Administrator, Site Architect, Site Developer, User Administrator, Super Group, and System. Their permissions are summarized in the Table C.
  • the site architect develops the overall information architecture of the Web site, including defining the needed elements and templates. Elements are created with XML schema and associated with a parser for data population. Templates are built from groups of elements. The goal of the site architect is to ensure that any repetitive or structured information is normalized and ordered in a consistent hierarchical manner throughout the entire Web site.
  • Figure 12 depicts the overview of the site architect method in accordance with the method of the present invention.
  • the site architect has access to the objects "elements,” “template,” and “mount points.”
  • One purpose of the XSL in the system of the present embodiment is to dictate how XML information generated by the system should be displayed on a Web page. For example, the XSL may indicate that the element "employeename" should be in bold font and centered. It is up to the site architect to determine the site structure and data element characteristics.
  • the site architect defines elements by inputting XML schema.
  • the site architect then associates these XML schema with parsers developed by the business logic programmers. Finally, the site architect constructs templates out of these elements.
  • the site architect role in conjunction with the other user roles compartmentalize the responsibilities of each person using the system of the present embodiment.
  • the system then enables the underlying business structures to be handled by a single role who is responsible for modeling the core business structure.
  • Underlying business structures are abstract enough to be free of design or content specifics. Consequently, the system takes advantage of the abstracted business structures.
  • the system normalizes and orders any repetitive or structured information in a consistent hierarchal manner throughout the entire Web site.
  • the content section of the present invention is generated dynamically, based on the DTD fragments of the elements.
  • the application can obtain the DTD for an element from its DTD body.
  • the following restrictions apply to the element's DTD:
  • the Element must have one ⁇ !ELEMENT> tag matching its name.
  • This ELEMENT tag must include an attribute list of fixed attributes:
  • the element's ELEMENT tag cannot include any other attribute list other than the one described above.
  • At least one user-defined child element must be included in the element's child list.
  • the reserved element exception must be included as one of the element's optional children, unless it is a basic DTD section.
  • any other markup including other ELEMENT declarations, may follow.
  • the schema is used to indicate the XML that will be returned by the parser 660, to categorize it (in this case as a "string” with the XML tag "Content”).
  • the Page Servlet 676 compares the output that is expected (indicated by the schema) with the output returned in order to validate it.
  • the element name in the schema (“Content”) is a special XML tag used by the Content parser 660, to wrap incoming data. It can be used for many different elements, thus this name is different from the name that the schema is stored under in the database. For example, elements named FirstName and LastName may be created by a user, with the schema element name "Content"
  • the present invention automatically returns a certain amount of
  • the "ngia:" prefix to the element name is the namespace for that element. Namespaces must be used with XML schema to distinguish them from elements of the same name created elsewhere. Thus namespaces reduce the chance of naming conflicts among elements. Namespaces are manipulated on the screen shown below. Each prefix (such as "ngia”) is mapped to a fully qualified URL. New namespaces can be added here, and existing ones deleted. Figure 13 depicts the element namespace process. As can be seen in Figure 13, each namespace 1330 has a prefix and a URL. For instance as shown in Figure 13, one prefix is "testl" having the URL http://www.test.com
  • present invention also defines a reserved processing instruction for importing DTD syntax from another Element.
  • This Element's DTD fragment will simply be appended to the end of the Template DTD, apparently allowing its Elements, Attributes, and Entities to be accessed from within side the definition of another Element.
  • Site architects are responsible for creating the elements as shown in Figure 13 and they work with the client and the content itself to determine the best way of breaking it down, or representing it through the element structure.
  • Content can be populated in the system either through the element mechanism, or through the XSL stylesheet associated with a template.
  • the user may wish to represent the company's privacy policy as static content within the XSL stylesheet that is loaded each time a page is created from that template, or as a PrivacyPolicy element that can be modified from a Web interface.
  • the element versus XSL stylesheet decision will determine whether or not end users will be able to serve as content managers.
  • XSL stylesheets are typically edited only by users with a higher level of permissions within the system than content managers.
  • the present embodiment supports all sorts of content. For instance, the present embodiment supports Unicode character encoding, two- byte Asian characters, and localization in any language.
  • the present embodiment supports two types of elements, namely, page elements and template elements.
  • a page element is one which changes for every page that is generated from a template.
  • Page elements originate from more dynamic, changeable content.
  • Template elements remain constant for every page based on a template. They are thus based on more static content.
  • An example of template elements are the editor and viewer XSL stylesheets because they are not page specific.
  • Figure 14 depicts an the element edit Web page in accordance with the method of the present embodiment.
  • a site architect enters the XML schema for the element 1434.
  • the present invention provides a convenient mechanism to create a "skeletal" schema with valid XML as a starting point for the user.
  • the appropriate field type for the element (page or template) 1432 is also selected here, and default parameters 1436 are set as well.
  • the default parameters option 1436 provides a way to pass arguments to the parser that are specific to the element.
  • Figure 15 depicts a further element edit Web page accessed from Figure 14.
  • Figure 15 highlights the default parameter option 1436.
  • the user has selected the "User Defined” XML schema 1534 for the element. Now, the user must choose the default parameters 1536.
  • the default parameters option 1536 provides a way for the user to pass arguments to the parser that are specific to the element.
  • One use of default parameters option 1536 would be to choose a subset of data from the parser, or tell the parser which directory to perform its operation (e.g.
  • the appropriate parser is associated with the element by selecting it from the default parameters pull down menu 1536 as shown directly above.
  • the XML for the element is stored in the database upon submit, and retrieved any time the element is triggered by the template in order to validate the output of the associated parser.
  • Templates are built by selecting elements from a library and adding them to the template.
  • Figure 16 depicts a exemplary template creation Web page.
  • the template is thus a collection of XML schema, and represents fully the data that will make up any page based on that template. As can be seen in
  • the system presents to the user both a list of elements 1538 and a list of template elements 1550.
  • elements will produce data either from information stored in the internal database, or from an action that gets information from an application or external database.
  • the template is a Web page representation of the data (content) elements present in this Web page. For example, on a human resources page there may be elements for employee name, social security number, and address that come from the HR database, as well as an element that pulls information from a news feed.
  • the site designer implements the look and feel of the Web site using XSL stylesheets. This may be the same person as the site architect. There are two "hard coded" XSL stylesheets with every template, one which creates HTML for the editor of the page (a template element called EditXSL), and one which creates HTML for the viewer of the page (a template element called ViewXSL). However, any number of XSL stylesheets may be used at runtime to display the final output, by including the appropriate argument in the URL.
  • the XSL for the hard coded XSL stylesheets is entered into the system using an XSL interface 1552 such as displayed in Figure 17, and upon "submit" this information is stored in the database and associated with the template.
  • the purpose of the XSL is to dictate how the XML information generated by the system should be presented (laid out) on the page. For example, it may indicate that the element called EmployeeName should be in a bold font and centered.
  • the XSL references the elements that have been associated with the template.
  • An excerpt of a sample XSL stylesheet is shown below:
  • xmlns:xsl http://www.w3.org/1999/XSL/Transform
  • xmlns:ngia http://www.dmind.com/ngia/application
  • xmlns:uni http://www. unispherenetworks.com
  • xmlns:sys http://www.dmind.com/ngia/system”> ⁇ xsl:output
  • the XSL stylesheet is primarily HTML with embedded references to the XML elements associated with the template.
  • XSL is capable of performing logical and conditional operations
  • the present embodiment encourages simple XSL stylesheets, with complexity relegated to the parser level.
  • FIG 18 depicts an overview of the site developer method in accordance with the method of the present embodiment.
  • the objects available to the site developer include access to modules such as Directory Pools, Embedded Classes, and MessageHandlers.
  • Figure 18A An exemplary of a edit Web page utilized by site developers is shown in Figure 18A.
  • site developers add their own Java application code 1854 to the system.
  • Figure 18A is known as an embedded class edit screen. Embedded class files are compiled by the system and inserted into the database as executable byte-code. When an element is called that is associated with one of these parsers, the system executes the element and returns data in accordance with the element's specification. In this way, the present embodiment enables the addition of custom applications and/or classes that invoke an external Enterprise Java Bean. PARSERS
  • Parsers are business logic modules that encapsulate CRUD (Create, Read, Update, Delete) actions for content fragments. Whereas elements as discussed above return DTD fragments, parsers return XML fragments. For better parsing performance, the user receives a standalone XML document containing both DTD and XML fragments.
  • One Page can activate an arbitrary number of Parsers to handle its business logic, and these Parsers allow the present invention to manage content, on a granular level, from many data sources.
  • Parsers are responsible for representing requested data in XML, and this data is in turn verified by criteria defined in the XML schema for the associated element. Parsers format data in XML's display neutral syntax, promoting the reuse of parsers between many presentation scenarios. Parsers extend an Abstract Class that dictates their functionality, and are deployed and loaded through the module platform of the present invention.
  • the present invention provides the facility for uploading an existing compiled Java class with the OS based Browse window 1990 as depicted in Figure 19.
  • Figure 19 depicts a further exemplary site developer edit Web page.
  • Programmers specify the class run type as a Caller 1982 or Principal 1984, meaning whether the module runs as its invoker (caller) or as its own unique identity.
  • the applications written for the present invention and used as parsers are accessed by the system through one or more elements in a template. When an element is called that is associated with one of these parsers, it is executed and returns data and verifies it against the element's XML schema. This is a way to extend beyond the out-of-the-box functionality of the present invention by adding custom applications and/or classes that invoke an external Enterprise Java Bean or data source/application.
  • Figure 20 depicts a further exemplary site developer Web page illustrating this upload functionality.
  • Figure 20 depicts an exemplary upload file screen 2092. Using the upload file screen, the compiled class 2094 is then inserted into the database as executable byte-code, at which point it becomes available for associating with an element.
  • Parsers, Message Handlers and Directory Pools are all modules within the present invention.
  • Modules are Java classes that extend or implement Java interfaces or Java abstract classes.
  • the byte-code for a module is stored in a database table along with certain metadata.
  • class loader Instead of searching for the class on the file system, which is the functionality supplied by Sun, the present invention's class loader examines the appropriate database table and loads the respective byte-code.
  • class libraries are centralized in a single repository that provides greater availability in a distributed application environment. All modules (parsers, message handlers and directory pools) utilize this mechanism.
  • Message Administrators and Directory Administrators are also programmers, and they use the same screen to upload their compiled code. While not shown in the screenshot above, programmers will be able to indicate which type of module their compiled class represents, a message handler, directory pool, or embedded class (parser).
  • Message Handlers are modules that respond to specific application events, such as viewing a certain element on a page, adding a page to the system, or a request for a page by an unauthorized user.
  • Message Handlers are built on top of the Java Messaging Service, a vendor-independent message oriented middleware ("MOM") API. Message Handlers accelerate the development time of MOM modules that serve as custom adapters to external services, such as third-party versioning, deployment scripts to specialized production environments, traffic analysis/personalization packages, and synchronization with external user repositories.
  • MOM vendor-independent message oriented middleware
  • Figure 21 depicts an exemplary Message Handler edit Web Page.
  • the topic 2156 shown in Figure 21 dictates the event or condition that the Message Handler responds to.
  • the Message Handler continuously listens to the system for the events 2156 and performs an action with the listen condition is met.
  • one listen condition 2156 can be a web page modification or a date.
  • the action could be an email notification.
  • the system sends notification to the message handler whenever the specified date passes or web page has been modified. Upon receiving notification that the condition has been met, the message handler would then send an e-mail to an appropriate individual informing them of the event.
  • DirectoryPools which are developed by users, partners, or clients of the present invention, may serve as a fagade for third-party applications, enabling external data sources to serve as data models for sections of the nGia directory tree. They essentially provide a "mount point" for existing external directories or software services, so that they can be accessed via the system's web interface.
  • An example of a Directory Pool edit screens can be found in Figures 22 and 22A. As shown in Figure 22, the user is editing the DirectoryPool "Pool4.”
  • a DirectoryPool is Java class that may be deployed at runtime to represent a specific section of the Web site, known as a mount point.
  • the mount point 2286 is depicted.
  • the DirectoryPool mapped to this mount point 2286 establishes a common set of policies for finding, creating, removing, and searching within this mount point 2286.
  • Clients obtain directory information through a single application entity, the DirectorySession EJB.
  • This object delegates directory requests to a concrete DirectoryPool implementation according to a reserved algorithm. This algorithm analyzes the incoming request and compares it to its list of mount points 2286, maintained in memory.
  • the DirectorySession object will resolve the request, worst case to the DocrootPool, whose mount point 2286 is the virtual document root.
  • the trimmed tokens for a relative request which is forwarded to the matching DirectoryPool, then resolves the request according to its own business logic, perhaps by querying a third party application or database. A potential use of this function would be to make assets that already exist in a file system accessible via a folder in an applet of the present embodiment.
  • Figure 22A depicts the Web interface for users to mount Directory
  • FIG. 22A depicts the DocrootPool as one of many potential Directory Pools 2288 in the browser pull down window 2296.
  • a pool could be written that accesses a specific directory in a file system and reads the contents, making them accessible via the folder frame 2270 of the applet.
  • the content manager is empowered to make changes to content within the system. Access is strictly controlled to individual elements and pages within the Web site. The template, and individual element permissions, control the area of influence the content manager has. In addition, the workflow component assures that any changes go through a process of approval and feedback.
  • the content can be added to the new templates, creating pages within the system.
  • the content contributor's responsibilities include populating the initial content, and updating it after deployment.
  • An overview of the content manager's role in the present embodiment is depicted in Figure 23.
  • the objects available to a content manager are web pages and file names.
  • the extent of the content manager's ability to alter Web pages is determined by the content manager's permissions.
  • Figure 23A depicts two exemplary content manager edit Web pages
  • Web sites created in accordance with the method of the present invention are most commonly served live from the database, to take advantage of the personalization and dynamic data capabilities. However, in some cases it may be necessary to create static versions of the Web site, to serve from multiple distributed Web sites that do not have the application or database installed of the present embodiment.
  • the Deployment parser was written which writes out the entire Web site into static HTML files, stored in the file system.
  • the Deployment utility depicted in Figure 24 allows the user to specify the root directory (origin of the content), starting point for the deployment, and target directory for file storage.
  • the present invention extends existing cutting-edge technologies in a way so as to provide capabilities not presently available in the marketplace.
  • Some benefits of the present invention include a purely object based architecture, a unique module deployment platform, a new templating architecture, a unique framework for managing and integrating external data as well as an extensible event-driven framework.
  • API -Session Objects
  • DirectorySession bean meaning one DirectorySession bean instance is equivalent to any other instance. • Handles all directory-related requests, including page creation, deletion, directory creation, moving pages, renaming, and determining the template of a page.
  • SecuritySession Handles authentication requests, and user/group/permission queries.
  • API -Entity Objects • Utilizes existing business process approval cycles for web Web site management (e.g., changes approved by supervisors in a way that mirrors the organizational structure) 5.
  • API -Entity Objects :
  • ElementEntity- Represents a single Element. Properties include
  • TemplateEntity - represents a single Template. Properties include
  • NativeFieldEntity - represents a Field of an Element that is housed in the database. Properties include • Content - body of the field
  • EmbeddedClassEntity represents an module; a Java class file housed in the database. Properties include
  • API - Messaging
  • HandlerRegistry a standalone Java program that runs on the Application Server and subscribes to reserved JMS topics, thus listening to all application-generated events.
  • EJBs and application modules use ResourceAdapter to determine the appropriate drivers programmatically • courtesy methods for bean lookup, JNDI authentication, obtaining database drivers, obtaining XML drivers, etc
  • the present invention's flexibility lies in its ability to be easily extended and integrated with other systems and data sources.
  • the present invention allows "snap-in" Java components that contain custom business logic to be synthesized into the system on the Application tier.
  • the present invention includes the following tiers: Database, Adapter, API, Application, and Presentation.
  • Parsers carry out specific business logic and return XML-wrapped data to the client.
  • a parser is associated with any number of Elements in the system and any number of Elements may be associated with any number of Templates.
  • Figure 25 depicts the parser process. As shown in Figure 25, when a page is requested from the system, the present embodiment executes each parser associated with the relevant Template and gathers their XML fragments to assemble one master XML Document that is consumed by the client and then transformed (using XSLT) into an appropriate format.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne la création, la prestation et la gestion rapides de services d'application et de services de contenu sur un réseau informatique réparti. L'invention est une application native XML sous forme de composants pour la gestion de contenu et l'intégration des applications sur un réseau informatique réparti. En outre, l'invention utilise une seule interface basée sur navigateur pour modifier des pages Web au moyen de feuilles de style extensibles (XSL), valider des applications Java et des modules extérieurs, modifier les permissions d'utilisateur, éditer, effacer, déplacer et ajouter des pages au site Web, enfin gérer les utilisateurs, les rôles des utilisateurs et les comportements du système.
PCT/US2002/001582 2001-01-17 2002-01-17 Procede et systeme permettant de generer et de gerer des contenus et des services sur un reseau WO2002069541A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US26251901P 2001-01-17 2001-01-17
US26204901P 2001-01-17 2001-01-17
US60/262,519 2001-01-17
US60/262,049 2001-01-17

Publications (1)

Publication Number Publication Date
WO2002069541A2 true WO2002069541A2 (fr) 2002-09-06

Family

ID=26948984

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/001582 WO2002069541A2 (fr) 2001-01-17 2002-01-17 Procede et systeme permettant de generer et de gerer des contenus et des services sur un reseau

Country Status (1)

Country Link
WO (1) WO2002069541A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004025971A2 (fr) * 2002-09-13 2004-03-25 Qualcomm Cambridge Limited Dispositif de communication sans fil
US8010597B2 (en) 2007-09-19 2011-08-30 Microsoft Corporation Componentized site engine services
US9037974B2 (en) 2007-12-28 2015-05-19 Microsoft Technology Licensing, Llc Creating and editing dynamic graphics via a web interface

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004025971A2 (fr) * 2002-09-13 2004-03-25 Qualcomm Cambridge Limited Dispositif de communication sans fil
WO2004025971A3 (fr) * 2002-09-13 2005-03-31 Qualcomm Cambridge Ltd Dispositif de communication sans fil
JP2005538631A (ja) * 2002-09-13 2005-12-15 クゥアルコム・ケンブリッジ・リミテッド 無線通信装置
AU2003271847B2 (en) * 2002-09-13 2008-02-07 Qualcomm Cambridge Limited Wireless communication device
KR100943876B1 (ko) * 2002-09-13 2010-02-24 퀄컴 캠브리지 리미티드 무선 통신 디바이스
US8010597B2 (en) 2007-09-19 2011-08-30 Microsoft Corporation Componentized site engine services
US9037974B2 (en) 2007-12-28 2015-05-19 Microsoft Technology Licensing, Llc Creating and editing dynamic graphics via a web interface

Similar Documents

Publication Publication Date Title
US10318620B2 (en) General purpose annotation service for portal-based applications
JP5787963B2 (ja) コンピュータプラットフォームのプログラミングインターフェース
US8700682B2 (en) Systems, methods and articles for template based generation of markup documents to access back office systems
US7516440B2 (en) System and method for providing a java interface to an application view component
US6732148B1 (en) System and method for interconnecting secure rooms
US7739310B1 (en) Extensible portlet templates
US20070239726A1 (en) Systems and methods of transforming data for web communities and web applications
US20070061428A1 (en) Customization of applications through deployable templates
US20020026461A1 (en) System and method for creating a source document and presenting the source document to a user in a target format
US7167863B2 (en) System and method for building a distributed internet application
EP1126681A2 (fr) Portique de réseau et procédé associé
WO2002059773A1 (fr) Applications modulaires de donnees mobiles distribuees
US8707171B2 (en) Service registry policy editing user interface
US20060265359A1 (en) Flexible data-bound user interfaces
US20040122915A1 (en) Method and system for an extensible client specific calendar application in a portal server
US10114617B2 (en) Rapid visualization rendering package for statistical programming language
WO2002001388A2 (fr) Serveur de portail fournissant une interface utilisateur personnalisable pour l'acces a des reseaux informatiques
Pialorsi Microsoft SharePoint 2013 Developer Reference
WO2002069541A2 (fr) Procede et systeme permettant de generer et de gerer des contenus et des services sur un reseau
Will et al. WebSphere Portal: Unified user access to content, applications, and services
Walther ASP. Net 2.0 Unleashed
Qaddoura Dynamic Website and Data Engine Generators for Distributed Enterprise/Business Architectures
Balsoy et al. Automating metadata Web service deployment for problem solving environments
Al-Ghourabi A comparison of web development technologies: WebObjects vs. ASP. NET
Polgar et al. Portal Development Framework

Legal Events

Date Code Title Description
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP