CA2237646A1 - Registry communications middleware - Google Patents
Registry communications middleware Download PDFInfo
- Publication number
- CA2237646A1 CA2237646A1 CA 2237646 CA2237646A CA2237646A1 CA 2237646 A1 CA2237646 A1 CA 2237646A1 CA 2237646 CA2237646 CA 2237646 CA 2237646 A CA2237646 A CA 2237646A CA 2237646 A1 CA2237646 A1 CA 2237646A1
- Authority
- CA
- Canada
- Prior art keywords
- registry
- client
- server
- message
- messages
- 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
Abstract
A computer system has a plurality of non-compatible clients (102) and servers (110) selectively interconnected over a network (108), each client capable of initiating an application (124) in which a related compatible server is involved. Communication between the clients and servers involves a first registry process (104, 126) including the acceptance of application specific messages from a client, destined to a preselected server, and encapsulating them into standard registry specific messages (128). The routing of the messages is determined by a database that responds to a verb command, from a particular client, to provide routing data. Next, there is a translation of the registry specific messages into a preselected protocol (106, 130). A second registry process (104, 126) occurs at a distant end to restore the message, after passing through the network. The second registry accepts the translated messages and converts them from protocol format to the original application specific format for use by the preselected compatible server.
Description
CA 02237646 1998-0~-14 W O 97119411 PCT~US96/18184 REGISTRY COMM1~11CATIONS MIDDLEWARE
Related Applica~ions This application relates to co-pending U.S. patent application Serial No.
08/580,950 entitled "EXITS: Extended Information Transfer Services", filed December 29, 1995.
Field of the Invention This invention relates to distributed cu~ .uLillg networks, and more specifically to a system that provides a standardized co~ tions layer between client/server applications and network mes~ging products.
Background of the Invention 0 Distributed colllL uLhlg is the method of allocating application data processing among several computing resources. It is a rapidly growing field in the information technology industry due to the efficiencies gained by lltili7ing several different processors for common applications.
Distributed c~ uLillg platforms are also known as client/server platforms, because each computing resource represents either a client or a server. A clientresource is a consumer of application services. It executes a filn~l~mental process of sending request me~s~ges to a server. Clients generally represent the users of asystem, such as a person rur~ing an application workstation.
A server resource is a provider of application services. It executes fim-l~mental processes of receiving request mess~ges from, and sending reply messages to, a client. Servers generally represent the components that m~int~in enterprise dataresources and implement l:usiness policies.
A fundamental requirement of implementing a distributed col-l~ulillg platform is the integration of various types of co~ uLillg and network resources into a single, enterprise-wide network. There are many products, standards, and communication protocols available for doing this, and many enterprises make use of several of them.
This creates a significant problem with regards to interoperability. Several different CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 applications running on various operating systems and hardware must interface with numerous mess,~gin~ and network co~ l licationprotocols . Applicationprogrammersmust deal with the complexities and intricacies of all of these protocols in order for their applications to work on the distributed co~ uLillg platform.
In addition, programmers must provide a means for their applications to determine the optimal transport mech~ni~m~ for messages. This is needed on both client and server resources.
Clearly there is a need for a business which utilizes distributed colll~uLillg resources and networks to irnplement a standard interface for applications which use 0 these resources. There is ~;ullellLly no product on the market to do this.
Br~ef Description of the Present Invention The present invention, identified as Registry, is a system that resides on each application resource (both clients and servers) of the distributed Colll~uLillg platform.
It is a co" " ~ ications agent that supports a suite of co~ 3tions me~s~gin~ products and network protocols. It serves as a logical layer of commnnic~tions between applications and the transport mech~ni.cm~ of the network.
By doing this, Registry shieIds the application prograrnmers from all of the underlying complexities of proprietary me.~s~ging and transport protocols.
Registry accepts application-specific messages from clients, encapsulates them 2 0 into standard Registry-specific messages, and then tr~n~l,.tes them into the protocol necess~ry for whichever transport and mess~ging mech~nicm~ that are to be used. At the other end, Registry takes the client-sent message and translates it from thetransport protocol that was used to an application-specific message that is used by the server.
Accordingly, it is an advantage of Registry that it provides enterprise-wide application connectivity across a broad array of operating systems, hardware platforms, messaging products, and network protocols.
CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 It is another advantage of Registry that it provides a single, standard interface to applications, while providing a product-specific interface to each of severaldifferent mess~gin~ and network commllnic~tion products.
It is another advantage of Registry that it allows application programmers to avoid the requirement o~ progr~rnmin~: low-level me~s~ginp; and transport semantics into their applications; programmers may focus on business-oriented semzlntics. This advantage increases the flexibility and decreases the complexities of the applications.
It is another advantage of Registry that it elimin~tes the need for each application to have specific interfaces to the various me~.c~ging and transport 0 protocols that are in use.
It is another advantage of Registry that it provides applications with a means of determinin~ optimal transport mech~ni~m~ for each transaction.
It is another advantage of Registry that it enables applications to become platform and protocol independent. That is, application programmers do not need to 15 know which operating systems, hardware platforms, and c~ll"llul~ications protocols may be used by the application clients and servers; they only need to program in a standard interface to Registry. Also, clients and servers may be ported from oneplatform/protocol to another without having to program corresponding changes into each application.
It is another advantage of Registry that through the use of a logical network routing directory, changes in addresses of physical resources only require updates in Registry's directory, and not on every application.
Brief Description of the F~gures The above-mentioned objects and advantages of the present invention will be 25 more clearly understood when considered in conjunction with the accompanying drawings, in which:
CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 Fig. 1 is a block diagram showing a high-level systems architecture of a sample distributed co~ .uLing platform utili7.ing Registry.
Fig. la is a diagram showing the logical layers of client/server communications and where Registry fits in.
s == Fig. 2 is a block diagram illustrating the internal architect~lre of Registry, and a single thread of a distributed coln~uLillg platform which ~lt~ es it.
Fig. 2a is a dataflow diagram which illustrates in detail the Generalized IPC
Inter~ace identified in Fig. 2.
Fig. 2b is a block diagram showing the Registry Process Monitor in greater detail.
Fig. 3a is a process flowchart illustrating the operation of Registry.
Fig. 3b is a contim~tion of the process flowchart in Fig. 3a.
Detailed Descr~ption Of The Invention Referring to Fig. 1, Registry is depicted as a single, standard interface to both 15== client and server applications. Registry is actually a system that resides on each individual client and server resource. It provides a single, standard interface to each client and server application to shield these applications from the complexities of various proprietary mess~ging products and networl~ protocols. The operating systems, mess~ing products, and network protocols shown are only a sample of 20 those supported by Registry.
Registry 104 accepts request messages from Client Applications 102 as part of a dialog. The applications 102 may run under various operation systems, as indicated. These request messages represent a solicitation for a response and/or an instruction to perform a process. They are generated by the Client Applications with 2s the intent of being delivered to a Server Application 110. Application 110 may also be run under various operating systems, as shown. ~ince the Registry software resides on the same hardware components as the applications, the link between CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 Registry 104 and the Client Applications 102 represents a software process. Although four examples of operating systems and terminal emulators are illustrated, Registry supports many more.
Registry 104 then executes a process of encapsulating the client's request message into a Registry-defined message. This process is depicted in greater detail in references to Figs. 2 and 4. Registry dete~ les the ~l~liate Mes~gin~
Product 106 and converts the message into the proprietary protocol of this ~es~ginp:
Product. In some situations, Registry may actually serve as the Me.ss~gin~ Product;
in these cases, it will convert the message to the proprietary protocol of the network 0 transport 108 ~i.e., SNA LU6.2, TCP/IP, etc.).
The Mess~gin~ Product 106 will use an a~pl~l,riate network protocol for transporting the message over an available network 108. At the distant end, the Mess~gin?~ Product 106 receives the message and passes it off to Registry 104.
Registry converts the mess~ge from the proprietary protocol of the Me~s~ing Product 106 to a message that is recognizable to the Server Application 110. If a response from the Server Application 110 is re~uired, the prece-~in~ process is repeated to send the response message back to the Client Application 102.
Referring to Fig. la, the role that Registry 104 assumes in logical layers of client/server c(J~ ications is illustrated. In t_is diagram, the resource is identified on the front of each layer, the interface it provides is identified on the top of each layër, and the semantics used in the interface are identified to the right of each layer.
The top layer 122 represents the User of an application. It interfaces with an Application via Application-defined User/Resource Interfaces, exch~nging business-oriented information with the Application.
2 5 The next layer down 124 represents the Application. It interfaces with Registry via use of a Standard Verb Set (SVS). The semantics used are business-oriented client/server tr~n~ctions known as 'verbs', and represent the only protocol that the application programmers need to deal with.
CA 02237646 1998-0~-14 W O 97/19411 PCTnJS96/18184 The next layer down 126 represents Registry. It interfaces with Mess~gin~
Products (a.k.a., Co~ ications Middleware) via Product-specific interfaces. The semantics used are specific to the Mess~ging Product.
The next layer down 128 represents the ~o"~"-ll"ic~tion Middleware -Mess~ing Products. They interface with the Network via Network ProtocolInterfaces, using data tr~n.smi~sion sem~nti~s. The bottom layer 130, which represents Network Protocol, may consist of such types as SNA LU6.2 or TCP/IP.
In some cases, Registry 126 may actually span across the Co"""ll.lications Middleware layer 128. For example, Registry may translate client request messages 0 into actual TCP/IP messages and send directly over the TCP/IP network.
Referring to Fig. 2, the internal logical structure of Registry is shown to illustrate a typical client/server conversation lltili7in~ Registry.
A Client Application 202 generates a request message that needs to be sent to a distant Server Application 222. A typical example of a request mess~e may be a5 ~request for a customer's monthly billing revenue from a company's customer billing database located on a distant server. The Client and Server are connected by an enterprise Data Network 218, and have several Mess~ginP: Products 216 available to transport their messages over the Network 218. They will use Registry 204 as an interface to all of these Mess~in~ Products 216 and Network 218 protocols.
The Client Application 202 c~""llll"icates with Registry 204 via Registry's Application Progr~mming Interface (API) 206. The API contains a set of comm~n-lsknown as a Standard Verb Set (SVS), which is defined as follows:
Standard Verb Set Registry's Standard Verb Set (SVS) is a set of comm~n~ls that Registry uses 25 =to c~ icate with both ~lient and Server applications. This limited set of comm~ntls represents all ofthe c(31"",l1-,ications protocol that client/server application CA 02237646 1998-0~-14 programmers will need to use for their applications to co~ l"icate with Registryand, thus, the t;llLel~lise network.
There are two sets of verbs: one for use by Client applications, and one for use by Server applications. Since an application can potentially function as either a Client or a Server, both sets of verbs are included in the SVS for every application.
As noted previously, the SVS is m~int~inP~1 within the API 206 of Registry, as well as each Client and Server application.
The Client verbs and their parameters are defined as follows:
REGISTER - Establishes a session between the calling application and Registry. This session is only between the calling application and Registry, and not between applications. The session consists of a Registration Control Area (RCA), which is memory allocated by the REGISTER verb in Registry and passed back to the calling application.
The RCA represents a unique instance of the registering process, and a new RCA is required for each issuance of REGISTER by the Client.
Parameters of REGlSTER are:
FEEDBACK - Field used to return to the calling application an indication as to whether Registry was able to complete the function called for.
REG-OPTIONS - This contains several fields, most of them optional, providing information used to identify the Client application. One required field o~F this parameter is a one-character designation indicating whether the calling application is a client or a server.
RCA-PTR - Field used to uniquely identify the RCA by serving as a pointer to the RCA. It designates a specific session established by REGISTER verb, and identifies subsequent calls to Registry as part of specific session. Each W O 97/19411 PCT~US96/18184 issuance of REGISTER must designate a dirl~lel~l session and therefore have a different value for this ~leld ~for example, RCA-PTRl, RCA-PTR2, etc.).
DEREGISTER - Termin~tes activities of the client/server applications, and releases any associated Registry-managed resources. Parameters are the same s as those for RE~l~
SENDREQUEST- Used to send a client request to a server. Contains same parameters as RECISTE~, plus the following:
WS-TEST-MSG - This field is the address of the actual message being sent by the Client to the ~erver.
0: WS-MSG-LEN - This field in-lic~t~s the length of the Client message.
RECEIVEREPLY- Used to receive a reply to a previous request. The RCA
must be the same one used for the SEND~QUEST verb. Contains same parameters as REGISTER, plus the following:
WS-OUT-MSG-PTR - This field is a pointer to the reply message.
15 ~ WS-OUT-MSG-LEN - This field indicates the length of the reply message.
~ONVERSE - Used to conduct a synchronous request/reply transaction.
Contains same parameters as SEl~REQUESTand RECEIVEREPLYcombined.
The Server verbs and their parameters are defined as follows:
REGlSTEl;~ - Same definition as Client version of verb. Server issues a ~EGISTER verb in response to Registry's request to do so.
DEREGISTER - Same definition as Client version of verb.
RECEIVEREQUEST- Used to receive a request message sent by a Client.
The message itself will be received unmodified by Registry, and then processed by the Server. Contains same parameters as REC~ l~, plus the following:
WS-REQUEST-MSG - This field is the address of the message being sent to the Server by the Client.
0 WS-REQUEST-LEN - This field in-lic~tes the length of the mess~ge.
SENDREPLY- Used to send the Server's reply to the Client's message.
~ontains same parameters as REGISTER, plus the following:
WS-SENDREPLY-MSG - This field is the address of the reply being sent to the Client by the Server.
WS-SENDREPLY-LEN - This field inclic~tes the leng~ of the reply.
With contim~ reference to Fig. 2, a Client Application 202 initi~te,c a session by registering itself as a client with Registry 204. This is accomplished by issuing a REGISTER verb, which is read by the API 206. A Registry component identified as - the Verb Execution 208 is responsible for v~ tinl~; the parameters and processing 2 o each verb. When a REGISTER verb is received by the API 206, Verb Execution 208 CA 02237646 1998-0~-14 W O 97/194~1 PCTAUS96/18184 -' will create a Registration Control Area ~RCA) and send the RCA address back to the Client 202 via the API 206. This RCA is used to store and process all commllnications between the Client and Registry.
The Client Application 202 will then issue a SENDREQUEST verb to 5 Registry. This verb will comm~n-1 Registry to send the Client's request message, generated previously by the Client, to the Server 222. The actual request mess~ge will also be sent to Registry as a parameter of the SENDREQUEST verb. This message is in a forrnat defined by the specific Client Application 202 that generated it, and will remain unInodified by Registry 2~4. Registry will simply deliver it to the o Server 222.
Alternatively, the Client 202 may issue a CONVERSE verb, which establishes a two-way, conversational dialog with the Server 222. This is equivalent to issuing a SENDREQUEST and RECEIVEREPLY verb in combination. By issuing solely a SENDREQUEST verb, the Client 202 may establish either a conversational or a one-15 = way dialog with the Server 222, depending on the verb's parameters.
With con~imle~l reference to Fig. 2, the SENDREQUEST verb is received andrecognized by the API 206. Registry then initi~t~s the Verb Execution 208 process.
The Verb Execution 208 will validate the parameters of the verb. It also resolves the destination address. It reads, from the Client Application's message, the naIne of the Server Application 222 for which the ~lient's request is intended. It then queries a Directory Services database 210 to determine the physical network destination for that Server Application 222. The Directory Services 210 containsphysical network routing codes for each client/server application on the network.
When a request or reply message is given to Registry to deliver to a specific application on the network, Registry determines where that application resides by translating its name to a physical network node via the Directory Services. In this way, when an application is migrated to another node on the network, only the CA 02237646 l998-0~-l4 Directory Services needs to be updated, as opposed to updating every clientlserver application.
In the preferred embodiment, the network destination of an application is represented by a three-part name, consisting of a Domain, a ServiceName, and a 5 ServiceQualifier. The Dornain refers to a distinct sub-network of the ellL~,~lise-wide net~,vork. The ServiceName refers to the function, rather than the physical location, of the destination node and is the fundamental identifier of the destination. The ServiceQualifier refers to a specific instance of the ServiceName function, in cases where there are more than one instance. An example would be specifying a 0 ServiceName function of geographical customer data into ServiceQualifiers of "l~ast"
and "West" .
With contimle-l reference to Fig. 2, the Verb Execution 208 launches execution of the SENDREQU~ST verb by issuing a Generalized IPC Request to a Generalized IPC Interface 212. IPC (Inter-Process Commlmications) refers to all components and processes between Registry at the Client end and Registry at the Server end. It includes Messaging Products 216, Data Networks 218, and anything that supports the commnnic~tions between the Client processes and the Server processes.
The Generalized IPC Interface 212 is the Registry component responsible for selecting the approL)liate IPC products for transporting the Client's mess~ge to the Server. The Generalized IPC Interface 212 contains a generalized view of all of the Mecs~gin~ 216 and Network 218 products available, and selects one for use in thecurrent session. It is also responsible for tr~n~l~tin~ the m~c~ge envelope (themessage itself remains unmodified) to the a~ro~liate format of the selected IPC
product. The Generalized IPC Request is a comm~n-l issued by Verb Execution 208 to the Generalized IPC Interface 212. It contains the Client's message, Server'snetwork address, and a request to send the message.
The Generalized IPC Interface 212 is shown in greater detail in Fig. 2a, which is a dataflow diagram illustrating the operation of the Interface 212. Referring to ~ig.
CA 02237646 1998-0~-14 2a, the Generalized IPC Interface is identified within the broken line. It consists of three prirnary logical components: a Generalized IPC Interface Request Processor230, an IPC Product Qualification 232, and an IPC Mess~in~ Interface 234. It also contains a database of Available Services Information 236, which may be a partitioned ~ e of the Directory Services 210, or a separate database.
The Generalized IPC Interface l~equest Processor 230 provides the formal and initial interface to the Verb Execution 208. It receives the Generalized IPC Request 240 and determines what services are required to process the request. It then compiles these services into a Required Services List 242, which it forwards to the 0 IPC Product Qualification 232. The Required Services List 242 is a set of data items, each item identifying a Registry-defined service that is needed to process the request.
Exarnples of such services are persistent queuing, message recovery, and time-out.
The IPC Product Qll~lific~tion component 232 determines which l!~les~z-ging Product 216 is to be used for transporting the Client's m~ss~pe over the Data 15 Net~,vork 218. This determination is based on two inputs: the Required Services List 242 from the Request Processor 230, and a list of Available IPC Products 244 from the Available Services Information ~i~t~b~e 236. The Available Services Information database 236, which resides with Directory Services 210 in the preferred embodiment of Registry, contains preprogrammed lists of all available IPC products (which 20 includes Me.~s~in~. Products 21L6 and Data Network 218 protocols) and their requirements. Based on the services required 242 for the particular request, and the Available IPC Products 244, the IPC Product Qualification component 232 selects the appropriate IPC Product 216 to use. It then sends the identification of this Selected IPC Product 246 to the IPC Me~s~ginp; Interface 234.
The IPC Mess~ging Interface 234 provides Registry's interface to the selected IPC products, including the selected Me~sz~ing Product 216. As previously noted,IPC refers to all components needed to transport the mess7~f~e from the Client'sRegistry to the Server's Registry; this includes primarily industry-standard Mecs~gin~
W O 97/19411 PCT~US96/18184 Products 216 and Data Network products 218. It tr~n.~l~tes the Generalized IPC
Request 240 to a format defined and required by the selected Mess~in~; Product 216.
It also initiates the dialog with the Mes.s~gin~ Product 216. When the Generalized IPC Request 240 (which contains the Client's native request mess~ge) is tr~n~l~t~d 5 to the proper Mess~ging Product 216 format, it is passed to the Mess~in~ Product 216 for transport over the Data Network 218 to a distant Server 222.
Referring back to Fig. 2, at the Server end, the Me~ging Product 216 receives the message from the Network 218, and delivers the message 224 to Registry 204 via the Generalized IPC Interface 212. This delivery of the m~sc~ge 224 0 to Registry 204, along wit'n the entire process conducted by Registry at the Server end, is controlled by a Registry component identified as a Registry Process Monitor 220. The Registry Process Monitor 220 controls the Server's 222 receiving and processing of messages. It's objectives are to maximize Server throughput of .essages, E~.~na~e the ~irgd rumbg~ o~ ~e~r ~ o p~cess w~r~loads, contr{31 server capacity and lltili7~tion by termin:~ting/ reactivating Server tasks as workload demands change, and to provide application-defined mech~ni~m~ for controlling server resource allocation.
Referring to Fig. 2b, the Registry Process Monitor (RPM) 220 is shown in greater detail to illustrate its operation. The RPM consists of tnree primary 20 components: a Queue Monitor (QM) 260, a Process Monitor (PM) 262, and a Control Monitor (CM) 264.
As Server-bound messages are retrieved from the Network 218 by the Messaging Products 216, they are held in queues pending retrieval by Regisky 204.
Each queue is assigned a class of service to indicate its priority. Each QM 260 is assigned to a queue or a range of queues, and therefore to a class of service or range of classes. The QM 260 monitors these queues by receiving queue status data 226 from the Mess~ging Products 216. By tracking which messages are released for Server processing, the QM 260 knows the Server's ~;ullellL level of ntili7~tion and its CA 02237646 1998-0~-14 capacity for h~nr11ing additional mess~es. When the QM 260 determines the Serverhas sufficient resource capacity for h~n~1lin~ additional messages, the QM 260 selects a message from a specific queue for subsequent proce~ing. It then sends to the PM
262 requirements 270 for a Server thread n~e-lecl to retrieve the message. This Server thread 276 represents a processing link between the operating system of the Server 222 and Registry 204. It will be used by the Server Application 222 to request and receive the Client's message.
The PM 262 will send a request 272 to the Server 222 to setup a thread by registering itself with Registry. The Server 222 will then issue a REGISTER verb to 0 Registry. This establishes a session between the Server 222 and Registry 204,identical to the manner in which the Client 202 has done. The Server 222 then issues a RECEIVEREQUEST verb, which allows it to receive the Client's request message via the Server Thread 276.
The RECEIVEREQUEST verb is received by the API 206 and passed to Verb 15 Execution 208 for processin~. Verb Execution 208 validates the parameters. From the WS-REQUEST-MS~ parameter, Registry knows where the message is and can retrieve it via the Generalized IPC Interface 212. The IPC Interface 212 retrieves the message 224 and extracts the Client's native request m~ss~e from it. This Client's request message is then passed to the Server 222 for application-specific proces~in~.
The CM 264 serves a utility function, providing systems management and con~lguration for Registry. It provides a Graphical User Interface (GUI) 266 to a systems operator to allow an operator to perform system ~-1mini~tration functions. It also allows the operator to modify the domain o~ queues managed by each QM 260.
Referring back to Fig. 2, after processing the Client's request message, and 2 5 = if a reply is required, the Server 222 issues a SENDREPLY verb. This verb contains the Server's reply message as a parameter, which is identified as WS-SENDREPLY-MSG. This verb is processed similar to how the SENDREQUEST verb was processed previously.
CA 02237646 1998-0~-14 Referring to Fig. 3a, a process flowchart illustrates the operation of Registry when a Client Application issues a SENDREQUEST verb to send a mloss~ge to a Server Application. A similar operation would be conducted if a CONVERSE verb was issued.
In step 302, ~e Client Application 202 initi~teS a request for a Server Application 222 to process. This request must be delivered to the Server Application 222, which resides on a distant machine. In step 302, the request is thus far cont~in~rl within the Client Application 202.
In step 304, the Client 202 issues a REGISTER verb to Registry 204. The 0 REGISTER verb is the comm~nl1 that establishes a co~ ications session between the Client 202 and Registry 204. In step 306, the Verb Execution component 208 of Registry 204 v~ tes the parameters of the REGISTER verb. Then in step 308, Verb Execution 208 builds a Registration Control Area (RCA), which is a memory allocation used for passing verb parameters (including the Client's message) between the Client 202 and Registry 204.
In step 310, the Client 202 issues a SENDREQUEST verb to Registry 204.
The Client 202 sends its request message as a parameter of the SENDREQUEST
verb. In step 312, the Verb Execution component 208 of Registry 204 v~licl~tes the parameters of the SENDREQUEST verb. Then in step 314, Verb Execution 208 determines the physical network routing address of the intended Server Application 222. This is done by extracting the Server Applicatiorl name from the Client's mes.~ge and tr~n~l~ting that name to a network destination via a query to the Directory Services 210. The Directory Services 210 will return a network destination in the form of a Domain, a ServiceName, and a ServiceQualifier, as specified previously in reference to Fig. 2.
In step 316, the Verb Execution component 208 performs its final function on - the SENDREQUEST verb by issuing a Generalized IPC Request to the Generalized IPC Interface 212. The Generalized IPC Reguest is a comm~n~l that instructs the T-PC
CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 Interface 212 to perform certain functions n~e~le~ to deliver the Client's message.
These functions are specified in steps 318 through 324. The Generalized IPC Request also contains the Client's message and the Server's network address. The issuance of the Generalized IPC Request is depicted in Fig. 2a as item 240.
With contimle~ lefe~ ce to Fig. 3a, in step 318, the Generalized IPC Interface Request Processor 230 compiles a list of services that are required to process the Generalized IPC Request. These re~uired services will be performed by the Mess~gin~ Product 216. The Required Services List 242 that is generated is used by the IPC Product Qualification component 232 in step 320 to select an IPC product.
0 The IPC Product Qualification 232 also receives a list of Available IPC: Products 244 from the Available Services Information ~l~t~b~e 236.
In step 320, the IPC Product Qualification 232 matches the required services from the Required Services List 242 to those offered from certain IPC products identified in the Available IPC Products list 244, and selects the a~pl-o~liate IPC
15 product. The selected IPC product will be a Mess~ging Product 216 and/or a Data Network 218 transport protocol. Identification of the selected IPC product is then sent to the IPC Me~s~ging Interface component 234.
In step 322, the IPC Mess~ging Interface component 234 formats the Generalized IPC Request (which it has received from Verb Execution 208 as depicted 20 in Fig. 2a) into a message that is proprietary to the selected IPC product. The procedures for this translation of formats have been programmed into the IPC
Mess~ginp Interface component 234. Then, in step 324, the Interface 234 establishes a commllnications session with the selected Mess~gin~ Product 216 in a manner that is standard for that Messaging Product. Once the session is established, the message 25 is passed to the Mess~gins~ Product, which proceeds to deliver the message over the Data Network 218. Note, the "message" referred to here consists of the Client's native re(luest message packaged in an envelope that Registry has formatted specifically for the selected IP~ Products.
CA 02237646 1998-0~-14 Step 326 represents the transport of the message over the Data Network 218 in a manner that is standard for the particular network protocol that is in use.In step 328, Registry at the Server site is prepared to receive the mes~ e. The Queue Monitor (QM) component 260 of the Registry Process Monitor Z20 monitors 5 the message in a certain queue. It does this by receiving ~ueue status data 226 from each of the connected Mess~in~ Products 216. The QM 260 also tracks Server resource capacity by being programmed with initial Server capacity and tracking each message that is sent to the Server. In this way, the QM 260 knows the ~;u~ L Server ili7~tion and its capacity for processing additional messages. As part of step 328, 0 the QM 260 assesses the ~;ullenL capacity of the Server and determines when the next message may be retrieved.
In step 330, the QM 260 deterrnines that the next message is to be retrieved and issues requirements for a Server thread 276. As mentioned previously, this Server thread 276 represents a processing link between the operating system of the 15 Server 222 and Registry 204. It will be used by the Server Application 222 to request and receive the message. The Server thread requirements are issued by the QM 260to the Process Monitor (PM) 262.
In step 332, the PM 262 issues a request for a Server thread to the operating system of the Server. This serves as a trigger for the Server Application 222 to20 establish a session with Registry 204. This is done by issuing a REGISTER verb, as was done previously by the Client 202.
In step 334, the Server 222 issues the REGISTl~R verb, which is read by Registry's API 206 and passed to Verb Execution 208. This establishes the Server's session with Registry. The process continues at the off-page connector A in Fig. 3b.
Referring now to Fig. 3b, in step 336, Verb Execution 208 processes the Server's REGISTER verb as it did with the Client's. It builds the RCA that is ~ specific to the current session. Then, in step 338, the Server 222 issues a CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 RECEIVEREQUEST verb to Registry. The RECEIVEREQUEST verb instructs Registry to send the Client's message to the Server 222.
In step 340, Verb Execution 208 validates the parameters of the RECEIVEREQUEST verb. One of these parameters will be populated with the 5 _ address in memory of the Client's request mess~e. In step 342, Verb Execution 208 extracts the Client's native request message from the packaged message that was delivered over the Network 218, and passes this request message to the Server 222.
In step 344, the Server 222 processes the Client's request message in a manner that is specific to the application and independent of Registry. A Server reply to the Client request may or may not be re~uired, as determined in step 346. If a reply is required, the Server 222 issues a SENDREPI_Y verb in step 348, which is processed in the same manner as a Client's SENDREQUEST verb, beginnin~ in step 310. The Server's reply is then delivered to the Client, as indicated in step 350. The Server 222 then proceeds to issue another RECEIVEREQUEST verb in step 352.
If a reply is not required, as determined in step 346, the Server 222 issues another RECEIVEREQUEST verb in step 352. If no more request mess~es are in queue for the Server, a mess~ge stating "No More Messages" is returned to the Server 222 from Registry 204, as indicated in step 354. Then the process ends with step 356, in which the Server 222 issues a DEREGISTER verb. The DEREGISTER
verb instructs Registry to end the session.
If, in step 354, the "No More Messages" message is not returned, an assumption is made that more request mes~es are in queue. The process returns tostep 340, in which the Verb Execution 208 proceeds to process the RECEIVEREQUEST verb by V~ tin~ the parameters.
The specifications in the above description should not be construed as limit~3tions on the scope of the invention, but rather as specifications of the preferred embodiment. Other obvious variations and modifications are possible, and will occur to persons skilled in the art.
It should be understood that the invention is not limitefl to the exact details of construction shown and described herein for obvious modifications will occur to persons skilled in the art.
Related Applica~ions This application relates to co-pending U.S. patent application Serial No.
08/580,950 entitled "EXITS: Extended Information Transfer Services", filed December 29, 1995.
Field of the Invention This invention relates to distributed cu~ .uLillg networks, and more specifically to a system that provides a standardized co~ tions layer between client/server applications and network mes~ging products.
Background of the Invention 0 Distributed colllL uLhlg is the method of allocating application data processing among several computing resources. It is a rapidly growing field in the information technology industry due to the efficiencies gained by lltili7ing several different processors for common applications.
Distributed c~ uLillg platforms are also known as client/server platforms, because each computing resource represents either a client or a server. A clientresource is a consumer of application services. It executes a filn~l~mental process of sending request me~s~ges to a server. Clients generally represent the users of asystem, such as a person rur~ing an application workstation.
A server resource is a provider of application services. It executes fim-l~mental processes of receiving request mess~ges from, and sending reply messages to, a client. Servers generally represent the components that m~int~in enterprise dataresources and implement l:usiness policies.
A fundamental requirement of implementing a distributed col-l~ulillg platform is the integration of various types of co~ uLillg and network resources into a single, enterprise-wide network. There are many products, standards, and communication protocols available for doing this, and many enterprises make use of several of them.
This creates a significant problem with regards to interoperability. Several different CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 applications running on various operating systems and hardware must interface with numerous mess,~gin~ and network co~ l licationprotocols . Applicationprogrammersmust deal with the complexities and intricacies of all of these protocols in order for their applications to work on the distributed co~ uLillg platform.
In addition, programmers must provide a means for their applications to determine the optimal transport mech~ni~m~ for messages. This is needed on both client and server resources.
Clearly there is a need for a business which utilizes distributed colll~uLillg resources and networks to irnplement a standard interface for applications which use 0 these resources. There is ~;ullellLly no product on the market to do this.
Br~ef Description of the Present Invention The present invention, identified as Registry, is a system that resides on each application resource (both clients and servers) of the distributed Colll~uLillg platform.
It is a co" " ~ ications agent that supports a suite of co~ 3tions me~s~gin~ products and network protocols. It serves as a logical layer of commnnic~tions between applications and the transport mech~ni.cm~ of the network.
By doing this, Registry shieIds the application prograrnmers from all of the underlying complexities of proprietary me.~s~ging and transport protocols.
Registry accepts application-specific messages from clients, encapsulates them 2 0 into standard Registry-specific messages, and then tr~n~l,.tes them into the protocol necess~ry for whichever transport and mess~ging mech~nicm~ that are to be used. At the other end, Registry takes the client-sent message and translates it from thetransport protocol that was used to an application-specific message that is used by the server.
Accordingly, it is an advantage of Registry that it provides enterprise-wide application connectivity across a broad array of operating systems, hardware platforms, messaging products, and network protocols.
CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 It is another advantage of Registry that it provides a single, standard interface to applications, while providing a product-specific interface to each of severaldifferent mess~gin~ and network commllnic~tion products.
It is another advantage of Registry that it allows application programmers to avoid the requirement o~ progr~rnmin~: low-level me~s~ginp; and transport semantics into their applications; programmers may focus on business-oriented semzlntics. This advantage increases the flexibility and decreases the complexities of the applications.
It is another advantage of Registry that it elimin~tes the need for each application to have specific interfaces to the various me~.c~ging and transport 0 protocols that are in use.
It is another advantage of Registry that it provides applications with a means of determinin~ optimal transport mech~ni~m~ for each transaction.
It is another advantage of Registry that it enables applications to become platform and protocol independent. That is, application programmers do not need to 15 know which operating systems, hardware platforms, and c~ll"llul~ications protocols may be used by the application clients and servers; they only need to program in a standard interface to Registry. Also, clients and servers may be ported from oneplatform/protocol to another without having to program corresponding changes into each application.
It is another advantage of Registry that through the use of a logical network routing directory, changes in addresses of physical resources only require updates in Registry's directory, and not on every application.
Brief Description of the F~gures The above-mentioned objects and advantages of the present invention will be 25 more clearly understood when considered in conjunction with the accompanying drawings, in which:
CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 Fig. 1 is a block diagram showing a high-level systems architecture of a sample distributed co~ .uLing platform utili7.ing Registry.
Fig. la is a diagram showing the logical layers of client/server communications and where Registry fits in.
s == Fig. 2 is a block diagram illustrating the internal architect~lre of Registry, and a single thread of a distributed coln~uLillg platform which ~lt~ es it.
Fig. 2a is a dataflow diagram which illustrates in detail the Generalized IPC
Inter~ace identified in Fig. 2.
Fig. 2b is a block diagram showing the Registry Process Monitor in greater detail.
Fig. 3a is a process flowchart illustrating the operation of Registry.
Fig. 3b is a contim~tion of the process flowchart in Fig. 3a.
Detailed Descr~ption Of The Invention Referring to Fig. 1, Registry is depicted as a single, standard interface to both 15== client and server applications. Registry is actually a system that resides on each individual client and server resource. It provides a single, standard interface to each client and server application to shield these applications from the complexities of various proprietary mess~ging products and networl~ protocols. The operating systems, mess~ing products, and network protocols shown are only a sample of 20 those supported by Registry.
Registry 104 accepts request messages from Client Applications 102 as part of a dialog. The applications 102 may run under various operation systems, as indicated. These request messages represent a solicitation for a response and/or an instruction to perform a process. They are generated by the Client Applications with 2s the intent of being delivered to a Server Application 110. Application 110 may also be run under various operating systems, as shown. ~ince the Registry software resides on the same hardware components as the applications, the link between CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 Registry 104 and the Client Applications 102 represents a software process. Although four examples of operating systems and terminal emulators are illustrated, Registry supports many more.
Registry 104 then executes a process of encapsulating the client's request message into a Registry-defined message. This process is depicted in greater detail in references to Figs. 2 and 4. Registry dete~ les the ~l~liate Mes~gin~
Product 106 and converts the message into the proprietary protocol of this ~es~ginp:
Product. In some situations, Registry may actually serve as the Me.ss~gin~ Product;
in these cases, it will convert the message to the proprietary protocol of the network 0 transport 108 ~i.e., SNA LU6.2, TCP/IP, etc.).
The Mess~gin~ Product 106 will use an a~pl~l,riate network protocol for transporting the message over an available network 108. At the distant end, the Mess~gin?~ Product 106 receives the message and passes it off to Registry 104.
Registry converts the mess~ge from the proprietary protocol of the Me~s~ing Product 106 to a message that is recognizable to the Server Application 110. If a response from the Server Application 110 is re~uired, the prece-~in~ process is repeated to send the response message back to the Client Application 102.
Referring to Fig. la, the role that Registry 104 assumes in logical layers of client/server c(J~ ications is illustrated. In t_is diagram, the resource is identified on the front of each layer, the interface it provides is identified on the top of each layër, and the semantics used in the interface are identified to the right of each layer.
The top layer 122 represents the User of an application. It interfaces with an Application via Application-defined User/Resource Interfaces, exch~nging business-oriented information with the Application.
2 5 The next layer down 124 represents the Application. It interfaces with Registry via use of a Standard Verb Set (SVS). The semantics used are business-oriented client/server tr~n~ctions known as 'verbs', and represent the only protocol that the application programmers need to deal with.
CA 02237646 1998-0~-14 W O 97/19411 PCTnJS96/18184 The next layer down 126 represents Registry. It interfaces with Mess~gin~
Products (a.k.a., Co~ ications Middleware) via Product-specific interfaces. The semantics used are specific to the Mess~ging Product.
The next layer down 128 represents the ~o"~"-ll"ic~tion Middleware -Mess~ing Products. They interface with the Network via Network ProtocolInterfaces, using data tr~n.smi~sion sem~nti~s. The bottom layer 130, which represents Network Protocol, may consist of such types as SNA LU6.2 or TCP/IP.
In some cases, Registry 126 may actually span across the Co"""ll.lications Middleware layer 128. For example, Registry may translate client request messages 0 into actual TCP/IP messages and send directly over the TCP/IP network.
Referring to Fig. 2, the internal logical structure of Registry is shown to illustrate a typical client/server conversation lltili7in~ Registry.
A Client Application 202 generates a request message that needs to be sent to a distant Server Application 222. A typical example of a request mess~e may be a5 ~request for a customer's monthly billing revenue from a company's customer billing database located on a distant server. The Client and Server are connected by an enterprise Data Network 218, and have several Mess~ginP: Products 216 available to transport their messages over the Network 218. They will use Registry 204 as an interface to all of these Mess~in~ Products 216 and Network 218 protocols.
The Client Application 202 c~""llll"icates with Registry 204 via Registry's Application Progr~mming Interface (API) 206. The API contains a set of comm~n-lsknown as a Standard Verb Set (SVS), which is defined as follows:
Standard Verb Set Registry's Standard Verb Set (SVS) is a set of comm~n~ls that Registry uses 25 =to c~ icate with both ~lient and Server applications. This limited set of comm~ntls represents all ofthe c(31"",l1-,ications protocol that client/server application CA 02237646 1998-0~-14 programmers will need to use for their applications to co~ l"icate with Registryand, thus, the t;llLel~lise network.
There are two sets of verbs: one for use by Client applications, and one for use by Server applications. Since an application can potentially function as either a Client or a Server, both sets of verbs are included in the SVS for every application.
As noted previously, the SVS is m~int~inP~1 within the API 206 of Registry, as well as each Client and Server application.
The Client verbs and their parameters are defined as follows:
REGISTER - Establishes a session between the calling application and Registry. This session is only between the calling application and Registry, and not between applications. The session consists of a Registration Control Area (RCA), which is memory allocated by the REGISTER verb in Registry and passed back to the calling application.
The RCA represents a unique instance of the registering process, and a new RCA is required for each issuance of REGISTER by the Client.
Parameters of REGlSTER are:
FEEDBACK - Field used to return to the calling application an indication as to whether Registry was able to complete the function called for.
REG-OPTIONS - This contains several fields, most of them optional, providing information used to identify the Client application. One required field o~F this parameter is a one-character designation indicating whether the calling application is a client or a server.
RCA-PTR - Field used to uniquely identify the RCA by serving as a pointer to the RCA. It designates a specific session established by REGISTER verb, and identifies subsequent calls to Registry as part of specific session. Each W O 97/19411 PCT~US96/18184 issuance of REGISTER must designate a dirl~lel~l session and therefore have a different value for this ~leld ~for example, RCA-PTRl, RCA-PTR2, etc.).
DEREGISTER - Termin~tes activities of the client/server applications, and releases any associated Registry-managed resources. Parameters are the same s as those for RE~l~
SENDREQUEST- Used to send a client request to a server. Contains same parameters as RECISTE~, plus the following:
WS-TEST-MSG - This field is the address of the actual message being sent by the Client to the ~erver.
0: WS-MSG-LEN - This field in-lic~t~s the length of the Client message.
RECEIVEREPLY- Used to receive a reply to a previous request. The RCA
must be the same one used for the SEND~QUEST verb. Contains same parameters as REGISTER, plus the following:
WS-OUT-MSG-PTR - This field is a pointer to the reply message.
15 ~ WS-OUT-MSG-LEN - This field indicates the length of the reply message.
~ONVERSE - Used to conduct a synchronous request/reply transaction.
Contains same parameters as SEl~REQUESTand RECEIVEREPLYcombined.
The Server verbs and their parameters are defined as follows:
REGlSTEl;~ - Same definition as Client version of verb. Server issues a ~EGISTER verb in response to Registry's request to do so.
DEREGISTER - Same definition as Client version of verb.
RECEIVEREQUEST- Used to receive a request message sent by a Client.
The message itself will be received unmodified by Registry, and then processed by the Server. Contains same parameters as REC~ l~, plus the following:
WS-REQUEST-MSG - This field is the address of the message being sent to the Server by the Client.
0 WS-REQUEST-LEN - This field in-lic~tes the length of the mess~ge.
SENDREPLY- Used to send the Server's reply to the Client's message.
~ontains same parameters as REGISTER, plus the following:
WS-SENDREPLY-MSG - This field is the address of the reply being sent to the Client by the Server.
WS-SENDREPLY-LEN - This field inclic~tes the leng~ of the reply.
With contim~ reference to Fig. 2, a Client Application 202 initi~te,c a session by registering itself as a client with Registry 204. This is accomplished by issuing a REGISTER verb, which is read by the API 206. A Registry component identified as - the Verb Execution 208 is responsible for v~ tinl~; the parameters and processing 2 o each verb. When a REGISTER verb is received by the API 206, Verb Execution 208 CA 02237646 1998-0~-14 W O 97/194~1 PCTAUS96/18184 -' will create a Registration Control Area ~RCA) and send the RCA address back to the Client 202 via the API 206. This RCA is used to store and process all commllnications between the Client and Registry.
The Client Application 202 will then issue a SENDREQUEST verb to 5 Registry. This verb will comm~n-1 Registry to send the Client's request message, generated previously by the Client, to the Server 222. The actual request mess~ge will also be sent to Registry as a parameter of the SENDREQUEST verb. This message is in a forrnat defined by the specific Client Application 202 that generated it, and will remain unInodified by Registry 2~4. Registry will simply deliver it to the o Server 222.
Alternatively, the Client 202 may issue a CONVERSE verb, which establishes a two-way, conversational dialog with the Server 222. This is equivalent to issuing a SENDREQUEST and RECEIVEREPLY verb in combination. By issuing solely a SENDREQUEST verb, the Client 202 may establish either a conversational or a one-15 = way dialog with the Server 222, depending on the verb's parameters.
With con~imle~l reference to Fig. 2, the SENDREQUEST verb is received andrecognized by the API 206. Registry then initi~t~s the Verb Execution 208 process.
The Verb Execution 208 will validate the parameters of the verb. It also resolves the destination address. It reads, from the Client Application's message, the naIne of the Server Application 222 for which the ~lient's request is intended. It then queries a Directory Services database 210 to determine the physical network destination for that Server Application 222. The Directory Services 210 containsphysical network routing codes for each client/server application on the network.
When a request or reply message is given to Registry to deliver to a specific application on the network, Registry determines where that application resides by translating its name to a physical network node via the Directory Services. In this way, when an application is migrated to another node on the network, only the CA 02237646 l998-0~-l4 Directory Services needs to be updated, as opposed to updating every clientlserver application.
In the preferred embodiment, the network destination of an application is represented by a three-part name, consisting of a Domain, a ServiceName, and a 5 ServiceQualifier. The Dornain refers to a distinct sub-network of the ellL~,~lise-wide net~,vork. The ServiceName refers to the function, rather than the physical location, of the destination node and is the fundamental identifier of the destination. The ServiceQualifier refers to a specific instance of the ServiceName function, in cases where there are more than one instance. An example would be specifying a 0 ServiceName function of geographical customer data into ServiceQualifiers of "l~ast"
and "West" .
With contimle-l reference to Fig. 2, the Verb Execution 208 launches execution of the SENDREQU~ST verb by issuing a Generalized IPC Request to a Generalized IPC Interface 212. IPC (Inter-Process Commlmications) refers to all components and processes between Registry at the Client end and Registry at the Server end. It includes Messaging Products 216, Data Networks 218, and anything that supports the commnnic~tions between the Client processes and the Server processes.
The Generalized IPC Interface 212 is the Registry component responsible for selecting the approL)liate IPC products for transporting the Client's mess~ge to the Server. The Generalized IPC Interface 212 contains a generalized view of all of the Mecs~gin~ 216 and Network 218 products available, and selects one for use in thecurrent session. It is also responsible for tr~n~l~tin~ the m~c~ge envelope (themessage itself remains unmodified) to the a~ro~liate format of the selected IPC
product. The Generalized IPC Request is a comm~n-l issued by Verb Execution 208 to the Generalized IPC Interface 212. It contains the Client's message, Server'snetwork address, and a request to send the message.
The Generalized IPC Interface 212 is shown in greater detail in Fig. 2a, which is a dataflow diagram illustrating the operation of the Interface 212. Referring to ~ig.
CA 02237646 1998-0~-14 2a, the Generalized IPC Interface is identified within the broken line. It consists of three prirnary logical components: a Generalized IPC Interface Request Processor230, an IPC Product Qualification 232, and an IPC Mess~in~ Interface 234. It also contains a database of Available Services Information 236, which may be a partitioned ~ e of the Directory Services 210, or a separate database.
The Generalized IPC Interface l~equest Processor 230 provides the formal and initial interface to the Verb Execution 208. It receives the Generalized IPC Request 240 and determines what services are required to process the request. It then compiles these services into a Required Services List 242, which it forwards to the 0 IPC Product Qualification 232. The Required Services List 242 is a set of data items, each item identifying a Registry-defined service that is needed to process the request.
Exarnples of such services are persistent queuing, message recovery, and time-out.
The IPC Product Qll~lific~tion component 232 determines which l!~les~z-ging Product 216 is to be used for transporting the Client's m~ss~pe over the Data 15 Net~,vork 218. This determination is based on two inputs: the Required Services List 242 from the Request Processor 230, and a list of Available IPC Products 244 from the Available Services Information ~i~t~b~e 236. The Available Services Information database 236, which resides with Directory Services 210 in the preferred embodiment of Registry, contains preprogrammed lists of all available IPC products (which 20 includes Me.~s~in~. Products 21L6 and Data Network 218 protocols) and their requirements. Based on the services required 242 for the particular request, and the Available IPC Products 244, the IPC Product Qualification component 232 selects the appropriate IPC Product 216 to use. It then sends the identification of this Selected IPC Product 246 to the IPC Me~s~ginp; Interface 234.
The IPC Mess~ging Interface 234 provides Registry's interface to the selected IPC products, including the selected Me~sz~ing Product 216. As previously noted,IPC refers to all components needed to transport the mess7~f~e from the Client'sRegistry to the Server's Registry; this includes primarily industry-standard Mecs~gin~
W O 97/19411 PCT~US96/18184 Products 216 and Data Network products 218. It tr~n.~l~tes the Generalized IPC
Request 240 to a format defined and required by the selected Mess~in~; Product 216.
It also initiates the dialog with the Mes.s~gin~ Product 216. When the Generalized IPC Request 240 (which contains the Client's native request mess~ge) is tr~n~l~t~d 5 to the proper Mess~ging Product 216 format, it is passed to the Mess~in~ Product 216 for transport over the Data Network 218 to a distant Server 222.
Referring back to Fig. 2, at the Server end, the Me~ging Product 216 receives the message from the Network 218, and delivers the message 224 to Registry 204 via the Generalized IPC Interface 212. This delivery of the m~sc~ge 224 0 to Registry 204, along wit'n the entire process conducted by Registry at the Server end, is controlled by a Registry component identified as a Registry Process Monitor 220. The Registry Process Monitor 220 controls the Server's 222 receiving and processing of messages. It's objectives are to maximize Server throughput of .essages, E~.~na~e the ~irgd rumbg~ o~ ~e~r ~ o p~cess w~r~loads, contr{31 server capacity and lltili7~tion by termin:~ting/ reactivating Server tasks as workload demands change, and to provide application-defined mech~ni~m~ for controlling server resource allocation.
Referring to Fig. 2b, the Registry Process Monitor (RPM) 220 is shown in greater detail to illustrate its operation. The RPM consists of tnree primary 20 components: a Queue Monitor (QM) 260, a Process Monitor (PM) 262, and a Control Monitor (CM) 264.
As Server-bound messages are retrieved from the Network 218 by the Messaging Products 216, they are held in queues pending retrieval by Regisky 204.
Each queue is assigned a class of service to indicate its priority. Each QM 260 is assigned to a queue or a range of queues, and therefore to a class of service or range of classes. The QM 260 monitors these queues by receiving queue status data 226 from the Mess~ging Products 216. By tracking which messages are released for Server processing, the QM 260 knows the Server's ~;ullellL level of ntili7~tion and its CA 02237646 1998-0~-14 capacity for h~nr11ing additional mess~es. When the QM 260 determines the Serverhas sufficient resource capacity for h~n~1lin~ additional messages, the QM 260 selects a message from a specific queue for subsequent proce~ing. It then sends to the PM
262 requirements 270 for a Server thread n~e-lecl to retrieve the message. This Server thread 276 represents a processing link between the operating system of the Server 222 and Registry 204. It will be used by the Server Application 222 to request and receive the Client's message.
The PM 262 will send a request 272 to the Server 222 to setup a thread by registering itself with Registry. The Server 222 will then issue a REGISTER verb to 0 Registry. This establishes a session between the Server 222 and Registry 204,identical to the manner in which the Client 202 has done. The Server 222 then issues a RECEIVEREQUEST verb, which allows it to receive the Client's request message via the Server Thread 276.
The RECEIVEREQUEST verb is received by the API 206 and passed to Verb 15 Execution 208 for processin~. Verb Execution 208 validates the parameters. From the WS-REQUEST-MS~ parameter, Registry knows where the message is and can retrieve it via the Generalized IPC Interface 212. The IPC Interface 212 retrieves the message 224 and extracts the Client's native request m~ss~e from it. This Client's request message is then passed to the Server 222 for application-specific proces~in~.
The CM 264 serves a utility function, providing systems management and con~lguration for Registry. It provides a Graphical User Interface (GUI) 266 to a systems operator to allow an operator to perform system ~-1mini~tration functions. It also allows the operator to modify the domain o~ queues managed by each QM 260.
Referring back to Fig. 2, after processing the Client's request message, and 2 5 = if a reply is required, the Server 222 issues a SENDREPLY verb. This verb contains the Server's reply message as a parameter, which is identified as WS-SENDREPLY-MSG. This verb is processed similar to how the SENDREQUEST verb was processed previously.
CA 02237646 1998-0~-14 Referring to Fig. 3a, a process flowchart illustrates the operation of Registry when a Client Application issues a SENDREQUEST verb to send a mloss~ge to a Server Application. A similar operation would be conducted if a CONVERSE verb was issued.
In step 302, ~e Client Application 202 initi~teS a request for a Server Application 222 to process. This request must be delivered to the Server Application 222, which resides on a distant machine. In step 302, the request is thus far cont~in~rl within the Client Application 202.
In step 304, the Client 202 issues a REGISTER verb to Registry 204. The 0 REGISTER verb is the comm~nl1 that establishes a co~ ications session between the Client 202 and Registry 204. In step 306, the Verb Execution component 208 of Registry 204 v~ tes the parameters of the REGISTER verb. Then in step 308, Verb Execution 208 builds a Registration Control Area (RCA), which is a memory allocation used for passing verb parameters (including the Client's message) between the Client 202 and Registry 204.
In step 310, the Client 202 issues a SENDREQUEST verb to Registry 204.
The Client 202 sends its request message as a parameter of the SENDREQUEST
verb. In step 312, the Verb Execution component 208 of Registry 204 v~licl~tes the parameters of the SENDREQUEST verb. Then in step 314, Verb Execution 208 determines the physical network routing address of the intended Server Application 222. This is done by extracting the Server Applicatiorl name from the Client's mes.~ge and tr~n~l~ting that name to a network destination via a query to the Directory Services 210. The Directory Services 210 will return a network destination in the form of a Domain, a ServiceName, and a ServiceQualifier, as specified previously in reference to Fig. 2.
In step 316, the Verb Execution component 208 performs its final function on - the SENDREQUEST verb by issuing a Generalized IPC Request to the Generalized IPC Interface 212. The Generalized IPC Reguest is a comm~n~l that instructs the T-PC
CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 Interface 212 to perform certain functions n~e~le~ to deliver the Client's message.
These functions are specified in steps 318 through 324. The Generalized IPC Request also contains the Client's message and the Server's network address. The issuance of the Generalized IPC Request is depicted in Fig. 2a as item 240.
With contimle~ lefe~ ce to Fig. 3a, in step 318, the Generalized IPC Interface Request Processor 230 compiles a list of services that are required to process the Generalized IPC Request. These re~uired services will be performed by the Mess~gin~ Product 216. The Required Services List 242 that is generated is used by the IPC Product Qualification component 232 in step 320 to select an IPC product.
0 The IPC Product Qualification 232 also receives a list of Available IPC: Products 244 from the Available Services Information ~l~t~b~e 236.
In step 320, the IPC Product Qualification 232 matches the required services from the Required Services List 242 to those offered from certain IPC products identified in the Available IPC Products list 244, and selects the a~pl-o~liate IPC
15 product. The selected IPC product will be a Mess~ging Product 216 and/or a Data Network 218 transport protocol. Identification of the selected IPC product is then sent to the IPC Me~s~ging Interface component 234.
In step 322, the IPC Mess~ging Interface component 234 formats the Generalized IPC Request (which it has received from Verb Execution 208 as depicted 20 in Fig. 2a) into a message that is proprietary to the selected IPC product. The procedures for this translation of formats have been programmed into the IPC
Mess~ginp Interface component 234. Then, in step 324, the Interface 234 establishes a commllnications session with the selected Mess~gin~ Product 216 in a manner that is standard for that Messaging Product. Once the session is established, the message 25 is passed to the Mess~gins~ Product, which proceeds to deliver the message over the Data Network 218. Note, the "message" referred to here consists of the Client's native re(luest message packaged in an envelope that Registry has formatted specifically for the selected IP~ Products.
CA 02237646 1998-0~-14 Step 326 represents the transport of the message over the Data Network 218 in a manner that is standard for the particular network protocol that is in use.In step 328, Registry at the Server site is prepared to receive the mes~ e. The Queue Monitor (QM) component 260 of the Registry Process Monitor Z20 monitors 5 the message in a certain queue. It does this by receiving ~ueue status data 226 from each of the connected Mess~in~ Products 216. The QM 260 also tracks Server resource capacity by being programmed with initial Server capacity and tracking each message that is sent to the Server. In this way, the QM 260 knows the ~;u~ L Server ili7~tion and its capacity for processing additional messages. As part of step 328, 0 the QM 260 assesses the ~;ullenL capacity of the Server and determines when the next message may be retrieved.
In step 330, the QM 260 deterrnines that the next message is to be retrieved and issues requirements for a Server thread 276. As mentioned previously, this Server thread 276 represents a processing link between the operating system of the 15 Server 222 and Registry 204. It will be used by the Server Application 222 to request and receive the message. The Server thread requirements are issued by the QM 260to the Process Monitor (PM) 262.
In step 332, the PM 262 issues a request for a Server thread to the operating system of the Server. This serves as a trigger for the Server Application 222 to20 establish a session with Registry 204. This is done by issuing a REGISTER verb, as was done previously by the Client 202.
In step 334, the Server 222 issues the REGISTl~R verb, which is read by Registry's API 206 and passed to Verb Execution 208. This establishes the Server's session with Registry. The process continues at the off-page connector A in Fig. 3b.
Referring now to Fig. 3b, in step 336, Verb Execution 208 processes the Server's REGISTER verb as it did with the Client's. It builds the RCA that is ~ specific to the current session. Then, in step 338, the Server 222 issues a CA 02237646 1998-0~-14 W O 97/19411 PCT~US96/18184 RECEIVEREQUEST verb to Registry. The RECEIVEREQUEST verb instructs Registry to send the Client's message to the Server 222.
In step 340, Verb Execution 208 validates the parameters of the RECEIVEREQUEST verb. One of these parameters will be populated with the 5 _ address in memory of the Client's request mess~e. In step 342, Verb Execution 208 extracts the Client's native request message from the packaged message that was delivered over the Network 218, and passes this request message to the Server 222.
In step 344, the Server 222 processes the Client's request message in a manner that is specific to the application and independent of Registry. A Server reply to the Client request may or may not be re~uired, as determined in step 346. If a reply is required, the Server 222 issues a SENDREPI_Y verb in step 348, which is processed in the same manner as a Client's SENDREQUEST verb, beginnin~ in step 310. The Server's reply is then delivered to the Client, as indicated in step 350. The Server 222 then proceeds to issue another RECEIVEREQUEST verb in step 352.
If a reply is not required, as determined in step 346, the Server 222 issues another RECEIVEREQUEST verb in step 352. If no more request mess~es are in queue for the Server, a mess~ge stating "No More Messages" is returned to the Server 222 from Registry 204, as indicated in step 354. Then the process ends with step 356, in which the Server 222 issues a DEREGISTER verb. The DEREGISTER
verb instructs Registry to end the session.
If, in step 354, the "No More Messages" message is not returned, an assumption is made that more request mes~es are in queue. The process returns tostep 340, in which the Verb Execution 208 proceeds to process the RECEIVEREQUEST verb by V~ tin~ the parameters.
The specifications in the above description should not be construed as limit~3tions on the scope of the invention, but rather as specifications of the preferred embodiment. Other obvious variations and modifications are possible, and will occur to persons skilled in the art.
It should be understood that the invention is not limitefl to the exact details of construction shown and described herein for obvious modifications will occur to persons skilled in the art.
Claims (14)
1. A client-server computer system serving as a logical layer of communications between applications and transport mechanisms of a data network, and comprising:a plurality of client means, each capable of executing applications controlled by a different operating system;
first registry means connected to each client means for-(a) accepting application specific messages from the client means, destined for a preselected server means, and encapsulating them into a standard registry specific message; and (b) translating the registry specific messages into a preselected protocol;
a network for communicating the translated messages to a distant end;
second registry means located at the distant end for-(a) accepting the translated messages; and (b) converting the messages from protocol format to the original application specific message; and means connecting the registry means to the preselected server means for communicating the application specific message to the server means.
first registry means connected to each client means for-(a) accepting application specific messages from the client means, destined for a preselected server means, and encapsulating them into a standard registry specific message; and (b) translating the registry specific messages into a preselected protocol;
a network for communicating the translated messages to a distant end;
second registry means located at the distant end for-(a) accepting the translated messages; and (b) converting the messages from protocol format to the original application specific message; and means connecting the registry means to the preselected server means for communicating the application specific message to the server means.
2. The system set forth in claim 1 further comprising:
first messaging means connected between the first registry means and the network, for communicating, to the network, the registry specific messages in the preselected protocol; and second messaging means, connected between the network and the second registry means input for receiving registry specific messages in the preselectedprotocol and transferring them to the second registry.
first messaging means connected between the first registry means and the network, for communicating, to the network, the registry specific messages in the preselected protocol; and second messaging means, connected between the network and the second registry means input for receiving registry specific messages in the preselectedprotocol and transferring them to the second registry.
3. The system set forth in claim 1 wherein the first registry means further comprises an application programming interface, connected to an output of the client means, for receiving a verb command from the client means and translating a related application specific message from the client means to a corresponding registry format.
4. The system set forth in claim 3 wherein the first registry means further comprises:
means for validating parameters of the verb command and subsequently resolving a destination address for the message from the client means; and directory services database means queried by the validated verb command for determining a logical network destination to the server means for which the client's message is intended.
means for validating parameters of the verb command and subsequently resolving a destination address for the message from the client means; and directory services database means queried by the validated verb command for determining a logical network destination to the server means for which the client's message is intended.
5. The system set forth in claim 2 wherein the first registry means further comprises inter-process communication means for switching the message in registry format to one of a plurality of adapters connected in parallel to the output of the inter-process communication means, in response to destination information derived from the directory services database means, the adapter mapping the registry message into a specific protocol format required by a selected first messaging means anddestined for a server means.
6. The system set forth in claim 2 wherein the second registry means comprises:
a plurality of parallel connected adapters connected to the outputs of the second messaging means for translating the messages in the specific protocol to registry format;
inter-process communication means for selectively receiving translated messages from the adapters for further processing; and an application programming interface, connected to an output of the inter-process communication means for translating a message, in registry format, to a format required by a server application and connecting it to a designated server.
a plurality of parallel connected adapters connected to the outputs of the second messaging means for translating the messages in the specific protocol to registry format;
inter-process communication means for selectively receiving translated messages from the adapters for further processing; and an application programming interface, connected to an output of the inter-process communication means for translating a message, in registry format, to a format required by a server application and connecting it to a designated server.
7. The system set forth in claim 6 further comprising registry monitoring means,connected to an input of the application programming interface, for scheduling processing by a designated server.
8. The system set forth in claim 7 wherein the second registry means further comprises:
(a) means for validating parameters of the a verb command generated by the server, in response to an inquiry from the and subsequently resolving a destination address for the message from the client means; and (b) directory services database means queried by the verb validating command from the client means, for determining a logical network destination for a response, from the server means to a client means that generated an initial inquiry;
(c) the inter-process communication means in the second registry means selecting an adapter in the second registry means for communicating the response to an input of a selected second messaging means; and adapter means, located outside the second registry means, for connecting the messaging means to the network.
(a) means for validating parameters of the a verb command generated by the server, in response to an inquiry from the and subsequently resolving a destination address for the message from the client means; and (b) directory services database means queried by the verb validating command from the client means, for determining a logical network destination for a response, from the server means to a client means that generated an initial inquiry;
(c) the inter-process communication means in the second registry means selecting an adapter in the second registry means for communicating the response to an input of a selected second messaging means; and adapter means, located outside the second registry means, for connecting the messaging means to the network.
9. A client-server computer system serving as a logical layer of communications between applications and transport mechanisms of a data network, and comprising:a plurality of clients, each capable of initiating applications controlled by a corresponding operating system;
a first registry connected to each client for-(a) accepting application specific messages from a client, destined for a preselected server, and encapsulating them into a standard registry specific message;
and (b) translating the registry specific messages into a preselected protocol;
a network for communicating the translated messages to a distant end;
a first messaging device connected between the first registry and the network, for communicating, to the network, the registry specific messages in the preselected protocol;
a second registry located at the distant end for-(c) accepting the translated messages; and (d) converting the messages from protocol format to the original application specific message; and wherein the second registry is connected to the preselected server for communicating the application specific message to the server;
a second messaging device, connected between the network and the second registry input for receiving registry specific messages in the preselected protocol and transferring them to the second registry.
a first registry connected to each client for-(a) accepting application specific messages from a client, destined for a preselected server, and encapsulating them into a standard registry specific message;
and (b) translating the registry specific messages into a preselected protocol;
a network for communicating the translated messages to a distant end;
a first messaging device connected between the first registry and the network, for communicating, to the network, the registry specific messages in the preselected protocol;
a second registry located at the distant end for-(c) accepting the translated messages; and (d) converting the messages from protocol format to the original application specific message; and wherein the second registry is connected to the preselected server for communicating the application specific message to the server;
a second messaging device, connected between the network and the second registry input for receiving registry specific messages in the preselected protocol and transferring them to the second registry.
10. The system set forth in claim 9 wherein the first registry further comprises:
an application programming interface, connected to an output of the client, for receiving a verb command from the client and translating a related application specific message from the client to a corresponding registry format;
a validating device for validating parameters of the verb command and subsequently resolving a destination address for the message from the client;
a directory services database queried by the validated verb command for determining a logical network destination to the server for which the client's message is intended;
an inter-process communicator for switching the message in registry format to one of a plurality of adapters connected in parallel to the output of the inter-process communicator, in response to destination information derived from the directory services database, the adapter mapping the registry message into a specific protocol format required by a selected first messaging device and destined for aserver.
an application programming interface, connected to an output of the client, for receiving a verb command from the client and translating a related application specific message from the client to a corresponding registry format;
a validating device for validating parameters of the verb command and subsequently resolving a destination address for the message from the client;
a directory services database queried by the validated verb command for determining a logical network destination to the server for which the client's message is intended;
an inter-process communicator for switching the message in registry format to one of a plurality of adapters connected in parallel to the output of the inter-process communicator, in response to destination information derived from the directory services database, the adapter mapping the registry message into a specific protocol format required by a selected first messaging device and destined for aserver.
11. The system set forth in claim 9 wherein the second registry comprises:
a plurality of parallel connected adapters connected to the outputs of the second messaging device for translating the messages in the specific protocol to registry format;
inter-process communication for selectively receiving translated messages from the adapters for further processing; and an application programming interface, connected to an output of the inter-process communication for translating a message, in registry format, to a format required by a server application and connecting it to a designated server; and a registry monitor connected to an input of the application programming interface, for scheduling processing by a designated server;
a second validator for validating parameters of the a verb command generated by the server, in response to an inquiry from the and subsequently resolving a destination address for the message from the client;
a directory services database queried by the verb validating command from the client, for determining a logical network destination for a response, from the server to a client that generated an initial inquiry;
the inter-process communication in the second registry selecting an adapter in the second registry for communicating the response to an input of a selected second messaging device; and an adapter, located outside the second registry, for connecting the messaging device to the network.
a plurality of parallel connected adapters connected to the outputs of the second messaging device for translating the messages in the specific protocol to registry format;
inter-process communication for selectively receiving translated messages from the adapters for further processing; and an application programming interface, connected to an output of the inter-process communication for translating a message, in registry format, to a format required by a server application and connecting it to a designated server; and a registry monitor connected to an input of the application programming interface, for scheduling processing by a designated server;
a second validator for validating parameters of the a verb command generated by the server, in response to an inquiry from the and subsequently resolving a destination address for the message from the client;
a directory services database queried by the verb validating command from the client, for determining a logical network destination for a response, from the server to a client that generated an initial inquiry;
the inter-process communication in the second registry selecting an adapter in the second registry for communicating the response to an input of a selected second messaging device; and an adapter, located outside the second registry, for connecting the messaging device to the network.
12. In a computer system having a plurality of client and server machines selectively interconnected over a network, each capable of executing applications controlled by a different operating system, a logical layer of communications between the machines and comprising the steps:
performing a first registry process including-(a) accepting application specific messages from a client, destined for a preselected server, and encapsulating them into a standard registry specific message;
and (b) translating the registry specific messages into a preselected protocol;
subjecting the registry specific message to messaging for communicating, to the network, the registry specific messages in the preselected protocol;
performing a second registry process at a distant end including-(c) accepting the translated messages; and (d) converting the messages from protocol format to the original application specific format;
connecting the converted application specific message to the preselected server.
performing a first registry process including-(a) accepting application specific messages from a client, destined for a preselected server, and encapsulating them into a standard registry specific message;
and (b) translating the registry specific messages into a preselected protocol;
subjecting the registry specific message to messaging for communicating, to the network, the registry specific messages in the preselected protocol;
performing a second registry process at a distant end including-(c) accepting the translated messages; and (d) converting the messages from protocol format to the original application specific format;
connecting the converted application specific message to the preselected server.
13. The method set forth in claim 12 wherein the first registry process further comprises the steps:
application programming interfacing with the client, for receiving a verb command from the client and translating a related application specific message from the client to a corresponding registry format;
validating parameters of the verb command and subsequently resolving a destination address for the message from the client;
querying a directory services database by the validated verb command for determining a logical network destination to the server for which the client's message is intended;
inter-process communication switching of the message, in registry format, to one of a plurality of adapters in response to destination information derived from the directory services database, the adapter mapping the registry message into a specific protocol format required by a selected first messaging device and destined for aserver.
application programming interfacing with the client, for receiving a verb command from the client and translating a related application specific message from the client to a corresponding registry format;
validating parameters of the verb command and subsequently resolving a destination address for the message from the client;
querying a directory services database by the validated verb command for determining a logical network destination to the server for which the client's message is intended;
inter-process communication switching of the message, in registry format, to one of a plurality of adapters in response to destination information derived from the directory services database, the adapter mapping the registry message into a specific protocol format required by a selected first messaging device and destined for aserver.
14. The method set forth in claim 12 wherein the second registry process comprises the steps:
subjecting messages in the specific protocol to reversed adaptation thereby translating the messages into registry format;
inter-process communication switching for selectively receiving translated adapted messages for further processing;
application programming interfacing for translating a message, in registry format, to a format required by a server application and connecting it to a designated server; and monitoring the application programming interfacing, for scheduling processing by a designated server;
validating parameters of the a verb command generated by the server, in response to an inquiry from the client and subsequently resolving a destination address for the message from the client;
querying a directory services database by the verb validating command from the client, for determining a logical network destination for a response, from the server to the client that generated an initial inquiry;
communicating the response in the direction of the client for final delivery to the client that initiated the application.
subjecting messages in the specific protocol to reversed adaptation thereby translating the messages into registry format;
inter-process communication switching for selectively receiving translated adapted messages for further processing;
application programming interfacing for translating a message, in registry format, to a format required by a server application and connecting it to a designated server; and monitoring the application programming interfacing, for scheduling processing by a designated server;
validating parameters of the a verb command generated by the server, in response to an inquiry from the client and subsequently resolving a destination address for the message from the client;
querying a directory services database by the verb validating command from the client, for determining a logical network destination for a response, from the server to the client that generated an initial inquiry;
communicating the response in the direction of the client for final delivery to the client that initiated the application.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/560,550 US5790809A (en) | 1995-11-17 | 1995-11-17 | Registry communications middleware |
| US08/560,550 | 1995-11-17 | ||
| PCT/US1996/018184 WO1997019411A1 (en) | 1995-11-17 | 1996-11-15 | Registry communications middleware |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2237646A1 true CA2237646A1 (en) | 1997-05-29 |
Family
ID=29406077
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2237646 Abandoned CA2237646A1 (en) | 1995-11-17 | 1996-11-15 | Registry communications middleware |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2237646A1 (en) |
-
1996
- 1996-11-15 CA CA 2237646 patent/CA2237646A1/en not_active Abandoned
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5790809A (en) | Registry communications middleware | |
| US5546584A (en) | System and method for establishing communication protocols between application programs | |
| EP1025507B1 (en) | Combined internet and data access system | |
| US5021949A (en) | Method and apparatus for linking an SNA host to a remote SNA host over a packet switched communications network | |
| US5926636A (en) | Remote procedural call component management method for a heterogeneous computer network | |
| US7418708B2 (en) | JMS integration into an application server | |
| JPH11312153A (en) | Method and device for managing work load between object servers | |
| US9325768B2 (en) | System and method for clustered transactional interoperability of multiple messaging providers using a single connector mechanism | |
| GB2320594A (en) | Dispatching client method calls to parallel execution threads within a server | |
| US6442619B1 (en) | Software architecture for message processing in a distributed architecture computing system | |
| US20020147962A1 (en) | Method and system for incorporating legacy applications into a distributed data processing environment | |
| CN111708550A (en) | Application deployment method and device, computer equipment and storage medium | |
| US20020107977A1 (en) | Multi-server system dynamic re-configuration | |
| KR100683812B1 (en) | Inbound connector | |
| US20170286261A1 (en) | System and method for providing runtime tracing for a web-based client accessing a transactional middleware platform using an extension interface | |
| US9479599B2 (en) | Reroute of a web service in a web based application | |
| US20100107178A1 (en) | System and Method for Providing a Communications Service in Distributed Computing Environment | |
| CA2237646A1 (en) | Registry communications middleware | |
| CN112905273A (en) | Service calling method and device | |
| US6912714B1 (en) | Finding named collections via life cycle interfaces | |
| US6745249B1 (en) | Enabling life cycle semantics via naming interfaces | |
| MXPA98003869A (en) | Customized logical support of communications | |
| CN115913879A (en) | Information integration method and system based on distributed architecture | |
| US6823521B1 (en) | Apparatus and method for communicating between computer systems using active datastreams | |
| CN115801427A (en) | Method and device for logging in office automation system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |