RE: PV Mapping Using Java Annotations

["Carcassi, Gabriele" <carcassi@bnl.gov>]

Hi Mitch,

You may want to have a look at the work that Simon Ebner presented last
spring:
http://www-arch.iter.org/sites/epics2010/slides/3-Wednesday/AM11-JCA_Ext
ensions.ppt
which I believe goes along the direction that you were describing.

In the area of things on top of JCA/CAJ, you may also want to look at my
work on PVManager which also addresses data rate decoupling and thread
local objects (which is always the case for UIs):
http://pvmanager.sourceforge.net/
Composing objects declaratively is what PVManager is about, and creating
an aggregation operation based on annotations is something that would be
easy to add.

The main problem that I think you'll have with simple pojos is that
get/set are synched operations, while with CA one should really be using
asynch operations. For read what you need is really a machinery that
gives you notifications with a new updated copy. You may use a
PropertyChangeListener to keep to the javabean spec, and be clear on the
thread safety of it all. But the locking policies might be an issue...

Writes, instead, are much more of a problem... I don't think there is
any way you can get support asynch writes within the javabean specs.

Gabriele


-----Original Message-----
From: tech-talk-bounces@aps.anl.gov
[mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Mitch McCuiston
Sent: Monday, January 10, 2011 7:13 PM
To: tech-talk@aps.anl.gov
Subject: PV Mapping Using Java Annotations


  I've been thinking about implementing an annotation based mapping of
Java objects to PVs.  I thought I would ask the community if something
like this already exists before I take it on.  If it doesn't exist,
would anyone find value in this.  The idea is loosely based on how
Hibernate maps Java objects to a relational database, although the
read/write semantics are a little different.  Here is an example.

######################################################
public class EpicsMotor{

     //This will peform a synchronous GET of PV "DLLM" upon invocation
     @PV(name="DLLM", accessType=PVAccessType.READ)
     public double getLowerLimit(){
     ...

     //This will establish a PV monitor for "DRBV" that will call the
method
     //below upon any change in "DRBV"
     @PV(name="DRBV", accessType=PVAccessType.MONITOR)
     public void setDialPosition(double position){
     ...

     //Any call to this method will result in a synchronous PUT
     //to the PV named "S".
     @PV(name="S", accessType=PVAccessType.WRITE)
     public void setSpeed(double position){
     ...

     //This will create a monitor for PV named "RBV" that will call this
method
     //upon any change in "RBV".  In addition, any invocations of this
method will
     //be intercepted and a synchronous PUT to PV "RBV" will occur.
     @PV(name="RBV", accessType=PVAccessType.MONITOR_WRITE)
     public void setPosition(double position){
     ...

}
#######################################################

This would allow someone to instrument an instance of the class above at

runtime and "connect" it to a set of PVs (given a prefix i.e. 
"xxx:motor1.").  I feel that this would have the following advantages 
over writing raw JCA/CAJ.

1.  This could increase read performance because the POJO essentially 
becomes a PV cache.
2.  This cuts down dramatically on the amount of channel managment code 
that needs writing.
3.  The little bit of channel management code that is written is 
centralized and can be better tested.
4.  This provides a nice way of abstracting a collection of PVs for 
easier application development.


Thanks in advance for your help!

Mitch McCuiston
mmccuiston@aps.anl.gov