WO2001024003A1

WO2001024003A1 - A software component-container framework for dynamic deployment of business logic components in a distributed object environment

Info

Publication number: WO2001024003A1
Application number: PCT/US2000/026789
Authority: WO
Inventors: Mark D. Tilden; Scott D. Hopkins; Brett J. Stonier
Original assignee: Datalex Usa West, Inc
Priority date: 1999-09-28
Filing date: 2000-09-28
Publication date: 2001-04-05
Also published as: TW490639B; EP1222539A1; AU7734100A

Abstract

This application pertains to multi-tiered, distributed computing systems and, more specifically, is directed to a component container middleware framework for dynamic deployment of business logic software components on a CORBA distributed object infrastructure. Each server container includes a configuration file which is read upon initializing the container. The container process loads software components as specified in the configuration file, and the configuration file includes information on names and locations of components creators, and defines relationships among components. The configuration file, expressed in XML syntax, makes it easy to deploy or update business logic components without exposing system source code, while maintaining a robust, scalable distributed system for demanding applications like supporting travel web sites.

Description

A SOFTWARE COMPONENT-CONTAINER FRAMEWORK FOR

DYNAMIC DEPLOYMENT OF BUSINESS LOGIC COMPONENTS IN A DISTRIBUTED OBJECT ENVIRONMENT

Related Applications

This application is a continuation of and claims priority from U.S. Provisional Applications No. 60/156,499 filed September 28, 1999, and No. 60/184,945 filed February 25, 2000.

Technical Field

This application pertains to multi-tiered, distributed computing systems and, more specifically, is directed to a component container middleware framework for dynamic deployment of business logic software components on a CORBA distributed object infrastructure.

Background of the Invention

On-line travel is one of the largest single e-commerce categories today. First- generation travel sites, those erected roughly in 1994 to 1996, were full of images and copy describing travel destinations and packages. These were essentially on-line brochures or "brochureware" and lacked interactivity. Sites were hard to maintain and were populated with static content. On-line booking was introduced in approximately 1996 in second-generation travel sites. Many airline sites and virtual travel agents introduced booking services for air, hotels and rental cars. For the first time, individuals had access to information previously available only through travel agents. A revenue stream developed, but profitability remained elusive due to the cost of accessing reservation systems such as Apollo and SABRE, high-maintenance costs, commission caps, etc. There remained a high ratio of "lookers" to "bookers. "

The third-generation travel sites, those emerging today, provide a high degree of personalization as distinguished from their predecessors. Modern travel sites present dynamic content based upon information volunteered by millions of users.

Pages are presented dynamically upon information stored in the member's profile. Such profiles can include home airport, seating preferences, usual destinations, membership award status, etc.

Supporting all of this interactivity, and the loads imposed by thousands of simultaneous users, present challenges to the computer programers and architects that design such systems. The present invention is directed to a "middleware" framework, i. e. , the software that lies between a Web site and a computer reservation system such as SABRE. Such a system must be robust, scalable and reliable.

More specifically, such a system should provide to its users, i.e. , travel-site system integrators, the ability to rapidly modify their own business logic software and deploy new business logic objects quickly and easily. If one can isolate modules of functionality and develop a simple and flexible means for introducing those modules of functionality into a booking system, system integrators will be able to provide more compelling and effective interface to customers while lowering their development and maintenance costs.

CORBA— the common object request broker architecture— defined by the object management group (OMG), is a protocol definition for communicating among heterogeneous systems. CORBA allows systems using different hardware, operating systems and programming languages to communicate. CORBA allows the interactions between those systems to be defined in a platform- independent way, giving the system a set of well-defined interfaces. Thus, CORBA provides an infrastructure for distributed computing.

The present invention is implemented on a CORBA platform. Conventionally, a CORBA server, i.e., a single, executable program, contains all the various components that may be required by its users or clients. This executable usually is hard-coded and compiled. A number of different compiled executables are provided to implement the system. Accordingly, to update that software or introduce a new component, code has to be modified, affected servers recompiled, and then the new executables distributed across the appropriate machines. This is a time-consuming and expensive process. It is also an inflexible solution that is difficult to extend.

