Experimental Physics and
| |||||||||||||||||
|
On Wed 26 May 2010 11:14:06 Kasemir, Kay wrote: Hello: 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: 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
| ||||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |