Java Reference
In-Depth Information
later. To put it in clothing terms, you want it nice and stretchy to give your application
room to breathe.
A good service contract clearly and cleanly defines the boundary between major
components and helps with development and maintenance. After the contract is
defined, you can work on implementing service providers and consumers in parallel
to reduce development time, and you can use scripted or mock services to perform
early testing of key requirements. Contracts are good news for everyone—but how do
you define one in Java?
MORE EMPHASIS ON INTERFACES
Java interfaces can form part of a service con-
tract. They list the various methods that
make up a service along with expected
parameters and return types. After they're
defined, you can begin programming
against the agreed-on set of interfaces with-
out having to wait for others to finish their
implementations (see figure 4.4). Interfaces
also have several advantages over concrete
classes. A Java class can implement several
interfaces, whereas it can only extend one
concrete class. This is essential if you want flexibility over how you implement related
services. Interfaces also provide a higher level of encapsulation because you're forced
to put logic and state in the implementing class, not the interface.
You could stop at this point, assemble your final application by creating the various
components with new , and wire their dependencies manually. Or you could use a
dependency injection framework to do the construction and wiring for you. If you did,
you'd have a pluggable application and all the benefits it entails, but you'd also miss out
on two other benefits of a service-oriented approach: rich metadata and the ability to
switch between implementations at execution time in response to events.
Right leg team
Body team
Left leg team
Figure 4.4 Programming to interfaces means
teams can work in parallel.
CLEAR DESCRIPTIONS OF DEPENDENCIES
Interfaces alone can't easily capture certain characteristics of a service, such as the
quality of a particular implementation or configuration settings like supported
locales. Such details are often best recorded as metadata alongside the service inter-
face, and to do this you need some kind of framework. Semantics , which describe what
a service does, are also hard to capture. Simple semantics like pre- and post-conditions
can be recorded using metadata or may even be enforced by the service framework.
Other semantics can only be properly described in documentation, but even here
metadata can help provide a link to the relevant information.
Think about your current application: what characteristics may you want to record
outside of classes and interfaces? To get you started, table 4.1 describes some charac-
teristics from real-world services that could be recorded as metadata.
Search WWH ::




Custom Search