Java Reference
In-Depth Information
pear to be business objects. But there is always the matter of perspective. At a bank, the idea
of currency might be considerably more detailed in its definition than it is at a pet food store,
making it a kind of business object to the bank.
NOTE
There are always exceptions to the rule. The idea here is to think in terms of services exchanging
business documents, rather than accepting lists of simple values.
You probably don't need an SOA if you don't have a business of some size, or at least of some
length of history. While programmers might enjoy writing a video game for their own person-
al use, no one builds an SOA out in the garage on Saturday afternoons. If you're talking about
an SOA, you're talking about a business of some measure. And your SOA will realize its po-
tential ROI (return on investment) if its constituent services operate at the appropriate level of
granularity in order to maximize their reuse. Of course, this begs the question what is meant
by “appropriate level.” That will depend on the business processes that define your services,
and what related processes might be able to reuse them.
I must stress that this guideline is open to a wide variety of interpretations, and is presented as
a starting point so that you can make some distinctions. You want to avoid being so vague that
you do not have enough to work with. Indeed, there are utility or functional services that op-
erate in the realm of technology alone; these are described in
Identifying Service Candidates
.
Decoratable
This refers to the idea that you must be able to decorate the service operation in some way in
order to provide for functional and non-functional requirements. It is this aspect that elevates
the service to something meaningful with an SOA.
If you are using SOAP, a variety of WS-* specifications (such as WS-ReliableMessaging or
WS-SecureConversation) add capabilities to your service that do not impact the core busi-
ness functionality, but make your service adaptable for use within an SOA. The ability to add
HTTP headers, for example, is one way of decorating a REST-based service implementation.
EJBs make the cut because, while the mechanism is not based on WS-* standards, intercept-
ors do allow for decoration of like functionality.
The point here is that you want to be able to provision your SOA, and by necessity its con-
stituent services, with technical means of governance (which we will discuss later). You want
to be able to include policies at runtime that augment how the service can be used. The ability
to interact securely, to allow for transactional operations, and, in some cases, to accept monit-
oring instrumentation are non-functional requirements that bridge the gap between a theoret-
ically pure implementation of your Invoice Processing service and the real world that involves