What is needed is an open solution that allows an integrator to introduce a new component into a distributed system quickly and easily, without compromising scalability and performance of that system.

Summary of the Invention

One general aspect of the present invention pertains to multi-tiered, distributed computing systems and, more specifically, is directed to a component container middleware framework for dynamic deployment of business logic software components on a CORBA distributed object infrastructure. The invention is described by way of example and not limitation by presenting salient features of such a system that implements a travel planning and booking system. Such a system can be used to allow consumers, using a web browser and connected via the internet, to investigate travel options, including airline flights (as well as hotel rooms, rental cars, etc.) and actually book their own reservations, i.e. purchase tickets "on line." The booking engine is built on top of a unique CORBA framework. This

"middleware" framework is the basis for the travel system's flexibility, scalability, and monitoring capability. These same services are available to programmers implementing new business objects for the travel system or even separate applications that will co-exist with the existing system. Thus, in practical application, the present invention allows system integrators to easily deploy new business rules or logic into a robust, scalable, distributed system not only without rebuilding that system, but indeed without even having access to the existing system source code.

The present framework is based on a component-container model. The framework includes a standard "container" that can contain "components." The container preferably is a generic CORBA server that can load one or more components, based on a "configuration file." The container automatically reads the configuration file when it starts up and it loads the components listed in the configuration file.

Components are implemented by deriving from a framework base class. The programmer implements the desired functionality in the component objects and loads the resulting objects into the container by adding them to the container's configuration file as further explained later. The components are implemented as shared libraries, so the container can load them at run time without recompiling or linking the generic server container. Figure 2 illustrates how the container and components fit together; this will be explained in greater detail below. The generic server container provides a rich set of services to components it contains. These services relieve much of the burden of creating components by handling the details required for load balancing, monitoring, configuration, logging, and threading. Illustrative services that the generic server and component base classes can provide include the following: ^• Reading XML configuration files

^• Loading components based on the configuration file

^• Establishing connections between components listed in the configuration files

^• Setting properties of the components based on the configuration file

^• Three different threading models for components ^• Publishing and consuming events

^• Logging

^• Administrative functions to allow monitoring components and the container

^• Gathering and publishing statistics for components

^• Component pools — part of the framework, but not generic server or component-base classes ^• Dynamic properties for trading In addition, the new framework can implement higher level services that are built on top of the generic server and component model. These higher level services can include, for example, a trader service that is specifically tuned for load balancing, and a document server for storing, querying, and persisting XML documents for state management. In this way the new framework allows a programmer to focus on creating the business logic of components without worrying about the myriad of details required to build a robust and scalable system. The generic server container implements many of these services for any components it contains-nothing special is required in the components as long as they inherit from the framework base classes.

The present invention thus can be described as a configurable middleware framework comprising a client layer interface; a container process for supporting one or more business objects or components; and a resource interface such as an interface to an existing computer reservation system. The container process has access to a configuration file, and can read XML, for configuring the container process at run time to include components specified in the configuration file. These can include internal components for loading into the logical container, and well as references to external components. The configuration file is implemented in XML, while the components themselves are not restricted in terms of implementation other than a CORBA compliant interface.

The generic server also allows components to extract information from the configuration files through interfaces in the component base class. This allows a programmer to easily store parameters or other information in the XML configuration file and modify those parameters without changing any code. The process of reading and parsing the XML is handled entirely by the generic server container and component base class, so the programmer doesn't have to worry about file formats or parsing issues. The present invention thus enables an integrator to add new business logic — and deploy it over a distributed system ~ without taking everything down; without modifying and recompiling source code; and without having to copy recompiled source code to each and every server. In fact, an integrator or other authorized user can add or modify functionality without exposing source code.

Additional objects and advantages of this invention will be apparent from the following detailed description of preferred embodiments thereof which proceeds with reference to the accompanying drawings.

Brief Description of the Drawings

Fig. 1 is a high-level block diagram of a multi-tiered, distributed computing system to implement a robust, flexible, scalable, high-performance system for connecting end-users, via the internet, to a back-end resource such as a computerized reservation system.

