Emulation of VistA's RPCs: Go, Rust

169 views
Skip to first unread message

rrichards

unread,
Oct 18, 2020, 8:56:12 AM10/18/20
to Hardhats
Up to this point (for the past 20+ years)  every effort in "modernizing"  VistA's interface for remote clients has been through encapsulation of the RPCs with some other technology or language.  (wrappers include python,  Javascript, and C#). 

Encapsulation, however, makes the existing code opaque, trapping in a black box, preventing any further evolution.

An alternative approach is emulation. This preserves all the business logic in a modern, maintainable language, and allows code maintenance to be broadened to a mainstream audience.

In the Vista data project we demonstrated that  RPCs could be emulated in Javascript.  Of the 1050 RPCs that comprise CPRS, we emulated 150 (15%):


The performance of M emulation in Javascript is variable, with a range of +/-  10X  faster or slower, depending on the RPC. 

However, there are much probably better languages than Javascript for back-end server-side systems programming, such as  the open-source Go (supported by Google) and Rust (supported by the Mozilla Foundation).  
These languages are fully supported by YottaDB:

Would anyone be interested in demonstrating emulation of a few RPCs using Go or Rust?  It would be very useful to benchmark against native MUMPS, and could be a path forward for further development. 

It most certainly would make VistA's RPC interface modern, maintainable,  mainstream, and allow it to continue to evolve.

Rafael

Nancy Anthracite

unread,
Oct 18, 2020, 9:02:03 AM10/18/20
to hard...@googlegroups.com, rrichards

Did you, by any chance, improve the documentation of the RPCs that you emulated? If so, could you please point me at it?

 

--

Nancy Anthracite

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/7770bb14-9b50-4adf-a335-639b99cce32an%40googlegroups.com.



rrichards

unread,
Oct 18, 2020, 9:51:49 AM10/18/20
to Hardhats
Yes, the RPCs that were emulated all were fully audited, and are now fully readable, and self-documented.

For example, the Allergies RPCs are emulated here:

The RPC Emulator implements the RPC call with an MVDM createAllergy operation. After creating and updating appropriate information in VISTA, the nodeVISTA manager will dispatch this create event. Unlike the cryptic RPC fields such as GMRAORIG, that event and the object that led to it have easy to understand properties such as enteredBy.

Before (cryptic)


MUMPS-allergy-mc-ORWDAL32-SAVE-ALLERGY-h.png

After:  Emulation (well defined, audited, readable):

EMULATED-allergy-mc-create-allergy-h.png







Nancy Anthracite

unread,
Oct 18, 2020, 1:34:06 PM10/18/20
to hard...@googlegroups.com, rrichards

That is not what I mean by documenting an RPC. More like the data dictionary information about an RPC.

 

--

Nancy Anthracite

 

On Sunday, October 18, 2020 9:51:49 AM EDT rrichards wrote:

Yes, the RPCs that were emulated all were fully audited, and are now fully readable, and self-documented.


For example, the Allergies RPCs are emulated here:

http://vistadataproject.info/demo/Allergies


The RPC Emulator implements the RPC call with an MVDM createAllergy operation. After creating and updating appropriate information in VISTA, the nodeVISTA manager will dispatch this create event. Unlike the cryptic RPC fields such as GMRAORIG, that event and the object that led to it have easy to understand properties such as enteredBy.


Before (cryptic)





After:  Emulation (well defined, audited, readable):



Sam Habiel

unread,
Oct 19, 2020, 8:49:37 AM10/19/20
to hardhats, rrichards
Rafael,

I will reply to you off-line.

--Sam


