WO2015059650A1 - Detachable functionality - Google Patents

Abstract

There is disclosed a detachable module, detachable from a database layer, which includes a database, for application implementation. The detachable module includes a logic layer comprising user oriented functions; and, an interface in communication with the logic layer, and for communication with a database layer external to the detachable module. The interface is also for obtaining data from the database layer for executing the user oriented functions.

Description

DETACHABLE FUNCTIONALITY

CROSS REFERENCES TO RELATED APPLICATIONS

This patent application is related to and claims priority from commonly owned U.S. Provisional Patent Application Serial No. 61/893,943, entitled: Detachable Functionality, filed on October 22, 2013, the disclosure of which is incorporated by reference in its entirety herein.

This patent application is also related to commonly owned PCT Patent Application entitled: Application Server, Attorney Docket No. 5592/5, filed on October 22, 2014, the same day as this PCT Patent Application, which is incorporated by reference in its entirety herein.

TECHNICAL FIELD

The present invention is directed to application server software and tools/libraries for developing server applications.

BACKGROUND

There are many instances of contemporary internet applications which have common requirements for such things as: support for multiple concurrent users, support for different views of data among multiple users, support for quick and reliable reattachment of users to the server following a communication outage, reuse of software modules in different applications, and runtime upgrade of soitware modules. Application Server developers must expend time and resources to solve these problems, which sometimes remain inadequately addressed.

SUMMARY

Embodiments of the present invention are directed to internet applications utilizing servers which are otherwise not limited to a particular programming language or technology. These applications implement functionality in "detachable function modules" (DF). These DFs typically include executable code that invokes the Transaction API of an application Server. These DFs also provide an API (Application Program Interface) for handling of user events (so that the DF can be viewed as a middleware layer between user event handling software and the application data as maintained by the data base). Additionally, the DFs can be attached or detached at any time from the server.

Detaching will leave the server data in a valid state - so that the server application will not be fundamentally affected by the detaching process. The only consequence of detaching is that a certain set of exposed functions will cease to exist, in such a case the users will be informed that their invocation requests targeting the missing functionality could not be fulfilled. It is up to the client application on the users' side to take appropriate measures/procedures in such a situation.

One simple scenario might be to retry a request later. However, the server will not detach the DF in an uncontrolled manner. In the example of a Poker game, the DF will be detached once a hand of Poker is over. In that situation the only invocation request users can issue is the request for leaving the room. This request will be repeated until fulfilled.

Embodiments of the present invention are also directed to a detachable module, detachable from a database layer, which includes a database, for application implementation. The detachable module includes a logic layer comprising user oriented functions; and, an interface in communication with the logic layer, and for communication with a database layer external to the detachable module. The interface is also for obtaining data from the database layer for executing the user oriented functions.

Embodiments of the present invention are directed to a detachable module for application implementation. The detachable module comprises: a logic layer comprising user oriented functions; and, an interface operatively coupled in electronic and/or data communication with the logic layer, and for electronic and/or data communication with a database layer (e.g., including a database) external to the detachable module, the interface for obtaining data from the database layer for executing the user oriented functions.

Optionally, the logic layer utilizes the obtained data for executing the user oriented functions.

Optionally, the interface layer is configured to support attachment and. detachment ΐο the database layer.

Embodiments of the present invention are also directed to an application server system. The application server system comprises: a database; at least one first module detachable from the database; and, a second module for attaching the at least one first module to the database. The second module for attaching the at least one firs module to the database comprises: a logic layer comprising user oriented functions; and, an interface in communication with the logic layer, and in communication with the database external to the detachable module, the interface for obtaining data from the database for executing the user oriented functions.

Optionally, the second module creates records in the database for attaching the at least one first module to the database.

Optionally, the at least one first module attaches additional first modules to the database.

Optionally, the at least one first module creates records in the database for attaching the additional first modules to the database.

Optionally, the second module includes instructions for the system to execute a boot procedure which initiates the creation of the records.

Optionally, the second module includes instructions to shut down the at least one first module and detach it from the database.

