Re: CA web service Re: iPhone port

[Ralph Lange <Ralph.Lange@bessy.de>]

Hello Kay,

On Wed 26 May 2010 11:14:06 Kasemir, Kay wrote:
> Hello:
>
> On 5/26/10 09:30 , "Pelaia II, Tom" <pelaiata@ornl.gov> 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