Javascript- interpreted or compiled to bytecode?

[jimkski]

Hi All-

I have a question about Mirth's use of JavaScript. I've never used the scripting features in Java so I'm learning as I go here. Reading the Java Scripting Programmers Guide (JSE6) I came across the following caveat:

"A few components have been excluded due to footprint and security reasons:

JavaScript-to-bytecode compilation (also called "optimizer"). This feature depends on a class generation library. The removal of this feature means that JavaScript will always be interpreted. The removal of this feature does not affect script execution because the optimizer is transparent."

Which made me wonder if that meant all the JavaScript code I'd be writing in Mirth is actually just running as interpreted JavaScript and never being compiled to bytecode. Can anyone clarify this?

I know that a couple Mirth competitors like Rhapsody and Chameleon actually generate C++ code which is then compiled before deployment. From the spec. sheets for the Mirth appliances you're stating max 75/mps throughput. I wonder what the number is when you're doing sophisticated, real world transforms and validations on the messages?

Is there an out available to us? Can we pass the encoded message to a compiled Java class? Would that encoded message be available as an Object structure? If so is there documentation for that?

Thanks,

Jim

[chrisl]

Re:Javascript- interpreted or compiled to bytecode?

Jim,

Mirth's JavaScript is pre-compiled and cached, however Java might internally still have to run an interpreter. One thing to note is that you aren't stuck using JavaScript! Any transformer or filter can:

1. Execute an external system program (and pass data back and forth) - this can be compiled C code, etc.
2. Execute compiled Java code (drop the JAR into the /lib/custom folder) and reference from Javascript using Packages.<class-path>

Let us know if that is sufficient!
-Chris

[jimkski]

Re:Javascript- interpreted or compiled to bytecode

Hi Chris--

That's great to hear. I've been using HAPI for 3 years now and have some legacy code that performs complete mappings between 2.3.z to 2.3.1 messages which fully leverages the internal representations of the messages available in HAPI to minimize the amount of code involved in the transform. I'd love to be able to use that code in Mirth.

So given what you've said, if I'm using Mirth with the HAPI API, if I pass the message I receive in the transformer to an external Java class will that class be receiving the HAPI object structure or something else?

Thanks for the quick responses.

Post edited by: jimkski, at: 07/25/2007 09:50

Post edited by: jimkski, at: 07/25/2007 09:50

[chrisl]

Re:Javascript- interpreted or compiled to bytecode

Jim,

You do not have access to the HAPI message in Mirth (by default HAPI isn't used unless you turn on strict parser).

You have access to the original HL7 message (message.getRawData()) and the XML representation of the message (message.getTransformedData()).

If you are using the Strict Parser, the XML representation of the message is the HAPI formatted XML. If your Java classes need HAPI "message" objects, you can invoke the HAPI converter in the Javascript (Packages.<hapi class>) and pass the resulting object to your code.

-Chris

[jimkski]

Re:Javascript- interpreted or compiled to bytecode

Ok I understand- That would involve a second parse of the message so probably not very good for performance. It would be a very compelling feature if you could get a hold of the objects instead of the strings. Is that something you'd ever consider?

For me, besides being able to reuse existing HAPI transforms I could also test transforms independent of the whole Mirth setup in JUnit tests. One of the things that worries me about buying into things like Mirth or Rhapsody is the tie in with the tool's UI in order to get stuff done. If I have to run the entire stack to test my transforms or validations then I'm not really unit testing anymore.

I definitely think that the Mirth UI is nice for what it is but I doubt that I'd ever really want to write something particularly complicated using it. It's good for casual users with basic transforms to implement but for coders trying to solve difficult problems it's probably not enough. I'd rather use Eclipse or IntelliJ or Netbeans to write the code and then plug it into Mirth. If you had a capability like that it'd put you head and shoulders above tools like Rhapsody which sticks its users with a monolithic dev environment that appears to model itself after MS Visual Studio circa 1996.

I hope this comes across as constructive criticism and not a complaint. Mirth is definitely showing a lot of promise and I'm very excited to see where you're going to take this platform next.

[chrisl]

Re:Javascript- interpreted or compiled to bytecode

Understood - and we appreciate the feedback!

A few things - we don't pass the message object around just because it's too "heavy" and proprietary. Mirth is built so that once messages are receiving, everything is treated as XML. This keeps the platform open for additional formats and datatypes (i.e. DICOM, NCPDP)

One thing we found during our performance testing was that HAPI itself caused major slowdowns and memory issues. The simple serialization/desierialization between the ER7 data and HAPI objects was the main bottleneck. To solve this we use our own "home-grown" parser/encoder that is significantly faster. It doesn't give you the full object model, but it gives you an accurate XML representation of your message - across versions (so unlike HAPI, a mapping for a 2.1 message will usually work with a 2.4).

That being said, HAPI is still great for validation and conformance checking.

What kind of integration would you like to see with a dev environment? Mirth 1.6 is coming very shortly and includes a very nice pluggable architecture, so it should be simple to extend the platform for use in other environments.

-Chris

[jimkski]

Re:Javascript- interpreted or compiled to bytecode

Hi Chris-

I took some time to think about your question and after a few false starts realized that the thing I was wrestling with is question of tooling vs open API design. When I say tooling I mean IDE plugins that tie into Mirth either by replicating Mirth's mapper UI functionality in my IDE (eg. the drag n drop message mapper) or that facilitate management of Mirth through JMX or similar. When I say open API design I mean a system whose architecture follows things like the Law of Demeter so that it's easy to plug components into the system and by extension work on components in isolation from the whole system.

That said what I'd like to see *isn't* tight integration between Mirth and my IDE via plugins but an API which lends itself to letting me write and test components without a Mirth server present. Having the Mirth jars in my IDE's path is fine, just so long as a Mirth server process isn't required. (I have to admit, that I haven't dug into your code base like I have HAPI so I don't know your design yet so if what I'm about to say is just stating the facts are they are in Mirth please just bear with me and then point me to the docs or the code samples.)

One way to achieve the capability I'm envisioning would be if Mirth used dependency injection to associate transformers, validators, and filters with channels. Each of those items would have no specific dependencies on the Mirth stack that couldn't be mocked up and injected or passed in as arguments. This would free me up to write all the code outside of Mirth Administrator and write suites of unit tests to run against each. Once I was satisfied with how the code worked I could plug the build products into the Mirth server via a web service call or a file upload in the administrator UI.

One thing I'm not entirely sold on is the decision to pass the message around as a string (at least that's how I interpreted your response, so correct me if I'm wrong). I don't see how needing to parse a DOM tree for each step in the process is a lighter weight operation than doing it once and then passing an object tree around. From the argument that it makes it easier to support multiple formats you might consider using some kind of AbstractMessage root class as the argument passed into and out of objects like transformers so that the API level remains message encoding agnostic yet all the richness you get from an object model remains. Plus, coding to an object model gives you much better compile time checking than walking a DOM ever could.