Re: method signature design question
From: Filip Larsen (filip.larsen_at_nospam.dk)
Date: Sun, 18 Jan 2004 17:45:59 +0100
> Having real-world experience implementing credit card systems, I can
> assure you that this is one of the more complex issues.
I fully agree with most of your post.
When I worked with implementing prepaid services for GSM, the system
design of prepaid and credit card validation were often more complex and
time-consuming than the "pure" technical stuff, mainly because there
were so many colliding interests: response-time, through-put,
availability, security, local law, provider policies, etc.
> In addition
> to some of the other validation failures I mentioned earlier you can
> also run into "system not available" and even "take card" situations.
Yes, that is also why I would model the API to support the business
process of credit card validation in general. I consider the verify
method the original poster mentions to be a validation engine or
service, doing all the distributed computing to validate a card, and
then some higher level code then adapt the results to fit the correct
business context (like your example with an ATM/POS versus on-line
> But how much information do you return to the customer? Do you let
> them know that they're over their credit limit? Do you really want
> to return the results of AVS (Address Validation System)? Certainly
> not! scammers seek out such "open" systems to test card numbers and
If you are worried that "client code" unintentionally might use a
validation service in a way that breaks the business process, then it
could be done following the usual Java service pattern where you
configure a factory and then get from it a validation instance on which
you then call verify. This way a number business process variations can
be configured into one service. For instance, the detail of information
passed back could be reduced appropriately to validation services called
in a "on-line" or "self-service" configuration so that caller code do
not have to do any filtering in that regard.
> Besides which, the requirements are different for the on-line trans-
> action and the customer service situations. In the latter case you
> might want the operator to see the failure message and tactfully
> deal with the customer on the line. The on-line transaction should
> fail, the failure reason should be logged, and the customer told,
> politely, that the transaction could not be completed. They should
> also be provided with the customer service telephone number.
> Hence my suggestion. It handles both situations as well as others
> which might be encountered in the future. As always, YMMV.
Assuming you refer to signature #3 in the original post I must say that
I do not agree in the following sense: an implementation of a business
process should only use exceptions for variations that are truely
exceptional, preferably for scenarios not specified in the process at
If, for instance, the validation process is modelled as a simple
"atomic" test with a yes/no answer, then the business result is boolean
and the implementation would then have to use exceptions to signal any
of the "normal" exceptions that occur in distributed systems. Throwing
an exception, however, carries no meaning for the business process, so a
caller cannot in general conclude yes or no on an exception.
Oh well, I can see I am heading out into an age old discussion :)
-- Filip Larsen