When the application to be integrated does not have a user interface but provides a cal. lable inter face, integration is best accomp lished by creating an appli cation server. Considered a fo rm of encap sulation, an appl ication se rver provides a consis tent program m i ng i n terface to the ap pl ication . An appl ication server provides jacket routines that use the appl ication's call able i nterface, hiding the actu a l details of t h is i n terface. This tech n ique is a lso used to create appl ications that have a clean separa tion of presentation and functions.
Appl ications that i mplement persistent data stores, such as databases, code managers, a nd repositories, are prime candidates for this sty le of in tegration. By using an appl ication server to access persistent data stores, a requesting appli cation need not know how the data store is
Application Control
implemented and which implementation is to be used. This technique promotes the reuse of existing functions contained in the environment regard less of the actual implementation of the function. Digital's Code Management System (DEC/CMS) and COD/Repository software are examples of appl ica tions that have been in tegrated using the appl i cation server technique. Figure 7 i l lustrates the typical structure of the various components invol.ved in this style of i ntegratio n.
As shown i n Figure 7, the integration process involves the fol lowing steps. ( 1 ) An invoke from the client application of the message " H.escrve" on the object "foo.c" goes through the resolution code and (2) out the transport to the server application. This may result i n starting the server appl ication, if no server was available to service the request. ()) The server application's main routine cal. l s the eve nt d ispatcher and waits for work to arrive, when the server is started. (4) When the "Reserve" message arrives on the transport, the transport notifies the server application , (5) causing the event dispatcher to dispatch the " Reserve" message by cal l ing the method d ispatcher routine. (6) The methou u is patcher routine calls the appropriate method inter face rou tine. (7) The method interface routine does any work requi red to cal l the appropriate callable interface routine. (8) When the cal lable interface routine returns control to the method in terface rou tine, the rou tine can perform any work neces sary before (9) returning control to the method d ispatcher routine .
(10)
The method d ispatcher rou tine then puts any arguments to be returned inAPPLICATION PROCESS
CLIENT APPLICATION
DATA TYPE/LIST CALLS ACAS_InvokeMethod(Reserve, foo c) ( 1 )
RESOLUTION CODE DATA TYPE/LIST CODE
(2)
TRANSPORT
the proper format and sends this information to the transpo rt, which actua l ly sends the information back to the cJ ient application.
Using the DEC/CMS application server as an exam ple, the software developer must create a main rou tine to
(I)
pert<>rm any setup requ ired to use the callable interface and (2) register the existence of the server with ACA Services. Registration includes specifying the method dispatcher routine, which is generated by ACA Services, so that the appropriate method routine will be d ispatched for the message received.A method routine exists for each operation that the server is capable of performing. The set of method routines is analogous to the operating sys tem script for compilation used to explain applica tion encapsulation later i n this section. Because the DEC/CMS application server is not an operating sys
tem script, message arguments are passed into the method rou tine directly. As mentioned earlier in t he section CASE Integration in Object-oriented Terms, the object on which the current operation is to be performed is available to the method rou tine through the use of the invocation context struc ture. Information about the object, such as its class, name, and generation, can be obtained by calling the ACAS_ParselnstanceHaml le routine. The class of the object can tben be used to determine if the object is an element u nder version control, a collec tion, or a group.
The name of the object and its generation are contained in the reference data field of the instance hand le that represents the object. Because each
SERVER PROCESS APPLICATION SERVER
MAIN ROUTING I N ITIALI ZATION CODE EVENT DI SPATC H E R
(4)
(5) TRANSPORT METHOD D I SPATC H E R(9)
METHOD INTERFACE (7) (Bl CALLABLE INTERFACEFigure 7 Block Diagram of a Code Management ,\j>stenz Application Server
different code management system has its own representation of generation, it was necessary to create a canonical format to represent all imple mentations. Therefore, the method must convert the canonical generation representation to a format that is native to the implementation, Le., DEC/CMS
specific In addition, any method that returns a ref erence to a versioned object must convert the native generation representation to its canonical format. Table 1 shows how an object reference can be mapped between its canonical and D EC/CMS
specific tormats.
Once the necessary information about the object has been retrieved and converted to a format native to the implementation, the method can cal l to the appropriate cal lable interface routine, possibly based on the object's data class. Once the cal l com pletes, the method must convert any objects to be
returned into a canonical format, at which point the method can return the status of the operation and output arguments.