William Cox wrote: > Feel free to ask any questions you may have. Thanks to both of you for a nicely done presentation.
A couple of follow-up questions: 1. Did either of you attempt to unit test your Java code? Presumably, if you structure things well, there should be minimal need for this. Your inlined Java code gets reduced down to wrapper/glue code, and that gets coverage through traditional Perl-driven unit tests or system test. 2. What alternatives to Inline did you explore for making the Perl-Java connection? One of you made reference to preferring Inline over using system() to call a command line Java tool, which makes sense, but I heard no mention of RPC options. An obvious solution (as a non-Java developer) that comes to mind is to use servlets. This gives you a nice clean separation between the Perl and Java code, allowing each domain to be handled by separate programmers and unit tests. (I've worked on the Perl side of teams doing Perl-Java servlets interfacing.) The downside to an RPC mechanism is that you'll need multiple processes, resulting in a heavier weight, slower solution. (Though you already discussed optimizing to minimize Perl-Java transitions, and it sounded like some of he Inline options used multiple processes.) Creating the Java side for an RPC solution may be more work, if you don't know Java or don't have a Java programmer on your team to cover that side. Both RPC and Inline require some work on the Perl side to deal with the transition. I suspect the servlet approach outnumbers Inline for inter-language interfacing these days. That's what SOA is all about. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