Fig. 2 is a conceptual diagram of a generic container for loading software components based on a configuration file according to the present invention.

Fig. 3 is a conceptual diagram illustrating a configuration file specifying connections between components.

Figs. 4 A and 4B together form an example of a configuration file implemented in XML for a city code lookup process.

Figs. 5A-5C illustrate software processes, each of which implements a generic container having a corresponding configuration file. Fig.6 is a simplified diagram illustrating operation of a multi-tiered, distributed computing system to support a travel planning and reservation web site. Fig. 7 A illustrates a portion of an XML configuration file corresponding to the container process of Figure 5B.

Figs. 7B-7C comprise a pseudo-code listing of an implementation of a Kosher meals component of the type deployed in the container of figure 6.

Figs. 8A-8B illustrate by example a flight schedule request expressed in XML. Figs. 9A-9B illustrate by example a flight schedule response expressed in XML.

Figs. 10A-10B illustrate a city code lookup process (container) configuration file. Fig.11 is an illustrative portion of a travel plan controller process (container) configuration file.

Figs. 12A-12C illustrate XML data, a DOM hierarchical model of the XML data and a corresponding node list, respectively. Figs. 13A-13B sets forth an interface definition for document server object.

Detailed Description of Preferred Embodiment

Figure 1 illustrates a three-tiered e-commerce architecture with CORBA providing the distribution mechanism. In the top tier, an HTTP server 102 is coupled to the Internet 104 to provide access to multiple end-users 106 running standard Web browsers, such as IE or Navigator. Behind the Web server 102 is an application server, such as BroadVision application server 108. The application server interacts with the business logic and framework "middleware" through a client wrapper layer 110 provided by the middleware vendor. The client wrapper layer can be implemented, for example, using javascript and provides methods appropriate to the application, in this case air travel, hotel reservations and car rental. The client wrapper does not implement business logic. Business logic is implemented at the framework (middleware) level and at the user interface level via Java scripts.

The second, intermediate tier implements the business logic and middleware framework of the present invention. This tier includes an XML document store 112, framework objects 114, business objects 116 and various interfaces for interfacing with computer reservation systems and/or inventory sources. By way of illustration, figure 1 shows a database access layer 120 for connection to a customer profile database 122 and it further shows a CRS (Computer Reservation System) interface 126 for interfacing to a computer reservation system 130. This drawing is highly simplified; for example, various of the framework objects 114 and business objects 116 may include factories for creating multiple instances of corresponding objects, and these various objects will be distributed in most applications across multiple servers. As noted above, a central theme of the present invention is to implement a middleware framework that greatly simplifies a deployment of business objects 116 without exposing the system source code. The business logic that drives the site include such things as ticketing rules or restrictions on a particular itinerary. Business logic components can implement policies for pricing, discounts, seat assignments, etc. In one example, described later, a kosher meals object confirms the availability of kosher meals when requested. The CRS interface 126 in a practical implementation is likely to manage on the order of 1,000 simultaneous connections with CRS mainframes such as the SABRE System.

Figure 2 illustrates a generic server container according to the present invention as mentioned in the summary above. Components are implemented by deriving from a framework base class. The programmer (or travel site integrater) implements desired functionality in the component objects and loads the resulting objects into the container by adding them to the container's configuration file 202 in Figure 2. The components are implemented as shared libraries, so the container 204 can load them at run time without recompiling or linking the generic server container. The configuration files, expressed in XML syntax, are the basis for specifying which components the generic server should load, and how they should be connected together.

When the generic server starts up, one of the first things it does is look for a configuration file based on a name passed on the command line for the server. There is a separate configuration file for each server process in the preferred embodiment, as well as a shared configuration file that the separation configuration files can include. This makes it easy to put common elements, such as certain shared object references in the shared file where every server can use the information.