Optionally, the second module includes instructions to attach another to the at least one first module to the database record previously utilized by the previous at least one first module.

Embodiments of the present invention are directed to a method for upgrading a currently operational software application. The method comprises: terminating at least one first module by a user management process; and, installing a replacement module including attaching the replacement module to the database record used by the terminated at least one first module.

This document references terms that are used consistently or interchangeably herein. These terms, including variations thereof, are as follows.

"n" and "n¹¹¹" in the description below and the drawing figures represents the last member of a series or sequence of members, such as elements, servers, databases, caches, components, listings, links, data files, etc.

A "computer" includes machines, computers and computing or computer systems (for example, physically separate locations or devices), servers, computer and computerized devices, processors, processing systems, computing cores (for example, shared devices), and similar systems, workstations, modules and combinations of the aforementioned. The aforementioned "computer" may be in various types, such as a personal computer (e.g., laptop, desktop, tablet computer), or any type of computing- device, including mobile devices that can be readily transported from one location to another location (e.g., smartphone, personal digital assistant (PDA), mobile telephone or cellular telephone).

A server is typically a remote computer or remote computer system, or computer program, therein, in accordance with the "computer" defined above, that is accessible over a communications medium, such as a communications network or other computer network, including the Internet. A "server" provides services to, or performs functions for, other computer programs (and their users), in the same or other computers. A server may also include a virtual machine, a software based emulation of a computer.

An "application", includes executable software, and optionally, any graphical user interfaces (GUI), through which certain functionality may be implemented.

A "client" is an application that runs on a computer, workstation or the like and relies on a server to perform some of its operations or functionality.

HTTP (Hypertext Transfer Protocol) is an application protocol for distributed, collaborative, hypermedia information systems. Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. HTTP is the protocol to exchange or transfer hypertext.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control, in addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting. BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

Attention is now directed to the drawings, where like reference numerals or characters indicate corresponding or like components. In the drawings:

FIG. 1 is a diagram of an exemplary environment on which embodiments of the present invention are performed;

FIG. 2 is a diagram of the architecture of the application server on which embodiments of the present invention are performed;

FIG. 3 illustrates the logical components and software interfaces of a Detachable Function module; and,

FIGs. 4-6 are flow diagrams detailing processes performed in accordance with embodiments of the present invention.

DETAILED DESCRIPTION OF THE DRAWINGS

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optica] storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF (Radio Frequency), etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such, as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special puipose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a non-transitory computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored on the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

Reference is now made to FIG. 1, which shows an operating environment for an application server (AS) 100, for example, a computer system, implemented in a user- server configuration according to some embodiments of the present invention and addressable over a network 50, by being linked either directly or indirectly to the network 50. The network 50 is a Local Area Network (LAN), or a Wide Area Network (WAN), including public networks such as the Internet. The application server 100 implements the logic of an application. The application is, for example, a process embodied in software, or the like, which is accessed and executed by the users 110a- 11 On through their computers l l la-l l ln, over the network 50. The users 1 lOa-ΠΟη, with their respective computers 111 a- 11 In, link to the network 50, either directly or indirectly, and connect to the application server 300, in order to use (run and execute) and consume (receiving information from the application and sending requests to the application server 100 that change the application itself) the application, including, for example, receiving information from the application and sending requests to the application server 100, that will change the application itself. The users 110a- 1 1 On may also have key rings 112a~112n associated with their respective computers l l la-l l ln, on which keys are held, allowing the users to access locked applications on the application server 100.

Throughout this document, the users 1 10a- 1 1 On are referenced with their respective computers l l la-l l ln. Accordingly, except where otherwise indicated, the "users" 1 10a- 1 1 On indicates each of the users 110a- 1 10η with their respective computers l l la-l l ln.

The application server 100 utilizes hardware, software and combinations thereof, for performing the processes and methods of the present invention. As shown in FIG. 2, the application server 100 includes an architecture 100' formed, for example, of three layers. These layers include a database layer 202, a transaction API (Application Programming Interface) layer 204, also known as an API or simply an interface, and an application layer 206, also known for example, as an application.

