EP1222539A1 - Structure composant logiciel-conteneur pour le deploiement dynamique de composants de logique commerciale dans un environnement objet reparti - Google Patents

Structure composant logiciel-conteneur pour le deploiement dynamique de composants de logique commerciale dans un environnement objet reparti

Info

Publication number
EP1222539A1
EP1222539A1 EP00967087A EP00967087A EP1222539A1 EP 1222539 A1 EP1222539 A1 EP 1222539A1 EP 00967087 A EP00967087 A EP 00967087A EP 00967087 A EP00967087 A EP 00967087A EP 1222539 A1 EP1222539 A1 EP 1222539A1
Authority
EP
European Patent Office
Prior art keywords
document
configuration file
component
container
node
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP00967087A
Other languages
German (de)
English (en)
Inventor
Mark D. Tilden
Scott D. Hopkins
Brett J. Stonier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hopkins Scott D
STONIER, BRETT J.
Tilden Mark D
Conducive Technology Corp
Original Assignee
Datalex USA West Inc
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 Datalex USA West Inc filed Critical Datalex USA West Inc
Publication of EP1222539A1 publication Critical patent/EP1222539A1/fr
Withdrawn legal-status Critical Current

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/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems

Definitions

  • 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.
  • 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.
  • 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.
  • a “middleware” framework i. e. , the software that lies between a Web site and a computer reservation system such as SABRE.
  • SABRE computer reservation system
  • 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.
  • OMG object management group
  • 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.
  • CORBA provides an infrastructure for distributed computing.
  • the present invention is implemented on a CORBA platform.
  • 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.
  • 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
  • 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.
  • 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.
  • Figure 1 illustrates a three-tiered e-commerce architecture with CORBA providing the distribution mechanism.
  • 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.
  • 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.
  • CRS Computer Reservation System
  • 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.
  • 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.
  • 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
  • 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.
  • the generic server 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.
  • 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.
  • the generic server also supports three different threading models for handling requests for the objects it contains.
  • 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.
  • FIGS. 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" .
  • the configuration file indicates a creator name and location, relationships (in this example there are none) and attributes.
  • attributes In this example, there are none
  • 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.
  • the next component is listed beginning with the component name "CityCodeStrictLookup. "
  • a creator name was provided and a location of the creator, i.e. , a library.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the kosher meal component 650 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.
  • the application server via the client wrapper, will request travel plan controllers as necessary and corresponding documents from the document factory.
  • the application server via the client wrapper, will request travel plan controllers as necessary and corresponding documents from the document factory.
  • Filter United has the task of removing from the document United Airlines flights that appear in the flight schedule response data.
  • Filter United has the task of removing from the document United Airlines flights that appear in the flight schedule response data.
  • the programmer can simply write one, derived from the base filter class, and add it into the list of filters in the configuration file.
  • 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.
  • 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.
  • 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.
  • Attributes ID - unique identifier
  • SubElements RequestedFlightSegment - Below, 1 or more, required
  • ValidCarriers Below, 0 or 1, optional
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the update_nodes_by_node_id the node id would no longer be valid.
  • a query is a string that conforms to a defined query language.
  • 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.
  • /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.
  • a query begins with a 7' , it begins at the root, which is the base of the document tree.
  • the current context is analogous to a pointer or cursor in other technologies, in that it refers to a specific place in the document.
  • 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 can only perform their function if the query specifies a single node in the document.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne des systèmes informatiques répartis à plusieurs niveaux, et plus précisément, une structure intergicielle composant-conteneur destinée au déploiement dynamique de composants logiciels de logique commerciale sur une infrastructure objet CORBA répartie. Chaque conteneur serveur comprend un fichier de configuration qui est lu lors de l'initialisation du conteneur. Le procédé du conteneur charge les composants logiciels comme spécifié dans le fichier de configuration, lequel fichier de configuration comprend des informations relatives aux noms et aux emplacements des créateurs de composants et définit des relations entre lesdits composants. Le fichier de configuration, exprimé en syntaxe XML, permet de déployer ou de mettre à jour facilement des composants de logique commerciale sans exposition du code source du système, et de tenir à jour dans le même temps un système réparti extensible et robuste pour applications complexes, telles que les sites Web de gestion de voyages.
EP00967087A 1999-09-28 2000-09-28 Structure composant logiciel-conteneur pour le deploiement dynamique de composants de logique commerciale dans un environnement objet reparti Withdrawn EP1222539A1 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US15649999P 1999-09-28 1999-09-28
US156499P 1999-09-28
US18494500P 2000-02-25 2000-02-25
US184945P 2000-02-25
PCT/US2000/026789 WO2001024003A1 (fr) 1999-09-28 2000-09-28 Structure composant logiciel-conteneur pour le deploiement dynamique de composants de logique commerciale dans un environnement objet reparti

Publications (1)

Publication Number Publication Date
EP1222539A1 true EP1222539A1 (fr) 2002-07-17

Family

ID=26853240

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00967087A Withdrawn EP1222539A1 (fr) 1999-09-28 2000-09-28 Structure composant logiciel-conteneur pour le deploiement dynamique de composants de logique commerciale dans un environnement objet reparti