In addition, the configuration file can specify connections between components that implements specific framework-defined interfaces. The connections can include components that are located within the same server process (internal components), components located in other generic server processes, and even objects located in other processes not implemented within the framework (external components). Any CORBA object whose object reference can be entered in the configuration file in string form can be connected— even if the object is written in another language supported by CORBA. Figure 3 illustrates a connection between two components as specified in a configuration file. In this case, component 1 requires a validator service, and a connection is provided in the configuration file to component 2, which implements the validator interface, and happens to be located in another server, identified by the component 2 object reference listed in the configuration file.

Threading Policies

The generic server also supports three different threading models for handling requests for the objects it contains.

1. Single Threaded. This is the simplest model. Each request coming into the generic server for any object contained in that server process is handled serially.

Incoming requests are stored in a queue and each request executes to completion before the next request is handled. Notice that this model applies to all the components contained in a server process, so only one request for any component in the server process is handled at a time. 2. Thread per Request. The generic server container also supports a model where each incoming request is handled by a separate thread. Each new request causes a thread to be created to handle that request, and the thread executes until the request is completed. Then the thread terminates. A parameter specified in the XML configuration file can set the maximum number of threads to be created. If this maximum is reached, new requests are blocked until at least one previous request finishes and its thread terminates.

3. Pool of Threads. In this model, the generic server starts a number of threads specified in the configuration file at startup. Incoming requests are assigned a thread from the pool of available threads. If no threads are available when a request comes in, the request waits in the queue until a thread becomes available. The threading model used is specified by the configuration file. However, it can also be changed at run time. The generic server also checks the thread-safe attribute of each component it loads and forces the single threaded model if any of the components it is loading are not thread-safe. In addition, the generic server container handles thread maintenance issues, such as handling dead or hung threads, and reporting statistics on thread usage. Figures 4 A and 4B illustrate a configuration file, in this case, for a server identified as the city code lookup server. This provides a city code lookup capability which is made available to the application server through the client wrapper layer of Figure 1. So, for example, if an end-user of the travel Web site enters a city name which is not unique (Portland, Oregon/Portland, Maine) or uses an airport abbreviation (PDX) or misspells the city name, the application server can call on the city code lookup to obtain one or more valid alternatives. Referring to Figure 4A, the first portion of this file lists attributes of the container, such as time out, thread policy and maximum number of concurrent threads ("MaxThreads"). < InternalComponents >

Internal software components are listed in this section, in this case, beginning with the component name "CityCodeLookup" . For each internal component, the configuration file indicates a creator name and location, relationships (in this example there are none) and attributes. A presently preferred embodiment, a component can have three types of attributes: simple, structure and sequence. In this example, all of the listed attributes are of the simple type.

The CityCodeLookup configuration file continues on Figure 4B. Here, the next component is listed beginning with the component name "CityCodeStrictLookup. " Once again, a creator name was provided and a location of the creator, i.e. , a library. There are no relationships in this example, and again various attributes are listed. Accordingly, when the CityCodeLookup server or container process initializes, it will read this configuration file, establishing the general attributes as noted, and then it will load (create) instances of the CityCodeLookup and CityCodeStrictLookup components. The simple-type attributes, and their corresponding values, provide the means for passing perimeters to these components. This enables the integrated to change the perimeters for a given business logic component simply by editing the XML configuration file.

Also, the configuration file defines the order of calling components simply by the order in which they appear in the configuration file. This allows new business logic (a new component) to be inserted at the correct point in an existing process simply by inserting it at the corresponding point in the component list in the configuration file. As further explained later, the configuration file can define relationships or "connections" between components; for example, defining which components use what other component's services. By "sequencing" a new component into the configuration file list at the correct location, in defining relations to other components, a new logic component can be fit into the overall system without changing any existing source code. Put another way, the present component container architecture presents a higher level of abstraction beyond, but still compatible with the CORBA infrastructure. Figure 5A presents a simple example of a container process Cl and corresponding configuration file "Config (Cl)". Container 500 includes a travel plan controller component 502, a kosher meal component 504 and any other business logic component "XX" 506. Figure 5B illustrates a second container process 510 that includes the components 502 and 504 previously mentioned, and introduces a new component, Amadeus Interface Factory 512. The interface factory creates interface objects as necessary, illustrated by interface objects 514. The Interface Factory component is added to the container by listing it in the corresponding configuration file "Config. (C2)". These configuration files are simplified for purposes of illustration and in practical application would contain more details such as those of Figure 4A-4B. Figure 5C illustrates another container process C3, in this example a document server container. This container includes two components, namely a document server component 520 and a Filter United component 516, as listed in the corresponding configuration file "Config. (C3)". The document server creates individual document objects as necessary, for example, objects (or "documents") 522 and 524.