The database layer 202 includes, for example, interfaces, databases, entities, and locking mechanisms. The interface is, for example, a collection interface. This layer 202, for example, serves as a database for storing collections, scalars, and the like. Application data is modeled with the collection interface, and the collection interface allows for modeling of an application in a tree-like manner, with collections serving as branches or containers for collections and scalars, and scalars serving as endpoints or leaves. Collections and scalars are both entities, with Collection mapping entities to names Scalar containing parameters, including value(s), name(s) and key(s). For example, in a files system, as disclosed herein, a "Collection" models the directory for the file system and a "Scalar" models the file(s). Scalars do not exist independently, but rather, only exist when collections are present.

An Entity or Entity Interface, is the base interface for a Collection and a Scalar. The Entity Interface has two features: 1) locking, and, 2) data manipulation.

Locking an Entity Interface (or Entity) is achieved with a key. Keys are strings of text, that when empty are considered "unlocked" or "public", accessible to all users. Data with keys (non-empty) are readable only by users holding a corresponding key. Should a user not hold a corresponding non-empty key, their key ring, on which their key is held, will read out the Entity as an undefined value, e.g., empty or null value. The Scalar specialization of the Entity Interface introduces a possibility to expose two values in the case when it is locked by a non-empty key: 1 ) the private value that will be exposed to users holding the corresponding key in their key ring; and, 2) the public value that will be exposed to users not holding the corresponding key in their key ring. The scalar interface is depicted in FIG. 10.

Data manipulation is performed by primitive data applications, also known as primitives. There are only two primitives, SET and REMOVE. Collections implement both SET and REMOVE primitives, while scalars implement only the SET primitive.

A collection is an extension of the Entity Interface. The collection extends the entity interface by introducing: 1) the list of clients; and, 2) the commit and the dump method. The client is a structure that has: 1) a key ring, which is a collection of keys; and, 2) a collection. The client maintains its collection with respect, to its key ring.

The collection also involves a "commit" procedure, formed of subprocedures including: 1) Taking a named array of primitives of the transaction; 2) performing all primitives from the array in a sequential order. 3) producing a particular Filtered Transaction for every client of the collection (detailed below). After the "commit" is done, each client of the collection will receive its Filtered Transaction to commit locally in order to come up with an accurate replica of the original collection.

A "Filtered Transaction" is a transaction that, once committed by a client, will produce a data tree that will accurately represent the original data tree with respect to the client's privileges materialized in a form of a key ring; this means that the resulting client's data tree contain all the data entities that are 1) not locked by a key; and, 2) locked by keys the client currently possesses in its key ring.

There is also a "dump" procedure, performed exactly once per each client in the client list, prior to putting the client in the list of clients, "dump" procedure is formed of subprocedures including: 1) Taking a client's key ring; 2) taking the current state of data in current moment of time; 3) producing a resulting transaction that is initially empty; 3) looping through all the entities of the current state of data; 4) for each entity in the current state of data producing a primitive that accurately describes the entity; 5) copying each produced primitive into the resulting transaction. The result of the "dump" procedure is a Filtered Transaction that will be sent over to the client so that the client can commit it and come up with an accurate initial replica of the original collection.

The transaction API layer 204 is where the contents of the data structure is altered. An array of primitives is designated as a transaction. A transaction is defined by its name and the array of primitives to be performed. Primitives can not exist independently, they are only contained within transactions. The transaction may be implemented in any programming language, such as JAVA Script, and the like.

The transaction API layer 204 also supports filtered transactions. A filtered transaction is derived from a particular transaction associated with a particular key ring. Different key rings will derive different filtered transactions from the same original transaction.

The application layer 206 supports actual applications. These applications are, for example, games such as poker, taking place in a room, as detailed in commonly owned PCT Patent Application entitled: Application Server, Attorney Docket No. 5592/5, filed on October 22, 2014, the same day as this PCT Patent Application, or other programs which are cumulative, building on actions of each prior user.

Returning to FIG. 1, users l lOa-l 10η, through their computers 11 la-11 In connect to the application server 100 in order to receive information from the application in the application server 100 and send requests to the application server 100 that change the application cumulatively.