Country Status (4)

Country Link
EP (1) EP1222539A1 (fr)
AU (1) AU7734100A (fr)
TW (1) TW490639B (fr)
WO (1) WO2001024003A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107957893A (zh) * 2017-12-20 2018-04-24 四川九洲电器集团有限责任公司 一种软件流程与功能动态实现方法

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2823932B1 (fr) * 2001-04-23 2003-06-27 Intaan Technology Systeme et procede pour la distribution dynamique de donnees et/ou de services
AUPS173802A0 (en) * 2002-04-16 2002-05-23 Camms Pty Ltd Data collection system using remotely configurable scripting
AU2002303070A1 (en) * 2002-05-16 2003-12-02 Agency For Science, Technology And Research A computing system deployment method
US7765521B2 (en) 2002-08-29 2010-07-27 Jeffrey F Bryant Configuration engine
US8006224B2 (en) 2005-04-15 2011-08-23 Research In Motion Limited System and method for unified visualization of two-tiered applications
EP1712987A1 (fr) * 2005-04-15 2006-10-18 Research In Motion Limited Système et procédé de visualisation d'applications multi-niveaux
DE102005041628B4 (de) * 2005-09-01 2012-12-27 Siemens Ag Vorrichtung und Verfahren zur Verarbeitung von Daten unterschiedlicher Modalitäten
US7739690B2 (en) 2007-04-26 2010-06-15 Microsoft Corporation Meta-container for model-based distributed applications
US8225308B2 (en) * 2007-10-26 2012-07-17 Microsoft Corporation Managing software lifecycle
US8015213B2 (en) 2008-06-26 2011-09-06 Microsoft Corporation Content having native and export portions
CN112631797B (zh) * 2020-12-18 2024-09-20 京东科技控股股份有限公司 配置业务系统的方法和装置
CN112558949B (zh) * 2020-12-21 2024-05-28 长沙树根互联技术有限公司 程序构造方法、装置、电子设备及存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5515508A (en) * 1993-12-17 1996-05-07 Taligent, Inc. Client server system and method of operation including a dynamically configurable protocol stack
KR960008583A (ko) * 1994-08-26 1996-03-22 윌리암 티. 엘리스 데이타 프로세싱 시스템 및 데이타 프로세싱 시스템 관리 방법
US5822580A (en) * 1996-01-19 1998-10-13 Object Technology Licensing Corp. Object oriented programming based global registry system, method, and article of manufacture
JP3622313B2 (ja) * 1996-01-29 2005-02-23 株式会社日立製作所 ドキュメント管理システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0124003A1 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107957893A (zh) * 2017-12-20 2018-04-24 四川九洲电器集团有限责任公司 一种软件流程与功能动态实现方法

Also Published As

Publication number Publication date
AU7734100A (en) 2001-04-30
TW490639B (en) 2002-06-11
WO2001024003A1 (fr) 2001-04-05

Similar Documents

Publication Publication Date Title
US20020129345A1 (en) Scripting business logic in a distributed object oriented environment
US7370335B1 (en) System and method for providing a public application program interface
US6738077B1 (en) Dynamic generation and automated distribution of user interface from database model
US6356920B1 (en) Dynamic, hierarchical data exchange system
Ceri et al. Data-driven, one-to-one web site generation for data-intensive applications
CA2304020C (fr) Procede et systeme de creation de logiciel d'application pour base de donnees requerant une programmation minimale
US5432925A (en) System for providing a uniform external interface for an object oriented computing system
US7912826B2 (en) Apparatus, computer program product, and method for supporting construction of ontologies
US7519976B2 (en) Collaborative business plug-in framework
US20040078105A1 (en) System and method for workflow process management
US20030233631A1 (en) Web services development method
US20020133579A1 (en) Methods, systems and computer program products for rule based delegation of administration powers
US20030018963A1 (en) Installation of a data processing solution
US7055134B2 (en) Service provider integration framework in object oriented programming environment
EP1222539A1 (fr) Structure composant logiciel-conteneur pour le deploiement dynamique de composants de logique commerciale dans un environnement objet reparti
US9513874B2 (en) Enterprise computing platform with support for editing documents via logical views
WO1994025924A1 (fr) Procede et appareil destines a la gestion du systeme informatique dans l'entreprise
US20060293936A1 (en) Method and system for automatically transforming a provider offering into a customer specific service environment definition executable by resource management systems
US20070094289A1 (en) Dynamic, hierarchical data exchange system
WO2005033933A1 (fr) Systeme et procede pour la gestion de processus de flux de travail
Sung et al. A component-based product data management system
US8484567B2 (en) Systems and methods for personalizing software programs
CN115222345A (zh) 一种审核作业方法及装置
de Souza Bomfim et al. Design and implementation of linked data applications using shdm and synth
US20070038926A1 (en) Method for automatically embedding TabIndex attributes

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020321

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17Q First examination report despatched

Effective date: 20021104

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CONDUCIVE TECHNOLOGY CORP.

Owner name: HOPKINS, SCOTT D.

Owner name: TILDEN, MARK D.

Owner name: STONIER, BRETT J.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20030315