US20060064574A1 - Application framework for use with net-centric application program architectures - Google Patents

Application framework for use with net-centric application program architectures Download PDF

Info

Publication number
US20060064574A1
US20060064574A1 US11/228,800 US22880005A US2006064574A1 US 20060064574 A1 US20060064574 A1 US 20060064574A1 US 22880005 A US22880005 A US 22880005A US 2006064574 A1 US2006064574 A1 US 2006064574A1
Authority
US
United States
Prior art keywords
application
user
service
conversation
facility
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.)
Abandoned
Application number
US11/228,800
Inventor
Damon Rolfs
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.)
Accenture Global Services Ltd
Original Assignee
Accenture Global Services GmbH
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 Accenture Global Services GmbH filed Critical Accenture Global Services GmbH
Priority to US11/228,800 priority Critical patent/US20060064574A1/en
Publication of US20060064574A1 publication Critical patent/US20060064574A1/en
Assigned to ACCENTURE GLOBAL SERVICES GMBH reassignment ACCENTURE GLOBAL SERVICES GMBH ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ROLFS, DAMON M.
Assigned to ACCENTURE GLOBAL SERVICES LIMITED reassignment ACCENTURE GLOBAL SERVICES LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ACCENTURE GLOBAL SERVICES GMBH
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/20Software design
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a toolkit for specifying net-centric application program architectures. More specifically, the invention relates to various general and reusable components, facilities, and frameworks for robustly structuring a net-centric application program in a modular manner.
  • Java 2 Platform, Enterprise Edition is a platform that enables solutions for developing, deploying and managing multi-tier net-centric or server-centric applications. J2EE utilizes Java 2 Platform, Standard Edition to extend a Java platform to the enterprise level.
  • J2EE-based products have typically been implemented as “one-off” implementations on top of the J2EE platform.
  • a “one-off” implementation refers to a solution that is focused on a specific set of requirements, with little or no thought about reuse across other problem domains.
  • Conventional J2EE-based one-off application architecture implementations typically include facilities for logging errors, setting up configuration behind the application, and structuring the application in accordance with the commonly known framework or pattern referred to as the model view controller.
  • the model view controller framework includes three layers that work together: (1) the view layer, which describes how information is presented to an application user; (2) the controller layer, which interprets how user actions are translated into business activities or work within the application; and (3) the model layer, which performs complicated computational tasks such as working with a database.
  • Activities and Presentations define boundary points in the Model-View Controller framework. Activities define the boundary between the Controller and the Model, while Presentations define the boundary between the Controller and the View. These boundary points define what is commonly referred to as separation of concerns.
  • An alternative structural framework relative to the model view controller is message oriented middleware.
  • Message oriented middleware based applications are essentially hooked together through a series of work queues for sending messages from one processing component to another processing component through these queues.
  • the work queues typically include some type of message send and message receive mechanisms.
  • Message oriented middleware tasks are performed by exchanging messages in an asynchronous manner, which is in contrast to the synchronous nature of the remote procedure call paradigm. Although the remote procedure call paradigm has been widely used, the message oriented middleware approach is beginning to be used more often than it has in the past.
  • the message oriented middleware structural framework facilitates managing the work performed by such a series of queues by creating a processing pipeline in which work is performed on messages that are passed from one processing component to another processing component. Passing messages or work units between these processing components is managed through a messaging pipeline.
  • the invention relates to a robust toolkit or set of components for defining a net-centric application program architecture that preferably lies on top of the Java 2 Enterprise Edition, commonly known as the J2EE.
  • a toolkit or set of components in accordance with illustrative embodiments of the invention may be separated into various major components or aspects for purposes of discussion, including: (1) the bootstrapping process; (2) the configuration facility; (3) the factory; (4) selectors; (5) the pipeline architecture; (6) Web application control flow; and (7) the authorization facility.
  • a bootstrapping process in accordance with illustrative embodiments of the invention may allow a project architect to use a declarative style for assembling various facilities within the architecture and initializing them.
  • the bootstrapping process may be driven by an XML document at run time.
  • the XML document could be edited to set up the architecture differently without having to recompile and/or rebuild the system.
  • the bootstrapping process can be extended by adding application-specific bootstrap tasks.
  • a toolkit and program architecture in accordance with illustrative embodiments of the invention may include a configuration facility having a single API or method for getting properties that can be defined in any number of different sources.
  • One or more of the sources could be: one or more properties files on one or more file systems; environment variables within one or more computers at run time; data within one or more databases; or any other number of suitable permutations and/or combinations of suitable sources.
  • a configuration facility in accordance with illustrative embodiments of the invention enables an architect to assemble any number of these sources behind the configuration facility API so that application developers can go against a single API. The application developers, therefore, do not need to know where the sources are located. Through the bootstrapping process a project architect can assemble the configuration sources that the architect wants to provide to application developers. Any number of these configuration sources may be assembled into or, stated differently, included in, the configuration facility.
  • the declarative style of the bootstrapping process advantageously facilitates modification of configuration data.
  • a factory in accordance with illustrative embodiments of the invention may allow a developer to de-couple how a resource is produced from where the resource is used. This de-coupling provides significant benefits for maintaining an application program over a long period of time and facilitating making changes to the program.
  • a factory in accordance with illustrative embodiments of this invention defines a simple API that application developers program in order to produce references to resources. How these references are produced can be plugged in according to any number of various strategies. This is unlike conventional factories, which typically are more rigid and suited to one particular type of a reference-producing scenario.
  • the factory facility provides a standard way of coupling subsystems and increasing the modularity of an application program thereby facilitating modification of the program.
  • the factory facility may allow for moving access from local to distributed without breaking any higher level parts of an application.
  • a factory in accordance with illustrative embodiments of the invention can be used to lower network connectivity-associated overhead by substituting a lighter weight co-located component for a heavier-weight distributed component, such as an Enterprise Java Bean (“EJB”).
  • EJB Enterprise Java Bean
  • a selector framework in accordance with illustrative embodiments of the invention may allow standard query language to be applied in contexts other than querying a database.
  • the selector framework advantageously may allow for defining context-specific ways of evaluating identifiers within a selector expression.
  • the selector framework may allow application of these types of expressions in different contexts that typically will have different types of identifiers. This is unlike the use of SQL expressions in the database context wherein the identifiers are assumed to be database fields.
  • a selector facility in accordance with illustrative embodiments of the invention provides an engine for evaluating selector expressions and preferably offers a way to extend the selector framework to a number of different contexts.
  • a pipeline architecture in accordance with illustrative embodiments of the invention enables an architect to define a model view controller-like framework for a processing pipeline or message oriented middleware-type application.
  • An application architect and/or developer can specify how each processing component does work through a series of fine-grained activities. The specified activities can be assembled together into an activity plan. There could be several different aspects of an activity plan for covering the basic steps that are commonly performed by processing components. For instance, processing of messages, processing of elements within a message, how output is produced, how errors are handled, how redelivered messages are handled, and the like.
  • the pipeline architecture provides a structured manner for specifying these fine-grained activities.
  • the pipeline architecture provides a significant benefit by allowing developers to focus on writing these fne-grained activities. Developers can then re-use these fine-grained activities in many different types of plans. This in turn significantly simplifies development, testing, integration, maintenance, and modification of an application built in accordance with various inventive pipeline architecture principles.
  • conversation refers to a cohesive set of pages that act together to perform some unit of work, such as purchasing an airline ticket or editing user profile information.
  • An architecture in accordance with illustrative embodiments of the invention provides a way of controlling conversation flow through the use of one or more selectors.
  • a selector is a logical expression that makes certain portions of a conversation available when certain specified conditions have been met.
  • the selectors-based approach provides a significant advantage relative to conventional techniques for controlling web application flow because the selectors-based approach is de-centralized and relatively lightweight. Selectors advantageously provide a simpler way to control the continuity of conversations relative to conventional techniques that often require modeling an application as a finite state machine, which is a relatively complex task.
  • An authorization facility in accordance with illustrative embodiments of the invention may be used for associating permissions with a user to specify which portions of an application a user is authorized to use and which portions of the application the user is not authorized to use.
  • the authorization facility is preferably integrated directly into a Web application and used to associate required permissions that are needed to enter certain Web conversations.
  • the authorization facility can associate requisite permissions at many levels of detail ranging from specific fine-grained parts of an application through larger views of the application.
  • the authorization facility may allow for declaratively associating, through a configuration approach, a required permission to enter a conversation (or a particular page within a conversation) within a Web application.
  • these associated requisite permissions can be modified by changing declarative definitions.
  • FIG. 1 depicts an exemplary distributed computing environment in which various aspects of the present invention may be embodied.
  • FIG. 2 depicts an exemplary computer system in which various aspects of the present invention may be embodied.
  • FIG. 3 depicts various components and aspects of a bootstrapping process in accordance with illustrative embodiments of the invention.
  • FIG. 4 depicts a legend for selected subsequent figures that are Unified Modeling Language (“UML”) analysis models.
  • UML Unified Modeling Language
  • FIG. 5 depicts a UML analysis model for a configuration facility in accordance with illustrative embodiments of the invention.
  • FIG. 6 depicts a UML static class diagram for a detailed illustrative embodiment of a configuration facility in accordance with various inventive principles.
  • FIG. 7 depicts a UML dynamic sequence diagram for a detailed illustrative embodiment of the get environment operation of the configuration facility of FIG. 5 in accordance with various inventive principles.
  • FIG. 8 depicts a UML analysis model, similar to FIG. 5 , for a factory in accordance with illustrative embodiments of the invention.
  • FIG. 9 is a UML static class diagram of a detailed illustrative embodiment of a factory in accordance with various inventive principles.
  • FIG. 10 is a UML dynamic sequence diagram showing exemplary steps performed by a detailed illustrative embodiment of a factory in accordance with various inventive principles.
  • FIG. 11 depicts a UML analysis model for a selector framework in accordance with illustrative embodiments of the invention.
  • FIG. 12 is a UML static class diagram for a detailed illustrative embodiment of a selector framework in accordance with various inventive principles.
  • FIG. 13 is a UML dynamic sequence diagram showing exemplary steps for performing a getObject operation of GrndsSelectiveObject of FIG. 12 .
  • FIG. 14 depicts a UML analysis model of a processing pipeline in accordance with illustrative embodiments of the invention.
  • FIG. 15 is a UML static class diagram for a detailed illustrative embodiment of a pipeline architecture in accordance with various inventive principles
  • FIG. 16 is a UML dynamic sequence diagram showing exemplary steps for implementing a pipeline architecture in accordance with a detailed illustrative embodiment of the invention.
  • FIG. 17 depicts a UML analysis model for controlling Web application flow in accordance with illustrative embodiments of the invention.
  • FIG. 18 is a UML static class diagram for a detailed illustrative embodiment of a Web application framework in accordance with various inventive principles.
  • FIG. 19 is a UML dynamic sequence diagram showing exemplary steps performed by a servlet for handling a request from a Web browser in accordance with a detailed illustrative embodiment of the invention.
  • FIGS. 20 and 21 are UML dynamic sequence diagrams showing exemplary steps performed by an authorization modifier in accordance with a detailed illustrative embodiment of the invention.
  • the invention relates to a robust toolkit or set of components for defining a net-centric application program architecuture that preferably lies on top of the Java 2 Enterprise Edition, commonly known as the J2EE.
  • a toolkit or set of components in accordance with illustrative embodiments of the invention may be separated into various major components or aspects for purposes of discussion. These major components or aspects will be presented herein in an order in which they build on one another to the extent possible. These components or aspects are presented below generally in the following order: (1) the bootstrapping process; (2) the configuration facility; (3) the factory; (4) selectors; (5) the pipeline architecture; (6) Web application control flow; and (7) the authorization facility.
  • the bootstrapping process may allow a project architect to specify in a declarative manner which facilities should be included within a net-centric application program architecture.
  • the configuration facility provides a mechanism for plugging-in any number of various types of configuration sources.
  • the factory can be used for producing references to any number of different types of resources and for de-coupling how the resource references are produced from the context in which the resource references are used.
  • Selectors are essentially logical expressions that can be used in various contexts, such as controlling conversation flow within a Web application.
  • the pipeline architecture can be used for defining a model view controller-like framework in a message oriented middleware-type context.
  • the authorization facility can be integrated into a Web application and used for associating permissions with a user of the Web application program thereby specifying which portions of the program a user is authorized to use and which portions the user is not authorized to use.
  • client device 100 Any of client device 100 , web server 102 , application server 104 , and data server 106 could be a computer, such as computer 200 depicted in FIG. 2 .
  • a distributed computer system could include multiple loosely coupled instances of any of these distributed computer system components.
  • Client device 100 could be a desktop PC, a smart phone, a handheld computer and/or the like.
  • a web application architecture framework could define a model view controller framework such that the view and the controller are implemented on web server 102 via Java Server Pages (JSPs) and Java servlets, respectively; and the model is implemented on the application server 104 via Enterprise JavaBeans (EJB) and/or business domain objects.
  • JSPs Java Server Pages
  • EJB Enterprise JavaBeans
  • computer 200 includes a central processor 210 , a system memory 212 and a system bus 214 that couples various system components including the system memory 212 to the central processor unit 210 .
  • System bus 214 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • the structure of system memory 212 is well known to those skilled in the art and may include a basic input/output system (BIOS) stored in a read only memory (ROM) and one or more program modules such as operating systems, application programs and program data stored in random access memory (RAM).
  • BIOS basic input/output system
  • ROM read only memory
  • RAM random access memory
  • Computer 200 may also include a variety of interface units and drives for reading and writing data.
  • computer 200 includes a hard disk interface 216 and a removable memory interface 220 respectively coupling a hard disk drive 218 and a removable memory drive 222 to system bus 214 .
  • removable memory drives include magnetic disk drives and optical disk drives.
  • the drives and their associated computer-readable media, such as a floppy disk 224 provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for computer 200 .
  • a single hard disk drive 218 and a single removable memory drive 222 are shown for illustration purposes only and with the understanding that computer 200 may include several of such drives.
  • computer 200 may include drives for interfacing with other types of computer readable media.
  • FIG. 2 shows a serial port interface 226 coupling a keyboard 228 and a pointing device 230 to system bus 214 .
  • Pointing device 228 may be implemented with a mouse, track ball, pen device, or similar device.
  • one or more other input devices such as a joystick, game pad, satellite dish, scanner, touch sensitive screen or the like may be connected to computer 200 .
  • Computer 200 may include additional interfaces for connecting devices to system bus 214 .
  • FIG. 2 shows a universal serial bus (USB) interface 232 coupling a video or digital camera 234 to system bus 214 .
  • An IEEE 1394 interface 236 may be used to couple additional devices to computer 200 .
  • interface 236 may be configured to operate with particular manufacturers' interfaces such as FireWire developed by Apple Computer and i.Link developed by Sony.
  • Input devices may also be coupled to system bus 214 through a parallel port, a game port, a PCI board or any other interface used to couple and input device to a computer.
  • Computer 200 also includes a video adapter 240 coupling a display device 242 to system bus 214 .
  • Display device 242 may include a cathode ray tube (CRT), liquid crystal display (LCD), field emission display (FED), plasma display or any other device that produces an image that is viewable by the user. Additional output devices, such as a printing device (not shown), may be connected to computer 200 .
  • Sound can be recorded and reproduced with a microphone 244 and a speaker 266 .
  • a sound card 248 may be used to couple microphone 244 and speaker 246 to system bus 214 .
  • FIG. 2 One skilled in the art will appreciate that the device connections shown in FIG. 2 are for illustration purposes only and that several of the peripheral devices could be coupled to system bus 214 via alternative interfaces.
  • video camera 234 could be connected to IEEE 2394 interface 236 and pointing device 230 could be connected to USB interface 232 .
  • Computer 200 can operate in a networked environment using logical connections to one or more remote computers or other devices, such as a server, a router, a network personal computer, a peer device or other common network node, a wireless telephone or wireless personal digital assistant.
  • Computer 200 includes a network interface 250 that couples system bus 214 to a local area network (LAN) 252 .
  • LAN local area network
  • a wide area network (WAN) 254 can also be accessed by computer 200 .
  • FIG. 2 shows a modem unit 256 connected to serial port interface 226 and to WAN 254 .
  • Modem unit 256 may be located within or external to computer 200 and may be any type of conventional modem such as a cable modem or a satellite modem.
  • LAN 252 may also be used to connect to WAN 254 .
  • FIG. 2 shows a router 258 that may connect LAN 252 to WAN 254 in a conventional manner.
  • network connections shown are exemplary and other ways of establishing a communications link between the computers can be used.
  • the existence of any of various well-known protocols, such as TCP/IP, Frame Relay, Ethernet, FTP, HTTP and the like, is presumed, and computer 200 can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server.
  • Computer 200 could also be operated in a more loosely coupled distributed computing environment.
  • any of various conventional web browsers can be used to display and manipulate data on web pages.
  • the operation of computer 200 can be controlled by a variety of different program modules.
  • program modules are routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types.
  • the present invention may also be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCS, minicomputers, mainframe computers, personal digital assistants and the like.
  • the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote memory storage devices.
  • a bootstrapping process may allow a project architect to use a declarative style for assembling various facilities within the architecture and initializing them.
  • a set of facilities may be provided.
  • each facility is focused on a particular problem, such as logging, configuration information, producing references to other components, or managing the life cycle of a facility.
  • a bootstrapping process may be driven by an XML document at run time.
  • Such an XML document could be edited to set up the architecture differently without having to recompile and/or rebuild the system.
  • the declarative approach to the bootstrapping process could be encapsulated within a specific class that would need to be edited and re-built to change a particular strategy.
  • FIG. 3 depicts various components and aspects of a bootstrapping process in accordance with illustrative embodiments of the invention.
  • XML facility deployment descriptor 300 is an XML document that details the facilities and their components and how those facilities should be set up for a particular application.
  • the XML facility deployment descriptor 300 preferably contains elements for multiple facilities, such as logging, life-cycle management, authorization, and factory.
  • the XML facility deployment descriptor 300 also preferably contains sub-elements that specify any behind-the-scenes components for each facility thereby defining how those facilities will work. For instance, there is a configuration bootstrap task 302 for setting up the configuration facility.
  • the configuration task and the sub-element tasks for each of the sources essentially define a resulting configuration facility produced by the configuration bootstrap task 302 .
  • XML facility bootstrap 304 represents an entity that performs work. Dashed arrow 306 represents a dependency by the XML facility bootstrap 304 upon the XML facility deployment descriptor 300 for performing the XML facility bootstrap's work.
  • a parse facility deployment descriptor step 308 parses XML facility deployment descriptor 300 , which is fed into the parse facility deployment descriptor step 308 via the XML facility bootstrap 304 as indicated by arrows 310 and 312 .
  • the execute facility bootstrap tasks in descriptor step 314 operates on the XML facility deployment descriptor 300 broken down into its elements and iterates over those elements. Each of these elements will typically correspond to a bootstrap task class.
  • configuration bootstrap task 302 preferably: (1) understands the XML facility deployment descriptor elements that were parsed; and (2) does the work of setting up the configuration sources and plugging them into the configuration facility.
  • the XML bootstrap facility may define, as part of its tasks, a framework through which sub-elements are provided to the facility bootstrap task 324 through, for example, a set of simple set-value operations. Following the execute facility bootstrap tasks in descriptor step 314 , the facility bootstrap process is complete, as depicted at 318 in FIG. 3 , and the configuration facility is set up.
  • the facility bootstrap task 324 defines a common API for facility bootstrap tasks.
  • Configuration bootstrap task 302 , logging bootstrap task 320 , and factory bootstrap task 322 are specific implementations of the facility bootstrap task API 324 , as depicted by the hollow arrowhead leading from the configuration bootstrap task 302 , the logging bootstrap task 320 , and the factory bootstrap task 322 to the facility bootstrap task 324 .
  • Ellipses 326 in FIG. 3 represents that the bootstrap process can be extended by adding new bootstrap tasks.
  • Dashed arrow 328 leading from the execute facility bootstrap tasks in descriptor step 314 to facility bootstrap task 324 represents a dependency of the execute facility bootstrap tasks in descriptor step 314 upon the specific implementations of the facility bootstrap task common API 324 .
  • FIG. 4 is essentially a legend for FIGS. 4 - 5 , 8 , 11 , 14 , and 17 , which depict Unified Modeling Language (“UML”) analysis models.
  • FIGS. 4 - 5 , 8 , 11 , 14 , and 17 show major entities within a model of various aspects of a toolkit and a net-centric application program in accordance with the present invention and how those major entities relate to one another. The different types of entities shown in these figures are depicted in FIG. 4 .
  • a boundary class 400 defines an API or an interface.
  • a control class 402 defines a process or an operation for doing some work.
  • An entity class 404 is a concrete thing. An entity class could implement an interface, or it could be a database or something else.
  • arrows between these three major types of components represent either associations or transfers of control similar to a process flow.
  • a common principal which preferably appears in multiple contexts within a toolkit and/or an architecture in accordance with illustrative embodiments of the invention, is the use of a single simple API for application developers to use.
  • Such an API preferably hides a server-provided interface that can have different implementations plugged in and/or composed behind the server-provided interface.
  • the configuration facility is one example in which programmers can get properties of the system through a single get environment operation. The specific details about how such information is retrieved are preferably completely hidden.
  • the GrndsConfigurationSource interface set forth below, defines a simple API, which concrete configuration sources may implement to provide their view of the system's configuration environment.
  • GrndsSystemPropertySource implements getenviroment( ), which returns a set of in-memory system variables. Normally, sources partition the configuration environment into domains and sub-domains, but in the example below, the GrndsSystemPropertySource assigns all system variables to every configuration domain and sub-domain combination.
  • the other operations in the interface in particular init( ), fini( ), clone( ) and refresh( ), are implemented to perform various lifecycle operations that may need to be performed by the source.
  • GrndsConfigurationSource extends Serializable, Cloneable ⁇ public abstract GrndsConfigurationEnvironment getEnvironment( String domain_, String[ ] sub-domains — ) throws GrndsConfigurationException; public abstract void init( String[ ] args — ) throws Exception; public abstract void fini( ) throws Exception; public abstract void refresh( ); public abstract Object clone( ); ⁇ public final class GrndsSystemPropertySource extends GrndsObject implements GrndsConfigurationSource ⁇ public GrndsSystemPropertySource( ) ⁇ super( ); ⁇ public GrndsSystemPropertySource( GrndsSystemPropertySource rhs — ) ⁇ super( ); ⁇ public Object clone( ) ⁇ return new GrndsSystemPropertySource( this ); ⁇ public GrndsConfigurationEnvironment getEnvironment( String domain_, String[
  • a toolkit and program architecture in accordance with illustrative embodiments of the invention may include a configuration facility having a single API or method for getting properties that can be defined in any number of different sources.
  • One or more of the sources could be: one or more properties files on one or more file systems; environment variables within one or more computers at run time; data within one or more databases; or any other number of suitable permutations and/or combinations of suitable sources.
  • a configuration facility in accordance with illustrative embodiments of the invention enables an architect to assemble any number of these sources behind the configuration facility API so that application developers can go against a single API. The application developers, therefore, do not need to know where the sources are located. Through the bootstrapping process a project architect can assemble the configuration sources that the architect wants to provide to application developers. Any number of these configuration sources may be assembled into or, stated differently, included in the configuration facility.
  • the declarative style of the bootstrapping process advantageously facilitates modification of configuration data.
  • a configuration facility could be used to define configuration data, such as a destination URL of a hyperlink.
  • the configuration facility Rather than hard coding the URL, which would require re-compilation and rebuilding of all the code to change the destination URL, the configuration facility preferably associates the URL with a key. Then, the destination URL of the hyperlink can be changed by changing the value associated with the key, which does not require re-compilation and rebuilding of all the code.
  • a configuration facility in accordance with illustrative embodiments of the invention enables an architect to plug different configuration information sources into the configuration facility, as desired, during the bootstrapping process.
  • the configuration facility preferably depends on an abstract configuration source interface, but is provided concrete implementations of that interface, via the bootstrap process, to implement the get environment operation differently, such as to retrieve information from the system environment, from .proporties file. from xml files. and/or the like.
  • Example contents of an XML facility deployment descriptor document are provided in section VIII below.
  • FIG. 5 depicts a UML analysis model for a configuration framework in accordance with illustrative embodiments of the invention.
  • the sources, or where the configuration comes from, are de-coupled from the act of getting to or accessing the configuration.
  • the get configuration environment operation 502 is the main operation behind configuration API 500 .
  • the get environment operation 502 uses configuration source interface 504 to build a single environment based upon data from one or more configuration sources, such as property file source 505 , XML file source 506 , and system property source 507 .
  • Ellipses 508 in FIG. 5 represents additional configuration sources that can be plugged into an architecture via specific implementations of configuration source interface 504 .
  • configuration source interface 504 namely, property file source 505 , XML file source 506 , and system property source 507 , are depicted in FIG. 5 with entity class symbols 404 to convey that these implementations of configuration source interface 504 perform respective operations of obtaining configuration information from various configuration sources.
  • the configuration sources are plugged into the configuration API 500 via the bootstrap process, which is depicted in FIG. 5 and discussed above.
  • Configuration sources may be specified via the configuration bootstrap task 502 , or configuration sources may be specified in an XML file or the like to dictate how the configuration is assembled together.
  • the configuration facility builds the configuration environment by iterating over each configuration source, requesting its view of the environment.
  • the configuration facility combines each source's environment view into a whole, preferably taking into consideration these precedence rules: configuration sources are ordered within the facility based on when they are added with earlier sources taking precedence over later sources.
  • Configuration environments are organized into domains and sub-domains, which are logically defined, and sub-domains override information specified at the domain level.
  • FIG. 6 depicts a UML static class diagram for a detailed illustrative embodiment of a configuration facility in accordance with various inventive principles.
  • FIG. 6 shows major components of such a configuration facility, including GrndsPropertyFileSource 505 ′, GrndsXmlFileSource 506 ′, and GrndsSystemPropertySource 507 ′ objects, which are concrete implementations of GrndsConfiguration common API definition 500 ′.
  • FIG. 7 depicts a UML dynamic sequence diagram for a detailed illustrative embodiment of the get environment operation 502 in accordance with various inventive principles.
  • FIG. 7 shows exemplary steps for delegating work from grndsconfiguration 500 ′ API to GrndsConfigurationSource 504 ′.
  • the bootstrapping process preferably defines a mechanism to actively set up application architecture facilities, whereas the configuration facility is typically one of the facilities set up by the bootstrap mechanism.
  • the configuration facility preferably defines a mechanism to get information about the application and its environment at runtime.
  • the bootstrap mechanism is preferably capable of setting up the configuration facility first, and then using data retrieved from the configuration facility to configure other facilities. While the bootstrap mechanism may use the configuration facility to help set up other facilities, the other facilities do net necessarily depend on the configuration facility. In fact, facilities are preferably defined to be independent of the configuration facility thereby enabling the bootstrap mechanism to use any means for getting environment information.
  • a factory in accordance with illustrative embodiments of the invention may allow a developer to de-couple how a resource is produced from where the resource is used. This de-coupling provides significant benefits for maintaining an application program over a long period of time and facilitating making changes to the program.
  • a factory in accordance with illustrative embodiments of the invention defines a simple API that application developers program in order to produce references to resources. How these references are produced can be plugged in according to any number of various strategies. This is unlike conventional factories, which typically are more rigid and suited to one particular type of a reference-producing scenario.
  • FIG. 8 depicts a UML analysis model, similar to FIG. 5 , for a factory in accordance with illustrative embodiments of the invention.
  • the produce operation 802 which produces a reference to a resource, is the main operation behind the component factory API 800 .
  • Various producers such as those represented by local producer 805 , EJB producer 806 , and XML activity plan producer 807 are concrete implementations of the producer interface 804 . These producers produce references to resources. These producers are plugged into factory API 800 through the bootstrap mechanism. Alternatively, the factory could assemble various producers underneath it by using information located in a Java standard Properties class, such as one created using the configuration facility.
  • FIG. 9 is a UML static class diagram of a detailed illustrative embodiment of a factory in accordance with various inventive principles.
  • FIG. 9 depicts the relationship among various components including GrndsFactory 800 ′, GrndsProducer 804 ′, produce 802′, GrndsLocalProducer 805 ′, and GrndsEjbProducer 806 ′, which correspond to the following entities depicted in FIG. 8 : component factory API 800 , producer interface 804 , the produce operation 802 , local producer 805 , and EJB producer 806 .
  • FIG. 10 is a UML dynamic sequence diagram showing exemplary steps performed by a detailed illustrative embodiment of a factory in accordance with various inventive principles.
  • FIG. 10 depicts exemplary steps for identifying a producer corresponding to a logical key or, if there is no corresponding producer, delegating to a default producer, which is preferably set up through a bootstrapping process in accordance with various inventive principles.
  • the factory facility provides a standard way of coupling subsystems and increasing the modularity of an application program thereby facilitating modification of the program.
  • the factory facility may allow for moving access from local to distributed without breaking any higher level parts of an application. In other words, higher level portions of the application are not directly dependent upon particular resource references. Accordingly a generalized factory facility is provided that may allow for changing out different producers behind the scenes.
  • a factory in accordance with illustrative embodiments of the invention can be used to lower network connectivity-associated overhead by substituting a lighter weight co-located component for a heavier-weight distributed component, such as an Enterprise Java Bean (“EJB”).
  • EJB's are typically maintained by an application server for performing tasks such as working with databases and/or legacy application software.
  • a factory in accordance with illustrative embodiments of the invention advantageously may allow for the interchangeability of co-located components and distributed components without requiring modification of the code of either the co-located components or the distributed components.
  • a factory in accordance with illustrative embodiments of the invention can also be used to facilitate production of various other types of resources including, but not limited to, accessing database connections and simplifying access to a central naming service.
  • Example contents of an XML facility deployment descriptor document in accordance with illustrative embodiments of the invention are set forth below.
  • XML Facility Bootstrap class 504 is preferably responsible for parsing an XML facility-deployment descriptor file 500 and for executing each facility bootstrap task.
  • two facilities are bootstrapped: a configuration facility and a factory facility.
  • the configuration facility is setup with three configuration sources of the type shown in FIG. 5 : a property file source 505 ; an XML file source 506 , which is further configured with a collection of XML files organized into domains and sub-domains; and a system property source 507 .
  • the factory facility is setup with a set of producers and targets.
  • the producers are named, given an implementation class, and may be provided with additional configuration information.
  • the factory targets are given a logical name, which can be used by developers to identify what should be produced, a named producer, and may be given additional properties to aid production.
  • XmlPipeline which is assigned a single target, Plan.
  • the Plan target is given a property, plan.file, that the producer parses to produce an activity plan object, GrndsActivityPlan.
  • the selector framework may allow standard query language to be applied in contexts other than querying a database.
  • the selector framework advantageously may allow defining context specific ways of evaluating identifiers within a selector expression.
  • a Standard Query Language (“SQL”) expression includes three major elements: identifiers, which are like variables; operators, such as a string comparison operator to check equality; and literals, such as numbers or character strings.
  • SQL Standard Query Language
  • the selector framework may allow application of these types of expressions in different contexts that typically will have different types of identifiers. This is unlike the use of SQL expressions in the database context wherein the identifiers are assumed to be database fields.
  • a selector facility in accordance with illustrative embodiments of the invention provides an engine for evaluating selector expressions and preferably offers a way to extend the selector framework to a number of different contexts.
  • the selector framework can be extended to the pipeline architecture, discussed below in section X.
  • selectors can be applied to various activities assembled into an activity plan to determine whether various activities should be applied to a message and/or to various elements within a message.
  • FIG. 11 depicts a UML analysis model for a selector framework in accordance with illustrative embodiments of the invention.
  • Selector API 1100 can be used for testing whether an expression is true or not, as depicted by the test expression operation 1102 .
  • Test expression operation 1102 uses the evaluate identifier strategy API 1104 for applying selectors to different problems. For example, there could be a special identifier strategy for the pipeline for pulling identifiers from the pipeline context, from the message, or from other areas. This is different from the Web application context where identifier information could be pulled from an HTTP request or from some different parts of a Web session.
  • Test expression 1102 applies the evaluate identifier strategy 1104 to the identifier entity 1106 . Based upon the value of identifier 1106 and any literals in test expression 1102 , a determination is made as to whether the test expression 1102 is true or false.
  • FIG. 12 is a UML static class diagram for a detailed illustrative embodiment of a selector framework in accordance with various inventive principles.
  • GrndsSelector 1100 ′, GrndsEvaluateldentifier 1104 ′, and GrndsIdentifier 1106 ′ correspond to the selector API 1100 , the evaluate identifier strategy 1104 , and the identifier entity 1106 .
  • GrndsSelectiveObject 1200 includes a getObject operation 1202 , illustrative steps of which are depicted in FIG. 13 .
  • an application developer can specify which identifiers can be used within selector expressions thereby facilitating tailoring the selector framework to any number of different contexts.
  • a toolkit in accordance with illustrative embodiments of the invention preferably includes two separate and unique concrete implementations of the evaluate identifier strategy 1104 , with one implementation corresponding to the pipeline and another implementation corresponding to the Web application. These unique strategies are passed into selector 1100 during the building of selector expression 1102 . Selector expressions are built when the web application XML map and pipeline activity plan are constructed; such as, during interpretation of XML configuration data for each respective framework.
  • a message oriented middleware approach facilitates integrating disparate computing systems by allowing one system to publish data to a work queue and by allowing a second system to subscribe to messages from the queue. In this manner, the two computer systems are advantageously able to remain relatively de-coupled.
  • a pipeline architecture in accordance with illustrative embodiments of the invention enables an architect to define a model view controller-like framework for a processing pipeline or message oriented middleware-type application.
  • An application architect and/or developer can specify how each processing component does work through a series of fine-grained activities.
  • a processing component will receive a message as an input and produce a message as an output.
  • the specified activities can be assembled together into an activity plan.
  • the pipeline architecture provides a structured manner for specifying these fine-grained activities.
  • the pipeline architecture provides a significant benefit by allowing developers to focus on writing these fine-grained activities. Developers can then re-use these fine-grained activities in many different types of plans. This in turn significantly simplifies development, testing, integration, maintenance, and modification of an application built in accordance with various inventive pipeline architecture principles.
  • FIG. 14 depicts a UML analysis model of a processing pipeline in accordance with illustrative embodiments of the invention.
  • JMS is a standard Java API for message oriented middleware. Destinations are a major component of the JMS. Destinations are code that plugs into the JMS middleware for receiving messages.
  • the pipeline 1402 subscribes to and receives messages and/or events from input JMS destination 1400 . When the pipeline 1402 receives a message, pipeline 1402 invokes the on Message process 1404 , which uses an activity plan 1406 .
  • the activity plan 1406 is an entity that describes the various activities that are used for processing the incoming message. In this manner, the activity plan defines the plan for performing that processing. Activity plans are described in more detail below.
  • the get activities operation 1408 uses activity selector 1410 , which is similar to the selector framework used for Web application flow, to execute one or more activities 1412 .
  • activities will typically be application-specific concrete implementations of Activity interface 1412 for performing tasks within an application.
  • activities can be filtered or used based upon a selector expression wherein the selector expression is based upon information in the received message, some state of the application, or the like. Accordingly, not all activities in an activity plan will necessarily be executed for a particular message. Instead, activities may be selectively executed for a particular message.
  • FIG. 15 is a UML static class diagram for a detailed illustrative embodiment of a pipeline architecture in accordance with various inventive principles.
  • GrndsPipeline 1402 ′, GrndsActivityPlan 1406 ′, and GrndsPipelineActivity 1412 ′ correspond to pipeline 1402 , activity plan 1406 , and activity interface 1412 .
  • FIG. 16 is a UML dynamic sequence diagram showing exemplary steps for implementing a pipeline architecture in accordance with a detailed illustrative embodiment of the invention.
  • FIG. 16 depicts steps for abstracting various details of message oriented middleware so that developers are able to focus on developing activities for processing messages to perform specific tasks, thereby facilitating re-use of these activities in various types of activity plans.
  • An activity plan which is described in more detail below, essentially defines the steps to perform some process.
  • the processing pipeline 1402 is an engine that receives events or messages.
  • the pipeline 1402 does work through activities.
  • An activity plan, such as activity plan 1406 tells the pipeline 1402 which activities should be performed and under what conditions those activities should be performed. In this manner, the activity plan 1406 ties specific tasks or activities together into a cohesive process.
  • An activity plan in accordance with illustrative embodiments of the invention may include several different sections.
  • One section could be a redelivered section for handling a situation in which a message is being redelivered, which may occur when a server shuts down and is restarted. Under these circumstances, messages may be sent more than once, which is not a normal operating condition.
  • an activity plan may include a message section, which performs activities on a received message at the message level or, in other words, performs activities on a received message as a whole. Messages, however, could contain many elements. Accordingly, an activity plan may include a message element section that executes a series of activities on individual elements within a received message. For example, if a message has five elements within its body, then the message element section would be applied to each of these five elements. Stated another way the message elements section would be applied five times.
  • An activity plan may also include an output section for doing work to produce output or results of the process at the message level. Accordingly, the output section would typically be executed one time per message.
  • An activity plan may also include a set of error handling sections that may be applied at the message level and/or the message element level for handling situations in which errors are thrown while processing a message.
  • An architecture in accordance with illustrative embodiments of the invention provides a way of controlling conversation flow through the use of one or more selectors.
  • a selector is a logical expression that makes certain portions of a conversation available when certain specified conditions have been met. For example, in the context of the airline ticket purchase and seat reservation example, an application could set a flag, or a variable, to indicate that the user has purchased a ticket before sending the user to the seat selection page. A corresponding selector could be associated with producing the seat selection page. The selector could then be evaluated and used for making the seat reservation page available if and only if the user has actually purchased a ticket for a particular flight.
  • the web application would not allow the user to select a seat because the selector would evaluate to false thereby causing an error page to be displayed to the user and/or some other appropriate action to be taken.
  • the selectors-based approach provides a significant advantage relative to conventional techniques for controlling web application flow because the selectors-based approach is de-centralized and relatively lightweight. Selectors advantageously provide a simpler way to control the continuity of conversations relative to conventional techniques, which often require modeling an application as a finite state machine. Modeling Web applications as finite state machines is a relatively complex task.
  • FIG. 17 depicts a UML analysis model for a Web application in accordance with illustrative embodiments of the invention.
  • Servlet 1700 is a standard API within the Java language.
  • Servlet 1700 is a plug-in point for the server.
  • the elements that do work to process the request are implemented behind the servlet API 1700 . Accordingly, the remainder of FIG. 17 implements that API and plugs into that engine.
  • FIG. 17 shows how processing of a Web request may be structured in accordance with illustrative embodiments of the invention.
  • the execute exchange operation 1702 is the main operation behind the Servlet 1700 API.
  • the execute exchange operation 1702 implements specific details of its algorithm using the conversation interface 1704 .
  • the conversation interface 1704 provides access to get exchange presentation 1706 and get exchange activity 1708 .
  • These elements define the separation of concerns within the model view controller framework.
  • the implementation of Servlet 1700 depicted in FIG. 17 translates user events, such as a user clicking on a link or a button, into application commands.
  • the processing of those application commands includes two main units of work.
  • the first main unit of work is performing some business activity in conjunction with the model layer, which defines the business logic.
  • the activity defines the application logic, while the model layer defines the more detailed business logic, which may span applications.
  • the second main unit of work is that the results of the activity are displayed through a presentation, which defines the view layer.
  • the conversation defines associations between the activity and presentation elements with their corresponding user events.
  • execute exchange 1702 When execute exchange 1702 begins running, it tells the conversation 1704 to do whatever work the conversation needs to do before the exchange's activity and presentation are processed.
  • the begin response operation 1710 looks to see whether there are any selectors 1712 registered for the received event/command. If a selector is identified for the received event/command, it is evaluated. If the selector evaluates to true, the event/command is processed further, otherwise an illegal state exception is thrown, which may be routed by the J2EE platform to an error page presented to the user.
  • an execute modifiers sub-process 1714 of the begin response operation 1710 transfers control to the execute modifiers operation 1714 and the exchange modifier 1716 API, which defines one or more extensions to the conversation, such as the authorization exchange modifier 1718 .
  • the execute modifiers operation iterates over each configured exchange modifier and executes them sequentially.
  • the authorization exchange modifier 1718 checks whether the user has an appropriate permission to work with a particular part of an application or to perform a particular command, which is done through authorization facility 1722 , which is described in more detail below.
  • an XML document that describes the Web application structure.
  • Such an XML document preferably ties: conversations to Servlets; commands to conversations; and activities and presentations to those commands.
  • Such an XML document also preferably ties one or more selectors to those commands, and, with respect to the authorization facility 1722 , the XML document may allow for specification of a minimum set of permissions that a user needs to have in order to execute a conversation and/or any specific command within a conversation.
  • the conversation will return the configured exchange activity, which the servlet will run, and the servlet will work with various components within the business model to do work such as looking up all the seats that are available in the airline ticket purchase and seat reservation example.
  • the servlet will then execute the presentation or, stated otherwise, output results to the user.
  • FIG. 18 is a UMIL static class diagram for a detailed illustrative embodiment of a Web application framework in accordance with various inventive principles. Entities depicted in FIG. 18 with prime reference numbers correspond to entities having corresponding non-prime reference numbers.
  • FIG. 19 is a UML dynamic sequence diagram showing exemplary steps performed by a servlet for handling a request from a Web browser in accordance with a detailed illustrative embodiment of the invention.
  • the conversation contains one command and is protected by an authorization modifier.
  • the command has a selector that prevents it from being available if the configuration property, isGalleryAvailable, is not set to “true”.
  • the default command is associated with a single activity, implemented by the conversation method “default_xa( )”.
  • the default command is associated to two presentations: a standard path implemented via the /grnds-docs/gallery/default/defaultjsp file; and an alternative implemented via the /grnds-docs/gallery/default/default.errorjsp file.
  • the alternative presentation branch is used if the activity set the presentation branch by calling the conversation's setPresentationBranch(“error”).
  • the authorization modifier sets two permissions, one for the conversation and one for the default command.
  • Authorization facility 1722 may be used for associating permissions with a user to specify which portions of an application a user is authorized to use and which portions of the application the user is not authorized to use.
  • the authorization facility is preferably integrated directly into a Web application and used to associate required permissions that are needed to enter certain Web conversations. A user attempting to enter a Web conversation without the requisite permissions could be denied access to the Web conversation.
  • the authorization facility can associate requisite permissions at many levels of detail ranging from specific fine-grained parts of an application through larger views of the application.
  • the authorization facility may allow for declaratively associating, through a configuration approach, a required permission to enter a conversation (or a particular page within a conversation) within a Web application.
  • these associated requisite permissions can be modified by changing declarative definitions.
  • These declarative definitions can be implemented in XML or any other suitable format.
  • the need to edit, compile, and re-build Java code in order to change authorization permissions for the application and/or various parts of the application can, therefore, be avoided, thereby facilitating maintenance and/or modification of the authorization permissions.
  • plug-in point 1900 is the point at which the Web application authorization integation UML dynamic sequence diagram of FIG. 20 plugs into the steps shown in FIG. 19 .
  • FIGS. 20 and 21 are UML dynamic sequence diagrams showing exemplary steps performed by the beginResponse and checkAuthorization operations of an authorization modifier in accordance with a detailed illustrative embodiment of the invention.

Abstract

A robust toolkit provides facilities that can be assembled in a modular manner to specify the fundamental architecture of a net-centric application. A bootstrapping process assembles various facilities within the architecture. A configuration facility defines an API for getting properties that can be defined in any number of different types of sources. A factory de-couples how a resource is produced from where the resource is used. A selector framework applies standard query language to contexts other than querying a database. A pipeline architecture defines a model view controller-like framework for a processing pipeline. Selectors are used to specify when certain portions of a Web conversation should be made available to a user. An authorization facility associates permissions with a user to specify which portions of an application a user is authorized to use.

Description

    PRIORITY INFORMATION
  • This application is a divisional of U.S. patent application Ser. No. 09/859,765 filed on May 17, 2001, which is herein incorporated by reference in its entirety.
  • FIELD OF THE INVENTION
  • The invention relates to a toolkit for specifying net-centric application program architectures. More specifically, the invention relates to various general and reusable components, facilities, and frameworks for robustly structuring a net-centric application program in a modular manner.
  • BACKGROUND OF THE INVENTION
  • Java 2 Platform, Enterprise Edition (J2EE) is a platform that enables solutions for developing, deploying and managing multi-tier net-centric or server-centric applications. J2EE utilizes Java 2 Platform, Standard Edition to extend a Java platform to the enterprise level.
  • Conventionally, J2EE-based products have typically been implemented as “one-off” implementations on top of the J2EE platform. A “one-off” implementation refers to a solution that is focused on a specific set of requirements, with little or no thought about reuse across other problem domains. Conventional J2EE-based one-off application architecture implementations typically include facilities for logging errors, setting up configuration behind the application, and structuring the application in accordance with the commonly known framework or pattern referred to as the model view controller.
  • As is well-known in the art, the model view controller framework includes three layers that work together: (1) the view layer, which describes how information is presented to an application user; (2) the controller layer, which interprets how user actions are translated into business activities or work within the application; and (3) the model layer, which performs complicated computational tasks such as working with a database. Activities and Presentations define boundary points in the Model-View Controller framework. Activities define the boundary between the Controller and the Model, while Presentations define the boundary between the Controller and the View. These boundary points define what is commonly referred to as separation of concerns.
  • An alternative structural framework relative to the model view controller is message oriented middleware. Message oriented middleware based applications are essentially hooked together through a series of work queues for sending messages from one processing component to another processing component through these queues. The work queues typically include some type of message send and message receive mechanisms. Message oriented middleware tasks are performed by exchanging messages in an asynchronous manner, which is in contrast to the synchronous nature of the remote procedure call paradigm. Although the remote procedure call paradigm has been widely used, the message oriented middleware approach is beginning to be used more often than it has in the past. The message oriented middleware structural framework facilitates managing the work performed by such a series of queues by creating a processing pipeline in which work is performed on messages that are passed from one processing component to another processing component. Passing messages or work units between these processing components is managed through a messaging pipeline.
  • Unfortunately, conventional one-off J2EE-based, and other conventional net-centric application, program implementations tend to be fairly rigidly configured and not well suited to component and/or facility re-use, ease of maintenance, and future modification.
  • Accordingly, there is a need for a robust toolkit that provides facilities that can be assembled in a modular manner thereby enabling an application architect to specify the fundamental architecture of a net-centric application program including specifying which facilities the architect wants, and which facilities the architect does not want, to use for a particular net-centric application program.
  • BRIEF SUMMARY OF THE INVENTION
  • The invention relates to a robust toolkit or set of components for defining a net-centric application program architecture that preferably lies on top of the Java 2 Enterprise Edition, commonly known as the J2EE. A toolkit or set of components in accordance with illustrative embodiments of the invention may be separated into various major components or aspects for purposes of discussion, including: (1) the bootstrapping process; (2) the configuration facility; (3) the factory; (4) selectors; (5) the pipeline architecture; (6) Web application control flow; and (7) the authorization facility.
  • A bootstrapping process in accordance with illustrative embodiments of the invention may allow a project architect to use a declarative style for assembling various facilities within the architecture and initializing them. The bootstrapping process may be driven by an XML document at run time. The XML document could be edited to set up the architecture differently without having to recompile and/or rebuild the system. The bootstrapping process can be extended by adding application-specific bootstrap tasks.
  • A toolkit and program architecture in accordance with illustrative embodiments of the invention may include a configuration facility having a single API or method for getting properties that can be defined in any number of different sources. One or more of the sources could be: one or more properties files on one or more file systems; environment variables within one or more computers at run time; data within one or more databases; or any other number of suitable permutations and/or combinations of suitable sources. A configuration facility in accordance with illustrative embodiments of the invention enables an architect to assemble any number of these sources behind the configuration facility API so that application developers can go against a single API. The application developers, therefore, do not need to know where the sources are located. Through the bootstrapping process a project architect can assemble the configuration sources that the architect wants to provide to application developers. Any number of these configuration sources may be assembled into or, stated differently, included in, the configuration facility. The declarative style of the bootstrapping process advantageously facilitates modification of configuration data.
  • A factory in accordance with illustrative embodiments of the invention may allow a developer to de-couple how a resource is produced from where the resource is used. This de-coupling provides significant benefits for maintaining an application program over a long period of time and facilitating making changes to the program. A factory in accordance with illustrative embodiments of this invention defines a simple API that application developers program in order to produce references to resources. How these references are produced can be plugged in according to any number of various strategies. This is unlike conventional factories, which typically are more rigid and suited to one particular type of a reference-producing scenario.
  • The factory facility provides a standard way of coupling subsystems and increasing the modularity of an application program thereby facilitating modification of the program. Advantageously, the factory facility may allow for moving access from local to distributed without breaking any higher level parts of an application. A factory in accordance with illustrative embodiments of the invention can be used to lower network connectivity-associated overhead by substituting a lighter weight co-located component for a heavier-weight distributed component, such as an Enterprise Java Bean (“EJB”).
  • A selector framework in accordance with illustrative embodiments of the invention may allow standard query language to be applied in contexts other than querying a database. The selector framework advantageously may allow for defining context-specific ways of evaluating identifiers within a selector expression. The selector framework may allow application of these types of expressions in different contexts that typically will have different types of identifiers. This is unlike the use of SQL expressions in the database context wherein the identifiers are assumed to be database fields. A selector facility in accordance with illustrative embodiments of the invention provides an engine for evaluating selector expressions and preferably offers a way to extend the selector framework to a number of different contexts.
  • A pipeline architecture in accordance with illustrative embodiments of the invention enables an architect to define a model view controller-like framework for a processing pipeline or message oriented middleware-type application. An application architect and/or developer can specify how each processing component does work through a series of fine-grained activities. The specified activities can be assembled together into an activity plan. There could be several different aspects of an activity plan for covering the basic steps that are commonly performed by processing components. For instance, processing of messages, processing of elements within a message, how output is produced, how errors are handled, how redelivered messages are handled, and the like.
  • The pipeline architecture provides a structured manner for specifying these fine-grained activities. The pipeline architecture provides a significant benefit by allowing developers to focus on writing these fne-grained activities. Developers can then re-use these fine-grained activities in many different types of plans. This in turn significantly simplifies development, testing, integration, maintenance, and modification of an application built in accordance with various inventive pipeline architecture principles.
  • Within a Web application, there are often conversations, or portions of the application, that should follow a very specific control flow, such as going from page A to page B to page C in only that specific order. Web application developers frequently confront this situation, namely, controlling the continuity of conversations within Web applications. The term conversation refers to a cohesive set of pages that act together to perform some unit of work, such as purchasing an airline ticket or editing user profile information.
  • An architecture in accordance with illustrative embodiments of the invention provides a way of controlling conversation flow through the use of one or more selectors. Within the Web application framework context, a selector is a logical expression that makes certain portions of a conversation available when certain specified conditions have been met. The selectors-based approach provides a significant advantage relative to conventional techniques for controlling web application flow because the selectors-based approach is de-centralized and relatively lightweight. Selectors advantageously provide a simpler way to control the continuity of conversations relative to conventional techniques that often require modeling an application as a finite state machine, which is a relatively complex task.
  • An authorization facility in accordance with illustrative embodiments of the invention may be used for associating permissions with a user to specify which portions of an application a user is authorized to use and which portions of the application the user is not authorized to use. The authorization facility is preferably integrated directly into a Web application and used to associate required permissions that are needed to enter certain Web conversations. Advantageously, the authorization facility can associate requisite permissions at many levels of detail ranging from specific fine-grained parts of an application through larger views of the application. The authorization facility may allow for declaratively associating, through a configuration approach, a required permission to enter a conversation (or a particular page within a conversation) within a Web application. Advantageously, these associated requisite permissions can be modified by changing declarative definitions. These declarative definitions can be implemented in XML or any other suitable format. The need to edit, compile, and re-build Java code in order to change authorization permissions for the application and/or various parts of the application can, therefore, be avoided, thereby facilitating maintenance and/or modification of the authorization permissions.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 depicts an exemplary distributed computing environment in which various aspects of the present invention may be embodied.
  • FIG. 2 depicts an exemplary computer system in which various aspects of the present invention may be embodied.
  • FIG. 3 depicts various components and aspects of a bootstrapping process in accordance with illustrative embodiments of the invention.
  • FIG. 4 depicts a legend for selected subsequent figures that are Unified Modeling Language (“UML”) analysis models.
  • FIG. 5 depicts a UML analysis model for a configuration facility in accordance with illustrative embodiments of the invention.
  • FIG. 6 depicts a UML static class diagram for a detailed illustrative embodiment of a configuration facility in accordance with various inventive principles.
  • FIG. 7 depicts a UML dynamic sequence diagram for a detailed illustrative embodiment of the get environment operation of the configuration facility of FIG. 5 in accordance with various inventive principles.
  • FIG. 8 depicts a UML analysis model, similar to FIG. 5, for a factory in accordance with illustrative embodiments of the invention.
  • FIG. 9 is a UML static class diagram of a detailed illustrative embodiment of a factory in accordance with various inventive principles.
  • FIG. 10 is a UML dynamic sequence diagram showing exemplary steps performed by a detailed illustrative embodiment of a factory in accordance with various inventive principles.
  • FIG. 11 depicts a UML analysis model for a selector framework in accordance with illustrative embodiments of the invention.
  • FIG. 12 is a UML static class diagram for a detailed illustrative embodiment of a selector framework in accordance with various inventive principles.
  • FIG. 13 is a UML dynamic sequence diagram showing exemplary steps for performing a getObject operation of GrndsSelectiveObject of FIG. 12.
  • FIG. 14 depicts a UML analysis model of a processing pipeline in accordance with illustrative embodiments of the invention.
  • FIG. 15 is a UML static class diagram for a detailed illustrative embodiment of a pipeline architecture in accordance with various inventive principles
  • FIG. 16 is a UML dynamic sequence diagram showing exemplary steps for implementing a pipeline architecture in accordance with a detailed illustrative embodiment of the invention.
  • FIG. 17 depicts a UML analysis model for controlling Web application flow in accordance with illustrative embodiments of the invention.
  • FIG. 18 is a UML static class diagram for a detailed illustrative embodiment of a Web application framework in accordance with various inventive principles.
  • FIG. 19 is a UML dynamic sequence diagram showing exemplary steps performed by a servlet for handling a request from a Web browser in accordance with a detailed illustrative embodiment of the invention.
  • FIGS. 20 and 21 are UML dynamic sequence diagrams showing exemplary steps performed by an authorization modifier in accordance with a detailed illustrative embodiment of the invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • I. Introduction
  • The invention relates to a robust toolkit or set of components for defining a net-centric application program architecuture that preferably lies on top of the Java 2 Enterprise Edition, commonly known as the J2EE. A toolkit or set of components in accordance with illustrative embodiments of the invention may be separated into various major components or aspects for purposes of discussion. These major components or aspects will be presented herein in an order in which they build on one another to the extent possible. These components or aspects are presented below generally in the following order: (1) the bootstrapping process; (2) the configuration facility; (3) the factory; (4) selectors; (5) the pipeline architecture; (6) Web application control flow; and (7) the authorization facility.
  • Before discussing these major components or aspects in detail, a brief introductory description of these aspects or components will be provided. The bootstrapping process may allow a project architect to specify in a declarative manner which facilities should be included within a net-centric application program architecture. The configuration facility provides a mechanism for plugging-in any number of various types of configuration sources. The factory can be used for producing references to any number of different types of resources and for de-coupling how the resource references are produced from the context in which the resource references are used. Selectors are essentially logical expressions that can be used in various contexts, such as controlling conversation flow within a Web application. The pipeline architecture can be used for defining a model view controller-like framework in a message oriented middleware-type context. The authorization facility can be integrated into a Web application and used for associating permissions with a user of the Web application program thereby specifying which portions of the program a user is authorized to use and which portions the user is not authorized to use.
  • II. Exemplary Distributed Computing Environment
  • Various aspects of the present invention may be embodied on a distributed computer system, such as the system shown in FIG. 1. Any of client device 100, web server 102, application server 104, and data server 106 could be a computer, such as computer 200 depicted in FIG. 2. As will be apparent, although only a single client device 102, application server 104, and data server 106 are depicted in FIG. 1, a distributed computer system could include multiple loosely coupled instances of any of these distributed computer system components. Client device 100 could be a desktop PC, a smart phone, a handheld computer and/or the like. In accordance with certain inventive principles described in more detail below, a web application architecture framework could define a model view controller framework such that the view and the controller are implemented on web server 102 via Java Server Pages (JSPs) and Java servlets, respectively; and the model is implemented on the application server 104 via Enterprise JavaBeans (EJB) and/or business domain objects.
  • Referring to FIG. 2, computer 200 includes a central processor 210, a system memory 212 and a system bus 214 that couples various system components including the system memory 212 to the central processor unit 210. System bus 214 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The structure of system memory 212 is well known to those skilled in the art and may include a basic input/output system (BIOS) stored in a read only memory (ROM) and one or more program modules such as operating systems, application programs and program data stored in random access memory (RAM).
  • Computer 200 may also include a variety of interface units and drives for reading and writing data. In particular, computer 200 includes a hard disk interface 216 and a removable memory interface 220 respectively coupling a hard disk drive 218 and a removable memory drive 222 to system bus 214. Examples of removable memory drives include magnetic disk drives and optical disk drives. The drives and their associated computer-readable media, such as a floppy disk 224 provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for computer 200. A single hard disk drive 218 and a single removable memory drive 222 are shown for illustration purposes only and with the understanding that computer 200 may include several of such drives. Furthermore, computer 200 may include drives for interfacing with other types of computer readable media.
  • A user can interact with computer 200 with a variety of input devices. FIG. 2 shows a serial port interface 226 coupling a keyboard 228 and a pointing device 230 to system bus 214. Pointing device 228 may be implemented with a mouse, track ball, pen device, or similar device. Of course one or more other input devices (not shown) such as a joystick, game pad, satellite dish, scanner, touch sensitive screen or the like may be connected to computer 200.
  • Computer 200 may include additional interfaces for connecting devices to system bus 214. FIG. 2 shows a universal serial bus (USB) interface 232 coupling a video or digital camera 234 to system bus 214. An IEEE 1394 interface 236 may be used to couple additional devices to computer 200. Furthermore, interface 236 may be configured to operate with particular manufacturers' interfaces such as FireWire developed by Apple Computer and i.Link developed by Sony. Input devices may also be coupled to system bus 214 through a parallel port, a game port, a PCI board or any other interface used to couple and input device to a computer.
  • Computer 200 also includes a video adapter 240 coupling a display device 242 to system bus 214. Display device 242 may include a cathode ray tube (CRT), liquid crystal display (LCD), field emission display (FED), plasma display or any other device that produces an image that is viewable by the user. Additional output devices, such as a printing device (not shown), may be connected to computer 200.
  • Sound can be recorded and reproduced with a microphone 244 and a speaker 266. A sound card 248 may be used to couple microphone 244 and speaker 246 to system bus 214. One skilled in the art will appreciate that the device connections shown in FIG. 2 are for illustration purposes only and that several of the peripheral devices could be coupled to system bus 214 via alternative interfaces. For example, video camera 234 could be connected to IEEE 2394 interface 236 and pointing device 230 could be connected to USB interface 232.
  • Computer 200 can operate in a networked environment using logical connections to one or more remote computers or other devices, such as a server, a router, a network personal computer, a peer device or other common network node, a wireless telephone or wireless personal digital assistant. Computer 200 includes a network interface 250 that couples system bus 214 to a local area network (LAN) 252. Networking environments are commonplace in offices, enterprise-wide computer networks and home computer systems.
  • A wide area network (WAN) 254, such as the Internet, can also be accessed by computer 200. FIG. 2 shows a modem unit 256 connected to serial port interface 226 and to WAN 254. Modem unit 256 may be located within or external to computer 200 and may be any type of conventional modem such as a cable modem or a satellite modem. LAN 252 may also be used to connect to WAN 254. FIG. 2 shows a router 258 that may connect LAN 252 to WAN 254 in a conventional manner.
  • It will be appreciated that the network connections shown are exemplary and other ways of establishing a communications link between the computers can be used. The existence of any of various well-known protocols, such as TCP/IP, Frame Relay, Ethernet, FTP, HTTP and the like, is presumed, and computer 200 can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server. Computer 200 could also be operated in a more loosely coupled distributed computing environment. Furthermore, any of various conventional web browsers can be used to display and manipulate data on web pages.
  • The operation of computer 200 can be controlled by a variety of different program modules. Examples of program modules are routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The present invention may also be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCS, minicomputers, mainframe computers, personal digital assistants and the like. Furthermore, the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
  • III. Bootstrapping Process
  • In accordance with illustrative embodiments of the invention, a bootstrapping process may allow a project architect to use a declarative style for assembling various facilities within the architecture and initializing them. A set of facilities may be provided.
  • Generally, each facility is focused on a particular problem, such as logging, configuration information, producing references to other components, or managing the life cycle of a facility.
  • In accordance with illustrative embodiments of the invention, a bootstrapping process may be driven by an XML document at run time. Such an XML document could be edited to set up the architecture differently without having to recompile and/or rebuild the system. Alternatively, the declarative approach to the bootstrapping process could be encapsulated within a specific class that would need to be edited and re-built to change a particular strategy.
  • FIG. 3 depicts various components and aspects of a bootstrapping process in accordance with illustrative embodiments of the invention. XML facility deployment descriptor 300 is an XML document that details the facilities and their components and how those facilities should be set up for a particular application. The XML facility deployment descriptor 300 preferably contains elements for multiple facilities, such as logging, life-cycle management, authorization, and factory. The XML facility deployment descriptor 300 also preferably contains sub-elements that specify any behind-the-scenes components for each facility thereby defining how those facilities will work. For instance, there is a configuration bootstrap task 302 for setting up the configuration facility. There could be sub-elements for plugging in a properties configuration source, a database configuration source, a “.ini” file, and the like. The configuration task and the sub-element tasks for each of the sources essentially define a resulting configuration facility produced by the configuration bootstrap task 302.
  • XML facility bootstrap 304 represents an entity that performs work. Dashed arrow 306 represents a dependency by the XML facility bootstrap 304 upon the XML facility deployment descriptor 300 for performing the XML facility bootstrap's work. A parse facility deployment descriptor step 308 parses XML facility deployment descriptor 300, which is fed into the parse facility deployment descriptor step 308 via the XML facility bootstrap 304 as indicated by arrows 310 and 312. The execute facility bootstrap tasks in descriptor step 314 operates on the XML facility deployment descriptor 300 broken down into its elements and iterates over those elements. Each of these elements will typically correspond to a bootstrap task class. Referring back to the configuration bootstrap task 302 example, configuration bootstrap task 302 preferably: (1) understands the XML facility deployment descriptor elements that were parsed; and (2) does the work of setting up the configuration sources and plugging them into the configuration facility. The XML bootstrap facility may define, as part of its tasks, a framework through which sub-elements are provided to the facility bootstrap task 324 through, for example, a set of simple set-value operations. Following the execute facility bootstrap tasks in descriptor step 314, the facility bootstrap process is complete, as depicted at 318 in FIG. 3, and the configuration facility is set up.
  • Application-specific facilities that could be unique to a particular project could also have their own corresponding bootstrap tasks. The facility bootstrap task 324 defines a common API for facility bootstrap tasks. Configuration bootstrap task 302, logging bootstrap task 320, and factory bootstrap task 322 are specific implementations of the facility bootstrap task API 324, as depicted by the hollow arrowhead leading from the configuration bootstrap task 302, the logging bootstrap task 320, and the factory bootstrap task 322 to the facility bootstrap task 324. Ellipses 326 in FIG. 3 represents that the bootstrap process can be extended by adding new bootstrap tasks. Dashed arrow 328 leading from the execute facility bootstrap tasks in descriptor step 314 to facility bootstrap task 324 represents a dependency of the execute facility bootstrap tasks in descriptor step 314 upon the specific implementations of the facility bootstrap task common API 324.
  • IV. Notation Used in Figures
  • FIG. 4 is essentially a legend for FIGS. 4-5,8,11,14, and 17, which depict Unified Modeling Language (“UML”) analysis models. FIGS. 4-5,8,11,14, and 17 show major entities within a model of various aspects of a toolkit and a net-centric application program in accordance with the present invention and how those major entities relate to one another. The different types of entities shown in these figures are depicted in FIG. 4. A boundary class 400 defines an API or an interface. A control class 402 defines a process or an operation for doing some work. An entity class 404 is a concrete thing. An entity class could implement an interface, or it could be a database or something else. In FIGS. 4-5,8,11,14, and 17, arrows between these three major types of components represent either associations or transfers of control similar to a process flow.
  • V. Single Simple API
  • A common principal, which preferably appears in multiple contexts within a toolkit and/or an architecture in accordance with illustrative embodiments of the invention, is the use of a single simple API for application developers to use. Such an API preferably hides a server-provided interface that can have different implementations plugged in and/or composed behind the server-provided interface. The configuration facility is one example in which programmers can get properties of the system through a single get environment operation. The specific details about how such information is retrieved are preferably completely hidden. For example, the GrndsConfigurationSource interface, set forth below, defines a simple API, which concrete configuration sources may implement to provide their view of the system's configuration environment. The example Concrete class, GrndsSystemPropertySource, set forth below, implements getenviroment( ), which returns a set of in-memory system variables. Normally, sources partition the configuration environment into domains and sub-domains, but in the example below, the GrndsSystemPropertySource assigns all system variables to every configuration domain and sub-domain combination. The other operations in the interface, in particular init( ), fini( ), clone( ) and refresh( ), are implemented to perform various lifecycle operations that may need to be performed by the source.
    public interface GrndsConfigurationSource
    extends Serializable, Cloneable
    {
      public abstract GrndsConfigurationEnvironment getEnvironment(
                String domain_,
                String[ ] sub-domains)
      throws GrndsConfigurationException;
      public abstract void init( String[ ] args) throws Exception;
      public abstract void fini( ) throws Exception;
      public abstract void refresh( );
      public abstract Object clone( );
    }
    public final class GrndsSystemPropertySource
    extends GrndsObject implements GrndsConfigurationSource
    {
      public GrndsSystemPropertySource( )
      {
        super( );
      }
      public GrndsSystemPropertySource( GrndsSystemPropertySource
      rhs)
      {
        super( );
      }
      public Object clone( )
      {
        return new GrndsSystemPropertySource( this );
      }
      public GrndsConfigurationEnvironment getEnvironment(
                String domain_,
                String[ ] sub-domains)
      {
        GrndsConfigurationEnvironment result =
            new GrndsConfigurationEnvironment( );
        result.putAll( System.getProperties( ) );
        return result;
      }
      public Enumeration getPropertyNames( String domain_,
              String[ ] sub-domains)
      {
        return System.getProperties( ).keys( );
      }
      public void init( String[ ] args)
      { }
      public void fini( )
      { }
      public void refresh( )
      { }

    VI. Configuration Facility
  • A toolkit and program architecture in accordance with illustrative embodiments of the invention may include a configuration facility having a single API or method for getting properties that can be defined in any number of different sources. One or more of the sources could be: one or more properties files on one or more file systems; environment variables within one or more computers at run time; data within one or more databases; or any other number of suitable permutations and/or combinations of suitable sources. A configuration facility in accordance with illustrative embodiments of the invention enables an architect to assemble any number of these sources behind the configuration facility API so that application developers can go against a single API. The application developers, therefore, do not need to know where the sources are located. Through the bootstrapping process a project architect can assemble the configuration sources that the architect wants to provide to application developers. Any number of these configuration sources may be assembled into or, stated differently, included in the configuration facility.
  • The declarative style of the bootstrapping process advantageously facilitates modification of configuration data. For instance, a configuration facility could be used to define configuration data, such as a destination URL of a hyperlink. Rather than hard coding the URL, which would require re-compilation and rebuilding of all the code to change the destination URL, the configuration facility preferably associates the URL with a key. Then, the destination URL of the hyperlink can be changed by changing the value associated with the key, which does not require re-compilation and rebuilding of all the code. A configuration facility in accordance with illustrative embodiments of the invention enables an architect to plug different configuration information sources into the configuration facility, as desired, during the bootstrapping process. The configuration facility preferably depends on an abstract configuration source interface, but is provided concrete implementations of that interface, via the bootstrap process, to implement the get environment operation differently, such as to retrieve information from the system environment, from .proporties file. from xml files. and/or the like. Example contents of an XML facility deployment descriptor document are provided in section VIII below.
  • FIG. 5 depicts a UML analysis model for a configuration framework in accordance with illustrative embodiments of the invention. The sources, or where the configuration comes from, are de-coupled from the act of getting to or accessing the configuration. The get configuration environment operation 502 is the main operation behind configuration API 500. The get environment operation 502 uses configuration source interface 504 to build a single environment based upon data from one or more configuration sources, such as property file source 505, XML file source 506, and system property source 507. Ellipses 508 in FIG. 5 represents additional configuration sources that can be plugged into an architecture via specific implementations of configuration source interface 504. The concrete implementations of configuration source interface 504, namely, property file source 505, XML file source 506, and system property source 507, are depicted in FIG. 5 with entity class symbols 404 to convey that these implementations of configuration source interface 504 perform respective operations of obtaining configuration information from various configuration sources. The configuration sources are plugged into the configuration API 500 via the bootstrap process, which is depicted in FIG. 5 and discussed above. Configuration sources may be specified via the configuration bootstrap task 502, or configuration sources may be specified in an XML file or the like to dictate how the configuration is assembled together.
  • The configuration facility builds the configuration environment by iterating over each configuration source, requesting its view of the environment. The configuration facility combines each source's environment view into a whole, preferably taking into consideration these precedence rules: configuration sources are ordered within the facility based on when they are added with earlier sources taking precedence over later sources. Configuration environments are organized into domains and sub-domains, which are logically defined, and sub-domains override information specified at the domain level.
  • FIG. 6 depicts a UML static class diagram for a detailed illustrative embodiment of a configuration facility in accordance with various inventive principles. FIG. 6 shows major components of such a configuration facility, including GrndsPropertyFileSource 505′, GrndsXmlFileSource 506′, and GrndsSystemPropertySource 507′ objects, which are concrete implementations of GrndsConfiguration common API definition 500′.
  • FIG. 7 depicts a UML dynamic sequence diagram for a detailed illustrative embodiment of the get environment operation 502 in accordance with various inventive principles. FIG. 7 shows exemplary steps for delegating work from grndsconfiguration 500′ API to GrndsConfigurationSource 504′.
  • The bootstrapping process preferably defines a mechanism to actively set up application architecture facilities, whereas the configuration facility is typically one of the facilities set up by the bootstrap mechanism. The configuration facility preferably defines a mechanism to get information about the application and its environment at runtime. The bootstrap mechanism is preferably capable of setting up the configuration facility first, and then using data retrieved from the configuration facility to configure other facilities. While the bootstrap mechanism may use the configuration facility to help set up other facilities, the other facilities do net necessarily depend on the configuration facility. In fact, facilities are preferably defined to be independent of the configuration facility thereby enabling the bootstrap mechanism to use any means for getting environment information.
  • VII. Factory
  • A factory in accordance with illustrative embodiments of the invention may allow a developer to de-couple how a resource is produced from where the resource is used. This de-coupling provides significant benefits for maintaining an application program over a long period of time and facilitating making changes to the program. A factory in accordance with illustrative embodiments of the invention defines a simple API that application developers program in order to produce references to resources. How these references are produced can be plugged in according to any number of various strategies. This is unlike conventional factories, which typically are more rigid and suited to one particular type of a reference-producing scenario.
  • FIG. 8 depicts a UML analysis model, similar to FIG. 5, for a factory in accordance with illustrative embodiments of the invention. The produce operation 802, which produces a reference to a resource, is the main operation behind the component factory API 800. Various producers, such as those represented by local producer 805, EJB producer 806, and XML activity plan producer 807 are concrete implementations of the producer interface 804. These producers produce references to resources. These producers are plugged into factory API 800 through the bootstrap mechanism. Alternatively, the factory could assemble various producers underneath it by using information located in a Java standard Properties class, such as one created using the configuration facility.
  • FIG. 9 is a UML static class diagram of a detailed illustrative embodiment of a factory in accordance with various inventive principles. FIG. 9 depicts the relationship among various components including GrndsFactory 800′, GrndsProducer 804′, produce 802′, GrndsLocalProducer 805′, and GrndsEjbProducer 806′, which correspond to the following entities depicted in FIG. 8: component factory API 800, producer interface 804, the produce operation 802, local producer 805, and EJB producer 806.
  • FIG. 10 is a UML dynamic sequence diagram showing exemplary steps performed by a detailed illustrative embodiment of a factory in accordance with various inventive principles. FIG. 10 depicts exemplary steps for identifying a producer corresponding to a logical key or, if there is no corresponding producer, delegating to a default producer, which is preferably set up through a bootstrapping process in accordance with various inventive principles.
  • The factory facility provides a standard way of coupling subsystems and increasing the modularity of an application program thereby facilitating modification of the program. Advantageously, the factory facility may allow for moving access from local to distributed without breaking any higher level parts of an application. In other words, higher level portions of the application are not directly dependent upon particular resource references. Accordingly a generalized factory facility is provided that may allow for changing out different producers behind the scenes.
  • A factory in accordance with illustrative embodiments of the invention can be used to lower network connectivity-associated overhead by substituting a lighter weight co-located component for a heavier-weight distributed component, such as an Enterprise Java Bean (“EJB”). EJB's are typically maintained by an application server for performing tasks such as working with databases and/or legacy application software. A factory in accordance with illustrative embodiments of the invention advantageously may allow for the interchangeability of co-located components and distributed components without requiring modification of the code of either the co-located components or the distributed components. A factory in accordance with illustrative embodiments of the invention can also be used to facilitate production of various other types of resources including, but not limited to, accessing database connections and simplifying access to a central naming service.
  • VIII. Example Contents Of An XML Facility Deployment Descriptor Document
  • Example contents of an XML facility deployment descriptor document in accordance with illustrative embodiments of the invention are set forth below.
    <?xml version=“1.0”?>
    <!--DOCTYPE grnds-web-app SYSTEM “DTD/grnds-web-app.dtd”-->
    <grnds-facility-deployment>
      <facilities>
        <configuration>
        <source
    classname=“org.grnds.facility.config.GrndsPropertyFilesource”/>
        <source classname=“org.grnds.facility.config.GrndsXmlFilesource”>
          <domain name=“webapp”>
            <config-sources>
              <source>
                <file>C:/bin/grnds-web-app-resrc.xconf</file>
                <dialect-
    class>org.grnds.structural.web.config.GrndsWebAppXmlDialect</dialect-
    class>
              </source>
            </config-sources>
            <sub-domain name=“foo”>
              <config-sources>
                <resource>grnds-web-app-resrc.xconf</resource>
                <dialect-
    class>org.grnds.structural.web.config.GrndsWebAppXmlDialect</dialect-
    class>
              </config-sources>
            </sub-domain>
          </domain>
        </source>
        <source
    classname=“org.grnds.facility.config.GrndsSystemPropertySource”/>
      </configuration>
      <factory>
        <producer name=“default”
    classname=“org.grnds.facility.factory.GrndsLocalProducer”/>
        <producer>
          <name>foo</name>
    <classname>org.grnds.facility.factory.GrndsEjbProducer</classname>
          <init-param>
              <param-name>java.naming.factory.initial</param-name>
              <param-value>weblogic.jndi.T3InitialContextFactory</param-
    value>
            </init-param>
            <init-param>
              <param-name>java.naming.provider.url</param-name>
              <param-value>t3://localhost:7001</param-value>
            </init-param>
          </producer>
          <producer name=“XmlPipeline”
    classname=“org.grndsx.structural.pipeline.GrndsXmlActivityPlanProducer”/>
          <target name=“Authorization” producer=“foo”/>
          <target name=“alpha” producer=“default”>
            <init-param>
              <param-name>classname</param-name>
              <param-
    value>org.grnds.foundation.util.GrndsSerializableObject</param-value>
            </init-param>
          </target>
          <target name=“Plan” producer=“XmlPipeline”>
            <init-param>
              <param-name>plan.file</param-name>
              <param-value>C:/grnds-test/test/grndsx/pipeline/plan-
    descriptor.xml</param-value>
            </init-param>
          </target>
        </factory>
      </facilities>
    </grnds-facility-deployment>
  • As described above in connection with FIG. 5, XML Facility Bootstrap class 504 is preferably responsible for parsing an XML facility-deployment descriptor file 500 and for executing each facility bootstrap task. In the sample XML code set forth above, two facilities are bootstrapped: a configuration facility and a factory facility. The configuration facility is setup with three configuration sources of the type shown in FIG. 5: a property file source 505; an XML file source 506, which is further configured with a collection of XML files organized into domains and sub-domains; and a system property source 507.
  • In the example provided above, the factory facility is setup with a set of producers and targets. The producers are named, given an implementation class, and may be provided with additional configuration information. The factory targets are given a logical name, which can be used by developers to identify what should be produced, a named producer, and may be given additional properties to aid production. In this example, there is a named producer, XmlPipeline, which is assigned a single target, Plan. The Plan target is given a property, plan.file, that the producer parses to produce an activity plan object, GrndsActivityPlan.
  • IX. Selectors
  • The selector framework may allow standard query language to be applied in contexts other than querying a database. The selector framework advantageously may allow defining context specific ways of evaluating identifiers within a selector expression. A Standard Query Language (“SQL”) expression includes three major elements: identifiers, which are like variables; operators, such as a string comparison operator to check equality; and literals, such as numbers or character strings. The selector framework may allow application of these types of expressions in different contexts that typically will have different types of identifiers. This is unlike the use of SQL expressions in the database context wherein the identifiers are assumed to be database fields.
  • A selector facility in accordance with illustrative embodiments of the invention provides an engine for evaluating selector expressions and preferably offers a way to extend the selector framework to a number of different contexts. In addition to the Web application scenario, such as the airline ticket purchase example discussed below in section XII, the selector framework can be extended to the pipeline architecture, discussed below in section X. In the context of the pipeline architecture, selectors can be applied to various activities assembled into an activity plan to determine whether various activities should be applied to a message and/or to various elements within a message.
  • FIG. 11 depicts a UML analysis model for a selector framework in accordance with illustrative embodiments of the invention. Selector API 1100 can be used for testing whether an expression is true or not, as depicted by the test expression operation 1102. Test expression operation 1102 uses the evaluate identifier strategy API 1104 for applying selectors to different problems. For example, there could be a special identifier strategy for the pipeline for pulling identifiers from the pipeline context, from the message, or from other areas. This is different from the Web application context where identifier information could be pulled from an HTTP request or from some different parts of a Web session. Test expression 1102 applies the evaluate identifier strategy 1104 to the identifier entity 1106. Based upon the value of identifier 1106 and any literals in test expression 1102, a determination is made as to whether the test expression 1102 is true or false.
  • FIG. 12 is a UML static class diagram for a detailed illustrative embodiment of a selector framework in accordance with various inventive principles. GrndsSelector 1100′, GrndsEvaluateldentifier 1104′, and GrndsIdentifier 1106′ correspond to the selector API 1100, the evaluate identifier strategy 1104, and the identifier entity 1106. GrndsSelectiveObject 1200 includes a getObject operation 1202, illustrative steps of which are depicted in FIG. 13.
  • Through various implementations of the evaluate identifier strategy API 1104 an application developer can specify which identifiers can be used within selector expressions thereby facilitating tailoring the selector framework to any number of different contexts.
  • A toolkit in accordance with illustrative embodiments of the invention preferably includes two separate and unique concrete implementations of the evaluate identifier strategy 1104, with one implementation corresponding to the pipeline and another implementation corresponding to the Web application. These unique strategies are passed into selector 1100 during the building of selector expression 1102. Selector expressions are built when the web application XML map and pipeline activity plan are constructed; such as, during interpretation of XML configuration data for each respective framework.
  • X. Pipeline Architecture
  • Under certain circumstances, a message oriented middleware approach facilitates integrating disparate computing systems by allowing one system to publish data to a work queue and by allowing a second system to subscribe to messages from the queue. In this manner, the two computer systems are advantageously able to remain relatively de-coupled.
  • A pipeline architecture in accordance with illustrative embodiments of the invention enables an architect to define a model view controller-like framework for a processing pipeline or message oriented middleware-type application. An application architect and/or developer can specify how each processing component does work through a series of fine-grained activities. In general, a processing component will receive a message as an input and produce a message as an output.
  • The specified activities can be assembled together into an activity plan. There could be several different aspects of an activity plan for covering the basic steps that are commonly performed by processing components. For instance, processing of messages, processing of elements within a message, how output is produced, how errors are handled, how redelivered messages are handled, and the like.
  • The pipeline architecture provides a structured manner for specifying these fine-grained activities. The pipeline architecture provides a significant benefit by allowing developers to focus on writing these fine-grained activities. Developers can then re-use these fine-grained activities in many different types of plans. This in turn significantly simplifies development, testing, integration, maintenance, and modification of an application built in accordance with various inventive pipeline architecture principles.
  • FIG. 14 depicts a UML analysis model of a processing pipeline in accordance with illustrative embodiments of the invention. JMS is a standard Java API for message oriented middleware. Destinations are a major component of the JMS. Destinations are code that plugs into the JMS middleware for receiving messages. The pipeline 1402 subscribes to and receives messages and/or events from input JMS destination 1400. When the pipeline 1402 receives a message, pipeline 1402 invokes the on Message process 1404, which uses an activity plan 1406.
  • The activity plan 1406 is an entity that describes the various activities that are used for processing the incoming message. In this manner, the activity plan defines the plan for performing that processing. Activity plans are described in more detail below.
  • The get activities operation 1408 uses activity selector 1410, which is similar to the selector framework used for Web application flow, to execute one or more activities 1412. These activities will typically be application-specific concrete implementations of Activity interface 1412 for performing tasks within an application. Typically, there will be many different activities within an activity plan 1406. Activities can be filtered or used based upon a selector expression wherein the selector expression is based upon information in the received message, some state of the application, or the like. Accordingly, not all activities in an activity plan will necessarily be executed for a particular message. Instead, activities may be selectively executed for a particular message.
  • FIG. 15 is a UML static class diagram for a detailed illustrative embodiment of a pipeline architecture in accordance with various inventive principles. GrndsPipeline 1402′, GrndsActivityPlan 1406′, and GrndsPipelineActivity 1412′ correspond to pipeline 1402, activity plan 1406, and activity interface 1412.
  • FIG. 16 is a UML dynamic sequence diagram showing exemplary steps for implementing a pipeline architecture in accordance with a detailed illustrative embodiment of the invention. FIG. 16 depicts steps for abstracting various details of message oriented middleware so that developers are able to focus on developing activities for processing messages to perform specific tasks, thereby facilitating re-use of these activities in various types of activity plans.
  • XI. Activity Plan
  • An activity plan, which is described in more detail below, essentially defines the steps to perform some process. The processing pipeline 1402 is an engine that receives events or messages. The pipeline 1402 does work through activities. An activity plan, such as activity plan 1406 tells the pipeline 1402 which activities should be performed and under what conditions those activities should be performed. In this manner, the activity plan 1406 ties specific tasks or activities together into a cohesive process.
  • An activity plan in accordance with illustrative embodiments of the invention, such as activity plan 1406, may include several different sections. One section could be a redelivered section for handling a situation in which a message is being redelivered, which may occur when a server shuts down and is restarted. Under these circumstances, messages may be sent more than once, which is not a normal operating condition.
  • For more common situations, an activity plan may include a message section, which performs activities on a received message at the message level or, in other words, performs activities on a received message as a whole. Messages, however, could contain many elements. Accordingly, an activity plan may include a message element section that executes a series of activities on individual elements within a received message. For example, if a message has five elements within its body, then the message element section would be applied to each of these five elements. Stated another way the message elements section would be applied five times.
  • An activity plan may also include an output section for doing work to produce output or results of the process at the message level. Accordingly, the output section would typically be executed one time per message. An activity plan may also include a set of error handling sections that may be applied at the message level and/or the message element level for handling situations in which errors are thrown while processing a message.
  • XII. Web Application Framework Control
  • Within a Web application, there are often conversations, or portions of the application, that should follow a very specific control flow, such as going from page A to page B to page C in only that specific order. For instance, when a person uses a Web application to purchase an airline ticket and reserve a seat on a particular airline flight, the person should not be able to reserve a seat without already having purchased a ticket. A person, however, could bookmark a page for reserving a seat and could potentially reserve a seat on another flight by returning to the book-marked page without having first purchased a ticket for this other flight. This scenario is possible under certain circumstances due to the relative lack of control of the manner in which users enter Web applications via the Internet. Web application developers frequently confront this situation, namely, controlling the continuity of conversations within Web applications. The term conversation refers to a cohesive set of pages that act together to perform some unit of work, such as purchasing an airline ticket or editing user profile information.
  • An architecture in accordance with illustrative embodiments of the invention provides a way of controlling conversation flow through the use of one or more selectors. Within the Web application framework context, a selector is a logical expression that makes certain portions of a conversation available when certain specified conditions have been met. For example, in the context of the airline ticket purchase and seat reservation example, an application could set a flag, or a variable, to indicate that the user has purchased a ticket before sending the user to the seat selection page. A corresponding selector could be associated with producing the seat selection page. The selector could then be evaluated and used for making the seat reservation page available if and only if the user has actually purchased a ticket for a particular flight. Accordingly, if a user book-marked the seat selection page and entered the application directly into the seat selection page without first purchasing a ticket for the flight, the web application would not allow the user to select a seat because the selector would evaluate to false thereby causing an error page to be displayed to the user and/or some other appropriate action to be taken.
  • The selectors-based approach provides a significant advantage relative to conventional techniques for controlling web application flow because the selectors-based approach is de-centralized and relatively lightweight. Selectors advantageously provide a simpler way to control the continuity of conversations relative to conventional techniques, which often require modeling an application as a finite state machine. Modeling Web applications as finite state machines is a relatively complex task.
  • FIG. 17 depicts a UML analysis model for a Web application in accordance with illustrative embodiments of the invention. Servlet 1700 is a standard API within the Java language. Servlet 1700 is a plug-in point for the server. When a Web request comes from a browser to a Web server, the elements that do work to process the request are implemented behind the servlet API 1700. Accordingly, the remainder of FIG. 17 implements that API and plugs into that engine.
  • FIG. 17 shows how processing of a Web request may be structured in accordance with illustrative embodiments of the invention. The execute exchange operation 1702 is the main operation behind the Servlet 1700 API. The execute exchange operation 1702 implements specific details of its algorithm using the conversation interface 1704. The conversation interface 1704 provides access to get exchange presentation 1706 and get exchange activity 1708. These elements define the separation of concerns within the model view controller framework. The implementation of Servlet 1700 depicted in FIG. 17 translates user events, such as a user clicking on a link or a button, into application commands. The processing of those application commands includes two main units of work. The first main unit of work is performing some business activity in conjunction with the model layer, which defines the business logic. The activity defines the application logic, while the model layer defines the more detailed business logic, which may span applications. The second main unit of work is that the results of the activity are displayed through a presentation, which defines the view layer. The conversation defines associations between the activity and presentation elements with their corresponding user events.
  • When execute exchange 1702 begins running, it tells the conversation 1704 to do whatever work the conversation needs to do before the exchange's activity and presentation are processed. The begin response operation 1710 looks to see whether there are any selectors 1712 registered for the received event/command. If a selector is identified for the received event/command, it is evaluated. If the selector evaluates to true, the event/command is processed further, otherwise an illegal state exception is thrown, which may be routed by the J2EE platform to an error page presented to the user.
  • Once one or more selectors 1712 have been evaluated, an execute modifiers sub-process 1714 of the begin response operation 1710 transfers control to the execute modifiers operation 1714 and the exchange modifier 1716 API, which defines one or more extensions to the conversation, such as the authorization exchange modifier 1718. The execute modifiers operation iterates over each configured exchange modifier and executes them sequentially. The authorization exchange modifier 1718 checks whether the user has an appropriate permission to work with a particular part of an application or to perform a particular command, which is done through authorization facility 1722, which is described in more detail below.
  • There is preferably an XML document that describes the Web application structure. Such an XML document preferably ties: conversations to Servlets; commands to conversations; and activities and presentations to those commands. Such an XML document also preferably ties one or more selectors to those commands, and, with respect to the authorization facility 1722, the XML document may allow for specification of a minimum set of permissions that a user needs to have in order to execute a conversation and/or any specific command within a conversation.
  • If all of these authorization permission checks pass, then the conversation will return the configured exchange activity, which the servlet will run, and the servlet will work with various components within the business model to do work such as looking up all the seats that are available in the airline ticket purchase and seat reservation example. The servlet will then execute the presentation or, stated otherwise, output results to the user.
  • FIG. 18 is a UMIL static class diagram for a detailed illustrative embodiment of a Web application framework in accordance with various inventive principles. Entities depicted in FIG. 18 with prime reference numbers correspond to entities having corresponding non-prime reference numbers.
  • FIG. 19 is a UML dynamic sequence diagram showing exemplary steps performed by a servlet for handling a request from a Web browser in accordance with a detailed illustrative embodiment of the invention.
  • Contents of an example XML document for describing the structure of a web application in accordance with illustrative embodiments of the invention are set forth below.
    <?xml version=“1.0”?>
    <!--DOCTYPE grnds-web-app SYSTEM “DTD/grnds-web-app.dtd”-->
    <grnds-web-app>
      <servlet mapping=“gallery”>
        <conversations>
          <conversation>
            <default-conversation/>
            <conversation-class>
              homesite.HomesiteConversation
            </conversation-class>
            <commands>
              <command>
                <command-name>default</command-name>
                <!--
                  -- command is available iff configuration property,
                  -- isGalleryAvailable, equals ‘true’
                  -->
                <selector>
                   <![CDATA[config.isGalleryAvailable = ‘true’]]>
                </selector>
                <activity type=“method”>default_xa</activity>
                <presentation type=“url”>
                  /grnds-docs/gallery/default/default.jsp
                </presentation>
                <presentation type=“url” branch=“error”>
                  /grnds-docs/gallery/default/default.error.jsp
                </presentation>
              </command>
            </commands>
            <modifiers>
              <modifier>
                <modifier-class>
                  org.grnds.structural.web.GrndsAuthorizationModifier
                </modifier-class>
                <!-- Apply permission at conversation level -->
                <init-param>
                  <param-name>conversation.permission.class</param-name>
                  <param-value>homesite.GalleryPermission</param-value>
                </init-param>
                <init-param>
                  <param-name>conversation.permission.resource</param-name>
                  <param-value>*</param-value>
                </init-param>
                <init-param>
                  <param-name>default.permission.actions</param-name>
                  <param-value>read</param-value>
                </init-param>
                <!-- Apply permission to default command -->
                <init-param>
                  <param-name>default.permission.class</param-name>
                  <param-value>homesite.GalleryPermission</param-value>
                </init-param>
                <init-param>
                  <param-name>default.permission.resource</param-name>
                  <param-value>*</param-value>
                </init-param>
                <init-param>
                  <param-name>default.permission.actions</param-name>
                  <param-value>read</param-value>
                </init-param>
              </modifier>
            </modifiers>
          </conversation>
        </conversations>
      </servlet>
    </grnds-web-app>
  • In the example set forth above, there is a single servlet, called “gallery”, comprising a single conversation. The conversation contains one command and is protected by an authorization modifier. The command, default, has a selector that prevents it from being available if the configuration property, isGalleryAvailable, is not set to “true”. The default command is associated with a single activity, implemented by the conversation method “default_xa( )”. The default command is associated to two presentations: a standard path implemented via the /grnds-docs/gallery/default/defaultjsp file; and an alternative implemented via the /grnds-docs/gallery/default/default.errorjsp file. The alternative presentation branch is used if the activity set the presentation branch by calling the conversation's setPresentationBranch(“error”). The authorization modifier sets two permissions, one for the conversation and one for the default command.
  • XIII. Authorization Facility
  • Authorization facility 1722 may be used for associating permissions with a user to specify which portions of an application a user is authorized to use and which portions of the application the user is not authorized to use. The authorization facility is preferably integrated directly into a Web application and used to associate required permissions that are needed to enter certain Web conversations. A user attempting to enter a Web conversation without the requisite permissions could be denied access to the Web conversation. Advantageously, the authorization facility can associate requisite permissions at many levels of detail ranging from specific fine-grained parts of an application through larger views of the application. The authorization facility may allow for declaratively associating, through a configuration approach, a required permission to enter a conversation (or a particular page within a conversation) within a Web application. Advantageously, these associated requisite permissions can be modified by changing declarative definitions. These declarative definitions can be implemented in XML or any other suitable format. The need to edit, compile, and re-build Java code in order to change authorization permissions for the application and/or various parts of the application can, therefore, be avoided, thereby facilitating maintenance and/or modification of the authorization permissions.
  • Referring to FIG. 19, plug-in point 1900 is the point at which the Web application authorization integation UML dynamic sequence diagram of FIG. 20 plugs into the steps shown in FIG. 19.
  • FIGS. 20 and 21 are UML dynamic sequence diagrams showing exemplary steps performed by the beginResponse and checkAuthorization operations of an authorization modifier in accordance with a detailed illustrative embodiment of the invention.
  • XIV. Variations and Permutations
  • While the invention has been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described architecture and techniques that fall within the spirit and scope of the invention as set forth in the appended claims and their equivalents.

Claims (36)

1-37. (canceled)
38. An application framework for use with netcentric application program architectures, the application framework comprising:
a server computer configured to receive a user event during a conversation that comprises a cohesive set of web pages;
a servlet operable on the server computer that is enabled by the conversation and responsive to the user event, the servlet comprising:
a document that defines a selector associated with the user event, wherein the selector is a logical expression that enables access to a web page when predefined conditions have been met;
a begin response element executable with the server computer to access the document and evaluate if the selector associated with the user event is true or false; and
a business logic executable on the server computer, wherein the servlet is configured to work with a plurality of components included in the business logic only when the selector evaluates to true.
39. The application framework of claim 38, wherein the servlet is configured to generate an illegal state exception that results in the display of an access error page when the selector associated with the user event evaluates to false.
40. The application framework of claim 38, further comprising an execute modifiers operation executable on the server computer to perform an authorization permission check, wherein the execute modifiers operation is enabled for execution when the selector evaluates to true.
41. The application framework of claim 40, further comprising an authorization exchange modifier executable on the server computer, wherein the authorization exchange modifier is executable to determine whether a user has appropriate permission to work with a part of an application, or perform a particular command.
42. The application framework of claim 38, wherein the servlet further comprises a get exchange presentation and a get exchange activity that are executable only when the selector evaluates to true, wherein the get exchange activity is executable to access data and the get exchange presentation is executable to display the data as an output to a user.
43. The application framework of claim 38, wherein the document is an XML document that also describes a minimum set of permissions that a user needs to have to execute the conversation or a specified word within the conversation.
44. The application framework of claim 38, wherein the document is configurable to include declarative definitions that are requisite authorization permissions to enter the conversation or a particular web page within the conversation.
45. The application framework of claim 44, wherein the declarative definitions are configured to be changeable absent modification to the business logic.
46. The application framework of claim 38, wherein the document further comprises a predefined association of the servlet with the conversation, a predefined association of the user command with the conversation and association of at least one of a predefined activity or presentation, or combinations thereof, with the user command.
47. A method of processing a web request with an application framework within a net-centric application program, the method comprising:
translating one or more user events into one or more application commands;
controlling conversation flow in a de-centralized manner through the use of a selector facility that provides a mechanism for specifying a plurality of identifiers of different types that may be used within a plurality of selector expressions;
performing one or more business activities based upon
predetermined business logic,
results produced by the selector facility, and
the one or more application commands; and
generating a presentation of results produced by performing the one or more business activities.
48. The method of claim 47 wherein the selector expressions are each a logical expression that enables portions of a conversation when pre-specified conditions are met, the conversation comprising a cohesive set of web pages.
49. The method of claim 47 wherein the plurality of selector expressions are expressed in standard query language.
50. The method of claim 47 further comprising tying at least one pair of entities together through a document, the at least one pair of entities being selected from the group consisting of: at least one conversation and at least one servlet; at least one command and at least one conversation; and at least one selector and at least one command.
51. The method of claim 47 wherein the document is an XML document.
52. The method of claim 47 further comprising associating one or more permissions with a user for specifying one or more portions of the application program that the user is authorized to use, wherein the one or more portions of the application can be specified at a plurality of different levels of detail.
53. The method of claim 52 wherein the plurality of different levels of detail range from a page of conversation to the entire application program.
54. The method of claim 52 further comprising declaratively associating in an XML document the one or more permissions with the application program.
55. An application framework defining netcentric application program architectures, the application framework comprising:
a server computer operable on a network;
an application or service operable on the server computer;
an authorization facility operable on the server computer, the authorization facility configured to associate requisite permissions with interaction between the application or service and a user;
a document accessible by the authorization facility, wherein the document includes a declarative definition that selectively enables access to at least predefined portions of a cohesive set of web pages only when predefined conditions are met, and wherein the cohesive set of web pages are generateable with the application or service; and
an exchange modifier operable on the server computer in response to a user event initiated by a user, wherein the user event is an application command transmitted over the network to the server computer;
the exchange modifier operable to integrate the authorization facility into the application or service to determine whether the user has permission to at least one of work with a particular part of the application or service, or to perform a particular command, or combinations thereof.
56. The application framework of claim 55, wherein the declarative definition is a logical expression that is readily changeable within the document without any other changes to the application or service to selectively specify a minimum set of permissions that a user needs to have.
57. The application framework of claim 55, wherein the exchange modifier is operable to enable a conversation element when it is determined the user has permission, the conversation element operable on the server computer to perform a business activity responsive to the user event and display the results of the business activity to the user.
58. The application framework of claim 55, wherein the requisite permissions are associated with the user to specify which portions of the application or service the user is authorized to use, and which portions of the application or service the user is not authorized to use.
59. The application framework of claim 55, wherein the authorization facility is integrated directly into a web application.
60. The application framework of claim 55, wherein the requisite permissions are associated with specific fine-grain parts of the application or service, or with a plurality of specific fine-grain parts of the application or service.
61. A method of processing a web request with an application framework within a net-centric application program, the method comprising:
providing a server computer operable on a network;
operating with the server computer an application or service that is configured to provide a cohesive set of web pages;
operating an authorization facility with the server computer, wherein the authorization facility associates requisite permissions with interaction between the application or service and a user;
the user accessing the application or service on the server computer over the network with a user event that is an application command to at least one of work with a particular part of the application or service, or to perform a particular command, or combinations thereof;
executing the authorization facility in response to the user event to access a document, wherein the document includes a declarative definition that selectively enables access to at least predefined portions of the cohesive set of web pages only when predefined conditions are met; and
enabling a response to the user event when the predefined conditions are met.
62. The method of claim 61 further comprising changing the declarative definition included in the document to modify the requisite permissions without changes to the application or service or the authorization facility.
63. The method of claim 61 further comprising changing only the declarative definition to modify the requisite permissions.
64. The method of claim 61 wherein the document is an XML document that includes the declarative definition, the declarative definition indicative of at least one of the requisite permissions, and further comprising changing only the XML document to change at least one of the requisite permissions.
65. The method of claim 61 wherein operating an authorization facility comprises specifying in the document a minimum set of permissions that the user needs in order to at least one of work with a particular part of the application or service, or to perform a particular command, or combinations thereof.
66. The method of claim 61 wherein operating an authorization facility comprises associating permissions with the user to specify which portions of the application or service that the user is authorized to use, and which portions of the application or service the user is not authorized to use.
67. The method of claim 61 wherein operating an authorization facility comprises integrating the authorization facility directly into a web application with an exchange modifier that is operable on the server computer in response to receipt of the user event.
68. The method of claim 61 wherein the requisite permission is an authorization permission, and further comprising changing the authorization permission to change the user's access to the cohesive set of web pages.
69. The method of claim 61 further comprising operating an exchange modifier on the server computer in response to the user event, the exchange modifier operable to integrate the authorization facility into the application or service to determine whether the user has permission to at least one of work with a particular part of the application or service, or to perform a particular command, or combinations thereof.
70. The method of claim 61 further comprising performing a business activity responsive to the user event and displaying the results of the business activity to the user when it is determined that the predefined conditions are met.
71. The method of claim 61 wherein accessing the application or service comprises evaluating a selector that is a logical expression to determine if the logical expression is true or false; and allowing access to at least one of the cohesive set of web pages when the logical expression evaluates to true.
72. The method of claim 71 wherein evaluating a selector comprises controlling a conversation flow within the application or service.
US11/228,800 2001-05-17 2005-09-16 Application framework for use with net-centric application program architectures Abandoned US20060064574A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/228,800 US20060064574A1 (en) 2001-05-17 2005-09-16 Application framework for use with net-centric application program architectures

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/859,765 US6971001B1 (en) 2001-05-17 2001-05-17 General and reusable components for defining net-centric application program architectures
US11/228,800 US20060064574A1 (en) 2001-05-17 2005-09-16 Application framework for use with net-centric application program architectures

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/859,765 Division US6971001B1 (en) 2001-05-17 2001-05-17 General and reusable components for defining net-centric application program architectures

Publications (1)

Publication Number Publication Date
US20060064574A1 true US20060064574A1 (en) 2006-03-23

Family

ID=25331648

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/859,765 Expired - Lifetime US6971001B1 (en) 2001-05-17 2001-05-17 General and reusable components for defining net-centric application program architectures
US11/228,800 Abandoned US20060064574A1 (en) 2001-05-17 2005-09-16 Application framework for use with net-centric application program architectures
US11/228,683 Active 2024-05-28 US7739657B2 (en) 2001-05-17 2005-09-16 Pipeline architecture for use with net-centric application program architectures

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/859,765 Expired - Lifetime US6971001B1 (en) 2001-05-17 2001-05-17 General and reusable components for defining net-centric application program architectures

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11/228,683 Active 2024-05-28 US7739657B2 (en) 2001-05-17 2005-09-16 Pipeline architecture for use with net-centric application program architectures

Country Status (5)

Country Link
US (3) US6971001B1 (en)
EP (3) EP1727041A3 (en)
AU (1) AU2002319843B2 (en)
CA (1) CA2446809C (en)
WO (1) WO2002093364A2 (en)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060064573A1 (en) * 2001-05-17 2006-03-23 Accenture Global Services Gmbh Pipeline architecture for use with net-centric application program architectures
US20070288759A1 (en) * 2003-05-22 2007-12-13 Wood Richard G Methods of registration for programs using verification processes with biometrics for fraud management and enhanced security protection
US20080021810A1 (en) * 2000-05-08 2008-01-24 Pappas Christian S Method and system for reserving future purchases of goods and services
US20080215495A1 (en) * 2000-05-08 2008-09-04 Pappas Christian S Method and system for reserving future purchases of goods and services
US20080215457A1 (en) * 2000-05-08 2008-09-04 Pappas Christian S Method and system for reserving future purchases of goods and services
US20090112932A1 (en) * 2007-10-26 2009-04-30 Microsoft Corporation Visualizing key performance indicators for model-based applications
US20090222827A1 (en) * 2008-02-29 2009-09-03 Microsoft Corporation Continuation based declarative definition and composition
US8301550B2 (en) 2000-05-08 2012-10-30 Smart Options, Llc Method and system for reserving future purchases of goods or services
US8620771B2 (en) 2000-05-08 2013-12-31 Smart Options, Llc Method and system for reserving future purchases of goods and services
US20140013300A1 (en) * 2009-08-27 2014-01-09 Crimson Corporation Platform for development and deployment of system administration solutions
US8650114B2 (en) 2000-05-08 2014-02-11 Smart Options, Llc Method and system for reserving future purchases of goods or services
US8930260B2 (en) 2000-05-08 2015-01-06 Smart Options, Llc Method and system for reserving future purchases of goods and services
US9026472B2 (en) 2000-05-08 2015-05-05 Smart Options, Llc Method and system for reserving future purchases of goods and services
US9026471B2 (en) 2000-05-08 2015-05-05 Smart Options, Llc Method and system for reserving future purchases of goods and services
US9047634B2 (en) 2000-05-08 2015-06-02 Smart Options, Llc Method and system for reserving future purchases of goods and services
US9064258B2 (en) 2000-05-08 2015-06-23 Smart Options, Llc Method and system for reserving future purchases of goods and services
US9070150B2 (en) 2000-05-08 2015-06-30 Smart Options, Llc Method and system for providing social and environmental performance based sustainable financial instruments
US9092813B2 (en) 2000-05-08 2015-07-28 Smart Options, Llc Method and system for reserving future purchases of goods and services
US9507891B1 (en) 2015-05-29 2016-11-29 International Business Machines Corporation Automating a microarchitecture design exploration environment

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7149752B2 (en) * 2002-12-03 2006-12-12 Jp Morgan Chase Bank Method for simplifying databinding in application programs
NO20032418D0 (en) * 2003-05-27 2003-05-27 Ericsson Telefon Ab L M Aggregation of non-blocking, durable state machines on an "EnterpriseJava Bean" platform
US8930944B2 (en) * 2003-11-18 2015-01-06 Microsoft Corporation Application model that integrates the web experience with the traditional client application experience
JP4643213B2 (en) * 2004-09-29 2011-03-02 シスメックス株式会社 Application program usage restriction method, measuring device user authentication system, authentication server, client device, and application program
US7581190B2 (en) * 2006-07-19 2009-08-25 Microsoft Corporation Constructing user interfaces on top of cmdlets
US20080021955A1 (en) * 2006-07-24 2008-01-24 Raytheon Company Message oriented middleware server pipeline architecture
US7908589B2 (en) * 2006-08-29 2011-03-15 Sap Ag Deployment
US7912800B2 (en) * 2006-08-29 2011-03-22 Sap Ag Deduction engine to determine what configuration management scoping questions to ask a user based on responses to one or more previous questions
US20080082517A1 (en) * 2006-08-29 2008-04-03 Sap Ag Change assistant
US8131644B2 (en) 2006-08-29 2012-03-06 Sap Ag Formular update
US8065661B2 (en) * 2006-08-29 2011-11-22 Sap Ag Test engine
US7823124B2 (en) * 2006-08-29 2010-10-26 Sap Ag Transformation layer
US8505030B2 (en) * 2007-11-16 2013-08-06 Microsoft Corporation Coordinating resources using a volatile network intermediary
US8719841B2 (en) * 2007-11-16 2014-05-06 Microsoft Corporation Dispatch mechanism for coordinating application and communication medium state
US9021503B2 (en) * 2007-11-16 2015-04-28 Microsoft Technology Licensing, Llc Coordinating application state and communication medium state
US8135659B2 (en) * 2008-10-01 2012-03-13 Sap Ag System configuration comparison to identify process variation
US8396893B2 (en) 2008-12-11 2013-03-12 Sap Ag Unified configuration of multiple applications
US8255429B2 (en) 2008-12-17 2012-08-28 Sap Ag Configuration change without disruption of incomplete processes
US9171097B2 (en) 2009-03-31 2015-10-27 Qualcomm Incorporated Memoizing web-browsing computation with DOM-based isomorphism
US9311425B2 (en) * 2009-03-31 2016-04-12 Qualcomm Incorporated Rendering a page using a previously stored DOM associated with a different page
US8301706B2 (en) 2009-06-15 2012-10-30 Microsoft Corporation Routing of pooled messages via an intermediary
US8549538B2 (en) * 2010-03-18 2013-10-01 Microsoft Corporation Coordinating communication medium state for subtasks
US8250234B2 (en) 2010-04-26 2012-08-21 Microsoft Corporation Hierarchically disassembling messages
US9262238B2 (en) * 2012-01-31 2016-02-16 Red Hat, Inc. Connection management for an application in a computing platform
US9665356B2 (en) 2012-01-31 2017-05-30 Red Hat, Inc. Configuration of an application in a computing platform
US9170797B2 (en) 2012-01-31 2015-10-27 Red Hat, Inc. Automated deployment of an application in a computing platform
US9513885B2 (en) 2013-08-22 2016-12-06 Peter Warren Web application development platform with relationship modeling
US20160328279A1 (en) * 2015-05-07 2016-11-10 Ebay Inc. Method and System for Providing a Framework as a Service
CN105183484A (en) * 2015-09-28 2015-12-23 北京奇虎科技有限公司 Method and device for compatibility of multi-version application programming interface
CN106250113A (en) * 2016-07-18 2016-12-21 百富计算机技术(深圳)有限公司 A kind of application development platform
US11520570B1 (en) * 2021-06-10 2022-12-06 Xilinx, Inc. Application-specific hardware pipeline implemented in an integrated circuit

Citations (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4996662A (en) * 1983-10-03 1991-02-26 Wang Laboratories, Inc. Method for generating document using tables storing pointers and indexes
US5727147A (en) * 1995-12-08 1998-03-10 Sun Microsystems, Inc. System and method for resolving symbolic references to externally located program files
US5748591A (en) * 1995-10-30 1998-05-05 Sony Corporation Disk drive
US6058389A (en) * 1997-10-31 2000-05-02 Oracle Corporation Apparatus and method for message queuing in a database system
US6088659A (en) * 1997-09-11 2000-07-11 Abb Power T&D Company Inc. Automated meter reading system
US6125363A (en) * 1998-03-30 2000-09-26 Buzzeo; Eugene Distributed, multi-user, multi-threaded application development method
US6199196B1 (en) * 1998-03-20 2001-03-06 Sun Microsystems, Inc. Methods and apparatus for linking a program for remote execution
US6253369B1 (en) * 1994-11-30 2001-06-26 International Business Machines Corp. Workflow object compiler with user interrogated information incorporated into skeleton of source code for generating executable workflow objects
US6256676B1 (en) * 1998-11-18 2001-07-03 Saga Software, Inc. Agent-adapter architecture for use in enterprise application integration systems
US6272674B1 (en) * 1998-12-14 2001-08-07 Nortel Networks Limited Method and apparatus for loading a Java application program
US6279030B1 (en) * 1998-11-12 2001-08-21 International Business Machines Corporation Dynamic JAVA™ class selection and download based on changeable attributes
US6282531B1 (en) * 1998-06-12 2001-08-28 Cognimed, Llc System for managing applied knowledge and workflow in multiple dimensions and contexts
US6308317B1 (en) * 1996-10-25 2001-10-23 Schlumberger Technologies, Inc. Using a high level programming language with a microcontroller
US6393605B1 (en) * 1998-11-18 2002-05-21 Siebel Systems, Inc. Apparatus and system for efficient delivery and deployment of an application
US6470494B1 (en) * 1998-11-30 2002-10-22 International Business Machines Corporation Class loader
US6490578B1 (en) * 2000-04-05 2002-12-03 Sybase, Inc. Database system with methodology for high-performance date
US6636855B2 (en) * 2001-03-09 2003-10-21 International Business Machines Corporation Method, system, and program for accessing stored procedures in a message broker
US6635089B1 (en) * 1999-01-13 2003-10-21 International Business Machines Corporation Method for producing composite XML document object model trees using dynamic data retrievals
US6643682B1 (en) * 1999-09-22 2003-11-04 International Business Machines Corporation Publish/subscribe data processing with subscription points for customized message processing
US6675381B1 (en) * 2000-01-20 2004-01-06 Mitsubishi Denki Kabushiki Kaisha Software-module dynamic loader, a software-module dynamic loading method and a medium storing the software-module dynamic loading method
US20040015954A1 (en) * 2001-03-19 2004-01-22 Autodesk, Inc. Method and apparatus for delivering electronic information
US6721777B1 (en) * 2000-05-24 2004-04-13 Sun Microsystems, Inc. Modular and portable deployment of a resource adapter in an application server
US6766361B1 (en) * 2000-02-24 2004-07-20 Cephire Technologies, Inc. Machine-to-machine e-commerce interface using extensible markup language
US6971001B1 (en) * 2001-05-17 2005-11-29 Accenture Global Services Gmbh General and reusable components for defining net-centric application program architectures
US7085814B1 (en) * 1999-06-11 2006-08-01 Microsoft Corporation Data driven remote device control model with general programming interface-to-network messaging adapter
US7092984B2 (en) * 2000-01-25 2006-08-15 Fujitsu Limited Method and apparatus for determining dynamic flow and computer-readable medium storing a program for performing the method
US20080052727A1 (en) * 2006-08-22 2008-02-28 International Business Machines Corporation Data processing system using matching engine and routing switch

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4984237A (en) * 1989-06-29 1991-01-08 International Business Machines Corporation Multistage network with distributed pipelined control
EP0490636B1 (en) * 1990-12-14 1998-09-09 Sun Microsystems, Inc. Method and apparatus for interprocess message switching
US5379426A (en) * 1991-01-25 1995-01-03 Sun Microsystems, Inc. Method and apparatus for object oriented interprocess message switching
US5371850A (en) * 1992-04-20 1994-12-06 Storage Technology Corporation Interprocess message queue
US5471626A (en) * 1992-05-06 1995-11-28 International Business Machines Corporation Variable stage entry/exit instruction pipeline
US5434975A (en) * 1992-09-24 1995-07-18 At&T Corp. System for interconnecting a synchronous path having semaphores and an asynchronous path having message queuing for interprocess communications
US5530848A (en) * 1992-10-15 1996-06-25 The Dow Chemical Company System and method for implementing an interface between an external process and transaction processing system
FR2702579B1 (en) * 1993-03-12 1995-05-24 Bull Sa Communication device between at least one client and at least one server, method of using the device and use of the device.
GB2345157B (en) * 1998-12-23 2003-06-18 Ibm Publish and subscribe data processing apparatus, method and computer program product with declaration of a unique publisher broker
GB9323241D0 (en) * 1993-11-11 1994-01-05 Int Computers Ltd Message handler
US5509000A (en) * 1994-06-10 1996-04-16 Motorola, Inc. Method and apparatus for routing information in a communication system
US6347342B1 (en) * 1996-07-15 2002-02-12 Next Software, Inc. Method and apparatus for dynamically brokering object messages among object models
US7028312B1 (en) * 1998-03-23 2006-04-11 Webmethods XML remote procedure call (XML-RPC)
US6510429B1 (en) * 1998-04-29 2003-01-21 International Business Machines Corporation Message broker apparatus, method and computer program product
US6182143B1 (en) * 1998-06-25 2001-01-30 International Business Machines Corporation Publish and subscribe data processing apparatus, method and computer program product with use of a stream to distribute local information between neighbors in a broker structure
US6144987A (en) * 1998-06-25 2000-11-07 Cisco Technology, Inc. System for characterizing information from an information producer
US6425017B1 (en) * 1998-08-17 2002-07-23 Microsoft Corporation Queued method invocations on distributed component applications
US6259461B1 (en) * 1998-10-14 2001-07-10 Hewlett Packard Company System and method for accelerating the rendering of graphics in a multi-pass rendering environment
US7047532B1 (en) * 1998-11-13 2006-05-16 The Chase Manhattan Bank Application independent messaging system
GB2345158A (en) * 1998-12-23 2000-06-28 Ibm Publish and subscribe data processing with ability to specify a local publication/subscription
GB2345164A (en) * 1998-12-24 2000-06-28 Ibm Publish and subscribe data processing with subscriber option to request subscription propagation prior to acknowledgment
US6298455B1 (en) * 1998-12-29 2001-10-02 International Business Machines Corporation Publish and subscribe data processing with failover using cascaded sequence numbers
US6715145B1 (en) * 1999-08-31 2004-03-30 Accenture Llp Processing pipeline in a base services pattern environment
US6434568B1 (en) * 1999-08-31 2002-08-13 Accenture Llp Information services patterns in a netcentric environment
US6748591B1 (en) * 2000-09-14 2004-06-08 International Business Machines Corporation Method, system, program, and data structures for loading programs into a runtime environment
US6704564B1 (en) * 2000-09-22 2004-03-09 Motorola, Inc. Method and system for controlling message transmission and acceptance by a telecommunications device
US6725446B1 (en) * 2000-11-01 2004-04-20 Digital Integrator, Inc. Information distribution method and system
US7136899B1 (en) * 2000-12-11 2006-11-14 Microsoft Corporation Inverse query decisions using binary decision diagrams and sub-expression implications
US6757901B1 (en) * 2000-12-21 2004-06-29 Cisco Technology, Inc. Method and system for setting expressions in network management notifications at an agent
US6993585B1 (en) * 2000-12-22 2006-01-31 Unisys Corporation Method and system for handling transaction requests from workstations to OLTP enterprise server systems utilizing a common gateway
US6772143B2 (en) * 2001-01-02 2004-08-03 Sprint Spectrum L.P. Method and system for managing messages
US6963930B2 (en) * 2001-02-15 2005-11-08 Centric Software, Inc. Automatic transfer and expansion of application-specific data for display at a website
US7257817B2 (en) * 2001-10-16 2007-08-14 Microsoft Corporation Virtual network with adaptive dispatcher
US20030074482A1 (en) * 2001-10-16 2003-04-17 Christensen Erik B. Composable messaging protocol
US7721193B2 (en) * 2001-10-18 2010-05-18 Bea Systems, Inc. System and method for implementing a schema object model in application integration
US7552205B2 (en) * 2002-05-21 2009-06-23 Accenture Global Services Gmbh Distributed transaction event matching
US7127520B2 (en) * 2002-06-28 2006-10-24 Streamserve Method and system for transforming input data streams
US7478402B2 (en) * 2004-02-12 2009-01-13 Microsoft Corporation Configurable message pipelines

Patent Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4996662A (en) * 1983-10-03 1991-02-26 Wang Laboratories, Inc. Method for generating document using tables storing pointers and indexes
US6253369B1 (en) * 1994-11-30 2001-06-26 International Business Machines Corp. Workflow object compiler with user interrogated information incorporated into skeleton of source code for generating executable workflow objects
US5748591A (en) * 1995-10-30 1998-05-05 Sony Corporation Disk drive
US5727147A (en) * 1995-12-08 1998-03-10 Sun Microsystems, Inc. System and method for resolving symbolic references to externally located program files
US6308317B1 (en) * 1996-10-25 2001-10-23 Schlumberger Technologies, Inc. Using a high level programming language with a microcontroller
US6088659A (en) * 1997-09-11 2000-07-11 Abb Power T&D Company Inc. Automated meter reading system
US6058389A (en) * 1997-10-31 2000-05-02 Oracle Corporation Apparatus and method for message queuing in a database system
US6199196B1 (en) * 1998-03-20 2001-03-06 Sun Microsystems, Inc. Methods and apparatus for linking a program for remote execution
US6125363A (en) * 1998-03-30 2000-09-26 Buzzeo; Eugene Distributed, multi-user, multi-threaded application development method
US6282531B1 (en) * 1998-06-12 2001-08-28 Cognimed, Llc System for managing applied knowledge and workflow in multiple dimensions and contexts
US6279030B1 (en) * 1998-11-12 2001-08-21 International Business Machines Corporation Dynamic JAVA™ class selection and download based on changeable attributes
US6256676B1 (en) * 1998-11-18 2001-07-03 Saga Software, Inc. Agent-adapter architecture for use in enterprise application integration systems
US6393605B1 (en) * 1998-11-18 2002-05-21 Siebel Systems, Inc. Apparatus and system for efficient delivery and deployment of an application
US6470494B1 (en) * 1998-11-30 2002-10-22 International Business Machines Corporation Class loader
US6272674B1 (en) * 1998-12-14 2001-08-07 Nortel Networks Limited Method and apparatus for loading a Java application program
US6635089B1 (en) * 1999-01-13 2003-10-21 International Business Machines Corporation Method for producing composite XML document object model trees using dynamic data retrievals
US7085814B1 (en) * 1999-06-11 2006-08-01 Microsoft Corporation Data driven remote device control model with general programming interface-to-network messaging adapter
US6643682B1 (en) * 1999-09-22 2003-11-04 International Business Machines Corporation Publish/subscribe data processing with subscription points for customized message processing
US6675381B1 (en) * 2000-01-20 2004-01-06 Mitsubishi Denki Kabushiki Kaisha Software-module dynamic loader, a software-module dynamic loading method and a medium storing the software-module dynamic loading method
US7092984B2 (en) * 2000-01-25 2006-08-15 Fujitsu Limited Method and apparatus for determining dynamic flow and computer-readable medium storing a program for performing the method
US6766361B1 (en) * 2000-02-24 2004-07-20 Cephire Technologies, Inc. Machine-to-machine e-commerce interface using extensible markup language
US6490578B1 (en) * 2000-04-05 2002-12-03 Sybase, Inc. Database system with methodology for high-performance date
US6721777B1 (en) * 2000-05-24 2004-04-13 Sun Microsystems, Inc. Modular and portable deployment of a resource adapter in an application server
US6636855B2 (en) * 2001-03-09 2003-10-21 International Business Machines Corporation Method, system, and program for accessing stored procedures in a message broker
US20040015954A1 (en) * 2001-03-19 2004-01-22 Autodesk, Inc. Method and apparatus for delivering electronic information
US20060064573A1 (en) * 2001-05-17 2006-03-23 Accenture Global Services Gmbh Pipeline architecture for use with net-centric application program architectures
US6971001B1 (en) * 2001-05-17 2005-11-29 Accenture Global Services Gmbh General and reusable components for defining net-centric application program architectures
US7739657B2 (en) * 2001-05-17 2010-06-15 Accenture Global Services Gmbh Pipeline architecture for use with net-centric application program architectures
US20080052727A1 (en) * 2006-08-22 2008-02-28 International Business Machines Corporation Data processing system using matching engine and routing switch

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7865424B2 (en) 2000-05-08 2011-01-04 Option It, Inc. Method and system for reserving future purchases of goods and services
US8620771B2 (en) 2000-05-08 2013-12-31 Smart Options, Llc Method and system for reserving future purchases of goods and services
US8650114B2 (en) 2000-05-08 2014-02-11 Smart Options, Llc Method and system for reserving future purchases of goods or services
US20080215495A1 (en) * 2000-05-08 2008-09-04 Pappas Christian S Method and system for reserving future purchases of goods and services
US20080215457A1 (en) * 2000-05-08 2008-09-04 Pappas Christian S Method and system for reserving future purchases of goods and services
US9070150B2 (en) 2000-05-08 2015-06-30 Smart Options, Llc Method and system for providing social and environmental performance based sustainable financial instruments
US9064258B2 (en) 2000-05-08 2015-06-23 Smart Options, Llc Method and system for reserving future purchases of goods and services
US9047634B2 (en) 2000-05-08 2015-06-02 Smart Options, Llc Method and system for reserving future purchases of goods and services
US20080021810A1 (en) * 2000-05-08 2008-01-24 Pappas Christian S Method and system for reserving future purchases of goods and services
US9092813B2 (en) 2000-05-08 2015-07-28 Smart Options, Llc Method and system for reserving future purchases of goods and services
US8032447B2 (en) 2000-05-08 2011-10-04 Option It, Inc. Method and system for reserving future purchases of goods and services
US7996292B2 (en) 2000-05-08 2011-08-09 Option It, Inc. Method and system for reserving future purchases of goods and services
US9026471B2 (en) 2000-05-08 2015-05-05 Smart Options, Llc Method and system for reserving future purchases of goods and services
US9026472B2 (en) 2000-05-08 2015-05-05 Smart Options, Llc Method and system for reserving future purchases of goods and services
US8930260B2 (en) 2000-05-08 2015-01-06 Smart Options, Llc Method and system for reserving future purchases of goods and services
US8229841B2 (en) 2000-05-08 2012-07-24 Smart Options, Llc Method and system for reserving future purchases of goods and services
US8301550B2 (en) 2000-05-08 2012-10-30 Smart Options, Llc Method and system for reserving future purchases of goods or services
US8543450B2 (en) 2000-05-08 2013-09-24 Smart Options, Llc Method and system for reserving future purchases of goods and services
US7962375B2 (en) 2000-05-08 2011-06-14 Option It, Inc. Method and system for reserving future purchases of goods and services
US7739657B2 (en) 2001-05-17 2010-06-15 Accenture Global Services Gmbh Pipeline architecture for use with net-centric application program architectures
US20060064573A1 (en) * 2001-05-17 2006-03-23 Accenture Global Services Gmbh Pipeline architecture for use with net-centric application program architectures
US8185747B2 (en) * 2003-05-22 2012-05-22 Access Security Protection, Llc Methods of registration for programs using verification processes with biometrics for fraud management and enhanced security protection
US20070288759A1 (en) * 2003-05-22 2007-12-13 Wood Richard G Methods of registration for programs using verification processes with biometrics for fraud management and enhanced security protection
US20090112932A1 (en) * 2007-10-26 2009-04-30 Microsoft Corporation Visualizing key performance indicators for model-based applications
US8191042B2 (en) * 2008-02-29 2012-05-29 Microsoft Corporation Continuation based declarative definition and composition
US8181155B2 (en) 2008-02-29 2012-05-15 Microsoft Corporation Unified expression and location framework
US20090222827A1 (en) * 2008-02-29 2009-09-03 Microsoft Corporation Continuation based declarative definition and composition
US20140013300A1 (en) * 2009-08-27 2014-01-09 Crimson Corporation Platform for development and deployment of system administration solutions
US9092201B2 (en) * 2009-08-27 2015-07-28 Crimson Corporation Platform for development and deployment of system administration solutions
US9507891B1 (en) 2015-05-29 2016-11-29 International Business Machines Corporation Automating a microarchitecture design exploration environment
US9665674B2 (en) * 2015-05-29 2017-05-30 International Business Machines Corporation Automating a microarchitecture design exploration environment

Also Published As

Publication number Publication date
EP1727041A3 (en) 2006-12-20
CA2446809A1 (en) 2002-11-21
EP1727045A3 (en) 2006-12-20
WO2002093364A3 (en) 2004-03-18
US6971001B1 (en) 2005-11-29
US7739657B2 (en) 2010-06-15
CA2446809C (en) 2012-10-23
US20060064573A1 (en) 2006-03-23
EP1727045A2 (en) 2006-11-29
EP1428115A2 (en) 2004-06-16
AU2002319843B2 (en) 2005-11-24
WO2002093364A2 (en) 2002-11-21
EP1727041A2 (en) 2006-11-29

Similar Documents

Publication Publication Date Title
US7739657B2 (en) Pipeline architecture for use with net-centric application program architectures
AU2002319843A1 (en) General and reusable components for defining net-centric application program architectures
US8626803B2 (en) Method and apparatus for automatically providing network services
US7330878B2 (en) Method and system for remote control of a local system
JP5248964B2 (en) Method and system for generating screen elements or data objects for wireless applications
RU2419837C2 (en) Work streams aimed at data
US7188158B1 (en) System and method for component-based software development
US8296412B2 (en) Method and system for event impact analysis
US20030093575A1 (en) Application view component for system integration
US7055134B2 (en) Service provider integration framework in object oriented programming environment
EP1287430A2 (en) System, method, and article of manufacture for distributed garbage collection in environment services patterns
WO2001016723A2 (en) A system, method and article of manufacture for a multi-object fetch component in an information services patterns environment
WO2001016734A2 (en) A system, method and article of manufacture for a self-describing stream in a communication services patterns environment
US7533114B2 (en) Mobile device having extensible software for presenting server-side applications, software and methods
Bálek Connectors in software architectures
CA2551025C (en) Application framework for use with net-centric program architectures
AU2006200733B2 (en) Application framework for the use with net-centric application program architectures
AU2006200734B2 (en) Pipeline architecture for use with net-centric application program architectures
Nyberg et al. Mastering BEA WebLogic Server: best practices for building and deploying J2EE applications
US20040039994A1 (en) System and process for communication between Java server pages and servlets
Talevski et al. Meta model driven framework for the integration and extension of application components
Siddiqui Time/performance budgeting for software designs
Jacob The OMEGA Component Model
Middleware et al. Xinetica White Paper

Legal Events

Date Code Title Description
AS Assignment

Owner name: ACCENTURE GLOBAL SERVICES GMBH, SWITZERLAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROLFS, DAMON M.;REEL/FRAME:024791/0036

Effective date: 20010823

AS Assignment

Owner name: ACCENTURE GLOBAL SERVICES LIMITED, IRELAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ACCENTURE GLOBAL SERVICES GMBH;REEL/FRAME:025700/0287

Effective date: 20100901

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION