Java Reference
In-Depth Information
and discover services. You'll hear more about this later, in section 4.2; for now, let's
continue to look at services in general.
You may be thinking that a Java method call in the same process can't possibly be a
service, because it doesn't involve a remote connection or a distributed system. In real-
ity, as you'll see throughout this chapter, services do
not
have to be remote, and there
are many benefits to using a service-oriented approach in a purely local application.
Components vs. services
When people discuss services, they often talk about components in the same con-
text, so it's useful to consider how services and components compare and overlap.
Service-oriented design and component-oriented design are extremely complementa-
ry. The key semantic difference between these two approaches is as follows:
■
In a component-oriented approach, the architect focuses on the provider's view.
■
In a service-oriented approach, the architect focuses on the consumer's view.
Typically, in a component-oriented approach, the architect is focused on ensuring that
the component they provide is packaged in such a way that it makes their life easier.
You know that when it comes to packaging and deploying Java code, the code will
often be used in a range of different scenarios. For example, a stock-quote program
can be deployed as a console, GUI, or web application by combining different compo-
nents. A component design approach tries to make it as easy as possible for the ar-
chitect to select what functionality they want to deploy without hardcoding this into
their application.
This contrasts with a service-oriented approach, where the architect is focused on
supplying a function or set of functions to consumers who typically have little interest
in how the internals of the individual component are constructed, but have specific
requirements for how they want the function to behave. Examples include acid trans-
actions, low latency, and encrypted data.
You'll see in chapters 11 and 12 that component-oriented approaches can easily be
built on top of the OSGi services model. With this in mind, let's continue our introduc-
tion to services by considering the benefits of services.
4.1.2
Why use services?
The main drive behind using services is to get others to do work on your behalf, rather
than attempting to do everything yourself. This idea of delegation fits in well with many
object-oriented design techniques, such as Class-Responsibility-Collaboration (
CRC
)
cards.
1
CRC
cards are a role-playing device used by development teams to think about
what classes they need, as well as which class will be responsible for which piece of work
and how the various classes should collaborate to get work done.
2
Techniques like
CRC
1
Kent Beck and Ward Cunningham, “A Laboratory for Teaching Object-Oriented Thinking,”
http://c2.com/
2
Don Wells, “Design a Simulator for the Coffee Maker,”
www.extremeprogramming.org/example/crcsim.html
.