In the travel site application, a document will be created for each end-user "session" handled by the Web site application server. The application server maintains session state information, and calls on the document server (the document factory) to generate a new document, and conversely, it can notify the document container to discard a given document when the corresponding session is concluded. The individual document objects store user/session information, such as a flight itinerary, in an XML format as further described later.

Figure 6 illustrates operation of the software system described above. Referring now to Figure 6, at the beginning of a client session on the travel planning Web site, the application server (see figure 1), using the client wrapper interface 600, makes a call 602 to a travel plan controller factory component 604 shown in container C2. This is essentially a request for the factory to create a travel plan controller instance 606. This object 606 will implement the travel planning process for this particular session. The client wrapper 600 also is used to make a call 610 to a document factory 612, in this case, located in a document server container C3. The document factory 612 creates document objects, in this example, document object 614, for storing information associated with this current session. The corresponding travel plan controller 606 communicates with the document 614 via path 616.

Assume that the end-user in the current session requests information about flights between given locations on a specified date, etc. This flight request information is written to the session document 614 via call 620 in an XML syntax. The travel plan controller (TPC) 606 makes a call 622 to the Amadeus IF Factory 624 to request an interface to the CRS. The factory 624 creates (or assigns from a pool) an interface object 626 as requested; makes it available to the TPC. The IF 626 reads the flight request information 627 from the document 614 using a query language explained later, and creates a flight schedule request in suitable form to present the flight schedule request to the computer reservation system 640. The IF receives a flight schedule response and writes that information into the document 614, again formatted into an XML Syntax. The client wrapper 600 can read the updated document via another call, and provide this information to the application server which, in turn, provides the flight information to the Web server (See Fig. 1). Note that the client wrapper layer provides an interface to the document for the application server to access XML data.

We next assume that the end-user selects her itinerary from among the flights offered. The selected flight information is written to the session document 614 through the client wrapper as described. Before the session is concluded, various business logic components may be called to modify and/or validate travel plan information as appropriate. These other components can be called by the travel plan controller for this session (606), and they will interact with the data stored in the corresponding document 614. Numerous components can be implemented to provide a variety of business logic, as mentioned above, such as pricing, seating assignments, special fares on discounts, mileage club, accommodations and even food requests. We illustrate this last feature by way of a kosher meal business logic component 650. The kosher meal component is shown deployed in container C2 and therefore appears in the corresponding configuration file 652.

The kosher meal component is to determine whether or not kosher meals are available on a flight requested by the end-user. For example, if a kosher meal is requested, the travel plan controller makes a call 654 to the kosher meal component 650. Component 650's job is to determine whether kosher meals are available on the flight segments requested. Two requirements must be satisfied: first, the departure city must be equipped to provide kosher meals; and second, a minimum number of days of advance notice is necessary to provide kosher meals. The number of days of advance notice required will be passed to the kosher meal component, via the configuration file C2, at run time as further explained later. In response to the call 654, the kosher meal component 650 makes a query 660 to the document 614. To determine, for each flight segment, two pieces of information; namely, the departure date and the departure city code. The kosher meal component 650 then makes a call 662 to a CityCodeLookup component 664 to determine whether the departure city indicated is capable of providing kosher meals. We assume this information is available to the CityCodeLookup, as it would have information about virtually all the commercial airports in the world. If kosher meals are available at the indicated departure city, and if the prior notice requirement is met, in terms of the number of days from ticketing (or the current date) to the departure date, the kosher meal component 650 will modify the document 614 to indicate that kosher meal is available on the corresponding flight segment. This process can be repeated for each flight segment on the itinerary. The kosher meal availability could be implemented with a Lookup table 666, but utilizing the city code lookup component would be preferred so that airport information is collected in one place. Travel plan controller 606 can provide this updated information to the client wrapper 670. An illustrative implementation of a kosher meal component is provided in Figures 7B-7C. This component uses the query language described below to access data stored in the session document object.

