This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Run-time design with line-of-business components
Posted by Alex on 01 Mar 1999, 12:12 PM
> Is there something else that you envision for which these
> solutions are unsatisfactory?
If I may, I'd like to jump in with some additional concerns that tie into
We have reached an impasse when designing our credit approval
portion when we recognized the runtime vs. the strong typing dilemma.
We are struggling with the following rationale: today, we can build
our own little CreditApproval class that will perform some rudimentary
processing by accepting pertinent customer information. We are aware, though,
that there are much more robust and more reliable products on the market
that will do the same thing. So, we can evaluate them, purchase them, and
incorporate the best service into our application (the quality of credit approval
processing is of paramount importance to our business). However, one can only expect
that the quality and the affordability of such services will only improve in the future.
Are we to leave things semi-open then, so that we can purchase a better component later
on, and re-wire it to the existing applications?
Or, is it feasible to think along the lines of building our applications in such a way
that they are enabled to interrogate any component we throw at them in order to find out
how to acquire that components credit approval services? Our rationale is that, for a vertical
type of the line-of-business components, the interface will be fairly stable (for instance,
a credit approval interface comes with little, or no surprises; there are always standard data
elements that the class needs in order to perform its work).
This is obviously a situation where the business will benefit from building a generic application
that is capable of growing with new classes that may be "thrown" at it.