A detachable function module (DF) 300, as shown in FIG. 3, referred to hereinafter as "DF", is a software module (software library). It contains executable code, exposed in a form of exported functions. Each function exported is recognized by its export name. Two special function names are recognized: 1) "init" and 2) "destruct". "init", if exposed by a DF 300, will be called immediately after the DF 300 is attached to a particular collection, "destruct", if exposed by a DF, will be called prior to the DF 300 being detached from the collection. DF impiementer is free to assemble executable code in these functions so that a DF as a whole behaves accordingly in the situations of initialization and destruction. All other functions have no special status. These other functions together build an API of the particular DF 300. This API is exposed to clients. Client executable code has to be programmed with a priori knowledge of the API exposed by the DF 300. In order to achieve a possibility for the client code to adapt to changes in the API of a particular DF (that is physically performed on the server by detaching a DF 300 with older API and attaching a DF 300 with a new API to the same collection), programming techniques/paradigms might be used based on interface querying (e.g., the DOM (Document Object Model) or CORBA (Common Object Request Broker Architecture) programming paradigms).

A DF 300 is typically instantiated with a particular set of run-time parameters. A typical example is a Player DF in Poker. All collections in a Poker room that represent seats for Players will have a Player DF attached to them. However, each Player DF will be instantiated with a different seat ordinal number. Each instance of a DF will reside in its part of the memory. The memory is populated with run-time parameters during the attaching procedure. The detaching procedure will release this memory.

The present invention relates to the architecture and implementation of the application layer 206. FIG. 3 illustrates the components and interfaces of the application layer 206. At the logical lower edge of the application layer there exists an interface to the Transaction API 310 - as all of the other components in the module utilize the Transaction API 360 to modify the state of the application. The components of the DF 300 use the Transaction API 360 to attach to and operate on one "collection" 370 maintained by the database layer 380.

The DF 300 offers services to other DFs and ultimately to users located across the network 50 through means of a transport layer that is left to the impiementer. It should be noted that transport should work consistently across 1) different software layers within the server process; 2) different processes within the server hardware memory; 3) different processes within a network (irrespective of how wide a network might be, for example LAN/Local Area Network, WAN/Wide Area Network or the Internet as a global network). The services are provided in the form of user-in vocable functions (user- oriented functions) 330. These user-invocable functions 330 are implemented in Javascript or any other implementation technology. In addition there are zero or more functions for initialization and destruction 350. Should the functions for initialization and destruction exist, they need to be called 1) "init" in which case this function will be called upon the very moment of attaching the DF 300 to the collection 370, 2) "destroy" in which case this function will be called prior to the moment of detaching the DF 300 from the collection 370. The described pair of functions mimics the Object Oriented paradigm that assumes a pair of constructor/destructor functions on Objects. The specific functions for the user-invocable functions 330 are dependent on the application e.g., there might be a function to add a new player to a multiplayer game. The functions for initialization and destruction 350 might include an initialization function that is run each time a DF 300 attaches to a collection instance.

It will be understood from the above description that the runtime functionality application layer is implemented significantly or entirely by way of the specialized Detachable Functions. However, a boot procedure should also be performed to initialize or set up, the system, such that the detachable functions and corresponding DFs 300 can operate.

Processes performed by the application server 100 and the client are now described with reference to the flow diagrams of FIGs. 4-6. The processes performed are, for example, performed automatically and in real time.

FIG. 4 is a flow diagram illustrating the sequence of steps executed at system initialization (e.g., by a boot process) to start operation of an application that is based on the database together with Detachable Function modules 300. This flow diagram shows the fimctions performed by an instance of the boot procedure.

Initially, at block 410 the boot procedure uses the Transaction API 204 to create initial collection instances. The process moves to block 420, where zero or more DFs 300 (FIG. 3) are attached to each of the created collection instances. Finally, at block 430 the initialization functions of each of the DFs is invoked (if extant). It will be understood that particular choices of collections to initialize and DFs to attach are dependent on the application. It will also be understood that the order of operations in this flow diagram is chosen for exemplary convenience and that other orders of operation are possible.

