Java Reference
In-Depth Information
8. Does it offer business value? Is there an existing service commodity that already performs
this function?
9. Is the proposed service the right level of granularity? (If it is very fine-grained, this will
weaken the interface aspect of the contract, shrink the possibility of reuse, and promote
undue chattiness. If it is very coarse-grained, it could be a candidate for a process service
that decomposes into other entity or functional services.)
10. Would making this function a service allow it to be composable? That is, can it participate
as a seamless blackbox with other services behind a unifying contract (like an orchestra-
tion)? Or does it represent just an isolated function, with little relation to other system
components?
11. Does the candidate represent an idea with an identifiable life cycle? Can the business
define the interface?
12. Is it advantageous if the software can be discovered dynamically (as from a registry/re-
pository)?
13. Does it present an opportunity to aid in the goal of providing a “single version of the
truth”?
14. Depending on the implementation, would the benefit derived from using XML to repres-
ent your data outweigh the performance hit for marshaling and unmarshaling to and from
XML? Is human-readability of the documents exchanged a factor?
15. Would implementing this as a service lower the cost of future integration projects? Would
it facilitate new products or business services?
Again, these are just points to consider. There are no hard-and-fast rules in this area. The idea
is to make sure that you don't run out and make everything into a service. I know of compan-
ies that did this years ago; they now have more than 5,000 “services” and they're in a lot of
pain. Just use this as a guideline.
Discussion
Not everything in your enterprise can or should be made a service. Do not fall into the “tool
trap”: if you have a hammer, everything looks like a nail. There are many real and important
problems that services and SOA simply do not address. Once you have established SOA as a
goal within your organization, it may be tempting to declare that every new project coming
down the pike should be written as a service. This is not going to aid in the creation of a func-
tioning SOA that gives you a real return on investment in the long run. It will, however, start
the process of building out Just a Bunch of Web Services, the anti-pattern mentioned earlier.
