That's quite detailed, and I'm sure it could be pursued, but the effort level at this point is somewhat high, and given that I'm already up against a deadline, there's just no time left to go down that road, as the overall level of experience necessary ends up extending into the Java space, to be able to create the wrapper. Lacking the truly quick and dirty solution, we'll leave well enough alone and leave the task in the ETL. Thanks so much for the well-thought out and detailed explanation, as it might otherwise have been one of those rabbit-holes that you check out, only to find yourself either A) right back where you started, less time spent, or B) so far down that hole you can't find your way back. Thanks again!
No problem. And certainly understood about time constraints ;-). The COM-accessible wrapper is just the cleanest implementation. I am not sure what level of effort is required to get the Java method exposed as a web-service (what Matt Miller suggested), but if that was somewhat easy, then this might be possible as consuming it via SQL CLR could be done in a matter of minutes (i.e. quick and not even dirty :-)) and then you have your ability to call this method.
PS, by "quick and not even dirty" I mean that there are ways to get the SQLCLR side of the web call done correctly and quickly, but maybe not free ;-). I can say, please do NOT use the code shown in either of the links posted by Matt. Nothing against Matt as the REST idea is a good idea, but the SQLCLR code shown in both places is poorly done and should not be on a Production server. I have submitted notes to the SqlSunday.com link.
SQL# - http://www.SQLsharp.com/