Of course, many other user sessions can be processed at the same time. The application server, via the client wrapper, will request travel plan controllers as necessary and corresponding documents from the document factory. In the figure BL-

205 merely identifies another business logic component. Another component, illustrated in container C3, is a filter component called "Filter United" 672. The component framework includes a generic operation called filter. This is used to modify a document that the system is working on. It essentially examines the document and deletes certain information. In this case, Filter United has the task of removing from the document United Airlines flights that appear in the flight schedule response data. To add any new filter, the programmer can simply write one, derived from the base filter class, and add it into the list of filters in the configuration file. For illustration, we show the Filter United updating a document 674. Figure 7 A illustrates the C2 configuration file in greater detail. The configuration file, shown in XML syntax, begins with the server name and attributes of the server. Next, it lists the three internal components, travel plan control, kosher meals, Amadeus IF Factory, as mentioned before. For each component name, the configuration name includes a creator name and a library location of that creator. It also includes attributes and relationships to other components, as appropriate. For the component KosherMeals, a creator name and library location of the creator are listed. Just one attribute is shown, of a simple type, called "PriorNotice" with a parameter value of 5, indicating five days advance notice required for kosher meals. A container process reads the configuration file and provides this attribute information to the KosherMeals component as a parameter at run time. In this way, the advance notice requirement can easily be changed by simply editing the XML configuration file. The file also shows that component KosherMeals has a relationship in that it uses the city code lookup component.

Figure 8 is an example of a flight-schedule request. The various elements of the flight schedule request are summarized in the following table.

Table 1. Flight Schedule Request Method Element List:

Element : FlightSchedule

Description: Contains all the information to perform a flight availability and flight schedule request and display the results. Attributes : None

SubElements : Request - Below, 1 or more, required

Element : Request

Description: Contains all the information to perform a flight availability request.

Attributes : ID - unique identifier SubElements : RequestedFlightSegment - Below, 1 or more, required

ClassOfService - Below, exactly 1, required

PassengerType: Below, 1 or more, required

ValidCarriers: Below, 0 or 1, optional

Element : RequestedFlightSegment Description: Contains all the information for one flight query.

Attributes : ID - unique identifier

SubElements : Departure - Below, exactly 1, required Arrival - Below, exactly 1, required IncludeConnectingCities - Below, 0 or 1, optional Element : Departure

Description : description of the departure point

Attributes : Date - departure date Time - departure time

SubElements : City - TravelPlanXML, exactly 1, required Element : Arrival

Description: arrival city

Attributes : None

SubElements : City - TravelPlanXML, exactly 1 , required

Element : IncludeConnectingCities Description : List of required connection cities, which the flight choices must include as stopover cities

Attributes : None

SubElements : City - TravelPlanXML, exactly 1, required

Element : ClassOfService Description: cabin request for all segments

Attributes : Code - cabin code for requested cabin

SubElements : None Element : ValidCarriers

Description : limiting list of carriers which are acceptable for the returned flights

Attributes : None

SubElements : Carrier - TravelPlanXML, exactly 1 , required Element : PassengerType

Description: Number of passengers to request availability for - the sum of all passenger type totals will be used in the request

Attributes : Number - number of passengers in this type

SubElements : None Element : NumChoices

Description: maximum number of flight choices to return

Attributes : Value - number of passengers in this type

SubElements : None

Element : FlightNumber Description: This element contains the flight number the user wants to get schedule or availability information on.

Attributes : Value - The number of the flight.

SubElements : None

The example of Figure 8 shows virtually all of the elements that might be included in a flight availability search, although not all of them are required, as indicated in the table. All the information in the flight schedule request and in the flight schedule response are stored in the corresponding session document, as mentioned above. Figures 9A-9B illustrate a flight schedule response. The response begins with the corresponding flight schedule request for identification. The response has an identification number, and includes two choices (flights), choice identification numbers 1 and 2.