On Sun, Oct 18, 2020 at 1:34 PM Nancy Anthracite
<nanth...@earthlink.net> wrote:
>
> That is not what I mean by documenting an RPC. More like the data dictionary information about an RPC.
>
>
>
> --
>
> Nancy Anthracite
>
>
>
> On Sunday, October 18, 2020 9:51:49 AM EDT rrichards wrote:
>
> Yes, the RPCs that were emulated all were fully audited, and are now fully readable, and self-documented.
>
>
> For example, the Allergies RPCs are emulated here:
>
> http://vistadataproject.info/demo/Allergies
>
>
> The RPC Emulator implements the RPC call with an MVDM createAllergy operation. After creating and updating appropriate information in VISTA, the nodeVISTA manager will dispatch this create event. Unlike the cryptic RPC fields such as GMRAORIG, that event and the object that led to it have easy to understand properties such as enteredBy.
>
>
> Before (cryptic)
>
>
>
>
>
> After: Emulation (well defined, audited, readable):
>
>
>
>
>
>
>
>
>
>
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/3708939.f77ZKbqU7l%40owl.

K.S. Bhaskar

unread,
Oct 19, 2020, 9:49:04 AM10/19/20
to Hardhats
Rafael –

By emulation, do you mean rewriting the code for an RPC in another language, and having that code call Fileman or other application API?

Regards
– Bhaskar

rtweed

unread,
Oct 23, 2020, 8:05:35 AM10/23/20
to Hardhats
Using the newer mg-dbx interface for Node.js with YottaDB should significantly improve the performance of the RPC JavaScript emulation.

I've written several articles etc on why, if you're going to use a new language to manipulate Global Storage, JavaScript is the most appropriate.  The key is the close similarity of the free-form nature of Globals and JavaScript objects, as embodied in my QEWD-JSdb abstraction.  I've still yet to see any other language that's a better or more natural fit

Rob

rrichards

unread,
Oct 25, 2020, 5:42:06 PM10/25/20
to Hardhats
Thank you Rob.  I had not heard of mg-dbx.   It looks very promising.

What is the relationship of mg-dbx to NodeM? 
Is it a drop-in replacement, or an enhancement?

Any performance comparisons between NodeM and mg-dbx?

Rafael

rtweed

unread,
Oct 26, 2020, 9:34:21 AM10/26/20
to Hardhats
Rafael

I've introduced and discussed mg-dbx in a couple of update presentations, the last one being at the most recent WorldVistA Community meeting - I think it was recorded, but I made the slides available, announced elsewhere in this group.  Here's the link again:



mg-dbx is not related to NodeM. 

Chris's tests have shown about a 4 - 5X performance improvement using mg-dbx.  In order to get this performance improvement (which is all to do with the Google V8 engine's API bottleneck), Chris introduced a new set of APIs for accessing a YottaDB/Cache/IRIS database.

However, mg-dbx is backward-compatible with the APIs supported by NodeM (which in turn are based on the APIs provided by InterSystems' original cache.node and then iris.node interfaces) if you want to use those older APIs - if you do, you don't get the performance benefits though.  

QEWD now uses mg-dbx and its new APIs.  I've described in detail how to use the latest versions of QEWD to implement REST APIs.  It's vastly simpler than it all used to be (and a lot simpler than its precursor EWD.js).  See:  


and, in particular the REST tutorial you'll find in that repo at:



Also check out:


which is a working QEWD/IRIS (or YottaDB) implementation of the so-called RealWorld Conduit reference application, which means it can be compared with all manner of other solutions that use other technologies.

Rob


Nancy Anthracite

unread,
Oct 26, 2020, 1:51:06 PM10/26/20
to hard...@googlegroups.com, rtweed

https://worldvista.org/Conferences/38th_VistA_Community_Meeting

 

See links at Day 3, 10:15 AM.

 

--

Nancy Anthracite

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.

K.S. Bhaskar

unread,
Oct 27, 2020, 10:43:20 AM10/27/20
to Hardhats
4-5× is quite impressive, Rob. What sort of workload generated such a dramatic difference? Thanks.

Regards
– Bhaskar

rtweed

unread,
Oct 27, 2020, 11:13:07 AM10/27/20
to Hardhats
Chris is the person to ask - best place to discuss is in the EWD Google Group and I'm sure he'll respond

Rob

Reply all
Reply to author
Forward
0 new messages