This wiki page describes how to create a new unix hosted AIDA Data Provider.
To create a new data provider on unix, we begin on an AFS unix node and use facilities in the Aida makefile system for creating the CORBA stubs and skeletons of a new Aida server:
First, create a development directory on AFS unix, and cvs checkout aida:
$ mkdir work2 $ cd work2 $ cvs co package/aida cvs checkout: Updating package/aida U package/aida/.classpath....
Source the Aida development setup files. Note the 2nd argument to aidaSetEnvDev.csh is the directory of your development instance of aida (what you created in the previous step):
$ source /afs/slac/g/cd/soft/dev/script/ENVS.csh
$ source /afs/slac/g/cd/soft/dev/script/aidaSetEnvDev.csh dev ${HOME}/work2/package/aida
cd to the dp directory
$ cd package/aida/edu/stanford/slac/aida/dp/
Create a new Data Provider (dp) directory. Then copy an existing Makefile.sun4 from one of the existing Data Provider directories, on which we'll base this new one.
$ mkdir dpSlcBpm $ cd dpSlcBpm/ $ cp ../dpSlcModel/Makefile.sun4 .
Modify the Makefile.sun4 file, replacing the PACKAGE, MODULE and INTERFACENAME values with values appropriate for your new data provider.
$ emacs Makefile.sun4 <edit PACKAGE, MODULE and INTERFACENAME>
Clone a CORBA java server entry point, from one of the other AIDA data providers:
$ sed 's/Ca/Rdb/g' < ../dpCa/DpCaServer.java > DpRdbServer.java
Run the Makefile.sun4; this will create all client and server sides, except the _impl.java file. You will create an _impl.java file by hand later.Ignore the jidl complaint about not finding an idl file, it's not supposed to.
$ gmake -f Makefile.sun4 jidl: couldn't open /u/cd/xxx/work2/package/aida/idl/dpSlcBpm.idl sed -e 's/THIS/dpRdb/g' .... ...
Add the server to the list of Aida servers. This list is part of the Aida directory service Oracle database. See the Aida Directory Database Guide for details, off the Aida homepage. See the Aida SQL Cheatsheet, Adding a new Data Provider.
SQL> @/afs/slac/g/cd/soft/ref/package/aida/common/script/add_service 'SLCBpm' 'SLC BPM orbit acquisition'
Add instances and their attributes for testing. Here's a single example that may be one of thousands when it comes to deploying your server:
SQL> @/afs/slac/g/cd/soft/ref/package/aida/common/script/add_IA 103 'P2BPMLER' 'BPMS'
Clone a server config file, that defines on which port this server will run. The config filename must be the same as the servername (see the java command line in the START<dpname>.COM file (see below)).
copy ref_aidashr:dpslcmodel.conf dpslcbpm.conf <edit the file and choose a unique port number>
Run the server. The java command to run an AIDA server takes several arguments, to pass the values of
environment variables to the server at startup, so we have little .com files for each server. To override the default classpath (JAVA$CLASSPATH) which points to the aida.jar in slcimage, and the default AIDASHR (in SLCSHR), redefine the logicals before running the START<dpname>.COM file:
MCCDEV> define myjava$classpath [------] MCCDEV> testshrx/define/default aidashr MCCDEV> @startdpslcbpm
Release
Release is described in "release" section of the SLC Peer Programmers Guide
When development is complete on VMS side
When you're done, you can cvs release the unix side aida checkout. Note that you do not need to checkin any of the CORBA stubs and skeletons you created for the VMS server. The client side of aida sees the VMS server simply as an "aidaObject", it does not know it is specifically talking to a dpSlcMagnet server object, so there is no need to keep any of the files for a VMS server on the unix side.