Figures 10A-10B form a listing of the city code lookup server configuration file. The file includes general attributes (applicable to the entire container) and internal components. Each of the internal components "CityCodeLookup" and "CityCodeStrictLookup" has multiple attributes. Again, these attributes are passed to the component as parameters at run time. Figures 11 A-l IB illustrate a portion of a travel plan controller container configuration file. The configuration file includes a travel plan controller factory of the type discussed above. Document Component

The Document component is a component that internally contains an XML document and whose external interface provides clients with the ability to set and retrieve certain portions of the document at a given time. The XML document preferably is stored internally using a C+ + DOM implementation. Most document users, however, will not need to deal with either XML or DOM directly, because most reading and writing of Document information can be done using the Node and NodeAttribute structures, using either a node id or an XQL query to identify a node or a group of nodes. As noted, session data is stored in the document objects in XML format.

Figure 12A illustrates the hierarchical association of tags in XML format. Figure 12B illustrates the DOM model in which the tags have a tree structure, and each node has a corresponding node id number. The present invention implements, in its query language, a node list concept. This is a list of tags and corresponding node id's. A node id is an internal unique identifier that the Document process uses to identify individual nodes. Users of Document should not try to determine a node id on their own, but should only use values that have been obtained from the Document instance they are working on through an operation like get_nodes_by_query. If a call to get_nodes_by_query is successful, then the nodes returned can be relied upon to have correct node ids, their values or attributes can be modified, they can be passed back to the document via the update_nodes_by_node_id, and the changes will be made in the proper spots in the document. However, if one of these node ids were to be extracted, the document saved to a file, and a new document created from that same file, the node id would no longer be valid.

Query Language

A query is a string that conforms to a defined query language. In a presently preferred embodiment of the invention, a query language suitable for accessing the content of a document is a subset of XQL (XML Query Language), which is an extension of XSL (Extensible Stylesheet Language). More information on these languages is publicly available. Following is a table containing examples of the query commands our Document component supports and what they do:

The present invention departs from standard XQL in that the symbols Document supports includes addition of the ! operator as a modifier to the // behavior. XQL defines the // operator to be a recursive descent beginning at a specific node. Therefore, .11 would indicate a recursive descent starting at, but not including, the current context node. This is significant in our use of XQL because a common XML query will be to find certain nodes and select them and all their descendants. For example, you might want to select all City nodes and their descendants anywhere in the document. Following XQL by the letter, you could write the query //City, which would select all City nodes anywhere in the document, but would not select their descendants. You could also write the query //City//, which would find all City nodes anywhere in the document and select their descendants, but not the City nodes themselves. Therefore, you'd have to do at least two queries to select the City nodes and their descendants, a potentially expensive process if being done across a network, and certainly one that will return a messy result. Our solution was to allow a ! operator, directly following a //, to modify the // behavior to include the starting node. This would allow the following queries:

/City//! Finds all City nodes that are children of the root node, and performs a recursive descent starting at (and including) each one. City//Code//! Finds all City nodes that are children of the current context node, finds all of their Code descendants, and performs a recursive descent starting at (and including) each one.

.11 ! Code Selects all of the Code nodes if the current context node or anywhere below the current context node (a very tiny difference.) City//! Code Finds all City nodes that are children of the current context node, and selects all of their Code descendants. In this case, the ! is useless, because it would modify the // behavior to check each City node to see if it is a Code node, which obviously would never be true. //'.City /Code Finds all City nodes within the document, and selects all of their Code node children. Again, here the ! is useless, because it would modify the // behavior to see if the root node is a City node, which would never be true because the root node is the document and is not an XML node.

The current context is an important concept when using a query. If a query begins with a 7' , it begins at the root, which is the base of the document tree.

However, if it doesn't begin with a '/' , it begins at the current context. The current context is analogous to a pointer or cursor in other technologies, in that it refers to a specific place in the document. When a document is loaded from a file or otherwise created, the current context is set to the root. From here the current context can be moved to any node in the document. Once the current context is set, it remains until changed explicitly or until the document is destroyed. This allows queries to be applied only to a specific portion of the document, if desired.

