Method and system for remote automation of object oriented applications6820267Abstract An object oriented programming environment is extended to allow a client object oriented application running under a client/server operating system to communicate with a plurality of server object oriented applications located on one or more remote computers in a distributed computer environment. The extended object oriented programming environment provides the capability for a client object oriented application to connect to, and communicate with remote server object oriented applications as well as make object references to remote objects and remote object data. The extended object oriented programming environment is used for designing N-tiered logical models for distributed computing applications, while providing a flexible and adaptable M-tiered physical model underneath the N-tiered logical model. This environment is also used to provide the ability to reference remote objects from Internet and other client network applications. Claims We therefore claim as our invention all that comes within the scope and spirit of the following claims: Description FIELD OF INVENTION
typedef struct _GUID
{
DWORD Data1;
WORD Data2;
WORD Data3;
BYTE Data4[8];
} GUID;
where "DWORD Data1" is a double word sized variable "Data1", "WORD Data2" and "WORD Data3" are single word sized variables, and "BYTE Data4[8]" is an array of eight one-byte (8-bit)variables. When a client application 44 asks OLE to create an object, OLE must first determine which server application to run. This information is stored in the operating system registry (e.g., Windows.RTM.95 registry) for each object class, and each object class is represented by a unique GUID. Most of the OLE object application information is stored in subkeys under the CLSID root key. For example, in Windows.RTM.95, the operating system registry may appear as follows:
CLSID // root key
{42754850-16b7-11ce-90eb-00aa003d7352} // GUID subkey
LocalServer32 = myserver.exe // local (same machine)
server;
where "{42754850-16b7-11ce-90eb-00aa003d7352}" is the ASCII representation of the GUID for the object class, and "LocalServer32" represents the registry sub-key name of the local server executable (e.g., myserver.exe) for the object class represented by the GUID. In order for Remote Automation to function, the Remote Automation application is invoked during the OLE object creation process. This is done by modifying the registry data in the operating system registry so that OLE still loads a server application, but it is in fact loading a Remote Automation Proxy application which will communicate with the server application. The "LocalServer32" registry sub-key is replaced with a sub-key that tells OLE to load the Remote Automation proxy. For example, the modified operating system registry may appear as follows after modification by Remote Automation:
CLSID // root key
{42754850-16b7-11ce-90eb-00aa003d7352} // GUID subkey
InProcServer32 = autprx32.dll // local (same
machine) proxy;
where "{42754850-16b7-11ce-90eb-00aa003d7352}" is the ASCII GUID for the class, and "InProcServer32" represent the name of the registry sub-key of the executable proxy for the object class represented by the GUID. However, in this example, the executable application is in autprx32.dll (i.e., AUTomation PRoXy Dynamic Link Library (DLL)). Dynamic link libraries, as is known in the art, provide functions that application programs link to and call as regular procedure calls. The "InProcServer32" keyword is used instead of the "LocalServer32" keyword since the Remote Automation proxy application (in autprx32.dll) is an in-process object (i.e., operates within the same process as the client object application), while myserver.exe is an out-of-process object application (i.e., operates within a process different from the client object application). The in-process Remote Automation proxy application will communicate with a remote server application. As long as the Remote Automation proxy object created by autprx32.dll forwards all requests to the real object in myserver.exe running on the remote computer, it does not matter that the real object does not exist on the same computer as the client object application which made the object reference. When creating the real object, the Remote Automation application must be able to identify which remote computer to ask to create the real object. As a result, the Remote Automation application adds additional sub-keys to specify the network location (address) and the network protocol to be used to find and connect to the remote computer. For example, the modified operating system registry may now appear as follows:
CLSID // root key
{42754850-16b7-11ce-90eb-00aa003d7352} // GUID subkey
InProcServer32 = autprx32.dll // local (same
machine) proxy;
NetworkAddress = 1.24.128.36 // remote IP address
ProtocolSequence = ncanc_ip_tcp // tcp/ip connect protocol
where the "NetworkAddress" sub-key in this example which specifies an IP address (e.g., 1.24.128.36) of a remote computer, and the "ProtocolSequence" specifies TCP/IP as the protocol that should be used to connect to the remote computer. However, any number of different network address formats and connection protocols could also be specified in the NetworkAddress and ProtocolSequence sub-keys. As is shown in FIG. 4, and is illustrated by method 134 in the flow chart in FIG. 8, a client object oriented application 58 on a client computer 60 makes a remote reference X->FOO( ) 62 (process block 136) to a remote object X::FOO( )64 which resides on a remote server computer 66, and OLE on the client computer 60 (i.e., local OLE) consults the modified operating system registry 67 to determine which server application to run. Using the modified operating system registry shown below, and assuming the ASCII GUID for the object class X::FOO( ) is {42754850-16b7-11ce-90eb-00aa003d7352}, local OLE finds this entry in the modified operating system registry, and invokes autprx32.dll to create a RA proxy object application 68 (hereinafter RA proxy) on the client computer 60 (process block 138).
CLSID // root key
{42754850-16b7-11ce-90eb-00aa003d7352} // GUID subkey
InProcServer32 = autprx32.dll // local (same machine)
proxy;
NetworkAddress = 1.24.128.36 // remote IP address
ProtocolSequence = ncanc_ip_tcp // tcp/ip connect protocol
In addition, local OLE will use "1.24.128.36" as the network address of the remote computer 66 and TCP/IP as the network protocol to connect to the remote computer. The Remote Procedure Call (RPC) facility is used to connect to the remote computer 66. However, other facilities could also be used to connect the client computer 60 to a remote server computer 66. Windows.RTM. 95 and Windows NT.TM. provide RPC functionality via a RPC channel object that encapsulates all the details about the underlying cross-process and cross-network transport. The RPC channel object uses a generic RPC transport provider interface to talk to a remote transport protocol. The RPC provider interface acts as thin layer between the RPC facility and the network transport, mapping RPC operations onto the functions provided by the network transport. The RPC facility implements transport providers (e.g., DLLs) for named pipes, NetBIOS, TCP/IP, DECnet, and others. Additional transports can be supported by writing new provider DLLs that plug into the RPC channel object. Returning to FIG. 4, a connection is made to the remote computer using the Remote Procedure Call (RPC) facility, to create an RPC channel (process block 140), which is called a Remote Automation (RA) channel 70. The RA Channel 70 connects the RA proxy 68 with a Remote Automation Object Manager 72 running on the remote server computer 66. The RA Object Manager 72 is an object oriented application that is invoked by any client/server operating system supporting Remote Automation. The RA Object Manager 72 is capable of accepting a RPC channel connection from a remote computer, and spawning the necessary RA object oriented applications to support remote object references. The RA Object Manager 72 can be thought of as the agent or daemon equivalent in other distributed object systems such as ObjectBroker, by Digital Equipment Corporation, Orbix, by Iona Corporation, or Portable Distributed Objects, by NeXT Corporation. In these distributed systems (i.e., Digital's, Iona's, NeXT's), the agent resides on the server platform and serves to connect client requests to an appropriate server implementation and to return an object reference to the requesting client. The RA Object Manger 72 performs the same service for requesting Remote Automation clients. However, the RA Object Manager 72 does not provide the Common Object Request Broker Architecture (COBRA) based Object Request Brokers, as the ObjectBroker, Orbix or NeXT products do. Once the RA channel 70 has been established to the RA Object Manager 72 (process block 142) the RA proxy 68 requests the RA Object Manger create a RA remote stub object oriented application 74 (hereinafter RA remote stub)(process block 144). As is shown in FIG. 5, The RA proxy 68 manages a facelet 76 for each object interface (e.g., there would be a facelet for the object interface to object FOO). The RA remote stub 74 manages a stublet 78 for each corresponding facelet managed by the RA proxy object (e.g., one stublet for FOO). Object references 62 made from the client application go directly to the appropriate facelet 76 in the RA proxy 68, which marshals the reference to the corresponding stublet 78 in the RA remote stub 74 through the RA channel (RPC channel) 70. Marshalling is the ordering and packaging of data in a particular way to suit a particular network link and protocol, such as resolving local references, obtaining a copy of any local data structures that a pointer refers to, byte swapping to conform to another CPU's data format, etc. When the appropriate stublet in the RA remote stub object 74 receives the marshalled reference, the stublet unmarshals the data and reconstructs the original reference. Marshalling is well known and understood by those skilled in the art. Returning now to FIG. 4, the RA Object Manager 72 is just another client object oriented application, so OLE on the remote server computer 66 (i.e., remote OLE) will create an OLE remote proxy object 80 within the RA Object Manager (process block 146), create the server application 82 (process block 148), an OLE remote stub object 84 within the server application 82 (process block 150), and an OLE channel 86 (process block 152) which connects the OLE proxy object 80 and local stub object 84 (see FIG. 2 and description above). After remote OLE does this creation, there is a two-way path between the client application 58 on the client computer 60, and the server application 82 on the remote server computer 66 (process block 154). Multiple two-way communications paths can be established between a client application on a client computer and a remote server application on a remote computer, or between a client application and multiple remote server applications on one or more remote server computers. The path is two-way in the sense that a client object oriented application 58 can make a request for a remote object or remote object data and receive the remote object or the remote object data from the server application 82. The client object oriented application 58 can make object requests, and the server object oriented application 82 responds to the requests. In an alternative embodiment of the present invention, the server object oriented application 82 can also make requests from the client object oriented application 58. The two-way communications path (process block 154) includes an object linking and embedding channel which is used to send object linking and embeding information (e.g., OLE information) to a remote computer, which is not possible with existing versions object linking and embedding software. The object linking and embedding channel allows object linking and embedding information to be sent from a local client computer 60 to a remote server computer 66 with no manipulation of the object linking and embeding data required by the applications and objects shown in FIG. 4. The actual data pathway is transparent for both local and remote OLE. Any data manipulation that may be necessary (e.g., the marshalling and unmarshalling of data described above) to transport object linking and embedding data on the object linking and embedding channel is also transparent to the applications and objects shown in FIG. 4. Any remote object reference 62 now made from the client application 58 to a remote object 64 from the server application 84 (process block 156), goes to the RA proxy 68 (including the proper facelet marshalling), through the RA channel 70 across the computer network, to the RA remote stub 74 (including the proper stublet unmarshalling), to the OLE remote proxy 80, through the OLE channel 86, to the OLE remote stub 84, and finally to the real object 64 on the remote server application 84. Local OLE on the client computer 60 is not aware of the actual pathway shown in FIG. 4 to make the object reference. Remote OLE on the remote server computer also is not aware the object reference 62 was made from the client computer 60, or the actual pathway to return the object reference. In one embodiment of the present invention, an RA proxy/RA remote stub pair is created for each remote object reference. However, a single RA proxy/RA remote stub pair could be created in an alternative embodiment of the present invention to handle all remote object references. The Remote Automation application ensures that objects are uniquely represented and identifiable when passed from one computer to another by assigning every object a unique GUID when it is created. GUIDs were explained in detail above. The GUIDs generated are stored in a data structure associated with the RA proxy on the client and in a corresponding data structure associated with all RA remote stubs to facilitate lookup by GUID while passing remote object references. Thus, the client and remote server computers all understand and can identify any remote object reference by looking up its GUID in their respective data structures. Each time a remote object reference is passed to a remote server computer 66, a fast lookup on the object pointer using the stored GUIDs is performed using an operating system thread. This lookup is complicated because each operating system thread may contain a distinct object pointer that references the same remote object. For example, thread A could contain a reference to object B with pointer A1, and thread B could contain a reference to object B with pointer B1. In one embodiment of the present invention, a common operating system thread called a "reference thread" is established to resolve all references to remote objects on the remote server computer. Every remote object reference 46 sent to the remote server computer 66 is passed to the common reference thread which determines the location of the real object 64, the OLE remote proxy object 80, and the RA stub object 74 (the location of the OLE remote stub object 80 and OLE remote channel 86 are determined from the location of the OLE remote proxy object 80). The common reference thread eliminates the complicated object lookup described above from multiple reference threads thereby increasing the speed and efficiency of Remote Automation. The common reference thread can also be used to resolve object references for local OLE automation (FIG. 3). Security for object information passed over the object linking and embedding channel connecting a client 60 and remote server computer 66 (i.e., inter-computer channels, including public Internet network channels) is also provided in Remote Automation. Data authentication, data encryption/decryption, and access control are used. However, more or fewer security processes could also be used. One level of data authentication is provided in part by the RPC facility. RPC authentication specifies the level of data integrity guaranteed between the connected computers. As is known in the art, RPC offers seven levels of authentication, ranging from "network default" to "packet privacy," which includes data encryption for any data sent. Other data encryption/decryption techniques could also be used on object reference data before the data was sent to RPC (e.g., encrypted in the RA proxy, and decrypted in the RA remote stub). Access control allows an administrator to specify which servers remote clients may access. Access can be controlled down to the object class level. Remote Automation offers four levels of access control: CreateNone, CreateAll, CreatelfKey, CreatelfAcl. CreateNone does not allow any objects to be created, CreateAll allows any object to be created, CreatelfKey allows an object to be created if the appropriate registry key is set, and CreatelfAcl allows object creation only if an access control list for the class includes the client user. Another level of security is also provided in the OLE environment (e.g., on the local OLE channel that is the intra-computer OLE channels) via object oriented data abstractions. Data access is restricted to an explicitly declared list of functions in an object class public interface. The protection of private object data (e.g., OLE channel data) relies on the object oriented restriction on the use of public class member names. In one embodiment of the present invention, the Remote Automation application is available in Visual Basic.RTM. 4.0, Enterprise Edition, by Microsoft Corporation. A developer familiar with creating client/server applications in Visual Basic.RTM. which execute on a single computer can now easily create distributed client/server applications using Remote Automation. However, the Remote Automation application can also be used with other object oriented programming languages such as C++, Visual C++, and others, and is not limited to the Visual Basic.RTM. language. Since Remote Automation is external to OLE, and extends OLE, Remote Automation can also be made available as a stand alone external OLE application or an OLE add-on. In addition, the Remote Automation concepts discussed here can also be directly incorporated in the COM or the Distributed Component Object Model (DCOM) (i.e. the component object model for distributed systems), which in turn could be directly incorporated into OLE, instead of existing as an external object oriented application which hooks into OLE. Remote Automation provides a set of interfaces to extend existing local OLE automation (FIG. 3) for use on distributed systems. Thus, Remote Automation inherits local OLE automation data limitations (e.g., local OLE automation cannot send data types such as structures through an OLE automation channel). However, in an alternative embodiment of the present invention where Remote Automation is created as a stand-alone object oriented application which includes modifying the existing local OLE automation process (FIG. 3), the local OLE automation data limitations are overcome (e.g., data types such as structures can be sent through an OLE channel). Remote Automation also provides the necessary building blocks for the deployment of N-tiered client/server applications as is shown by method 160 in FIG. 9. An N-tiered services model, for any type of client/server services, can be developed using Remote Automation. For example, a three-tiered client/server architecture is ideal for business applications. The three-tiered architecture provides the ability to support a conceptual layer of business logic between the traditional two-tier components of the client user interface and a server database. The business logic layer can be maintained separately (e.g., on a separate computer) from the data, which is not possible in the two-tiered client/server environment known in the art. As is shown in FIG. 6, a logical three-tiered business architecture includes a user services application 88 providing a user interface and user interface navigation, that exists as a client application on a client computer 90. The user services application uses Remote Automation 92 (FIGS. 3 and 4) to communicate with a server business services application 94 on a remote second computer 96. The business services application 94 provides business policies/rules and generation of business information from data. The server business services application 94, now acting as a client application, uses Remote Automation 92 to communicate with a server data services application 98 on a third remote computer 100. The data services application has access to a database 102, and handles data definition, storage and retrieval of data requested by the business services application. In the two-tiered client/server model known in the art, the business services application 94 and the data services application 98 would typically exist on the same server computer, and consist of a complex set of object oriented applications. This complex set of object oriented applications reside on the same computer in the traditional two-tier client/server environment since remote object references are not available. Remote Automation permits a physical N-layered business architecture to be developed independently from the logical three-tier business architecture (process block 162) shown in FIG. 6. For example, as is shown in FIG. 7A, a user services application 104 on a client computer 106 uses Remote Automation 108 to communicate with several different server business services applications (110-114) on a remote second computer 116. Each different business services application provides a specific business functionality (e.g., one provides an account balance, two provides a record of sales, three provides a record of payments, etc.). Each of the different server business services applications, acting as client applications, uses Remote Automation 108 to communicate with a data services application 118 on a remote third server computer 120. The remote third computer is coupled to a database 122. FIG. 7A shows a physical model with one layer in each of the three logical tiers corresponding to the three-tiered logical model shown in FIG. 6. The business applications (110-114) may also exist on multiple remote business computers (124-128) as is shown in FIG. 7B. There may also be multiple data services applications (118,130) on multiple remote data computers (120,132) connected via Remote Automation in a variety of configurations. Remote Automation enables the physical performance and administration needs of a computer system (i.e., physical layering) to be fully addressed by allowing application objects to be located on one or more remote computers as needs dictate (process block 164), without having to give up the code partitioning benefits of the logical model. For example, if a user interface application called several business services applications residing on one remote computer (e.g., FIG. 7A), and the performance of the one remote computer became unacceptable (process block 166), one or more of the business services applications could be moved to one or more additional remote computers (e.g., FIG. 7B) to improve performance (process block 168). A similar scenario could be employed for the data services applications (e.g., FIG. 7B) including adding additional computers/databases to the physical layout. The physical layering could be changed a number of times (process blocks 166,168) without changing the logical model. Changing the physical layering (e.g., FIG. 7B) has no effect on the logical concepts developed for the three-tiered (or N-tiered) logical model (e.g., FIG. 6). For example, FIG. 7B illustrates a six layer physical model to provide functionality for the three-tiered logical model shown in FIG. 6 (i.e., one physical layer for logical tier one (user services), three physical layers for logical tier two (business services), and two physical layers for logical tier three (data services)). Remote Automation provides the ability to quickly and easily change and configure a physical model without affecting the original logical model. Any remote object references made by a client object oriented application are uniquely represented, and known to all server object oriented applications, no matter how many physical layers are used to represent a logical model. Business applications on the remote business services computer would use Remote Automation to move some of the business service applications to one or more additional remote computers. The move would be invisible to the user services interface application. When the user services interface application made a reference to a business services application that was moved to a remote computer, the reference would be passed to the proper place using Remote Automation. The remote computer would know and understand the reference passed to it. Thus, Remote Automation provides substantial "invisible" physical flexibility once an N-tiered logical services model has been developed. The N-tiered logical model made possible by Remote Automation is not limited to business services, but may be used to design a wide variety of other applications, requiring N-tiered layering. Remote Automation is also used to provide the ability to reference remote objects from a client network object oriented application (e.g., an Internet client network application). Remote Automation provides the ability to reference a remote object from a HyperText Markup Language (HTML) file. HTML is one of the standards for defining Internet network documents. An object reference can now be added to an HTML file to provide additional capabilities (e.g., multi-media capabilities) for HTML applications which formerly could only reference objects on the same computer. A Remote Automation object reference can also be used with, as, or within a Universal Resources Locator (URL) in a HTML file. A URL is a standard way specifying a site or page on a network (e.g., the Internet or world wide web). For example, a HTML reference to a remote object may be: <OBJECT ID=MyObj"CLASSID=clsid:SF6E4ELO-9C38-11CF-B63C-0080C792B782"> where "OBJECT ID=MyObj" is the name of an OLE object (e.g., MyObj) and "CLASSID=clsid:SF6E4ELO-9C38-11CF-B63C-0080C792B782" is the name and the ASCII GUID value of the remote object. Since hypertext transfer protocol (HTTP) and other protocols used with URLs for the Internet and other computer networks typically do not provide any state information or object type checking, Remote Automation is used to provide state information and object type checking for network client object oriented applications which need to access remote object information. Since Remote Automation uses RPC, which provides data authentication, data encryption/decryption and access control, Remote Automation also provides the ability for a network client object oriented application to use a secure, two-way communications path to complete a remote object reference without building in additional security features. It should be understood that the programs, processes, and methods described herein are not related or limited to any particular type of computer apparatus, unless indicated otherwise. Various types of general purpose or specialized computer apparatus may be used with or perform operations in accordance with the teachings described herein. In view of the wide variety of embodiments to which the principles of our invention can be applied, it should be understood that the illustrated embodiments are exemplary only, and should not be taken as limiting the scope of our invention. Rather, we claim as our invention all such embodiments as come within the scope and spirit of the following claims and equivalents thereto.
|
Same subclass Same class Consider this |
||||||||||