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. This page goes through the steps for creating the new server called DpRdb (the Aida server for accessing a relational db).
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/dpRdb.idl sed -e 's/THIS/dpRdb/g' .... ...
Ok, now you're ready to start writing code! Write your implementation file. Our standard, and the makefiles assume, this will be named Dp<name>I_impl.java, eg DpRdbI_impl.java. You can ask the Aida makefile system to create a skeleton for you, or maybe you want to start by cloning an existing one:
Either ask Aida to make an implementation skeleton for you: $ gmake -f Makefile.sun4 impl Or, clone one: $ cp ../dpCa/DpCaI_impl.java DpRdbI_impl.java Then edit it, - change in particular the get() method $ emacs DpRdbI_impl.java
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 port number (defined in the line ooc.orb.oa.endpoint=iiop --port" must be unique on the host (and in fact, in case we change hosts, should at least be unique across all AIDA hosts). So, grep all the .conf files, adn pick an unused port num. By convention, the DPs are counting down from 58999. The .conf file name must be identical to the server name define by AIDA__NAME, since it's found automagically by the st. startup file (see below).
copy DpCaServer.conf DpRdbServer.conf <edit the file and choose a unique port number, from all the unix DPs>
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 st. files for each unix server. Clone one.
cp st.DpCaServer st.DpRdbServer
Run the test server from you own account, from the host on which it will run. See the New Labour Development Cheatsheet. In particular, not that aidarun and aidaproc aliases search for Orbacus .conf files in /afs/slac/g/cd/soft/dev/confsys, so you will have to modify the alias you use or not use an alias before you release the conf file.
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.