Some operations that operate by query, such as set_current_context_by_query and add_nodes_at_query, can only perform their function if the query specifies a single node in the document. In other operations, such as get_nodes_by_query, queries can specify and select multiple nodes. A simple example of use of these types of queries is illustrated in the Kosher Meals example of Figures 7B-7C.

It will be obvious to those having skill in the art that many changes may be made to the details of the above-described embodiment of this invention without departing from the underlying principles thereof. The scope of the present invention should, therefore, be determined only by the following claims.

Claims

ClaimsWe Claim:

1. A multi-tiered, distributed object framework comprising:

(a) a client wrapper layer for interaction with a client process;

(b) a middleware layer including a container process for hosting one or more business logic objects; and

(c) a resource interface layer for connection to and interfacing with a computer reservation system;

(d) the container process having access to at least one configuration file for configuring the container process at run time by loading into the container one or more components specified in the configuration file.

2. A framework according to claim 1 wherein the configuration file includes identification of at least one external component.

3. A framework according to claim 1 wherein the configuration file includes at least one attribute of the container process.

4. A framework according to claim 3 wherein the container attribute comprises selection of a predetermined threading policy.

5. A framework according to claim 1 wherein the configuration file includes, for the specified component, identification of at least one attribute for passing to the component at run time as a parameter.

6. A middleware framework according to claim 5 wherein the component attribute comprises a selected parameter and a value of the selected parameter, for passing the value of the selected parameter to the said internal component by editing the value in the corresponding configuration file.

7. A framework according to claim 1 wherein the configuration file is formed in XML syntax.

8. A framework according to claim 1 wherein the configuration file is implemented in a text file.

9. A framework according to claim 1 wherein the configuration file is encapsulated as a software object.

10. A framework according to claim 1 wherein the configuration file includes for the specified component, identification of at least one relationship of that component to another component.

11. A document server container process comprising: a document factory component for creating document objects; each document object encapsulating data stored internally in an XML syntax; each document object further implementing an interface for accessing the encapsulated data; and the document server container process having access to a configuration file associated with the document server container for configuring the container process at run time by loading into the container one or more software components specified in the configuration file, including the document factory component.

12. A document server container process according to claim 11 wherein the document object implements a hierarchical tree structure of the encapsulated data, and assigns to each node of the XML data, a corresponding unique internal node identifier (id); the node id corresponding to a specific node within a hierarchical tree model.

13. A document server container process according to claim 12 wherein the document interface maintains an indication of a cuπent context, for executing query language commands on the encapsulated data relative to the cuπent context.

14. A document server container process according to claim 12 wherein the document object implements a node list, the node list including a list of tags of the XML data and a coπesponding node id for each tag.

15. A document server container process according to claim 12 wherein the document interface implements a predetermined query language for accessing the encapsulated data; the query language including commands for accessing the data based on node identifiers.

16. A document server container process according to claim 15 wherein the query language implements commands for obtaining query results including node identifiers.

17. A method of storing and maintaining dynamic session data in a distributed object environment, comprising the steps of: providing a document factory for creating a document object for each session; in each document object, storing selected session data in an XML syntax; implementing a hierarchical internal tree structure associating the data stored in the document object; assigning to each tag of the stored data a unique internal node identifier coπesponding to the tag location on the tree structure; and in each document object, implementing an interface for accessing the session data stored in the object based on the assigned node identifiers, thereby encapsulating the actual XML syntax data.

18. A method of storing and maintaining dynamic session data according to claim 17 wherein the document object implements a predetermined query language that includes query commands that return selected node identifiers.

19. A method of storing and maintaining dynamic session data according to claim 18 wherein the document object implements a predetermined query language that includes query commands that update the document object at node identifiers specified in a query command.

20. A method according to claim 18 and further comprising maintaining an indication of a cuπent context in the document, for executing query language commands on the encapsulated data relative to the cuπent context.