[evla-sw-discuss] Re: evla, corba, & aips++

[Boyd Waters]

On Jun 22, 2005, at 6:26 AM, Darrell Schiebel wrote:
>
> Thanks Boyd. I'll look into the pointers you give. It sounds  
> interesting. I don't know why the NRAO seems unable to develop  
> these sorts of tools/technology and deploy them on a larger scale  
> than a single project. If your communication system is uniform  
> enough, perhaps I can create a generator using ccmtools to tie our  
> components into your xml based ipc.
>


Darrell:

I should mention that the lightweight XML-IPC that is used so far has  
been considered peculiar to the EVLA monitor/control system; they  
cannot support CORBA on the embedded module interface boards (MIBs),  
but those MIBs are complete computers with embedded OS and C  
development environment, and they parse simple XML messages.

A messaging item which has yet to be fully realized is asynchronous  
messaging, although we are rather far along in that area, as well.  
EVLA monitor and control currently uses small XML datagrams via IP  
multicast: your process subscribes to the appropriate multicast  
domain to receive alarms and alerts in near-real time. Concerns about  
guaranteed delivery of messages -- as UDP does not guarantee  
delivery, contrast with TCP -- are dealt with by the simple,  
deterministic network topology of the (E)VLA. We generally don't have  
collisions or dropped packets. The alarms/alerts protocol has been  
tuned so that the system is robust in the event of dropped packets,  
while keeping to a minimum the number of messages required to signal  
an alert.

I have tried to find some time to experiment with BEEP, which is  
basically an extension of multicast to support guaranteed delivery;  
BEEP leverages the IETF "zero-configuration" infrastructure that grew  
out of (among other things) AppleTalk router setup protocol (that a  
number of my pals developed). On the Macintosh, BEEP used to be  
called Rendezvous and is now called Bonjour, and is used for dynamic  
resource discovery and ad-hoc, asynchronous message push. BEEP is  
interesting to EVLA M&C in that it keeps much of the network utility  
below the application layer and is a good match for the current  
multicast-based implementation: it may be that BEEP can be  
implemented on the network stack with minimal change to existing  
application code.

Another close fit to what EVLA M&C has developed is JXTA, which as I  
understand it is an XML serialization of the Java JINI system: JINI  
itself pretty much occupies the same network-ecological niche as  
Bonjour. JXTA has bindings for languages other than Java...  EVLA has  
so far viewed JXTA as relatively heavyweight compared to its current,  
in-house implementation.

EVLA M&C resource discovery is somewhat dynamic.  Top-down, there is  
a naming convention which maps the module of a particular antenna in  
the array to a host name in DNS. Bottom-up, there are configuration  
pins on the MIB chassis which tell a module what its MAC address  
should be, a BOOTP/NFS boot process that gives a MIB some  
configuration parameters, and a non-volatile memory on the MIB that  
maintains local configuration state. If you take a module out of an  
antenna and plug it into another, the control system will figure out  
what the MIB does, where it is, and what its name should be. (I could  
be a bit inaccurate about some of the details here.) I say "somewhat  
dynamic" because there is little run-time reconfiguration of MIBs,  
but that's a problem we don't need to solve.

It's important to repeat that everything that I've discussed with you  
so far applies to EVLA M&C, rather than EVLA-as-a-whole. We have  
assumed that we would work with whatever the ISD/CASA comes up with  
in their component re-implementation efforts, hoping that such would  
be significantly more simple than full-blown ACS.

The EVLA idea is peer-to-peer XML over HTTP with minimal centralized  
control. For example, as yet there is no concept of booting up the  
array. Perhaps the Executor is a central point of control, as  
Executor will run a script on a central-control computer that  
dispatches commands to available antennas. But the array can be said  
to exist without the Executor. I think.

I believe that it would be rather straightforward to wrap CORBA  
components so that they catch and throw the appropriate XML messages.



> On Jun 22, 2005, at 12:56 AM, Boyd Waters wrote:
>
>
>> Darrell:
>>
>> Thanks for asking!
>>
>> The short answer is, EVLA is rather loosely-coupled as far as  
>> distributed objects go; so far, we have used (very) simple XML  
>> messages over HTTP, without any particular framework (although  
>> they have developed some simple libraries).
>>
>> For more tightly-distributed things, so far the only tightly- 
>> coupled distributed processing has been on the correlator backend,  
>> and Tom is using sort-of-Grid-computing Linux cluster for that  
>> (he's using PVM instead of MPI, as PVM has some better management  
>> tools).
>>
>> We have discussed the deployment of AIPS++/casa on that Linux  
>> cluster, or perhaps on one node of that cluster: we understand  
>> that we will need to implement the data formatter, the thing that  
>> builds the SDM, in very close proximity to the correlator backend.
>>
>> EVLA has - to date - been very CORBA-averse. The XML over HTTP has  
>> worked so far. EVLA-the-people understand that we plan to leverage  
>> any work done by the ISD on pipeline implementations. We have had  
>> a difficult time extracting any ALMA tools from the ACS  
>> infrastructure.
>>
>> The most recent attempt to co-develop anything with ALMA was work  
>> with Jeff Kern to deploy the (Goddard?) CALC stuff as an ACS  
>> component or as a server for EVLA's Executor.
>>
>> Getting back to AIPS++ -- EVLA has a very strong preference for  
>> something more simple than CORBA. ICE is close. I don't recall  
>> looking at ccmtools, I'll look into it.
>>
>> Mostly we just want a language-neutral, asynchronous XML message  
>> over HTTP; the higher-level handshaking tries to follow the REST  
>> architecture of distributed Web services, without WSDL overhead of  
>> SOAP or early-binding of XML-RPC.
>>
>> See also
>> http://www.nrao.edu/evla/techdocs/computer/workdocs/do_comm_rpt.pdf
>> http://www.nrao.edu/~tromero/EVLAPRBK/chap9/chap9.pdf
>>
>>
>>
>> On Jun 21, 2005, at 8:50 PM, Darrell Schiebel wrote:
>>
>>
>>
>>>
>>> Hi Boyd,
>>>
>>> You're the only one I know on the evla project, so I send these  
>>> questions to you. For the science component of the evla project  
>>> (which uses aips++... er... casa), is there a requirement that it  
>>> be distributed, i.e. with cooperating pieces running on different  
>>> machines? What do you plan to use for communication, CORBA, ICE,  
>>> something else?
>>>
>>> Thanks for any info. I'm trying to push ccmtools (http:// 
>>> ccmtools.sourceforge.net/) which is a pretty minimal set of java  
>>> tools to generate harnesses to allow components to be used in a  
>>> number of settings (e.g. local within a C++ application (no  
>>> corba), local within python (no corba), or distributed (with MICO)).
>>>
>>> Darrell
>>>
>>>
>>>
>>
>>
>