Fwd: EPICS communication paradigm

[renato sanhueza <renato.sanhueza@alumnos.usm.cl>]

---------- Forwarded message ----------
From: renato sanhueza <renato.sanhueza@alumnos.usm.cl>
Date: Mon, Nov 13, 2017 at 1:39 PM
Subject: Re: EPICS communication paradigm
To: Ralph Lange <ralph.lange@gmx.de>

Hi Ralph,

Mi final conclusions make more sense now thanks to you.

As you say the EPICS/CA protocol appears to be an original thing and it is also old. We can easily classify it under the Client-Server Paradigm (Channel Access clients and Channel Access servers communicate) which is also an old an "general" paradigm and the base of many others. 

This is further confirmed by the fact that EPICS V4 claims to provide a new protocol with RPC communication: 

• The Remote Procedure Call Paradigm has a lower level of abstraction than the Distributed Object Paradigm. Even tho it is feasible it makes little sense to me that a new version of any middleware will implement a  protocol with a lower level of abstraction.
• In the other hand the Remote Procedure Call Paradigm provides a higher level of abstraction than the "raw" Client-Server Paradigm so it makes sense that EPICS V4 implemented RPC.
  
  

Thanks for your time. I hope this discussion also contributed with a little theoretical information for the community :)

On Mon, Nov 13, 2017 at 12:15 PM, Ralph Lange <ralph.lange@gmx.de> wrote:

Hi Renato,

One reason making it hard to decide which of the common communication paradigms EPICS/CA are based on: EPICS/CA have been designed in the 80s, i.e. years before Distributed Objects (and their communication paradigms) were developed.

If you look at currently commonly used protocols, CA shares a number of properties with OPC UA, in that it offers:

• Discovery: work transparently across multiple servers on local PCs and/or networks
  
• Global address space: all data is found through its unique name
  
• On-demand: read and write data/information based on access-permissions
  
• Subscriptions: monitor data/information when values change

Hope this helps,

~Ralph

On Sun, Nov 12, 2017 at 1:17 AM, renato sanhueza <renato.sanhueza@alumnos.usm.cl> wrote:

Hiding things is a common feature associated to a high level of abstraction. Thanks again for your time Mark. I will continue reflecting about this topic with the information you gave me.

On Sat, Nov 11, 2017 at 8:36 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

I'm not a computer scientist by any means.  But I think it is fair to say that Channel Access operates at a fairly low level of abstraction.  It deliberately hides the "object" nature of EPICS records.  It only provides access to specific fields in those records.  So there is no capability of introspection of the record structure, etc.


There is a new EPICS protocol called pvAccess, commonly known as EPICS V4.  It provides a much higher level of abstraction, and is designed with middleware services as one of its target applications.  It allows the transmission of arbitrary structured data with full introspection.


Mark



________________________________
From: renato sanhueza <renato.sanhueza@alumnos.usm.cl>
Sent: Saturday, November 11, 2017 4:28 PM
To: Mark Rivers
Cc: tech-talk@aps.anl.gov
Subject: Re: EPICS communication paradigm

Hi Mark,

Thanks for your answer. You give a good summary of the whole communication process. I was asking about the communication paradigm as an attempt to determine in which level of abstraction EPICS works.

For example the Message Passing Paradigm is associated with the lowest level of abstraction in distributed inter-process communications. Message Systems Paradigm (aka Message Oriented Middleware) works in a higher level of abstraction than Message Passing, but lower than Distributed Object Paradigm.

EPICS use the Channel Access Protocol to communicate clients and servers, but I couldn't intuitively map this protocol to any of the "common" communication paradigms I know (besides the Distributed Objects Paradigm).

On Sat, Nov 11, 2017 at 6:59 PM, Mark Rivers <rivers@cars.uchicago.edu<mailto:rivers@cars.uchicago.edu>> wrote:
Hi Renato,


What you said is basically correct.   An EPICS control system typically consists of multiple channel access servers located on multiple computers.  There are also multiple channel access clients located on multiple computers.  The clients normally locate EPICS process variables (PVs) on the servers using a UDP broadcast with the PV name, and then connect to them with TCP.  They can then subscribe to callbacks from the servers whenever the PV changes (publish/subscribe model), and can write new values to the PVs.

I'm not sure if this answers your question?

Mark


________________________________
From: tech-talk-bounces@aps.anl.gov<mailto:tech-talk-bounces@aps.anl.gov> <tech-talk-bounces@aps.anl.gov<mailto:tech-talk-bounces@aps.anl.gov>> on behalf of renato sanhueza <renato.sanhueza@alumnos.usm.cl<mailto:renato.sanhueza@alumnos.usm.cl>>
Sent: Saturday, November 11, 2017 1:05 PM
To: tech-talk@aps.anl.gov<mailto:tech-talk@aps.anl.gov>

Subject: EPICS communication paradigm

Hi, I am learning about EPICS and I think I understand the basic concepts about it but I am still unable to determine in which communication paradigm is EPICS based on.

My best guess is that EPICS implements the Distributed Object Paradigm because Records are object distributed across different Channel Access Servers. Other technologies which implement this paradigm are CORBA and JavaRMI for example.

I would really appreciate if someone can point me in the right direction.

Thanks in advance
--
Renato Sanhueza Ulsen
Ing Civil Informática.



--
Renato Sanhueza Ulsen
Ing Civil Informática.

--

Renato Sanhueza Ulsen
Ing Civil Informática.

--

Renato Sanhueza Ulsen
Ing Civil Informática.

--

Renato Sanhueza Ulsen
Ing Civil Informática.