I didn’t have the privilege of attending Rob’s AWG presentation but I did watch the recording and catch up on the blog postings – yes, including the openMDWS cookbook.
After digesting the excellent openMDWS discussion, along with an equally excellent Thanksgiving meal, I’m finding that the key architectural goals of openMDWS and MDWS aren’t so different after all. That’s worth exploring…
The openMDWS architecture incorporates core re-usable functions, full variable scoping, no leakage of VistA variables and wrapping code in a function. It’s very well explained in the openMDWS cookbook blog post. I’m all for it – sounds great. And familiar!
Since the inception of the MDWS project on OSEHRA we have worked hard to follow precisely the same architectural principles. From the get-go, the MDWS team specifically chose to use the refactored scheduling codebase for the same reasons Rob has articulated. The refactored scheduling codebase exposes a mumps API of re-usable functions with full variable scoping, etc. (Kudos goes to the EHR refactoring group for taking it one step further by abstracting a data access layer and documenting the API.) Once the mumps API is exposed you can wrap openMDWS, MDWS, jMeadows, closedMDWS, and whatever you like around it.
So really there aren’t core architectural differences in the design principles of openMDWS and MDWS.
They do differ in implementation, however. MDWS uses the RPC broker as its intermediary pipeline to connect and query a VistA instance, which by its very nature is stateful. So to address the problem and quickly summarize a lot of my thinking I’ll pose the following question: Is it easier to make an existing stateless service stateful, or to make an existing stateful service stateless? Now mix in a little bit of the RPC broker implementation details to the equation. My opinion: It’s easier to make an existing stateful service stateless. Which, as you can imagine, is what we did for the MDWS scheduling effort.
MDWS also differs by its use of the .NET framework to create consumable services (SOAP, REST, WebSockets, and any other imaginative endpoint you can think of). For the MDWS scheduling effort we aren’t focused entirely on exposing it as a SOAP service.
A .NET implementation of MDWS won’t work for individuals who don’t run a Microsoft OS or an open source .NET development framework. That’s a fact, but it’s one that, given enough community interest in converging on a common set of web services, we might address by moving off the .NET platform.
Scalability has been described as a problem yet it is unknown to me in the VA using MDWS or jMeadows.
MDWS can feasibly read and write to any portion of VistA. I say feasibly because the technical limitation to read or write from VistA is not a MDWS limitation but a limitation of the VistA system itself. The VistA scheduling package is an example that depicts the VA’s inability to modernize due to numerous factors such as technical debt. VistA’s scheduling technical debt can be described as a lack of loosely coupled routines separating business logic and data access from the traditional character user interface. It can also be described as a lack of a mumps API to allow other systems or software (MDWS, openMDWS) to interoperate. Therefore to successfully read and write to VistA from an outside system or software, a mumps API must be exposed, following the previously described architectural principles such as re-usable functions and full variable scoping. VA is addressing a portions of these issues through the OSEHRA EHR refactoring services contract to RGI (now PWC).
MDWS can be enhanced by anyone. I recommend developers’ fork the OSEHRA MDWS projects on GitHub. Commit their changes, document the enhancement and issue a GitHub pull request. The MDWS team will gladly review the proposed changes.
And lastly, thinking about community convergence on common web services… it may not make sense for VA to adopt M-based services when they could more easily use web services provided by their InterSystems licenses. And for folks outside VA, who may be running GT.M, it’s not clear that building M-based services offers any special advantage. A set of web services developed on a non-M platform seems to allow the broadest adoption by users inside and outside VA. If we’re all interested in enabling the largest set of application developers to develop VistA-based software, isn’t that all that matters?