EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CA web service Re: iPhone port
From: Ralph Lange <[email protected]>
To: "Kasemir, Kay" <[email protected]>
Cc: ³EPICS Tech-talk³ <[email protected]>
Date: Thu, 27 May 2010 09:39:28 -0400
Hello Kay,

On Wed 26 May 2010 11:14:06 Kasemir, Kay wrote:
Hello:

On 5/26/10 09:30 , "Pelaia II, Tom" <[email protected]> wrote:
... I want to abstract the CA source so it can be from a plugin or a web
service. In either case, it will get data packaged in JSON. This should work
fine for any modern browser ...

I think that is a web service is a great idea. Not for the highest performance needs, but for the other 98% of the use cases.

Does anybody have a good Channel Access web service?

We've developed the very basics of one for a general status web page that
uses JSP. It's similar to something that Matthias Clausen described to me at
EclipseCon 2010:

A PV pool subscribes to Channel Access, so the client code always gets the
"latest" value right away.
PVs are added to the pool on first access.

[...]

.. except that would need a lot more though to prevent an explosion of the
PV pool:

Who's allowed to call the service?

Should any requested PV that's not in the pool be added to the pool, or is
that limited to some PVs requested from a certain number of hosts/users?

How long should PVs stay in the pool when nobody asks for them any more?

Please do not reimplement the Channel Access Gateway.


Keep it simple instead, and use the existing tool:

Start a CA Gateway on the web server host, pointing its server side to localhost (the loop back interface).

Make the web service's CAJ use localhost as its CA_ADDRESS_LIST.

Make the web service a simple CAJ based client: any HTTP GET request does a separate CA get. That's it.

The CA Gateway will do all the caching, persistence, auto-disconnect, auto-reconnect. Fast, stable, and reliable. It handles heavy-load situations, protects your IOCs. That's what the Gateway was made for.

The loop back interface usually does not have bandwidth issues - the additional latency will be acceptable compared to the HTTP side plus the "real" CA to the IOCs.

If you enable authentication in your web container and make CAJ create a new connection using the security principal's name, the Gateway's Access Security layer will allow you to fine-tune who is able to see what.

If you enable authorization in your web container, you can even start experimenting with doing PUTs through the web service (uahhhh - possible security nightmare).

If you want some of the GETs to go through to the IOCs, you can start another Gateway with the nocache option on a different port, configure it to prefix its channels, and add that prefix in your web service if the client request signals that type of operation and is authorized to do so.

There's even more light on the horizon:
Once Cosylab got funding for their current project to reimplement the CA Gateway in Java, you will be able to plug your web service directly onto the Gateway and get rid of the additional ca-over-loopback layer. (Or you could have Cosylab do this for you.)


In principle it would be easy to turn that into a web service that can be
used by any other web page, Javascript, web client, somewhat like this:

http://your.site/livedata/get?name=SomePVName
Get current value with time, status, units as string for display to user.

http://your.site/livedata/get?name=SomePVName&format=value
Get only the value, no time stamp etc.

http://your.site/livedata/get?name=SomePVName&format=json
Get current value with meta data in JSON notation.

To keep the service stupid and simple, I would opt for always sending over the value and the small set of metadata as XML - not much overhead, and the client is always free to not use it.


I would also rather use HTTP request types and headers instead of arguments:

http://your.site/livedata/SomePVName GET
"accept: application/xml" or "accept: application/json" to specify data format


http://your.site/livedata/SomePVName PUT (if you dare)
"content-type: application/xml" or "content-type: application/json" to specify data format


But that might be a matter of style preference. (Although it avoids redundancies in the request and inconsistent situations where e.g. the header would request XML while the parameter specifies JSON.)

Cheers,
Ralph


References:
CA web service Re: iPhone port Kasemir, Kay

Navigate by Date:
Prev: Re: Epics 3.14.8: faulty registrar statement in dbd causes memPartAlloc error on vxWorks Andrew Johnson
Next: RE: a waveform record question Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: CA web service Re: iPhone port Matthias Clausen
Next: Re: iPhone port Robert Soliday
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·