CA2330707A1 - Method and apparatus for abstracting device independent request-response network interactions - Google Patents
Method and apparatus for abstracting device independent request-response network interactions Download PDFInfo
- Publication number
- CA2330707A1 CA2330707A1 CA002330707A CA2330707A CA2330707A1 CA 2330707 A1 CA2330707 A1 CA 2330707A1 CA 002330707 A CA002330707 A CA 002330707A CA 2330707 A CA2330707 A CA 2330707A CA 2330707 A1 CA2330707 A1 CA 2330707A1
- Authority
- CA
- Canada
- Prior art keywords
- server
- client
- components
- maui
- request
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Abstract
The present invention relates to a method and apparatus for abstracting device-independent request-response network interactions.
Description
METHOD AND APPARATUS FOR ABSTRACTING DEVICE INDEPENDENT
REQUEST-RESPONSE NETWORK INTERACTIONS
FIELD
The present invention is directed to a method and apparatus for abstracting device-independent request-response network interactions using a high-level application programming interface.
BACKGROUND OF THE INVENTION
Deploying applications on the Internet with its widely varying protocols for transport and communications has become a daunting task. Much effort must be expended to rework portions of the same applications in order to be compatible with different client hardware and software configurations. Additionally, many recently developed technologies and tools for the Internet are attempts to bridge the fundamentally incompatible concepts and patterns upon which stand-alone client applications are built.
Further, since the fundamental concepts and patterns upon which stand-alone client applications are built cannot be directly represented or supported via most Internet protocols, many recent Internet technologies and tools have been developed as attempts to smooth over and compensate for the basic incompatibility.
There are many products for developers to choose from when writing applications for use over the Internet.
However, these applications do not address the challenege of how a single application, in a single code base, can be presented to a wide variety of client devices and protocols.
In general, device independent request-response network interactions refer to data exchanges between a client device and a server device over a previously agreed to non-persistent communications medium. Examples of device independent request-response network interactions include communication between an HTTP client and a server via a series of non-persistent TCP/IP socket connections and the communication between a mobile phone and a network server using SMS message packets.
Presently, developers of network-based software applications, such as those applications for the World Wide Web or for mobile telephones, are required to implement their software by dealing directly with the client-server interactions inherent in these technologies. Programmers must directly implement rules for handling each and every data communication request sent from the client device, and they must provide rules for sending response communications for each individual request. This procedure is very cumbersome and inefficient as programmers as forced to spend their time writing software to handle network interactions instead of spending their time writing software to solve the problem at hand.
One of the difficulties recognized when programming device independent software applications is that Client Software Programs are often designed to work only with specific Server programs and vice-versa.
As a result of these difficulties, there is a need for a method and apparatus that allows developers to develop device-independent network based software applications without directly dealing with low-level request-response interactions.
REQUEST-RESPONSE NETWORK INTERACTIONS
FIELD
The present invention is directed to a method and apparatus for abstracting device-independent request-response network interactions using a high-level application programming interface.
BACKGROUND OF THE INVENTION
Deploying applications on the Internet with its widely varying protocols for transport and communications has become a daunting task. Much effort must be expended to rework portions of the same applications in order to be compatible with different client hardware and software configurations. Additionally, many recently developed technologies and tools for the Internet are attempts to bridge the fundamentally incompatible concepts and patterns upon which stand-alone client applications are built.
Further, since the fundamental concepts and patterns upon which stand-alone client applications are built cannot be directly represented or supported via most Internet protocols, many recent Internet technologies and tools have been developed as attempts to smooth over and compensate for the basic incompatibility.
There are many products for developers to choose from when writing applications for use over the Internet.
However, these applications do not address the challenege of how a single application, in a single code base, can be presented to a wide variety of client devices and protocols.
In general, device independent request-response network interactions refer to data exchanges between a client device and a server device over a previously agreed to non-persistent communications medium. Examples of device independent request-response network interactions include communication between an HTTP client and a server via a series of non-persistent TCP/IP socket connections and the communication between a mobile phone and a network server using SMS message packets.
Presently, developers of network-based software applications, such as those applications for the World Wide Web or for mobile telephones, are required to implement their software by dealing directly with the client-server interactions inherent in these technologies. Programmers must directly implement rules for handling each and every data communication request sent from the client device, and they must provide rules for sending response communications for each individual request. This procedure is very cumbersome and inefficient as programmers as forced to spend their time writing software to handle network interactions instead of spending their time writing software to solve the problem at hand.
One of the difficulties recognized when programming device independent software applications is that Client Software Programs are often designed to work only with specific Server programs and vice-versa.
As a result of these difficulties, there is a need for a method and apparatus that allows developers to develop device-independent network based software applications without directly dealing with low-level request-response interactions.
Furthermore, there is a need for a technology that allows programmers to create a single application in a single code base that can be presented to a variety of client devices and protocols.
SL1L~A,RY OF THE INVENTION
According to the invention there is provided a method and apparatus for abstracting device independent request-response network interactions. The method of request-response network interactions takes place over network. In general, the network will be comprised of Client Devices, a Maui Server, an Application Server and a Data Server.
Client Devices Client devices are that class of device that contact and obtain data from a server. In most cases, the Client Device will be running a Client Program that performs the request-response interactions with a server. Examples of Client Devices include mobile phones, PDAs and personal computers.
The Client Devices communicate with the Application Server and the Data Server through the Maui Server. It is important to note that the Application Server, Data Server and Maui Server may be a single machine or a plurality of machines distributed throughout the network.
Maui Server The Maui Server is the principal device for carrying out the method for abstracting device independent request-response network interactions. The Maui Server provides a conduit for the transfer of information (requests and responses) between Client Devices. The Maui Server is comprised of three main components: the Client Engine, The Server Engine and the Application Environment. Together, the Client Engine and The Server Engine form the Maui Engine.
The Client Engine consists of Client Drivers, Compositors, Layout Managers and Client Components. The Client Drivers act as a translator between Client Devices and the programs that access the Client Devices. The Layout Managers manage the Graphical User Interface (GUI) components for the different types of Client Devices. The Compositors are platform specific components relied upon to provide the rendering for different Client Devices and the underlying protocols. The Client Components are generic GUI
components such as windows, buttons and scroll bars.
The Server Engine consists of Server Components and Server Drivers. The Server Drivers act as a translator between Servers and the programs that access the Servers.
The Server Components are visual components such as generic GUI components, which include windows, buttons and scroll bars, and non-visual components such as tables.
The Application Environment is the Application Program Interface (API) providing an interface to programmers to fully utilize the Maui Engine. The Application Environment also includes three levels of access: basic, advanced and expert depending on the skill level of the programmer.
The Application Server and the Data Server are standard network components and thus will not be described in any further detail.
The method for abstracting device independent request-response network interactions involves the translation of client centric request data packages into server centric Event objects and correspondingly the translation of server centric Event objects into client centric response data packages.
The objective of the method for abstracting device independent request-response network interactions is to provide software developers with a standard mechanism of integrating object-oriented server software components with client software. Therefore, programmers are allowed software applications to be written as though they were desktop applications thereby simplifying the programming of networked applications. This invention fully abstracts all knowledge of the underlying protocol away from the application developer thus eliminating the need to deal directly with the communications protocol and allowing the application to be portable over a variety of protocols.
Using the Maui Engine, the software objects that represent GUI components may be assembled in collections to describe the layout of a software application's screen interface. The rendering process is dynamic allowing the output by the system to be customized to the Client Devices specific system requirements. It also provides the further advantages of allowing the development of web software applications without any knowledge of HTML or graphic design.
Other objects and advantages of the invention will become clear from the following detailed description of the preferred embodiment, which is presented by way of illustration only and without limiting the scope of the invention to the details thereof.
BRIEF DESCRIPTION OF THE DRAWINGS
Further features and advantages will be apparent from the following detailed description, given by way of example, of a preferred embodiment taken in conjunction with the accompanying drawings, wherein:
Fig. 1 is a schematic block diagram of a sample network; and Fig. 2 is a schematic block diagram of the components of the Maui Server.
DETAILED DESCRIPTION
Throughout the figures, like elements are indicated by like reference numbers.
Referring to FiQ. 1, a typical network 10 is depicted having a plurality of client devices 12, a Maui server 30, an application server 32 and a data server 34. The application server 32 and the data server 34 can be collective referred to as the server 36.
The client devices 12 are that class of device that enters into request-response interactions with the server 36. In most cases, the client devices 12 will be running a client program that performs the request-response interactions with the server 36. Examples of client devices 12, include, but are not limited to: client 14 that is a computer running the client program Microsoft Internet Explorer 5.0 for Windows; client 16 is a computer running the client program Netscape 4.0 for Linux; client 18 is a Personal Digital Assistant (PDA), client 20 is a mobile phone running WAP 1.0 as client program; client 22 is a personal computer running Lynx as a client program; and client 24 is a computer running Netscape 3.0 for the Mac as a client program.
SL1L~A,RY OF THE INVENTION
According to the invention there is provided a method and apparatus for abstracting device independent request-response network interactions. The method of request-response network interactions takes place over network. In general, the network will be comprised of Client Devices, a Maui Server, an Application Server and a Data Server.
Client Devices Client devices are that class of device that contact and obtain data from a server. In most cases, the Client Device will be running a Client Program that performs the request-response interactions with a server. Examples of Client Devices include mobile phones, PDAs and personal computers.
The Client Devices communicate with the Application Server and the Data Server through the Maui Server. It is important to note that the Application Server, Data Server and Maui Server may be a single machine or a plurality of machines distributed throughout the network.
Maui Server The Maui Server is the principal device for carrying out the method for abstracting device independent request-response network interactions. The Maui Server provides a conduit for the transfer of information (requests and responses) between Client Devices. The Maui Server is comprised of three main components: the Client Engine, The Server Engine and the Application Environment. Together, the Client Engine and The Server Engine form the Maui Engine.
The Client Engine consists of Client Drivers, Compositors, Layout Managers and Client Components. The Client Drivers act as a translator between Client Devices and the programs that access the Client Devices. The Layout Managers manage the Graphical User Interface (GUI) components for the different types of Client Devices. The Compositors are platform specific components relied upon to provide the rendering for different Client Devices and the underlying protocols. The Client Components are generic GUI
components such as windows, buttons and scroll bars.
The Server Engine consists of Server Components and Server Drivers. The Server Drivers act as a translator between Servers and the programs that access the Servers.
The Server Components are visual components such as generic GUI components, which include windows, buttons and scroll bars, and non-visual components such as tables.
The Application Environment is the Application Program Interface (API) providing an interface to programmers to fully utilize the Maui Engine. The Application Environment also includes three levels of access: basic, advanced and expert depending on the skill level of the programmer.
The Application Server and the Data Server are standard network components and thus will not be described in any further detail.
The method for abstracting device independent request-response network interactions involves the translation of client centric request data packages into server centric Event objects and correspondingly the translation of server centric Event objects into client centric response data packages.
The objective of the method for abstracting device independent request-response network interactions is to provide software developers with a standard mechanism of integrating object-oriented server software components with client software. Therefore, programmers are allowed software applications to be written as though they were desktop applications thereby simplifying the programming of networked applications. This invention fully abstracts all knowledge of the underlying protocol away from the application developer thus eliminating the need to deal directly with the communications protocol and allowing the application to be portable over a variety of protocols.
Using the Maui Engine, the software objects that represent GUI components may be assembled in collections to describe the layout of a software application's screen interface. The rendering process is dynamic allowing the output by the system to be customized to the Client Devices specific system requirements. It also provides the further advantages of allowing the development of web software applications without any knowledge of HTML or graphic design.
Other objects and advantages of the invention will become clear from the following detailed description of the preferred embodiment, which is presented by way of illustration only and without limiting the scope of the invention to the details thereof.
BRIEF DESCRIPTION OF THE DRAWINGS
Further features and advantages will be apparent from the following detailed description, given by way of example, of a preferred embodiment taken in conjunction with the accompanying drawings, wherein:
Fig. 1 is a schematic block diagram of a sample network; and Fig. 2 is a schematic block diagram of the components of the Maui Server.
DETAILED DESCRIPTION
Throughout the figures, like elements are indicated by like reference numbers.
Referring to FiQ. 1, a typical network 10 is depicted having a plurality of client devices 12, a Maui server 30, an application server 32 and a data server 34. The application server 32 and the data server 34 can be collective referred to as the server 36.
The client devices 12 are that class of device that enters into request-response interactions with the server 36. In most cases, the client devices 12 will be running a client program that performs the request-response interactions with the server 36. Examples of client devices 12, include, but are not limited to: client 14 that is a computer running the client program Microsoft Internet Explorer 5.0 for Windows; client 16 is a computer running the client program Netscape 4.0 for Linux; client 18 is a Personal Digital Assistant (PDA), client 20 is a mobile phone running WAP 1.0 as client program; client 22 is a personal computer running Lynx as a client program; and client 24 is a computer running Netscape 3.0 for the Mac as a client program.
It is clear from the example listed above, that the there are numerous possible client devices and client programs that may be utilized within the framework outlined herein.
The Maui server 30 provides a conduit between the client devices 12 and the server 36. It is important to note that the Maui server 30, the application server 32 and the data server 34 may be a single computer or a plurality of computer distributed throughout a network. The application server 32 will be running any software capable of developing and deploying Internet, intranet, extranet and e-commerce applications. Further, the software running on the application server 32 should have the ability to utilize Java servlets, JavaServer Pages, XML and Enterprise JavaBeans (EJB) components. The data server 34 will be running any data base program capable managing the required data. For example, the data server may be running Oracle, IBM DB2~, or Microsoft SQL Server. The application server 32 and the data server 34 are standard network components and thus will not be described in any further detail.
Referring to Fig. 2, the Maui server 30 is the principal device for carrying out the method for abstracting device independent request-response network interactions.
The Maui server 30 is comprised of three main components:
the client engine 40, the server engine 50 and the application environment 60.
The client engine 40 is further comprised of client drivers 42, compositors 44, layout managers 46 and client components 48.
The client drivers 42 act as a translator between client devices 12 and the programs that communicate with the client devices 12. Each of the client devices 12 requires a different client driver. The driver accepts generic commands from a communicating program and translates them into specialized commands for the particular client device.
The use of drivers provides the advantage of allowing a high-level programming interface for access to the devices.
The developer is not required to delve into the intricacies of communicating with every one of the client devices 12.
The compositors 44 are platform specific components relied upon to provide the rendering for the client devices 12 and the underlying client programs and protocols. The compositors integrate all of the graphics and text in a manner to be displayed on a particular client device. As the compositors are platform specific, a compositor will be required for each of the different types pf protocols and client devices 12.
The layout managers 46 determine where the GUI
components will be placed in relation to one another when displayed on the client devices 12. When the protocol or client device changes, the layout manager takes care of the necessary adjustments to ensure the GUI components are properly arranged.
The client components 48 may be visual or non-visual components. Visual components include generic GUI
components such as windows, buttons and scroll bars. Non-visual components are data managers used to manage the data and values used by the visual components. Non-visual components may also include data tables. It is important to note that the client components are not platform specific and thus a developer does not require knowledge of any of the device characteristics specific to any of the client devices 12. Due to the generic nature of the client components 48, they may be rendered on any of the client devices 12. The client components can be defined and accessed through the Application Program Interfaces (APIs) 62, 64, 66 of the application environment 60.
The server components 52 are similar in nature to the client components 48. The server components 52 may be visual or non-visual components. As with the client components 48, the server components may be visual components including generic GUI components such as windows, buttons and scroll bars and non-visual components such as data managers used to manage the data and values used by the visual components. Non-visual components may also include data tables. Therefore, the server components 52 provide generic, syntax independent interfaces to the server connection devices. Furthermore, the server components 52 may be rendered on any of the servers 36. Again, the server components 52 can be defined and accessed through the Application Program Interfaces (APIs) 62, 64, 66 of the application environment 60.
The server drivers 54 act as a translator between client devices 12 and the servers 36. Each type of server 36 in the network requires a different server driver. The driver accepts generic commands from a communicating program and translates them into specialized commands for the particular server. The use of drivers provides the advantage of allowing a high-level programming interface for access to the devices. The developer is not required to delve into the intricacies of communicating with every one of the servers 36.
The application environment 60 is the API providing an interface to developers to fully utilize the components of the Maui server 30. The application environment 60 allows the creation of high-quality, platform-independent graphics (including line art, text, and images) in a single model that uniformly addresses color, spatial transforms, and compositing. Furthermore, the application environment 60 allows developers to access the client drivers 42 and the server drivers 54, allows developers to access shared resources, and allows developers to access debugging and diagnostics services provided within the application environment 60.
The application environment 60 further includes three levels of access or usability: basic, advanced and expert.
In the basic level, the application environment 60 performs almost all of the underlying details. The layout, platform targeting and almost all of the event handling is performed by the application environment 60. In the advanced level, the developer must control the layout and arrangement of components and respond various events, resource sharing and server connections. The expert level allows the developer to handle all of the aspects of the device specifics and compositors including event handling, layout and device specific presentation control.
The method of abstracting device independent request-response network interactions involves the translation of client centric request data packages into server centric event object and correspondingly the translation of server centric objects into client centric response data packages.
In general, each client device 12 will have their own native Application Program Interface (API) or Application Program Interfaces (APIs). The API is a set of functions between the application software and the application platform. These functions are a formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services. In this way, the API allows a developer to (a) facilitate communication between a client device and the Maui server 30 and (b) build user interfaces for a client device.
The method of abstracting device independent request-response network interactions is integrated through the application environment 60 of the Maui server 30. The application environment provides a single Maui API to abstract the client devices' 12 APIs. The Maui API
facilitates the creation of the user interface for a client device using a collection of user interface software objects (Maui user interface objects) that represent user interface elements such as text fields, check boxes or buttons. It should be noted that this list is not exhaustive.
The steps in the method of abstracting device independent request-response network interactions will be described with reference to client device 14. It should be noted that the general steps in the method are essentially the same for all client devices 12 but largely differ in the client device's native protocol.
The client device 14 sends a request to the Maui server 30. As the client device 14 is a PC running a web browser, the request sent by the client device 14 may be a request for a web page. The Maui server 30 will accept the client device's 14 request in the client device's 14 native protocol. In this particular example, the native protocol will be HTTP where an HTTP command will be sent to the server directing it to fetch and transmit the requested web page. The Maui server 30 will then dynamically translate the request into Maui Event Objects. The Maui event objects will then be dynamically translated into the server's The present invention is directed to a method and apparatus for abstracting device-independent request-response network interactions using a high-level application programming interface. native protocol in order to retrieve the requested web page. The requested web page (~~the Response") will then be sent from the server 36 to the Maui server 30 in the server's 36 native protocol. The Response will then be dynamically translated into Maui event objects.
The Maui event objects manipulate Maui user interface objects, which are then translated into client device 14 specific API calls such as HTML pages. The HTML pages are then communicated to the client device 14 in the client device's 14 native protocol.
Accordingly, while this invention has been described with reference to illustrative embodiments and examples, this description is not intended to be construed in a limiting sense. Various modifications of the illustrative embodiments and examples, as well as other embodiments of the invention, will be apparent to persons skilled in the art upon reference to this description. For example, there are numerous possible client devices 12 and specific native protocols for each device.
The Maui server 30 provides a conduit between the client devices 12 and the server 36. It is important to note that the Maui server 30, the application server 32 and the data server 34 may be a single computer or a plurality of computer distributed throughout a network. The application server 32 will be running any software capable of developing and deploying Internet, intranet, extranet and e-commerce applications. Further, the software running on the application server 32 should have the ability to utilize Java servlets, JavaServer Pages, XML and Enterprise JavaBeans (EJB) components. The data server 34 will be running any data base program capable managing the required data. For example, the data server may be running Oracle, IBM DB2~, or Microsoft SQL Server. The application server 32 and the data server 34 are standard network components and thus will not be described in any further detail.
Referring to Fig. 2, the Maui server 30 is the principal device for carrying out the method for abstracting device independent request-response network interactions.
The Maui server 30 is comprised of three main components:
the client engine 40, the server engine 50 and the application environment 60.
The client engine 40 is further comprised of client drivers 42, compositors 44, layout managers 46 and client components 48.
The client drivers 42 act as a translator between client devices 12 and the programs that communicate with the client devices 12. Each of the client devices 12 requires a different client driver. The driver accepts generic commands from a communicating program and translates them into specialized commands for the particular client device.
The use of drivers provides the advantage of allowing a high-level programming interface for access to the devices.
The developer is not required to delve into the intricacies of communicating with every one of the client devices 12.
The compositors 44 are platform specific components relied upon to provide the rendering for the client devices 12 and the underlying client programs and protocols. The compositors integrate all of the graphics and text in a manner to be displayed on a particular client device. As the compositors are platform specific, a compositor will be required for each of the different types pf protocols and client devices 12.
The layout managers 46 determine where the GUI
components will be placed in relation to one another when displayed on the client devices 12. When the protocol or client device changes, the layout manager takes care of the necessary adjustments to ensure the GUI components are properly arranged.
The client components 48 may be visual or non-visual components. Visual components include generic GUI
components such as windows, buttons and scroll bars. Non-visual components are data managers used to manage the data and values used by the visual components. Non-visual components may also include data tables. It is important to note that the client components are not platform specific and thus a developer does not require knowledge of any of the device characteristics specific to any of the client devices 12. Due to the generic nature of the client components 48, they may be rendered on any of the client devices 12. The client components can be defined and accessed through the Application Program Interfaces (APIs) 62, 64, 66 of the application environment 60.
The server components 52 are similar in nature to the client components 48. The server components 52 may be visual or non-visual components. As with the client components 48, the server components may be visual components including generic GUI components such as windows, buttons and scroll bars and non-visual components such as data managers used to manage the data and values used by the visual components. Non-visual components may also include data tables. Therefore, the server components 52 provide generic, syntax independent interfaces to the server connection devices. Furthermore, the server components 52 may be rendered on any of the servers 36. Again, the server components 52 can be defined and accessed through the Application Program Interfaces (APIs) 62, 64, 66 of the application environment 60.
The server drivers 54 act as a translator between client devices 12 and the servers 36. Each type of server 36 in the network requires a different server driver. The driver accepts generic commands from a communicating program and translates them into specialized commands for the particular server. The use of drivers provides the advantage of allowing a high-level programming interface for access to the devices. The developer is not required to delve into the intricacies of communicating with every one of the servers 36.
The application environment 60 is the API providing an interface to developers to fully utilize the components of the Maui server 30. The application environment 60 allows the creation of high-quality, platform-independent graphics (including line art, text, and images) in a single model that uniformly addresses color, spatial transforms, and compositing. Furthermore, the application environment 60 allows developers to access the client drivers 42 and the server drivers 54, allows developers to access shared resources, and allows developers to access debugging and diagnostics services provided within the application environment 60.
The application environment 60 further includes three levels of access or usability: basic, advanced and expert.
In the basic level, the application environment 60 performs almost all of the underlying details. The layout, platform targeting and almost all of the event handling is performed by the application environment 60. In the advanced level, the developer must control the layout and arrangement of components and respond various events, resource sharing and server connections. The expert level allows the developer to handle all of the aspects of the device specifics and compositors including event handling, layout and device specific presentation control.
The method of abstracting device independent request-response network interactions involves the translation of client centric request data packages into server centric event object and correspondingly the translation of server centric objects into client centric response data packages.
In general, each client device 12 will have their own native Application Program Interface (API) or Application Program Interfaces (APIs). The API is a set of functions between the application software and the application platform. These functions are a formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services. In this way, the API allows a developer to (a) facilitate communication between a client device and the Maui server 30 and (b) build user interfaces for a client device.
The method of abstracting device independent request-response network interactions is integrated through the application environment 60 of the Maui server 30. The application environment provides a single Maui API to abstract the client devices' 12 APIs. The Maui API
facilitates the creation of the user interface for a client device using a collection of user interface software objects (Maui user interface objects) that represent user interface elements such as text fields, check boxes or buttons. It should be noted that this list is not exhaustive.
The steps in the method of abstracting device independent request-response network interactions will be described with reference to client device 14. It should be noted that the general steps in the method are essentially the same for all client devices 12 but largely differ in the client device's native protocol.
The client device 14 sends a request to the Maui server 30. As the client device 14 is a PC running a web browser, the request sent by the client device 14 may be a request for a web page. The Maui server 30 will accept the client device's 14 request in the client device's 14 native protocol. In this particular example, the native protocol will be HTTP where an HTTP command will be sent to the server directing it to fetch and transmit the requested web page. The Maui server 30 will then dynamically translate the request into Maui Event Objects. The Maui event objects will then be dynamically translated into the server's The present invention is directed to a method and apparatus for abstracting device-independent request-response network interactions using a high-level application programming interface. native protocol in order to retrieve the requested web page. The requested web page (~~the Response") will then be sent from the server 36 to the Maui server 30 in the server's 36 native protocol. The Response will then be dynamically translated into Maui event objects.
The Maui event objects manipulate Maui user interface objects, which are then translated into client device 14 specific API calls such as HTML pages. The HTML pages are then communicated to the client device 14 in the client device's 14 native protocol.
Accordingly, while this invention has been described with reference to illustrative embodiments and examples, this description is not intended to be construed in a limiting sense. Various modifications of the illustrative embodiments and examples, as well as other embodiments of the invention, will be apparent to persons skilled in the art upon reference to this description. For example, there are numerous possible client devices 12 and specific native protocols for each device.
Claims
WHAT IS CLAIMED IS:
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002330707A CA2330707A1 (en) | 2001-01-12 | 2001-01-12 | Method and apparatus for abstracting device independent request-response network interactions |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002330707A CA2330707A1 (en) | 2001-01-12 | 2001-01-12 | Method and apparatus for abstracting device independent request-response network interactions |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2330707A1 true CA2330707A1 (en) | 2002-07-12 |
Family
ID=4168065
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002330707A Abandoned CA2330707A1 (en) | 2001-01-12 | 2001-01-12 | Method and apparatus for abstracting device independent request-response network interactions |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2330707A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004095794A1 (en) * | 2003-04-23 | 2004-11-04 | Telecom Italia S.P.A. | A client-server system and method thereof for providing multimedia and interactive services to mobile terminals |
| WO2007074464A2 (en) * | 2005-12-29 | 2007-07-05 | Pike Ltd. | Method and system for operating applications for remote terminal devices |
-
2001
- 2001-01-12 CA CA002330707A patent/CA2330707A1/en not_active Abandoned
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004095794A1 (en) * | 2003-04-23 | 2004-11-04 | Telecom Italia S.P.A. | A client-server system and method thereof for providing multimedia and interactive services to mobile terminals |
| CN1765101B (en) * | 2003-04-23 | 2010-09-01 | 意大利电信股份公司 | Client-server system for providing multimedia and interactive service for mobile terminal and its method |
| WO2007074464A2 (en) * | 2005-12-29 | 2007-07-05 | Pike Ltd. | Method and system for operating applications for remote terminal devices |
| WO2007074464A3 (en) * | 2005-12-29 | 2007-08-23 | Pike Ltd | Method and system for operating applications for remote terminal devices |
| US7747683B2 (en) | 2005-12-29 | 2010-06-29 | Pike Ltd. | Method and system for operating applications for remote terminal devices |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5768510A (en) | Object-oriented system, method and article of manufacture for a client-server application enabler system | |
| US5848246A (en) | Object-oriented system, method and article of manufacture for a client-server session manager in an interprise computing framework system | |
| US6434598B1 (en) | Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system | |
| US6424991B1 (en) | Object-oriented system, method and article of manufacture for a client-server communication framework | |
| US6393497B1 (en) | Downloadable smart proxies for performing processing associated with a remote procedure call in a distributed system | |
| US6560618B1 (en) | On-demand generation, packaging, and delivery of archive files | |
| US6272556B1 (en) | Object-oriented system, method and article of manufacture for migrating a client-server application (#5) | |
| US6304893B1 (en) | Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system | |
| US5999972A (en) | System, method and article of manufacture for a distributed computer system framework | |
| US8832181B2 (en) | Development and deployment of mobile and desktop applications within a flexible markup-based distributed architecture | |
| US6253282B1 (en) | Object-oriented system, method and article of manufacture for a client-server with a client program cache | |
| EP0827077B1 (en) | Object-oriented system, method and computer program for a client-server failure reporting process | |
| CA2495024C (en) | System and method for adaptable provisioning of generic application content | |
| EP0827075A2 (en) | Object-oriented system, method and article of manufacture for a client-server state machine framework | |
| EP0822487A2 (en) | Object-oriented system, method and article of manufacture for a client-server session WEB access in an interprise computing framework system | |
| US20020188941A1 (en) | Efficient installation of software packages | |
| US20030084120A1 (en) | Software framework for web-based applications | |
| US20030037327A1 (en) | Run-time rule-based topological installation suite | |
| EP0827073A2 (en) | Object-oriented system, method and article of manufacture for a client-server-centric enterprise computing framework system | |
| JPH10254702A (en) | Object oriented system/method/product for client server state machine in enterprise computing frame work system | |
| US7281236B1 (en) | System and methods for developing and deploying a remote domain system | |
| EP0827076A2 (en) | Object-oriented system, method and article of manufacture for a presentation engine in an interprise computing framework system | |
| EP1061445A2 (en) | Web-based enterprise management with transport neutral client interface | |
| CA2330707A1 (en) | Method and apparatus for abstracting device independent request-response network interactions | |
| EP1560114A1 (en) | Computer system and method for customized provisioning of application content |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |