Thanks Jeremy,
These are very good overviews. I guess I still need to look at the code.
I’m obsessed with understanding the difference between doing work in Mule (or an ESB), vs doing it in Java.
I really want to know what the ESB is doing for me.
My whole issue revolves around:
Any abstraction worth its salt should have
[1] a direct java DAO implementation (In this case, the client program has all the DAO jars built in. High performance, but tight coupling. The server uses
this to actually respond to requests.)
[2] A “remoting” client. (The client has a tiny jar that contains a Interface to the remote service. The client makes natural java calls (the same as in
#1), but instead of doing direct data base accesses, the client is actually invoking a proxy that encapsulates all the networking details. The client jar is either supplied by the service implementer, or is generated from a WSDL/interface-definition-language
specification.
[3] By hand construction of the web service invocation. (The client code shows some evidence of knowledge of how the connection to the remote service is
being made.)
With this in mind, I wonder if ESP steps that look like “Adapt XYZ to needs of Registry X” might be activity that should be hidden by remoting api’s.
For example,
I use a TermMapperDAO in some of the stuff I do.
My “map all terms in HL7 message” code, then, does a loop over the segments, and when it finds something to map, it invokes a method on the mapper. My “orchestration
code” does not show evidence of adaption, and just feels like straight up Java, and not an ESB “network flow.”
:++++++++++++++++++++++
TermMapperDAO mapper = …. << this is where “wiring” takes place. Use Spring or better here >>
foreach segment s in Message
if( s.tag = “OBX” )
CE ce = s.getCode()
CE target_code = mapper.map(ce)
:--------------------
What I am getting at is that if I can use a registry the way I use the “mapper” object – that is, with natural Java calls – then it doesn’t feel like the ESB
is doing work. It is fine for the ESB to do routing, and allow new clients to splice in their interest in existing message flows.
I’m just trying to come to grips with that kind of “orchestration”, vs, the normal processing that goes on when handling messages.
I need to look at the mule code.
— Mark
On Behalf Of Jeremy Keiper…
···
Mark, have you seen this? https://wiki.ohie.org/display/documents/RHIE+Workflows
Each of those is a pretty descriptive workflow that looks like it matches up with the Mule flows in OpenHIM. Is this what you were looking for from Shahid? I understand if you want an exact rendering from the actual code, but I bet these
workflows were written from the logic that Hannes and Ryan used.
Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support
–
You received this message because you are subscribed to the Google Groups “OpenHIE RHEA Sandbox” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ohie-sandbox+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.