FIG. 5 is a flow diagram illustrating the steps that might be taken by a initialization function DF 300 (FIG. 3) component as part of the attachment of the DF to a collection instance. This flow diagram shows steps which are, for example, taken in a DF's 300 (FIG. 3) initialization function. At block 510 collections and scalars appropriate to the application are created, inside the initial attached collection (e.g., a collection containing scalars representing cards in a poker hand might be created). The process moves to block 520, where other DFs 300 might be attached to any newly created collections, it will be understood that particular choices of collections and scalars to initialize and DFs to attach are dependent on the application. It will also be understood that the order of operations in this flow diagram is chosen for exemplaiy convenience and that other orders of operation are possible.

The DF 300 (FIG. 3) can be removed (and possibly replaced/updated) while the system is in operation. FIG. 6 is a flow diagram illustrating a sequence of events which are executed to detach a DF 300 (FIG. 3) from the system during operation.

Initially, at block 10, if the DF exposes a destruction function "destruct", it will be called prior to detaching. For example, in most gaming applications the "destruct" function will not be exposed in the DF; thereby the collection to which the DF was attached will be left in a state ready for eventual reattachment of a DF with updated/improved functionality. Then, at block 620, the memory that contained the executable code and. optional accompanying temporary run-time data (depending on the particular DF's implementation) of a DF will be released.

Once the DF is detached, clients will be left with no possibility to invoke functions that were originally exposed by the now detached DF. It is up to the logic of the client's software to act accordingly with this situation. On the other side, it is up to the server logic to recognize an optimal moment in time when a DF should be detached. Typically, a gaming algorithm allows for recognition of temporal units of data processing (e.g., a Poker hand is such a temporal unit). The moment when a temporal unit is over is a proper moment to detach an existing DF and re-attach a DF with updated improved functionality. A more sophisticated mechanism for detaching a DF might include setting a specially designated scalar at a specially designated location in the data structure ~ through an accompanying Transaction. Such a data alteration will be communicated to clients in a form of a Filtered Transaction. Clients will recognize the special scalar and refrain from sending invocation requests towards a DF that is detached; they will wait for the scalar to be removed and then continue with sending invocation requests, assured that the DF is in back in place.

The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. The terms "comprises", "comprising", "includes", "including", "having" and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of and "consisting essentially of.

The phrase "consisting essentially of means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise.

The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments". Any particular embodiment of the invention may include a plurality of "optional" features unless such features conflict.

It is appreciated, that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

Claims

What is claimed is:

1. A detachable module for application implementation, comprising: a logic layer comprising user oriented functions; and, an interface in communication with the logic layer, and for communication with a database layer external to the detachable module, the interface for obtaining data from the database layer for executing the user oriented functions.

2. The detachable module of claim 1, wherein the logic layer utilized the obtained data for executing the user oriented functions.

3. The detachable module of claim 2, wherein the interface layer is configured to support attachment and detachment to the database layer.

4. An application server system comprising: a database; at least one first module detachable from the database comprising: a logic layer comprising user oriented functions; and, an interface in communication with the logic layer, and in communication with the database external to the detachable module, the interface for obtaining data from the database for executing the user oriented functions; and, a second module for attaching the at least one first module to the database.

5. The system of claim 4, wherein the second module creates records in the database for attaching the at least one first module to the database.

6. The system of claim 5, wherein the at least one first module attaches additional first modules to the database.

7. The system of claim 6, wherein the at least one first module creates records in the database for attaching the additional first modules to the database.

8. The system of claim 7, wherein the second module includes instructions for the system to execute a boot procedure which initiates the creation of the records.

9. The system of claim 8, wherein the second module includes instructions to shut down the at least one first module and detach it from the database.

10. The system of claim 9, wherein the second module includes instructions to attach another to the at least one first module to the database record previously utilized by the previous at least one first module.

1 1. A method for upgrading a currently operational software application comprising: terminating at least one first module by a user management process; and, installing a replacement module including attaching the replacement module to the database record used by the terminated at least one first module.