Java Reference
In-Depth Information
process service might. The process service doesn't do any independent work: its single func-
tion is to direct the activities of other services, and in so doing, creates something new.
In a more service-oriented example, imagine you are a retail company, and need to write a ser-
vice that your point of sale application will invoke to perform pre-approvals of a customer's
credit during checkout. If the customer is credit-worthy, your salesperson can offer her a dis-
count for filling out your private label credit card application. Your requirements dictate that
you must first check your customer database to determine if the customer already has your
credit card, so the salesperson doesn't offer her something she already has.
If you already have a Customer lookup service that indicates, among other things, whether a
customer has your private label card, that service can perhaps be reused by, and composed in-
to, your CreditCheck service. That assumes that the Customer lookup service was designed for
general purposes and includes all of the relevant data. Likewise, you want the service that per-
forms the basic CreditCheck to do only the credit check, and nothing else. You don't want that
service itself checking the local customer database, even if it is doing so by reusing the exist-
ing customer lookup service. Doing so would dilute the composability of the CreditCheck. In
object-oriented programming, this idea is called “high cohesion”—the design restriction that
dictates that the operations of a class must be very closely related.
It may seem that the customer lookup and the credit check are closely related, but that is de-
batable. Getting customer data is a simple operation, with no apparent business case other than
the fact that you need to know stuff about your customers. Likewise, the act of performing a
credit check says absolutely nothing about whether you must first check your local customer
database to see if the customer already has your card. That is a requirement that a specific IT
project must fulfill, but it is not relevant to the act of checking credit. To conflate these ideas
is to make a category mistake, and limit the reusability and flexibility of your SOA.
So now you are left with three separate ideas and therefore three separate services:
▪ The Customer lookup service that you already had and which you designed to be free of
any particular use case, so it is available for further composition.
▪ The basic credit check service that simply hits the credit bureau with a name and address
and returns a result.
▪ The overall credit check process service as described by the business analyst, which does
no work itself other than coordinating the activities of the worker (member) services.
It is the job of this third composing service to coordinate the activities in such a way that the
business requirements are fulfilled. That is, it is the job of the workflow to know that you want
to check if the customer already has a card before wasting cycles invoking the credit check
