Patent Application
20160364277
This invention provides a method of using user session data to provide a middle-ware function to integrate data across multiple applications thereby providing a method of sharing user generated data between applications by enabling the data stored in the user session to be shared across one or more applications.
Middle-ware systems and software have been used extensively to connect different applications together, to automate business processes across multiple applications to complete business workflows.
The typical middleware software systems are sited between two or more applications passing transactions between the systems. In some implementations the middleware acts as a broker between the applications and perform data transformation as transaction objects are passed between the applications in order to mediate the transactions between the applications.
U.S. Pat. No. 7,003,482 B1-Middleware for business transactions
U.S. Pat. No. 7,216,181 B1-Middleware brokering system
U.S. Pat. No. 8,032,636 B2-Dynamically provisioning clusters of middleware appliances
US 20130227547 A1-Adaptable middleware layer
Many companies, such as insurance companies and financial service organizations, have come to rely on software systems to help operate their businesses. The software systems may include a program or programs that process and store data associated with business transactions. Such programs may be referred to as business transaction servers. To process a particular business transaction, one or more business transaction servers may be used.
To use a business transaction server, an interface program may be needed to interact between the business transaction server and a user. Typically, the interface program receives input data from the user, transforms the data into a form that is recognizable to the business transaction server, and transmits the data to the server. The server receives the data, processes the data, and the server returns results to the interface program. The interface program receives the results from the server and the interface program may transform the results into a desired output form. The interface program may provide both a graphical user interface to a specific data input source, and a functional interface that communicates with a business transaction server.
There are many different systems and ways in which a user may input data.
A system for inputting data into a computer system may be referred to as a “channel.” Channels include, but are not limited to, office terminal entry systems, kiosk systems, Internet systems, and telephone centre assistance systems. A channel may be limited to certain types of transactions. For example, in the insurance industry, a kiosk entry system may be set up to process only insurance quotes, while an office terminal entry system located in an insurance company office may be set up to allow all available types of insurance transactions.
The order in which data is requested from a user for a specific type of transaction may vary depending upon which type of channel is being used. For example, when a telephone assistance centre entry system is used, one of the first pieces of information requested from the user is the user's name; while the user's name is often one of the last pieces information requested from a user when using an Internet entry system. Because the order in which data is entered for different types of channels may vary, the interface program between a user and a business transaction server may be different for each different channel.
Typically, a company wants the graphical user interface that the company uses to be unique. Even if two companies use the same types of business transaction servers for the same types of business transactions, it is very likely that the graphic user interfaces for the two companies will be different. An interface program supplier may not be able to write one generic set of computer code that operates as an interface program for several different clients.
Typically, programmers write computer code to create a required interface program between a specific type of channel and a business transaction server or servers. If a company wants to offer the ability to enter data through a different type of channel that requires a different mode or layout for data entry, another interface program would have to be written for the new channel. Typically, programmers who create interface programs have to code both a graphical user interface and a functional interface to the business transaction server or servers.
Writing computer code to provide the required interfaces typically requires specialist programmers who are familiar with the data requirements of the server, and who are also familiar with the specific requirements of data entry for the channel. Writing computer code to provide interfaces for two different types of channels may result in inefficient duplication of code in separate programs.
Developing an interface system between a user and a business transaction server could take months. One approach towards reducing development time is to use object-oriented software design techniques. Object-oriented software design may include the use of objects and classes. An object may include an encapsulation of data and methods for manipulating the data. A class may include a template for an object. An object is therefore an instance of a class, and an object is created by instantiating it from a class. Object-oriented techniques, when used properly, may permit the re-use of previously written program code such as classes.
Web browser interaction with a web server over an IP connection using HTTP protocol is well known in the art.
There many web applications incorporate multiple services into the web application such as an online shop using a payment gateway to complete a purchase. In general these application have a single purpose, and the external services are directly associated with execution of the primary purpose.
With the advent of mobile computing it has been necessary to substantially simplify many business applications when delivering them over a mobile device. As a result it has been necessary to split business systems over one more applications running on mobile devices with the result that many users are forced to open multiple applications in order to complete a work task.
It is an object of at least embodiments of the present invention to address or ameliorate the above-mentioned problems.
Application is a business application that the middleware software is communicating with.
Middleware software sits between different applications passing business transactions between the different applications.
Session data this is data that has been user generated as the user transactions with the applications integrated into the User Application.
User Application is an application that a user interacts with. This application could be a native application running on the user workstation or a web application where the user is interacting with the application via web browser or mobile application.
User Interface is the user interface to the User Application.
Primary event is a transaction event that is initiated by the user. This could be a query, retrieval, and business process step or data update event.
Secondary event is a transaction event that is initiated by a primary event as part of its execution process.
This invention seeks to extend the typical web application functionality to enable the application to execute multiple workflow processes that are initiated by the user. These workflow processes may be ad hoc enabling the user to dynamically move between the different applications or as a pre-defined process that the user is working through.
In preferred embodiments, this is achieved by sharing user's session data across multiple different applications. In preferred embodiments, this is achieved by terminating the different applications into an integrating software component that allows the user to access and execute each application's components and store access data structures in a common data area.
As a result, as the user executes their business process they retrieve and store application data that follows their workflow process.
The stored data once accessed and stored in the user session, the data object can be used or be passed to other applications as the user seeks to access different applications.
For Example Repairing a Fridge:
This process reduces the need to re-enter data or query the application databases to fill the order form.
Accordingly, in one broad form of the invention, there is provided a method of inserting a middle ware layer between a web application's user interface or web application service and business applications; said method comprising the steps:
Preferably, the Method Further Includes the Steps:
Preferably each Transaction Event Process Consists of:
Preferably the Session Middleware Layer is Able to:
Preferably the session middleware layer contains the logic necessary to define the primary business application event and all secondary business application events needed to complete any arbitrary user transaction, thereby defining the process for completing any user generated request.
Preferably the session middleware logic contains the necessary business rules to determine when any primary or secondary business event is to be triggered, this logic includes:
Preferably the interfaces between the middleware layer and the business applications are reusable across multiple different middleware transaction events, or when new business applications are added to the middleware layer environment.
Preferably the cross references between middleware layer and business applications object can be implemented directly in middleware layer application source code or stored in a data file or database and loaded on application start up.
Preferably the middleware event logic can be implemented directly in middleware layer application source code or stored in a data file or database and loaded on application start up.
In a further broad form of the invention, there is provided a system consisting of a middle ware layer inserted between a web application's user interface or web application service that:
Preferably a web application or mobile app service contains a session based middleware layer between the web application or mobile app service and the business applications, whereby the system facilitates the integration of user generated transactions generated via the web application with the one or more business applications; the system further including:
Preferably each Transaction Event Process Consists of:
Preferably the Session Middleware Layer is Able to:
Preferably the session middleware layer contains the logic necessary to define the primary business application event and all secondary business application events needed to complete any arbitrary user transaction, thereby defining the process for completing any user generated request.
Preferably the session middleware logic contains the necessary business rules to determine when any primary or secondary business event is to be triggered, this logic including:
Preferably the interface between the middleware layer and the business applications is reusable across multiple different middleware transaction events, or when new business applications are added to the middleware layer environment.
Preferably the cross references between middleware layer and business application objects can be implemented directly in middleware layer application source code or stored in a data file or database and loaded on application start up.
Preferably the middleware event logic can be implemented directly in middleware layer application source code or stored in a data file or database and loaded on application start up.
In a further broad form of the invention there is provided a web application or mobile app service containing a session based middle layer between the web application or mobile app service and the business to facilitate the integration of the user generated transactions with the one or more business applications where:
Preferably each Transaction Event Process Consists of:
Preferably the Session Middleware Layer is Able to:
Preferably the session middleware layer contains the logic necessary to define the primary business application event and all secondary business application events needed to complete any arbitrary user transaction, thereby defining the process for completing any user generated request.
Preferably the session middleware logic contains the necessary business rules to determine when any primary or secondary business event is to be triggered, this logic includes:
Preferably the interfaces between the middleware layer and the business applications are reusable across multiple different middleware transaction events, or when new business applications are added to the middleware layer environment.
Preferably the cross references between middleware layer and business application's object can be implemented directly in middleware layer application source code or stored in a data file or database and loaded on application start up.
Preferably the middleware event logic can be implemented directly in middleware layer application source code or stored in a data file or database and loaded on application start up.
Embodiments of the present invention will now be described with reference to the accompanying drawings wherein:
In summary with reference to
At an appropriate step in Application 1, workflow process a transaction needs to be sent to application 3. This transaction could be a request to update a stock level. The sending application 1 sends a transaction in its native format to the middleware system 2 via connection 4.
On receiving the transaction middleware system 2, identifies the end recipient of the transaction, then transforms the transaction structure in to a compatible format for the application receiving the transaction. The middleware system 2 then forwards the transaction the receiving application 3 via connection 5.
Application 3 on receiving the transaction, executes the transaction locally and the sends the appropriate response as a transaction to middleware 3 via connection 5.
Middleware 2 on receiving the transaction, identifies it recipient, transforms the transaction into it native format and forwards it to the receiving application 1 via connection 4.
As the HTTP protocols are stateless, the web server maintains creates user sessions to manage the user's transactions has with the Web Application 11 over a period of time. The user session persist for a specific period of time after the last transaction received by the web server. After this period of time the session will be disposed of along with any data associated with it. Data associated with a specific session is stored in the Session data object 15.
Where Web Application 11 needs to persist data across multiple user transactions, Business Application 12 data object are saved as session data 13. Session data 15 persists for the duration of the use session with the web server.
On the user submitting a HTTP transaction to the Web Application 11 the user's session data 15 is retrieved and used to initialise data objects with session content generated in the previous user transactions.
The received transaction is processed and if a sales process passed to the Sales Process 12 components. The sales process components 12 interact with the Sales Stock System 13 to display stock, record customer orders. The sales process components interact with the payment gateway 14 to process customer payments.
The retrieved session data can be updated during any time during the processing of the user's transaction and saved to session data 15. This provides a method of maintaining continuous storage throughout out the sales process 12 across multiple user transactions with the online shop web site 11, for the duration of the user's session.
The method of storing and retrieving session data 15 is dependent upon the software development framework. In .NET the program can store and retrieve any .NET object into the Session objects.
In some instances the Web Application 11 and Sales Process 12 may reside as a single software application.
The user interacts with the patient administration system 25 by submitting HTTP transaction to web application 22.
When web application 22 receives a user transaction the user session data 28 is retrieve into the web application memory to provide data continuity between user transactions for the duration of the user session with the web application.
After retrieving the user session data 28 into memory web application 22 processes the user transaction request, by interacting with the patient administration system 25. To generate an appropriate html response document.
At the completion of the processing of the user's transaction relevant application data is saved to session data 28 to make it available for the next user transaction.
The user interacts with the clinical notes system 27 by submitting HTTP transaction to web application 24:
Depending upon the web application 22, 23, 24, implementation it is possible to pass information between the web applications using HTTP link. However the information is limited to the information that can be embedded into a HTTP link.
A limitation of this embodiment is that while the user may only login once, the user will have separate use sessions with each web application 22, 23, 24, each having it own session data storage 28, 29, 30.
The user interacts with the patient administration system 33 by submitting HTTP transaction to web application 32.
The user interacts with the lab system 34 by submitting HTTP transaction to web application 32:
The user interacts with the clinical notes system 35 by submitting HTTP transaction to web application 32:
While each of the application modules or systems 33, 34, 35 can operation independently. The integrated environment provides the ability to share session data across each of the modules. This can streamline the modules operation by re-using user retrieved data. For example: Having retrieved patient information from the patient administration system 33, this data can be used to initialize lab system 34 or clinical notes system 35 queries.
As described below, embodiments of the present invention provides a framework for inserting a middleware layer between a web application and the backend applications, to manage the integration between the web application and the backend applications. This arrangement also provides a native interface to each of the backend applications while controlling the interactions across multiple backend applications to complete the web application user's transaction requests.
The embodiments of the invention extends the web application architecture outlined in
The session middleware layer 43 provides a number of services to both the web user interface 42 and the business applications 44, 45:
The Middleware Layer 43 Consists of:
The event execution framework needs to sense when an event has been triggered, e.g. retrieve an object. To identify the events to be generated and data transformation that is required to pass the relevant data to the backend application 44, 45 for processing.
The data transformation functions, consists of a bi-directional cross-reference between the backend applications 44 and 45 data objects and the session middleware 43 data structures. This enables a data object received from business application a 44 to be converted into session middleware layer 43 data object, which then passed to web user interface 42 to be displayed on a html page or transformed and passed to business application B 45 for further processing.
For Example a Data Object Mapping may be Implemented as:
The Data Transformation Function Consists of:
The business event logic function needs to have a logic structure that defines:
When the web application 42 receives a HTTP transaction from a user requesting a specific web page. The user interface layer session data 46 is retrieved a loaded into the web user interface 42 memory, the web user interface 42 processes the URL request:
The Middleware Layer 43 Provides:
The session middleware layer 53 provides a number of services to both the web application 52 and Administration System 54, Lab Systems 55 and Clinical Notes System 56:
The user sends a request to search for a specific patient's details via the web user interface 52. This request triggers primary transaction event to the Patient Administration System 54 this is achieved by:
The user sends a request to retrieve the patient's laboratory reports. This request is triggers a primary transaction to request patient laboratory reports this is achieved by:
The user sends a display request selecting a specific report. This request is converted to transaction event retrieve a specific lab report. As the laboratory reports are in user session memory 57, the selected report can be retrieved and formatted as a lab reports and sent to the user's web browser as an html.
The updates a patient details, this request could affect multiple backend systems. This request triggers a primary event to update the patient's details in the Patient Administration System 54, and secondary events to update the Lab system 55 and the clinical notes system 56. This is achieved by:
By inserting the middleware layer 53 into the hospital system embodiment, it is possible to ensure that when a user sends a request that the appropriate systems are accessed and updated correctly with a defined role back pathway should that be necessary.
In addition the interface between middleware layer 43 or 53, the business applications 44, 45 or hospital system 54, 55, 56 can be standardised to provide a reusable interface between the middleware layer 43 or 53 and the business applications to facilitate changes to the middleware transaction process flows or the addition of new transaction processes.
In addition the middleware layer 43 and 53, enables the application to optimise the interactions between the various backend applications in a consistent manner. Providing a framework for adding new backend applications and updating the transaction workflows as business systems change over time.
An alternative embodiment could abstract the object transformation and transaction event logic into a form that could be stored in a data object that is read when the application starts or set of database tables that can be queried to retrieve the transformation cross references and execution logic for the middleware layer 43 or 53.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2014900409 | Feb 2014 | AU | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/AU2015/000076 | 2/11/2015 | WO | 00 |
